Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes: > Add test cases for 'git rebase --keep-empty' with and without an > "empty" commit already in upstream. The empty commit that is about to > be rebased should be kept in both cases. > > Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> > --- > > Added another test for when the upstream already has an empty > commit. The test case protects the current behavior; I just assume the > current behavior is what we want. Thanks. I think it makes sense, as "upstream already has an empty commit" together with "want to keep empty while rebasing" is a strong sign that the user wants to have a history littered with many empty commits. Unlike a normal commit whose "patch-id" identity may have meaningful significance (i.e. "the change to do X is already in, or not yet in, this branch"), all the empty commits share the same emptiness, so having one empty somewhere long time ago in the history of where we are transplanting the commits shouldn't be a reason to countermand the "want to keep empty" wish by the user. And I do not think the conclusion would change even if we changed the definition of "identity" for empty commits so that two empty commits with the same message are detected as equal. The only semi sensible justification I heard from people who want to have empty commits in their history is to keep in-history "notes" (e.g. "at this point in the series, the code stops to compile, but the next one fixes it", "it is possible that we may want to redo the previous patch but I dunno"), and it may not make sense to drop such an empty commit under "--keep-empty" mode if there are similar or identical looking "notes" in the "upstream" part of the history. -- 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