making stgit handle being rebased by git rebase

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

On Mon, Nov 8, 2010 at 11:39 PM, Chris Packham <judge.packham@gmail.com> wrote:

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.

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

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.

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

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

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.

That goes for my proposal as well.

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.