Re: en/merge-tree (Was: Re: What's cooking in git.git (Feb 2022, #08; Mon, 28))

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Elijah,

On Tue, 1 Mar 2022, Elijah Newren wrote:

> On Tue, Mar 1, 2022 at 7:26 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > * en/merge-tree (2022-02-23) 13 commits
> >  - git-merge-tree.txt: add a section on potentional usage mistakes
> >  - merge-tree: add a --allow-unrelated-histories flag
> >  - merge-tree: allow `ls-files -u` style info to be NUL terminated
> >  - merge-tree: provide easy access to `ls-files -u` style info
> >  - merge-tree: provide a list of which files have conflicts
> >  - merge-ort: provide a merge_get_conflicted_files() helper function
> >  - merge-tree: support including merge messages in output
> >  - merge-ort: split out a separate display_update_messages() function
> >  - merge-tree: implement real merges
> >  - merge-tree: add option parsing and initial shell for real merge function
> >  - merge-tree: move logic for existing merge into new function
> >  - merge-tree: rename merge_trees() to trivial_merge_trees()
> >  - Merge branch 'en/remerge-diff' into en/merge-trees
> >
> >  A new command is introduced that takes two commits and computes a
> >  tree that would be contained in the resulting merge commit, if the
> >  histories leading to these two commits were to be merged, and is
> >  added as a new mode of "git merge-tree" subcommand.
> >
> >  Will merge to 'next'.
> >  source: <pull.1122.v6.git.1645602413.gitgitgadget@gmail.com>
>
> As I mentioned on the last "What's cooking", let's not.  Please mark
> it as expecting a reroll instead.  I'm waiting to hear back from Dscho
> on whether my latest proposal at [1] would solve his usecase.  That
> proposal suggests output format and various code changes.
>
> [1] https://lore.kernel.org/git/CABPp-BGnqXdFBNAyKRXgvCHv+aUZTMg-CgcQf95dKAR-e1zSjQ@mail.gmail.com/

I am _so sorry_! I didn't expect you to wait for me (and even then, I
cannot take time where there is no time to take, I am unfortunately quite
short on time these days).

From my side, this patch series is totally ready to be merged to `next`!

In the interest of heeding the matra "the perfect is the enemy of the
good", let's avoid adding more concerns that this patch series needs to
address.

Whatever machine-parseable info we want to provide can be made optional,
and we can iterate on the design by marking that option as experimental.

Thank you so much for your hard work!
Dscho