Re: whither merge-tree?

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

 



On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:

> I dug this all the way down to your cb93c19 (merge-one-file: use common
> as base, instead of emptiness., 2005-11-09), which states that the goal
> is just to get:
> 
> 	common file contents...
> 	<<<<<< FILENAME
> 	version from our branch...
> 	======
> 	version from their branch...
> 	>>>>>> .merge_file_XXXXXX
> 	more common file contents...
> 
> But that seems to be what we produce now. Did all of this simply predate
> xdl_merge, and the crappy rcs merge did not bother minimizing the diff?
> That certainly seems to be the case in my tests.
> 
> If that is the case, I think we can get rid of the complex
> create_virtual_base(), as well.

So here is what I would propose:

  [1/3]: merge-one-file: use empty blob for add/add base
  [2/3]: merge-tree: drop generate_common strategy
  [3/3]: xdiff: drop XDL_EMIT_COMMON

I briefly wondered if there were any bugs in merge-one-file around this
"no newline at end of file" issue. But there shouldn't be. It generates
the common file by applying the diff to the first file with "--no-add",
which should do the right thing, I think.

I stopped short of dropping the create_virtual_base function in the
first patch, for reasons explained there. But if we were to do so, I
suspect we could deprecated and eventually drop "apply --no-add", too.

-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]