Re: making stgit handle being rebased by git rebase

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Nov 11, 2010, 10:41 UTC
Message-ID: <AANLkTimjO0yMJvf_fF3g7qypAuhPyiHCeF-sUv5toM_S@mail.gmail.com>
In-Reply-To: <AANLkTik_dFsaiDkugrpBp8T31zNWVMRNC=hQBj0RmV+o@mail.gmail.com>

On 11 November 2010 10:29, Karl Wiberg <kha@treskal.com> wrote:

Show 13 quoted lines

> 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