Re: RFC PATCH: support for default remote in StGIT

From: Yann Dirson <ydirson@altern.org>
Date: Dec 9, 2006, 13:36 UTC
Message-ID: <20061209133618.GB17132@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <1165656205.2816.47.camel@portland.localdomain>

Hi Pavel,

This is quite related to the subject of the "Handling of branches in stgit" thread I launched recently (Nov 30th).

On Sat, Dec 09, 2006 at 04:23:25AM -0500, Pavel Roskin wrote:

> It's very important for me to have default remote support in StGIT.  I'm
> trying to track different Linux branches, and I don't want to remember
> what branch I'm on when I run "stg pull".

Right, that's the main problem with the current implementation.

> 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?

It could just print a generic message and let GIT print out the details.

> Also, git-pull doesn't allow to specify the refspec without the remote.
> This limitation seems artificial to me, but we have to pass this
> limitation to the StGIT users.

In which situtation do you need to pass a refspec ? I thought all necessary refspecs should already be part of a remote's definition.

> The positive side if that StGIT is completely unaware of the word
> "origin", and any changes in git handling of the default remote will
> propagate to StGIT immediately.

Indeed.

> The other approach is to calculate the default remote in StGIT.  This
> would allow StGIT to tell the user where it's pulling from.

Doing so would probably require to teach StGIT about every new way of fetching a branch (we already have 3 ways, as outlined in my initial mail). OTOH, it may be the only way to present the user with a uniform way of working, independently of the way we update the parent branch.

Indeed, we may just want to distinguish whether the parent branch is a remote one or not. Then if it's a remote one, git-fetch already has enough info to do its work updating the parent branch (whether using .git/remotes or .git/branches). If it's not a remote branch, there's just nothing to do at this step.

Then, we just have to "pop -a" and move the stack base, without relying on "pull". That would also transparently give support for branching off a non-forwarding branch (like git's "next" and "pu", or like any stgit managed branch). Would anyone miss the "git-pull" call ?

Best regards,