Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > I am against a new command for what essentially serves the original > purpose of `merge-tree`. > > The fact that `merge-tree` has not seen any work in almost 12 years is > testament not only to how hard it was to disentangle the work-tree > requirement from the recursive merge (it is one of my favorite > counterexamples when anybody claims that you can easily prototype code in > a script and then convert it to C), but the fact that there is no user > within Git itself (apart from t/t4300-merge-tree.sh, which does not count) > speaks volumes about the design of that `merge-tree` tool. > > So it's only fair to breathe life into it by letting it do what it was > meant to do all along. My "Yup" would not weigh as much as one that Linus (whose original merge-tree survived this long without seeing much enhancements) might give us, but he is busy elsewhere so you guys have to live with mine ;-) As to its output, I do agree that "we give a tree when it is already usable to record in a new commit" is a valuable option to have. The original behaviour should be made available somehow, for those who built their workflow (including scripts) around it, though.
