On Mon, Mar 7, 2022 at 8:31 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi Elijah, > > On Tue, 1 Mar 2022, Elijah Newren wrote: > > > On Tue, Mar 1, 2022 at 7:26 AM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx> > > > > 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@xxxxxxxxxxxxxx/ > > 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! Thanks, and while I usually am glad to see folks want to merge stuff of mine down, this one suggests core changes to the existing output sections rather than a new output section, and makes me wonder how to handle the new info without -z[2]. Since this command is meant for the plumbing-level, I'd like to avoid solidifying it too early -- at least until we can handle the current usecases. So even though everyone else is saying to merge it down, I'd rather not quite yet. [2] https://lore.kernel.org/git/CABPp-BGW39_5r8Lbt3ymR+F_=hWJcf=2e7O75vFNJ=3CEL5s=g@xxxxxxxxxxxxxx/
