Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 15, 2007, 20:24 UTC
Message-ID: <20070115202412.GE9761@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <8b65902a0701150526j5a954529xf45b2d0348a77573@mail.gmail.com>

On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:

Show 5 quoted lines

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

 "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

The latter is, unless I miss something:

- overkill when what we want is just to move the head to another place

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

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)

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

That only partly works - that is, it works if I add the expected "+" in the remote refspec line (or if I add an explicit refspec on command-line). There is surely a way for "stg clone" to detect the parent is an stgit stack, and we can possibly have the clone operation setup things right from the start. I remember someone suggesting that such branches advertise their status so git-clone itself would add this - not sure this is planned for 1.5.0, though.

Even when this fully works, I'm reluctant to leave things that way, because would be easy to forget the --to, and get a broken stack, with "stg diff" being confused enough to happily show this:

|bar$ stg diff; echo $?
|* Unmerged path file
|0

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.

Best regards,

-- 
Yann.