Re: What's cooking in git.git (Dec 2013, #05; Thu, 26)

Eric Sunshine [off-list ref] writes:

On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano [off-list ref] wrote:

quoted

Eric Sunshine [off-list ref] writes:

quoted

On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano [off-list ref] wrote:

quoted

[New Topics]

Would $gmane/239575 [1] be of interest for "New Topics"?

[1]: http://article.gmane.org/gmane.comp.version-control.git/239575/

Actually I was planning to scoop it up directly to master but forgot
to do so.

Make sense.

quoted

Running "git diff maint pu -- name-hash.c" shows that we have added
a comment that mentions index_name_exists---that needs to be
adjusted, too, by the way.

Oops, yes, I had noticed that too when testing atop 'pu' but then
forgot about it when preparing the patch for submission on 'master'.

I'm not sure how to move forward with this now that kb/fast-hashmap,
with which it has a textual conflict, has graduated to 'next'. Should
this become a two-patch series with one for scooping directly to
'master' and one for 'next' to sit atop kb/fast-hashmap? (But how will
the textual conflict be handled?)

I have a feeling that a small unused helper function is not a huge
breakage that needs to be immediately fixed, so a single patch as a
clean-up on top of whatever is cooking on 'next' should be the best
approach, I would think.

On Thu, Jan 2, 2014 at 4:11 PM, Junio C Hamano [off-list ref] wrote:

Eric Sunshine [off-list ref] writes:

quoted

On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano [off-list ref] wrote:

quoted

Eric Sunshine [off-list ref] writes:

quoted

On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano [off-list ref] wrote:

quoted

[New Topics]

Would $gmane/239575 [1] be of interest for "New Topics"?

[1]: http://article.gmane.org/gmane.comp.version-control.git/239575/

Actually I was planning to scoop it up directly to master but forgot
to do so.

Make sense.

quoted

Running "git diff maint pu -- name-hash.c" shows that we have added
a comment that mentions index_name_exists---that needs to be
adjusted, too, by the way.

Oops, yes, I had noticed that too when testing atop 'pu' but then
forgot about it when preparing the patch for submission on 'master'.

I'm not sure how to move forward with this now that kb/fast-hashmap,
with which it has a textual conflict, has graduated to 'next'. Should
this become a two-patch series with one for scooping directly to
'master' and one for 'next' to sit atop kb/fast-hashmap? (But how will
the textual conflict be handled?)

I have a feeling that a small unused helper function is not a huge
breakage that needs to be immediately fixed, so a single patch as a
clean-up on top of whatever is cooking on 'next' should be the best
approach, I would think.

Sounds good. Thanks.