Rebasing stgit stacks

[Yann Dirson <ydirson@altern.org>]

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.

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