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

Mike Hommey [off-list ref] writes:

On Mon, Jan 11, 2016 at 03:45:35PM -0800, Junio C Hamano wrote:

quoted

* 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.