whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:

> * jk/merge-tree-merge-blobs (2016-02-16) 1 commit
>  - merge_blobs: use strbuf instead of manually-sized mmfile_t
> 
>  "git merge-tree" (a throw-away demonstration) did not work very
>  well when merging "both sides added a new file at the same path"
>  case.
> 
>  Undecided; we might be better off deleting it altogether.

What do we want to do with this? I think there are basically three
options:

  1. Take the patch you queued above. That's the minimal fix with no
     user-visible changes.

  2. Rip out the weird add/add conflict resolution. This gets rid of the
     buggy code, makes merge-tree more like the rest of git, and I think
     lets us even drop the EMIT_COMMON stuff from xdiff).

     That lets people keep using merge-tree if they have found it useful
     over the years.

  3. Drop merge-tree completely. This deletes even more code, and helps
     the people in (2) realize that it is utterly unmaintained. :)

I think at this point I am waffling between (2) and (3). I did (1) in a
hope that I could avoid looking deeper into the code at all, but now
that I have, I do not think (2) would be so bad. I'm happy to work up a
patch, but won't bother if we think that (3) is viable.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]