On Wed, Dec 22, 2010 at 6:48 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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" That should be the pain of being the maintainer. You have to deal with this, like I have to deal with all the critics too. > patches that may overlap with them at the list until the dust settles. The dust never settles in this mailing list. > 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, Which is impossible, due to the high traffic that this project attracts. > these are genuinely good clean-up patches, but when other patches that give us real-life benefit are in flight, Well, I'd say to just ignore it as you have done many times before. > just having to check if they overlap with whatever > is cooking now is already annoying. > What I can do if you are the ONLY one that has commit access to this project. -- 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