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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:17

Thiago Farina [off-list ref] writes:
On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano [off-list ref] wrote:
quoted
* 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].
quoted
already introduced an unnecessary conflict.
Which conflict? If you say, I could try to fix it.
quoted
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.

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

From: Thiago Farina <hidden>
Date: 2016-06-15 22:50:17

On Wed, Dec 22, 2010 at 6:48 PM, Junio C Hamano [off-list ref] wrote:
Thiago Farina [off-list ref] writes:
quoted
On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano [off-list ref] wrote:
quoted
* 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].
quoted
already introduced an unnecessary conflict.
Which conflict? If you say, I could try to fix it.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help