[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Uday S Reddy
Subject: Re: Please don't use revision numbers on commit messages (and elsewhere).
Date: Sun, 03 Apr 2011 09:00:38 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

On 4/2/2011 2:47 PM, Óscar Fuentes wrote:

The branch-local-revision is the localized version of the revision
number, i.e., 1 = 11-10, 2 = 12-10, ...

So, doing that bit of arithmetic is all it takes to decode "revision 11".

Yes, that works as long as those commits are merged in the same

I think it always works independent of how you merge. The local revision 11 will always be 10.x.1 and local revision 12 will always be 10.x.2. Whether you merge in one steps or multiple steps doesn't make a difference.

But even on that case we would be better without the arithmetic. Think a
feature branch with dozens or hundreds of commits. And I'm not talking
just about commit messages. References on bug reports or e-mail
exchanges suffer from the same.

In that case, you are talking about a tradeoff, what will be easier to the committer versus what will be easier for somebody to analyze things later on. My feeling is that committing is done much more often and doing additional chores in the middle of committing is distracting. So I would want to make it easier for committing.

If one states the branch nickname and the original revision id on the branch, then it can always be found on the trunk after merging. You can find the branch nickname in the log and then do the little bit of arithmetic to find the right revision.

When bug reports are submitted for a branch, the Emacs reporter should be including the branch nickname as part of the version information (if it isn't doing so already). That would ensure that the context is included.

My branch log doesn't show the revnos of trunk as they are on trunk, but
some renumbered version. As you mention, I can start counting merged
revisions across merge points until reaching the referenced revision,
but that's impractical.

Every revision is marked by the branch nick(name) and a revision number. If the branch nick is stated as "trunk" for a top-level revision then it is the revision number on the trunk. Otherwise, it is your local revision which would again be identified by your branch nick.

There is no counting involved.  A maximum of one addition or subtraction.

And, it should also be easy enough to write an Emacs command or two to automate it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]