svn commit: r317409 - head/contrib/tcpdump

[Rodney W. Grimes]

> On Tue, Apr 25, 2017 at 2:07 PM, Rodney W. Grimes <
> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > >
> > > 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.
> >
> >
> That is correct.  Nor should there be!
> 
> (However, even if they change their history, the direct link to a commit
> will still work,
> due to the way the github implementation works -- you have to delete and
> recreate
> a repository in order to fully expunge a commit.)
> 
> I don't expect the previous parenthetical to provide any persuasive value,
> of course,
> as you have to know where to look before it's useful.  But, right now there
> are some
> 300-odd forks of tcpdump on github, no doubt including Gleb.  If
> the-tcpdump-group
> goes away, there's a lot of backups, not just in github forks but also the
> local clones
> of people using github.  Do you really think that the collapse of such a
> prominent
> project would leave an unarchived void?  I don't understand what scenario
> you're trying
> to protect against, basically.

This is the first time I have seen a raw git1 sha used in the body of
the commit message, at best it should be in a Obtained From: 

Are there other commits that use a raw git sha1 as the explination
for the commit, with or without supporting text?

> > 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'm sorry, but I must continue to oppose this sentiment.  I would prefer a

And so we stand opposed.  

> full
> (github or otherwise) URL including the commit hash to just a bare commit
> hash,
> but find either acceptable and adequate for the purpose.  (FWIW, the
> correct commit
> was the top google hit for me.)
> 
> I hope we are in agreement that commit messages ought to still include some
> description of what change is being brought in, in addition to the
> hash/link, though.

Commit messages should stand complete and alone, without need to refernce
outside material to understand what was changed and why it was changed.
Again, at best Obtained From:  should of been a usable url.


-- 
Rod Grimes                                                 rgrimes at freebsd.org