Re: Please don't use revision numbers on commit messages (and elsewhere).

[Juanma Barranquero <lekktu@gmail.com>]

On Thu, Mar 31, 2011 at 22:47, Óscar Fuentes <ofv@wanadoo.es> wrote:

> A revision number only makes sense on the branch where it was created
> (and this only after setting some options, as Emacs did.)

Yeah, well, we're dealing with Emacs, not some random bzr branch.

> If I'm reading
> the VC log on a random branch and see "Fix breakage introduced by rXXXX"
> and want to look at the referenced revision, I need to switch to trunk
> and hope that XXXX corresponds to one of its revisions.

Revision numbers refering to the trunk seem to be, until now, the most
common case. And I see that people sometimes uses the branch name as
an adjetive to clarify which one contains the revno:

  Merge from emacs-23 branch, up to r100386.

  emacs-23 r100373 is rendered unnecessary by pre-existing 2010-05-20
  trunk change.

  Backport revno:103582 from trunk.

  Fix the MS-Windows build broken by r102878 and emacs-23/r100409.

Seems pretty clear to me.

> If a series of
> commits on a feature branch mentions one another by revison number,
> after merging them into trunk (or into any other branch) those numbers
> are wrong.

Isn't that a case of "if it hurts, don't do that"?

> So, if you wish to refer to another revision on the commit message (or
> anywhere else) please use the revision id, which is unique for every
> commit.

It's also quite unwieldy. git SHA-1 ids seem a joy by comparison (at
least you can use a prefix of 6-8 characters and be right most of the
time).

    Juanma