On 09/12/06, Pavel Roskin <proski@xxxxxxx> wrote:
Sorry, I was unlucky to pick your address from setup.py, where it's incorrect (gmail.org, not gmail.com), so I'm sending you another copy.
Thanks for spotting this.
One approach is to leave the default remote selection completely to git. The downside is that StGIT prints the remote it's pulling from. Now StGIT will have to print common words that it's pulling something. Or maybe it shouldn't print anything?
Yann started a thread on this but I didn't find the time to look at this properly. He's idea was to store the remote branch information in the StGIT metadata but I'd like to leave this for GIT to deal with. The StGIT UI can probably be modified to display something useful but I don't see a problem if it doesn't.
The other approach is to calculate the default remote in StGIT. This would allow StGIT to tell the user where it's pulling from. However, I had to introduce a function that ignores errors except there is any output on stderr. This is because git-repo-config returns error code 1 if it cannot find the key. Maybe git-repo-config should have an option not to fail in this case? Perhaps a default value to return?
With the recent changes, StGIT shares the config files with GIT and it has direct access to git settings without the need to use git-repo-config. Just use "config.has_key" and "config.get_option". Maybe a combination of your two options - StGIT could try to get the default branch and, if there isn't any in the config files, just invoke git-pull without any argument (and display something like "pulling from default"). -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html