Re: git notes: notes

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2010, 23:14 UTC
Message-ID: <7vljfsz7vx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.1001202354070.4985@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Makes sense, and the patch actually removes what could be seen as an ugly 
> side effect (why it only ONELINE not getting notes?).

Thanks.

The motivation was that the user should be able to get notes even under ONELINE mode if desired. But then the call to get_commit_notes() may want to inspect the commit format being used and tweak the flag parameter; right now it always sends NOTES_SHOW_HEADER and NOTES_INDENT.

> I would agree with Peff about the mention of --pretty disabling notes 
> (unless asked for by a user format) in the commit notes as well as in the 
> pretty options,...

Actually I am of two minds regarding --pretty={short,medium} and the like. The "how about this" patch may be the safest for people who are used to read "log --pretty=xxx" output with scripts, but it does look inconsistent and hard to explain to new people who do not even know that there were versions of git that does not know about notes.

> but I fully disagree on the need for tests.  We should not 
> have a thorough test suite that runs for days on end, but we should 
> concentrate on things that are more likely to get broken.  And the added 
> code is just too obvious for that.

I agree with that principle, but it doesn't explain nor justify the lack of tests for format-patch, which would have caught the breakage a lot earlier.

Or perhaps we all (not just you but I am just as guilty) misjudged "things that are more likely to get broken", even though we are very well aware that touching log-tree infrastructure will have fallout all over the "log" family.