svn commit: r317409 - head/contrib/tcpdump

[Xin LI]

On Tue, Apr 25, 2017 at 12:07 PM, Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Tue, Apr 25, 2017 at 1:30 PM, Rodney W. Grimes <
>> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>>
>> > [ Charset UTF-8 unsupported, converting... ]
>> > > Author: glebius
>> > > Date: Tue Apr 25 15:56:46 2017
>> > > New Revision: 317409
>> > > URL: https://svnweb.freebsd.org/changeset/base/317409
>> > >
>> > > Log:
>> > >   Cherry-pick 5d3c5151c2b885aab36627bafb8539238da27b2d, it fixes use
>> > after free
>> >
>> > Lets not use git hashes as references in commit messages,
>> > it has very little value for someone reading a log of changes
>> > looking for something.  There is no promise that it can be
>> > found later (github can go Poof).
>> >
>>
>> On the contrary, a git SHA1 seems like an eminently stable and unique
>> search parameter!
>> I agree that a commit log should inline some summary of the change as well
>> as provide a
>> link to the external source, but I am not worried that a future reader will
>> be unable to find
>> the referenced commit.
>
> There is no administrative policy in place that says github users shall
> maintain there history.

Anyone who have a copy of the git repository would be able to 'git
show 5d3c5151c2b885aab36627bafb8539238da27b2d' and prove (arguably,
SHA1 is now broken, but it's still better than referencing e.g. a CVS
or SVN revision), and the location of the repository is publicly
known.

> I had too many indirections to find this change on github:
> commitlog -> google -> wrong article that references this sha1 -> actual commit
>
> I re-iterate lets NOT start to use git hashes in our commit messages.

I don't see any problem with Gleb's commit message, it have referenced
the original commit using the right notion (Git SHA1) and have
included a brief description of what was done at the same time.