On Tue, Jan 30, 2024 at 9:15 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > [...] > >> opt.branch1 = branch1; > >> opt.branch2 = branch2; > > > > If branch1 and branch2 refer to trees, then when users hit conflicts > > they'll see e.g. > > > > <<<<<<< aaaaaaa > > somecode(); > > ======= > > othercode(); > >>>>>>>> bbbbbbb > > > > but aaaaaaa and bbbbbbb are not commits that they can find. > > Correct. They are what they fed as two trees to be merged, aren't > they? They (or the script that drives merge-tree and fed these two > trees) should be recognise these two trees, as long as they are told > that is what we show, no? > > > That raises the question: if the user passes trees in, should we > > require helpful names be provided as additional parameters? > > If the user wants to give human-readable name to override whatever > the code would internally produce, such new options may help them, > and should probably apply equally to input that happens to be a > commit (or a tag that is a tree-ish) as well, I would think. > > > Or are > > the usecases such that we don't expect callers to have any useful > > information about where these trees come from and these suboptimal > > conflicts are the best we can do? > > I do not necessarily think the output is "suboptimal" from the point > of view of our users, exactly because that is what they fed into the > command themselves. Yeah, I was worried though that the end user wasn't the one running the git-merge-tree command, and was trying to dig more into usage cases. Johannes example of using revision:path specification lessens my worry, and you are right to point out that we can add additional options in the future to allow overriding with more human readable names.
