Hey, > Ever since Jeff brought up this issue, I've been wondering what > issue/workflow is that patch trying to fix. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html