Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2016, 03:04 UTC
Message-ID: <xmqqh9ijv6qg.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160112000612.GA32363@glandium.org>

Mike Hommey <mh@glandium.org> writes:

Show 22 quoted lines

> On Mon, Jan 11, 2016 at 03:45:35PM -0800, Junio C Hamano wrote:
>> * mh/notes-allow-reading-treeish (2015-10-08) 3 commits
>>   (merged to 'next' on 2015-10-23 at 8a697f0)
>>  + notes: allow treeish expressions as notes ref
>>  + Merge branch 'jk/notes-dwim-doc' into next
>>  + Merge branch 'jc/merge-drop-old-syntax' into next
>>  (this branch uses jc/merge-drop-old-syntax.)
>> 
>>  Some "git notes" operations, e.g. "git log --notes=<note>", should
>>  be able to read notes from any tree-ish that is shaped like a notes
>>  tree, but the notes infrastructure required that the argument must
>>  be a ref under refs/notes/.  Loosen it to require a valid ref only
>>  when the operation would update the notes (in which case we must
>>  have a place to store the updated notes tree, iow, a ref).
>> 
>>  As the patch was done on top of the 'drop old-syntax from merge',
>>  this has to wait until that other topic can graduate, unfortunately.
>>  It can be redone in a way that does not depend on that topic after
>>  this cycle, though.
>
> I'm not sure what you mean here. The patch applies just fine on top of
> current master.

I exactly mean what I wrote ;-).

IIRC, back when the patch was queued, it wasn't directly applicable to the tip of the master branch (I suspect that you made a patch against 'next'), and the two topics you can see merged above turned out to be the ones your change was textually depending on. Because at least one of them was slated to be kept in 'next' during the 2.7 cycle, and because we do not rewind 'next' in the middle of a cycle, this made the patch at the tip of this topic to be ineligible for merging to 'master' without dragging the other topics that were not meant for 'master'.

Post release is a rare occasion that we can rewind and rebuild 'next', so you can simply send an updated patch that would apply cleanly to the tip of 'master' (which is a lot newer than the tip of 'master' back then, and possibly have merged quite a lot of changes from either of the two other topics your patch depends on) and tell me "Drop that old copy queued in 'next' and replace it with this new one when you rebuild 'next'". If the old patch is identical to such a patch, then just telling me "When you rebuild 'next', rebuild the topic by just cherry-picking the tip of the topic directly to the tip of 'master', as all the prerequisite changes have been merged already" would be sufficient.

Which I guess you just did ;-). I haven't checked if the changes you depended on are all in 'master' already, but if that is the case, then I'll do just that--if you see me forgetting to do so when I rewind 'next', please holler.

Thanks.