Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 22, 2010, 20:48 UTC
Message-ID: <7vvd2l4jpx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTin_u9FiZf-hbnhY0Dp+LifctxH8wKDL=yRrSpm+@mail.gmail.com>

Thiago Farina <tfransosi@gmail.com> writes:

Show 15 quoted lines

> On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * tf/commit-list-prefix (2010-11-26) 1 commit
>>  (merged to 'next' on 2010-12-21 at 16e1351)
>>  + commit: Add commit_list prefix in two function names.
>>
>> This churn
> Since you said that, can could you drop this patch? I don't mind if
> you discard this patch since you consider it a CHURN[1].
>
>> already introduced an unnecessary conflict.
> Which conflict? If you say, I could try to fix it.
>
>> It is not by itself a biggie, but these things tend to add up.
>
> How *these things* add a conflict? This is a new thing to me really.

Look at output from "git show 16e1351 sha1_name.c".

The damage (i.e. my time wasted to deal with the conflict resulting from the rename of the function) has already been done. There is nothing to fix.

One thing you _could_ fix is to keep an eye on what are cooking (e.g. the diff between maint and pu), and refrain from throwing "trivial clean-up" patches that may overlap with them at the list until the dust settles. That would greatly reduce the annoyance factor.

The same comment applies to your patches to reduce use of alloc_nr(). If absolutely nothing else is going on in the project, these are genuinely good clean-up patches, but when other patches that give us real-life benefit are in flight, just having to check if they overlap with whatever is cooking now is already annoying.

Thanks.