Re: [PATCH] revert: prettify fatal messages

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] revert: prettify fatal messages

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:29

Ramkumar Ramachandra [off-list ref] writes:
 Candidate for 'maint'?
Too minor to matter when 'master' is already at -rc2.

Thanks.

Re: [PATCH] revert: prettify fatal messages

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:52:29

Hi,

Matthieu Moy wrote:
(I just misread the subject line at first, and understood that this was> a revert of an earlier commit, while this is actually a commit touching> the "revert" part of Git)
Reminds me of an earlier note Jonathan made about the git-revert
commit message format.  To avoid confusion, reverts should always look
like the following:

  Revert [commit message]

  This reverts commit [unabbreviated sha1 hex].

Junio C Hamano wrote:
Ramkumar Ramachandra [off-list ref] writes:
quoted
 Candidate for 'maint'?
Too minor to matter when 'master' is already at -rc2.
Ah, I haven't been paying much attention to these release cycles.  I
suppose we can put this patch in `master` after the release?  I wince
everytime I see these ugly fatal messages: it happens shockingly often
while testing :)

Thanks.

-- Ram

Re: [PATCH] revert: prettify fatal messages

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:52:29

Ramkumar Ramachandra wrote:
To avoid confusion, reverts should always look
like the following:

  Revert [commit message]

  This reverts commit [unabbreviated sha1 hex].
Don't forget the description of why it is being reverted. :)

Actually, I think Matthieu's confusion makes a lot of sense.  I don't
think it matters very much, but it can sometimes be clearer to say
"cherry-pick/revert: remove spurious period in error message".

Another benefit to moving the juicy part to sequencer.c, I guess.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help