Re: making stgit handle being rebased by git rebase

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

On 11 November 2010 10:29, Karl Wiberg <kha@treskal.com> wrote:
> On Mon, Nov 8, 2010 at 11:39 PM, Chris Packham <judge.packham@gmail.com> wrote:
>> Has anyone looked at making stgit interact with git-rebase more gracefully?
>
> The problem is that StGit's metadata gets out of date when you do a
> git rebase. A solution would either have to change StGit's metadata
> representation so that it can't get out of date, or be a fancy version
> of repair/uncommit that can actually figure out what git did.
>
> I've thought a bit about this in the past, and the best solution I
> could come up with is of the first kind, and would change the
> representation of applied patches to use just two refs: the branch
> itself, and the stack base ref. I think git rebase wouldn't wreck
> things for that representation.

git rebase would most likely change the base of the stack so stgit can
no longer track its patches. If git rebase just moves the stack base
forward, stgit could generate additional patches that have been
brought in by git, though sometimes this would include merges etc.

Maybe a better option for stgit is to just remember the branch and the
number of patches (probably including the patch names unless we always
generate them automatically, not that bad but you lose the possibility
of renaming patches).

The above would work well if people use git commit on top of an stgit
branch. The patch names maybe be wrongly associated or (if we
automatically generate patch names) we may miss the first patch in the
series because of the number of commits. The latter is not that bad
since we can always use stg uncommit, though a stg rebase could
override the committed patch.

-- 
Catalin