Re: making stgit handle being rebased by git rebase

From: Karl Wiberg <kha@treskal.com>
Date: Nov 11, 2010, 11:34 UTC
Message-ID: <AANLkTimfJZ5q+fg0qhr6o2y7SGWKKNP4-kVFiL8DS1Sd@mail.gmail.com>
In-Reply-To: <AANLkTimjO0yMJvf_fF3g7qypAuhPyiHCeF-sUv5toM_S@mail.gmail.com>

On Thu, Nov 11, 2010 at 11:41 AM, Catalin Marinas <catalin.marinas@gmail.com> wrote:

Show 10 quoted lines

> On 11 November 2010 10:29, Karl Wiberg <kha@treskal.com> wrote:
>
>> 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.

I was thinking we could use another git branch as stack base---specifically, use origin/master as stack base for master, etc. The stack of applied patches would then be defined as origin/master..master. That way, git rebase really wouldn't do any harm.

Of course, if git rebase was used to rebase onto a different branch, then StGit would have to be told about it; but git already stores information of this sort, used by e.g. git pull with no arguments. (No, I haven't researched this part properly. )

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

Yes, that's another way to do it. I think I like my proposal better, but as I said, I haven't worked it out in detail, and I'm not about to do so any time soon.

> The above would work well if people use git commit on top of an
> stgit branch.

That goes for my proposal as well.

Show 5 quoted lines

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

Patch names are a problem in all these "minimal metadata for applied patches" ideas. They could possibly be preserved by guessing the best match if the stack is modified outside StGit.

-- 
Karl Wiberg, kha@treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle