Re: Rebasing stgit stacks

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 15/01/07, Yann Dirson <ydirson@altern.org> wrote:
> 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.

>  "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.

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

> 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