Re: What's cooking in git.git (Sep 2021, #08; Mon, 27)

From: Elijah Newren <newren@gmail.com>
Date: Sep 29, 2021, 06:42 UTC
Message-ID: <CABPp-BF-tEk-ef3tVD_27a2UbcrRsZw8y+49+v0H5E39UPgPrg@mail.gmail.com>
In-Reply-To: <xmqqo88clixa.fsf@gitster.g>

On Tue, Sep 28, 2021 at 10:16 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 33 quoted lines

>
> Elijah Newren <newren@gmail.com> writes:
>
> >> * js/scalar (2021-09-14) 15 commits
> > ...
> > However, since Johannes has been away for a couple weeks, maybe give
> > him a chance to return and respond to myself and others (and perhaps
> > push any updates that occurred to him while on vacation) before
> > merging down?
>
> Fair enough.
>
> >> * en/remerge-diff (2021-08-31) 7 commits
> >>  - doc/diff-options: explain the new --remerge-diff option
> >>  - show, log: provide a --remerge-diff capability
> >>  - tmp-objdir: new API for creating and removing primary object dirs
> >>  - merge-ort: capture and print ll-merge warnings in our preferred fashion
> >>  - ll-merge: add API for capturing warnings in a strbuf instead of stderr
> >>  - merge-ort: add ability to record conflict messages in a file
> >>  - merge-ort: mark a few more conflict messages as omittable
> >>
> >>  A new presentation for two-parent merge "--remerge-diff" can be
> >>  used to show the difference between mechanical (and possibly
> >>  conflicted) merge results and the recorded resolution.
> >>
> >>  Will merge to 'next'?
> >
> > It has been a month that it's been cooking with no issues brought up,
> > and it's been in production for nearly a year...
>
> Please do not read that much for being in "seen".  Until a topic
> hits 'next', where some orgs package and ship to their internal
> audience, I am not sure if it can be called "cooking".

As a heads up, I found this topic in an email titled "What's Cooking...", and in particular it was listed in a section of that email that was titled "[Cooking]". ;-)

Sorry, I couldn't resist.

But yeah, I know "seen" doesn't mean much. My comment was reflecting that while leaving a topic in seen for a while sometimes results in more information coming forth to inform the decision about whether to merge the series to next, or drop it, or ask the submitter for changes, there comes a point where further waiting is unlikely to provide any additional information that would help inform that decision. I was starting to wonder whether we'd get any (more) feedback. But I'm glad we waited a little longer. :-)

> But your using it on your folks in the production (how big is your
> audience, I don't know) does count ;-)

~100 opt-in users (apparently shot up in the past few months; used to be ~50). I have a hard time gauging how heavily this particular feature was/is used by them, however:

  * The feature was explicitly announced, but I did it because I
thought it was cool and a nice demonstration of merge-ort features,
not because there were explicit requests for it
  * I did make "-p" imply "--remerge-diff" for git-log in our internal
opt-in distribution, so that should increase usage significantly.
  * A bug in an internal tool for a while was accidentally running
`git log -p --name-status $COMMIT --not
--remotes=ACCIDENTALLY_INVALID_REMOTE_NAME` for a while, including in
big repos; in combination with previous point, this increased usage
and scope of remerge-diff usage a fair amount as that command would
run on all commits in history.
  * Most merges here are done by either GitHub (Enterprise) or Gerrit,
both of which require the user to rebase and re-push if there are any
conflicts.  This makes remerge-diff boring for most merges.  There are
some notable exceptions where merges are done differently, they're
just much less common.  (--remerge-diff-only for cherry-picks and
reverts is a bit more interesting, but that's not part of this
series...and I also haven't gotten much feedback on it.)
  * I have only received feedback from two users about the
remerge-diff feature, one only indirectly, and both reports actually
ended up being about underlying bugs in early versions of merge-ort[+]

[+] The bugs were (1) my QSORT in write_tree() was not originally using tree_entry_order() and thus was writing trees with the wrong ordering of elements; this was a bug that was fixed before write_tree() was ever submitted upstream, and (2) and the bug fixed by 72b3091040f8 (merge-ort: use STABLE_QSORT instead of QSORT where required, 2021-03-20)

Show 8 quoted lines

> > But just this morning I pinged peff and jrnieder if they might have
> > time to respectively look at the tmp-objdir stuff (patch 5, plus its
> > integration into log-tree.c in patch 7) and the ll-merge.[ch] changes
> > (patch 3).  I don't know if either will have time to do it, but
> > perhaps wait half a week or so to see if they'll mention they have
> > time?
>
> Sure.

Apparently that was a good idea; Peff and Ævar have both chimed in with feedback. :-)