Settings chapter
pmme opened this issue · 16 comments
I've opened this issue for questions I have about the GitExt settings while updating the documentation on that chapter.
Q1: I have inquired from @jbialobr regarding changing settings while the radio button "Effective" is selected. Janusz replied with the following including an example:
GitExt looks for the lowest, unset level on which the setting can be set to become effective when a read is performed. If there is no such level, then the Local one is chosen. The Distributed level isn't considered here, because it is treated specially and settings can be set on this level only by a direct assignment.
The levels come in the order (from the lowest to the highest): Global for all repositories, Distributed with the current repository, Local for the current repository.
Settings that are shared with git, like "user name" don't have the "Distributed with the current repository" level.
To give an example, let's say you want to set your user name. When you type it on the Effective level, then three cases may occur:
- The setting isn't set on any level. In this case the setting will be set on the Global level.
- The setting is set on the Global level and isn't set on the Local level. In this case the setting will be set on the Local level.
- The setting is set on the Local level (no matter if there is an entry for the global level). In this case the setting will overwrite the setting on the Local level.
In my testing, case 2 did not work as stated. When I changed my email or user name in the Git Config while "Effective" was selected, the change was saved to the global config file in my user folder and not in the local .git\config file.
I wonder, is it actually working as intended or if it is malfunctioning?
Assuming that it is working as intended, then could the behaviour be summarised instead as:
"GitExt looks for the highest level on which the setting is currently set"
and therefore, in my test, the user name and email were global settings with no local setting so changing the setting while on the "Effective" level saved to the global settings.
Q2: Could someone experienced with TeamCity please explain the Git Extensions "Build Id Filter" setting in the "Build server integration" page?
Assuming that it is working as intended, then could the behaviour be summarised instead as:
"GitExt looks for the highest level on which the setting is currently set"
It is working correctly in your case, and my description was incorrect. The description you gave is correct, and if there is no such level, the Global one is chosen.
Q2: Could someone experienced with TeamCity please explain the Git Extensions "Build Id Filter" setting in the "Build server integration" page?
@pmme For example, you have build project named "All my builds". It includes build configuration that compiles everything and runs unit tests with Build configuration ID = bt01 and build configuration publishing results somewhere or builds documentation with Build configuration ID = bt02. bt02 runs after bt01. You'll see the results of bt02 build in GE summary, becouse it is last build.
But if you want to see only b01 results, you can configure "Build Id Filter" as (bt01)
Thanks Janusz and Irina. That all makes sense.
I have just corrected the behavior of skipping the Distributed level when assignment comes from the Effective page. But while doing that, I met a difficulty:
To unset a setting on the Effective page, I have to unset the setting at each level, but making changes to the Distributed level is forbidden by definition. If I don't unset the setting at the Distributed level, the effective value will remain set as it is computed with use of the Distributed level. This may be confusing to the user because he expected the setting to be effectively unset. I wonder then if there should be such a restriction for the Distributed level. By introducing this restriction I wanted to prevent from making unintended changes to the Distributed level, which can be committed then by accident.
From the other hand every change committed to the repository can be easily reverted.
Should I drop this restriction? What do you think, Paul?
/cc @KindDragon
In general my opinion is that anything that is overly difficult to describe in the help should have the behaviour changed to make the usage obvious.
I like the fact that currently the user is protected from making an accidental change that could be accidentally included in a commit if they use "Stage all" and have many files. Accidental changes made to non-distributed settings have less chance of affecting others.
In my opinion the easiest to implement and easiest to describe behaviour would be that the user cannot change settings from the Effective level at all, that the Effective level is used only to view the settings that are "in effect" and that changes must be made by switching to the desired local / distributed / global page.
However, that is a substantial change to the current implementation.
I've not dealt much with the PuTTY/SSH settings of Git and Git Ext. So far these things work as they're intended and I have had no advanced requirements, so currently I have limited knowledge of their configuration options.
Q3: Does the GitExt setting for the credential helper always set only the global credential.helper Git config variable?
Can Git have a local credential.helper config?
@KindDragon Do you know the answers for these questions?
@KindDragon Do you know the answers for these questions?
Ok. I'll try
Q3: Does the GitExt setting for the credential helper always set only the global credential.helper Git config variable?
GitExt always set global credential.helper
Can Git have a local credential.helper config?
Yes, but we do not support this script
I see numerous raised issues for gitextensions relating to the credential helper setting. Ideally I can document it sufficiently that even new GitExt users can fix configuration and installation problems that arise. Given that I have limited experience with it I may have a few questions :)
Q4: Is git-credential-winstore always set as a default in Git Ext, or did I simply choose something during my installation? Presumably it would be an inappropriate setting for Mac users.
I would link the Git help page here but it's missing from git-scm.com. The closest I can get is http://git-scm.com/docs/gitcredentials but really I wanted the link titled "credentials API" at the bottom under the section "CUSTOM HELPERS". You should find that the api-credentials.html page does exist in your local installation of Git.
An excerpt from the page:
The string is transformed by Git into a command to be executed using these rules:
- If the helper string begins with "!", it is considered a shell snippet, and everything after the "!" becomes the command.
- Otherwise, if the helper string begins with an absolute path, the verbatim helper string becomes the command.
- Otherwise, the string "git credential-" is prepended to the helper string, and the result becomes the command.
I see that my GitExt setting for git-credential-winstore begins with !, which means that it is a shell snippet. I have some questions about what alternatives would be valid and why one was chosen over another.
The naming of git-credentials-winstore.exe appears to be designed so that the setting could simply be "winstore" (option 3 from above) and Git would automatically add "git-credentials-" to the start, but GitExt doesn't use this simple setting. However, this would require git-credentials-winstore.exe to be on the path.
Q5: Is the reason GitExt doesn't use simply "winstore" to ensure that the setting works regardless of the path?
It appears that Git Extensions could use an absolute path (option 2 from above). It appears that some of the raised issues for gitextensions relate to problems with escaped quotations (") in the shell snippet. I wonder why the shell snippet format was used in preference to (what appears to be) the slightly simpler absolute path.
Q6: Is there someone that knows why a shell snippet was used instead of an absolute path?
I hope to describe this setting in reasonable detail, as it seems to have caused a bit of trouble for some people, but I don't want to introduce anything incorrect or inappropriate about it.
@KindDragon Would you take these questions as well? I've never used the credential helper nor have implemented any piece of GitExt related to it.
Q4: Is git-credential-winstore always set as a default in Git Ext.
Old GitExt version install git-credential-winstore by default.
..., or did I simply choose something during my installation? Presumably it would be an inappropriate setting for Mac users.
GitExt 2.48 install it on if you select it in Complete installer. Mac/Linux users doesn't have installer for GitExt.
Q5: Is the reason GitExt doesn't use simply "winstore" to ensure that the setting works regardless of the path?
Yes, you right
I wonder why the shell snippet format was used in preference to (what appears to be) the slightly simpler absolute path.
Q6: Is there someone that knows why a shell snippet was used instead of an absolute path?
We use the same format as proposed in gitcredentialstore source code https://gitcredentialstore.codeplex.com/
Working on the Plugins section:
I see that the "Check for updates" plugin and settings are missing and "Check for updates" now appears on the Help menu.
Q7: Did "Check for updates" change from a plugin to a core feature?
"Periodic background fetch" includes a checkbox "Fetch all submodules". I have not yet used submodules in Git. I note that there is the concept of Updating submodules, which appears as a post-checkout dialog.
Q8: What is fetching a submodule as opposed to updating a submodule?
I just realised that I have not looked at the Git documentation. I'll leave this question here, but feel free to direct me there if this is already clearly explained in Git's reference manual, and I will read about it there.
There is a plugin "Create Stash Pull Request".
Q9: Is "Stash" a Git repository host similar to GitHub?
When I direct a web browser to stash.com it appears to be an unused domain name.
Q7: Yes, it did.
Q8: Updating a submodule (a git operation) is to make the submodule repo being up to date and then to checkout the commit specified in the index of the containing repository. Fetching submodules (a GitExt operation) is executing git fetch --all for each submodule recursively. Fetching doesn't perform a checkout action and it fetches from all the remotes specified for the submodule, as opposed to Updating, which fetches changes only from the remote specified in the .gitmodules of the containing repository.
Q9: This is a plugin for the Atlassian Stash: https://www.atlassian.com/software/stash
Thanks guys.
I have finished writing the new content for this update but I see on readthedocs that there must be some error because at least one table is not showing (SSH settings)!
Once that's finished I should have it ready for a PR.
My intention is to squash my progress commits and pull+rebase, since "latest" has progressed one commit from where I started.