Re: Rebasing stgit stacks

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 15, 2007, 22:46 UTC
Message-ID: <b0943d9e0701151446l45eff9dbgcae718c1461d0725@mail.gmail.com>
In-Reply-To: <20070115202412.GE9761@nan92-1-81-57-214-146.fbx.proxad.net>

On 15/01/07, Yann Dirson <ydirson@altern.org> wrote:

Show 9 quoted lines

> On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:
> > >What you should have done is moving your stack base from your old
> > >origin branch to remotes/trunk - something that StGIT does not support
> > >yet from command-line, but I've done this manually in the past
> > >(migrating an StGIT stack after re-running a full git-cvsimport after
> > >the original cvs branch got corrupted).
>
> I have started work on implementing "stg pull --to <newbase>", but I'm
> facing some issues.

I think the combination of 'pull' and '--to' is confusing (at least to me) if you think of there English meaning.

Show 7 quoted lines

>  "stg pull", after popping all patches, currently calls "git pull",
>  which indeed has 2 roles:
>
> - running "git fetch" on the parent branch
> - updating the head of the stack (which matches the base since
>   no patch is applied), by relying on git-pull to fast-forward the
>   stack head

As Petr suggested at the OLS last year, I added the possibility to configure the 'git pull' command so that people use whatever script they like.

> The latter is, unless I miss something:
>
> - overkill when what we want is just to move the head to another place

Doesn't git automatically detect that it can do a fast forward? A fetch is still necessary anyway.

I'm not sure how people intend to use StGIT. Some might have their own changes to the base of the stack (maybe caused by 'stg commit') and would want 'git pull' to do a proper merge and not just fast-forward.

I actually did the above when maintaining a public (well, ARM internal only currently) kernel branch for other people to pull from. Since StGIT is not public branch friendly, I was working on a set of patches (mainly picking from other branches and minor modifications) and just committing them when finishing. Further updates from kernel.org triggered full merges with the base.

Show 5 quoted lines

> - problematic when the parent branch is one that would be tracker with
> "+" in the remote pull line (eg. "next", "pu", or an stgit stack).  In
> that case, although "git fetch" refuses to update the parent head
> because it would not be a fast-forward, git-pull then attempt to do a
> merge, which completely breaks expectations.

Is there any way to configure git (via gitconfig) to behave differently? You can add some per-branch options with the parent to pull from but this would require separate .git/remotes/ files for each branch.

Show 8 quoted lines

> What my implementation of "pull --to" does is just moving the head
> with the following code added to git.py:
>
> def move_branch(tree_id):
>     """Move HEAD to another commit
>     """
>     __set_head(tree_id)
>     switch(tree_id)

The switch() function already calls __set_head()

>     if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):
>         os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))

When is the MERGE_HEAD file generated? Is there any harm in leaving this file?

> I would be of the opinion to stop calling "git pull" entirely, and use
> "git fetch and the git.move_branch show above.  Unless I hear about
> better ideas, my next patch set will be along those lines.

Or replace the 'git pull' in the config file with 'git fetch && git reset --hard MERGE_HEAD'? I might be wrong though as I almost never use git directly :-).

-- 
Catalin