making stgit handle being rebased by git rebase

making stgit handle being rebased by git rebase

[Chris Packham]

Hi Catalin, Karl,

Has anyone looked at making stgit interact with git-rebase more gracefully?

I've been playing with some of the recent git submodule improvements,
in particular the submodule.<mod>.update=rebase option. When I have a
submodule which I've been using stgit on it gets a bit upset when the
branch gets rebased by git. I don't loose any work but all my stgit
patches get turned into git commits. I can get them back with stg
repair and/or stg uncommit but I was wondering if there was any way of
making stgit play nicely with git rebase.

As a workaround I could have something remember the applied patches,
run stg pop -a and re-apply the patches after the fact. All of which
is doable but maybe there is a better way.

Thanks,
Chris

Re: making stgit handle being rebased by git rebase

[Karl Wiberg]

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.

This kind of change is a lot of work, though, more than I have time
for at the moment. And it's not like I have the details worked out or
anything... Making stg repair more intelligent would be a lot less
involved.

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

Re: making stgit handle being rebased by git rebase

[Catalin Marinas]

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

Re: making stgit handle being rebased by git rebase

[Karl Wiberg]

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

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

> 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