Behavior of various history editing commands regarding empty changesets

Manuel Jacob me at
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 mailing list