Re: Handling of branches in stgit

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Dec 1, 2006, 12:42 UTC
Message-ID: <b0943d9e0612010442gf7bf2ccr8995967403788fe7@mail.gmail.com>
In-Reply-To: <20061130000038.GA13324@nan92-1-81-57-214-146.fbx.proxad.net>

On 30/11/06, Yann Dirson <ydirson@altern.org> wrote:

> I have started to work on recording parent information for stgit
> branches, so we don't need to give the same info on every "git pull".

Isn't this what the branch.<name>.remote configuration option is for? I think we should leave GIT handle this and StGIT only invoke "git pull" without any arguments.

Show 7 quoted lines

> I'm facing a problem, in that we have several kind of stgit branches:
>
> * those created against a cogito branch (eg. by "cg clone" and "stg
>   init").  They work pretty much intuitively (and it happens I mostly
>   used this flavour before those tests).  All we need is the name of
>   the local branch, and "stg pull <branch>" relies on "git fetch" to
>   find the repository information in .git/branches/<branch>.

But I think .git/branches got deprecated or it is a cogito-only feature.

Show 6 quoted lines

>   In this case, it is easy to request pulling from any branch, but
>   usually only one of them is what you want, and the results of using
>   another one (or forgetting to specify the one you want) can be
>   annoying [ISSUE 1].  Hence this work of mine: being able to store
>   this info in .git/patches/<stack>/parent (my initial implementation)
>   was sufficient in theory.

I would leave this to GIT and its configuration files. Do you see any problems with this approach?

I plan to merge the stgit config with the git one (and have a [stgit] section) so that it is more maintainable.