2

I have a rather devilish idea in my head that requires me to run different merge operations where I do not want to touch the index nor the working tree. I know about git merge-tree that I think used to do what I am requesting but it has been obsoleted (at least the possibility of providing the 3 trees and getting the resulting tree id as output). Are there other current ways to do it?

Just to be clear:

  • I do not want to mess up with histories.
  • I want to provide the base tree and the 2 tip trees.
  • And last but not least, I do not want to mess up with the index nor the working tree.

All I need as output is the resulting tree id if merge succeeds.... if there are conflicts it's ok that I get nothing.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • 2
    There's some ongoing work on this right now, but unless you want to hack on the Git internals, the thing to do is use a temporary working tree and index, it's a lot easier that way... (For the ongoing work, see the Git mailing list.) – torek Nov 01 '22 at 09:44
  • Understand.... will go into the archives to see how it is going and to keep an eye on it. Is there a thread that stands out on this? – eftshift0 Nov 01 '22 at 10:12
  • 1
    Not sure about "stands out" but start with [the most recent here](https://marc.info/?l=git&m=166729251919413&w=2), and/or look for the corresponding topic in Junio's tree (not sure where one finds that). – torek Nov 01 '22 at 11:20
  • Actually, that look _a lot_ like what I am missing at the time from `git merge-tree`. I guess I can wait a little bit until it reaches main. – eftshift0 Nov 01 '22 at 11:37
  • This is a third (?) go-around on some ideas that are getting shoved in various directions, so there's no telling when it might actually get into `next`, much less master/main. – torek Nov 01 '22 at 11:40
  • ok. Will keep that in mind. – eftshift0 Nov 01 '22 at 11:42

1 Answers1

3

While git merge-tree already improved with Git 2.37/2.38, only Git 2.40 (Q1 2023) adds the missing part you seek: "merge-tree" learns a new --merge-base option.

See commit 4cc9eb3 (24 Nov 2022), and commit 501e3ba, commit 66265a6 (11 Nov 2022) by Kyle Zhao (yefengzkk).
(Merged by Junio C Hamano -- gitster -- in commit 7576e51, 14 Dec 2022)

merge-tree.c: add --merge-base= option

Signed-off-by: Kyle Zhao
Signed-off-by: Taylor Blau

This patch will give our callers more flexibility to use git merge-tree(man), such as:

git merge-tree --write-tree --merge-base=branch^ HEAD branch

This does a merge of HEAD and branch, but uses branch^ as the merge-base.

And the reason why using an option flag instead of a positional argument is to allow additional commits passed to merge-tree to be handled via an octopus merge in the future.

Note: Specifying multiple bases is currently not supported

And:

merge-tree.c: allow specifying the merge-base when --stdin is passed

Signed-off-by: Kyle Zhao
Signed-off-by: Taylor Blau

The previous commit added a --merge-base option in order to allow using a specified merge-base for the merge.
Extend the input accepted by --stdin to also allow a specified merge-base with each merge requested.
For example:

printf "<b3> -- <b1> <b2>" | git merge-tree --stdin

does a merge of b1 and b2, and uses b3 as the merge-base.

git merge-tree now includes in its man page:

INPUT FORMAT

'git merge-tree --stdin' input format is fully text based. Each line has this format:

[<base-commit> -- ]<branch1> <branch2>

If one line is separated by --, the string before the separator is used for specifying a merge-base for the merge and the string after the separator describes the branches to be merged.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the update, @VonC. I had been keeping an eye on the patch, just not every day. Good to know it made it to `main`. – eftshift0 Dec 17 '22 at 11:04