Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"

Hey,

I'm fairly sure the case the patch was fixing is t3411's "squash F1 into D1".

Where, starting with a tree like:

# A1 - B1 - D1 - E1 - F1 # \ / # -- C1 --

The user is on F1 and issues: "git rebase -i -p B1", the todo list is "D1, E1, F1" (no C1), and they choose "D1 squash F1, E1", the resulting tree should be:

# A1 - B1 - D2 - E2 # \ / # -- C1 --

And, the fix was that C1 should not be in the todo list.

Perhaps that is unreasonable with whatever you guys are looking at now, but, IIRC, the use case was that B1=some old commit, like a 2.0 release, and a bunch of work happened on the C1 branch, it was merged in E1, but now when you want to rebase D1/E1/F1 on top of B1, you don't want all of the noise of the C1 commit(s), since when rewriting E1 into E2, you can just reuse the un-rewritten C1 as its 2nd parent.

Well, and not just the noise--since the todo is still flat, if C1 was listed in the todo, there's no way to recreate E2 as a merge and maintain the C1 commit(s) as a separate branch. I think C1 would get flattened between D2/E2, depending on where it was in the todo. You'd lose a merge, contrary to the -p flag. That sounds like the core issue that was being fixed.

The patch in question:

http://article.gmane.org/gmane.comp.version-control.git/98251

Did actually have a test (t3411) but it was still failing until the following commit:

http://article.gmane.org/gmane.comp.version-control.git/98253

Where the test changed from expect failure to expect success. I remember that looking odd at the time, but for some reason liked the commits being separate.

- Stephen