Re: Referring to revisions in the git future.

[David Kastrup]

"Eric S. Raymond" <address@hidden> writes:

> David Kastrup <address@hidden>:
>> Just use the SHA1.
>
> Please *don't* use the SHA1.  It's an opaque blob, not portable to any
> future VCS we may need to move to someday.  It is better, and more
> human friendly, to refer to commits by their summary line, or by
> committer and date.

Shrug.  Not if the human actually wants to use it for any purpose.  It's
fine to be more explicit, like

commit 0c59175f0867663196e77061786dc07708d69894
Author: David Kastrup <address@hidden>
Date:   Wed Jan 1 12:47:42 2014 +0100

    Some parser work, mostly unconvincing

But in the end, the one thing that is actually definitive is the commit
id.  And I don't see it as either more or less useful than a revision
number.  You don't want to type in either by hand, but at least the
commit id is reasonably safe against typos, given enough digits.

> About summary lines, a reminder: Please don't write the traditional
> GNUish run-on change comment with a semi-infinite number of bulleted
> items in it any more. We're no longer in CVS-land, commits are cheap,
> make them fine-grained.

Commits are awfully expensive since they should contain the ChangeLog
entries corresponding to each commit.

With regard to ChangeLog entries, we are still quite in CVS-land (though
CVS commits only allowed one file at a time, making it even worse to
keep track of the corresponding ChangeLog entry).

One thing that we really used ChangeLog for is distinguishing between
committer and author of a change, and we needed to keep track of the
latter for copyright and attribution reasons.  Fortunately, Git keeps
track of both.

At any rate, as long as ChangeLog entries are here to stay (and that's a
different discussion we had a few times), "commits are cheap" is not
matching reality.  Each commit tends to come with its own manual
conflict resolution for ChangeLog.

-- 
David Kastrup