Re: [PATCH 2/3 (edit v2)] gitweb: Cache $parent_commit info in git_blame()

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 12, 2008, 03:05 UTC
Message-ID: <7vr64e9jq6.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200812110133.33124.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 21 quoted lines

> ...
> Alternate solutions:
> ~~~~~~~~~~~~~~~~~~~~
> ...
> Acked-by: Luben Tuikov <ltuikov@yahoo.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> On Wed, 10 Dec 2008, Junio C Hamano wrote:
>
>> To recap, I think the commit log for this patch would have been much
>> easier to read if it were presented in this order:
>> 
>>         a paragraph to establish the context;
>> 
>>         a paragraph to state what problem it tries to solve;
>> 
>>         a paragraph (or more) to explain the solution; and finally
>> 
>>         a paragraph to discuss possible future enhancements.
>
> Like this?

Yes, basically.

The "future possibilities" section might be a bit too heavy, and also calling it "Alternate solutions" makes it slightly unclear if it is talking about what is implemented, or only talking about idle speculation without an actual code (in this case, it is the latter), though.

> Only commit message has changed.

Which is a bit unnice, because it will conflict with the original [3/3] that I queued already (with a pair of fixes, including but not limited to the one you sent "Oops, it should have been like this" for).

I can hand wiggle the patch to make it apply, but I'd prefer if I did not have to do this every time I receive a patch.

I think the conflict was trivial (just a single s/rev/short_rev/) and I did not make a silly mistake when I fixed it up, but please check the result on 'pu' after I push the results out.

Thanks.