On Tue, Jun 26, 2012 at 2:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Hrm, why does this break 9140.6? Has the test been expecting a > wrong result? I wish I could say that it was. I guess I never had the subversion libraries installed while running the test cases :-(. It turns out that that test case happens to create an empty commit. So when I changed from git-format-patch to git-cherry for calculating the revisions to rebase, it started including empty commits. It also turns out we don't have any test cases specifically for rebasing empty commits, so I'm glad 9140.6 caught it. I'll send out a patch that adds a test case for rebasing of empty commit, which should be good regardless of whether the current patch, in some form, is eventually accepted. I got all the tests to pass by special-casing empty patches in git-am.sh when $rebasing, but I'm now unsure about this patch for a few reasons: 1) I suppose the $revisions passed to git-am and may result in too long a command line. This should be fixable by replacing it by a function, I guess. 2) The new --keep-empty stuff is clearly closely related to these changes and at least the 'if test -n "$keep_empty"' block in git-rebase--am.sh could possibly be replaced by similar logic in git-am.sh by passing the --keep-empty to it. Using git-am should make it faster, which it the whole point of using git-am instead of git-cherry-pick, IIUC. I'm not sure when I'll get time to work on these issues. If someone else feels the urge, please go ahead. Martin -- 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