On 09/12/06, Pavel Roskin <proski@gnu.org> wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html