Behavior of various history editing commands regarding empty changesets
me at manueljacob.de
Mon Oct 21 16:09:12 EDT 2019
Various history editing commands (e.g. rebase and absorb, but not amend)
drop a changeset if it was or becomes empty. It definitively makes
sense for some workflows, but not so much for many workflows enabled by
changeset evolution, where each changeset is considered as a patch
instead of just saving the current working state.
For example, a changeset description could contain valuable information,
which would disappear during the rebase if the destination happens to
already include the changes. If the rebase is done in TortoiseHG, it
could easily go unnoticed. I’d expect that changing the default
behavior is too controversial. But what do you think about a
configuration options that would change this behavior?
Sometimes, empty changesets are used to have identical file contents,
but in another branch (this is useful for triggering CI in some
specifically named branch). Rebase and absorb drop these as well.
In the case of absorb, there’s a difference between changesets which
*were* empty and changesets which *become* empty. The absorb source
code was apparently written with the assumption in mind that no
changesets were empty originally and therefore can only *become* empty,
reflecting in comments like "if it will become an empty commit (does not
change anything, after the memworkingcopy overrides), [...]" and
"changeset is *no longer* necessary" (emphasis mine), and the command
output "[changeset]: became empty and was dropped". So I think it would
be reasonable to re-consider this behavior for the case when the
changeset was empty originally.
More information about the Mercurial-devel