Allow stg rebase to rebase a stack other than the one you're currently on

[hjfreyer]

git rebase allows you rebase a branch that isn't currently checked out:

 git rebase [<upstream> [<branch>]]

This is basically the same as first checking out <branch>, but it doesn't actually update the working directory before rebasing. This has a nice side-effect when your currently checked-out branch is close to <upstream>, but <branch> is far behind. If you do the checkout first, the checkout operation will overwrite most of your working directory, and git rebase <upstream> will revert most files right back to where they were. On the other hand, git rebase <upstream> <branch> will just leave most files untouched. Build systems that use mtime are much happier in the latter case.

It'd be great if stg rebase exposed this functionality, for example: stg rebase -b <branch> <new-base-id>.

[jpgrayson]

Thank you for writing up this idea, @hjfreyer.

For stg rebase -b <branch> <new-base-id>, it seems like <branch> would have to be a StGit-enabled branch. Is that consistent with what you're thinking?

In order to achieve the benefit of avoiding spurious mtime changes, StGit would have to avoid changing the working tree to the target branch like git rebase does. However, the current way that stg rebase operates is to start by doing a stack transaction that pops all the branch's patches. The key thing here is that when this stack transaction executes, the tree that results from all the patches being popped (i.e. the stack's base commit) is checked-out to the working tree. So it seems like we would need to find a clever way to record that all the stack's patches have been popped without realizing those pops in the working tree and then execute the subordinate git rebase, and then performing the final step of pushing-back all the previously popped patches.

My sense is that this may be possible, but it is not immediately clear to me how to do this. To move this feature forward, someone will have to figure out a workable strategy for how we can do this in StGit while keeping the stack, working tree, and index states consistent throughout.

I suppose we could implement stg rebase -b <branch> the easy way, i.e. just switch to <branch> before performing the existing rebase procedure. This would ostensibly not net the benefit of minimizing mtime updates, but perhaps the -b <branch> option would still have enough value to warrant adding it without the mtime optimization?