Martin von Zweigbergk <martin.von.zweigbe...@gmail.com> 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.zweigbe...@gmail.com>
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html