On Wed, Feb 27, 2019 at 7:36 PM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>
> On Wed, Feb 27, 2019 at 06:49:53PM +0700, Duy Nguyen wrote:
> > On Wed, Feb 27, 2019 at 6:37 PM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
> > >
> > > On Wed, Feb 27, 2019 at 06:07:42PM +0700, Duy Nguyen wrote:
> > > > > It was discovered that the --no-gpg-sign option was documented
> > > > > but not implemented in 55ca3f99, and the existing implementation
> > > >
> > > > Most people refer to a commit with this format
> > > >
> > > > 55ca3f99ae (commit-tree: add and document --no-gpg-sign - 2013-12-13)
> > >
> > > No, most often we use
> > >
> > > 55ca3f99ae (commit-tree: add and document --no-gpg-sign, 2013-12-13)
> > >
> > > i.e. with a comma instead of a dash between subject and short date;
> > > and without quotes around the subject.
> > >
> > > Truly sorry for nitpicking :)
> >
> > Naah it's about time I update my ~/.gitconfig to be "conformant" :D I
> > think we both failed to mention where to find the command for Brandon
> > though: search commit-reference in SubmittingPatches.
>
> Well, yes... but I didn't mention that on purpose: SubmittingPatches
> advocates for quotes around the subject, which is still the less often
> used format of the two, and there is no good reason for those quotes
> (that 'deadbeef (' before and ', 2019-12-34)' after the subject
> provide plenty of separation and indicate quite clearly what's going
> on).
Perhaps a patch to strip those quotes from the command in SubmittingPatches?
> However, looking at the length of the suggested command in
> SubmittingPatches made me remember that I've been using a couple of
> patches implementing 'git log --format=reference' for a couple of
> years now... I wonder whether it would be worth having something like
> that in git.git, and thus making it conveniently available for other
> projects as well.
It does sound nice to have something like this built in. But I'm not
sure if "git log" would be the right place. For handling single
revisions (most often the case), git-show or git-rev-parse might be
the better interface. Even for referencing multiple hashes at the same
time (e.g. you prepare a text with bare hashes first, then run some
program to insert the "(..)" part) then name-rev might be a better
candidate.
A softer route to avoid any of that is simply adding default config
"pretty.reference", then let the user define their own alias that uses
--pretty=reference. Or perhaps just put it in EXAMPLES section of
git-log.
--
Duy
