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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thiago Farina <tfransosi@xxxxxxxxx> writes:

> On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]