|Re: [jgit-dev] "instable" diff algorithms lead to wrong merge results|
On Wed, Nov 24, 2010 at 4:23 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: >> >> From what Junio explained to me, it sounds like the "lines of context" >> rule used by C Git is sort of an accident. > > It was no accident. The merge code is all mine, and if you do not ask me > about it, well, you can only guess what the intention was, Shawn. Sorry, I was banging out an email off-the-cuff the other day to Christian, I didn't want to bother cracking open git log to see who mucked with or wrote the merge code, or when this particular feature occurred. It seemed like too much effort to simply point out to Christian that the C implementation of merge uses a lines of context rule. And so does RCS, because I remember that from the dark days of using CVS and even RCS. Too many folks have contributed to C Git to always remember who wrote what, when, or what they had done intentionally vs. what was simply an accident. I'm glad you are still lurking around here to set the record straight where my own memory is incomplete or infallible. > The idea was that the merge would be not only a 3-way merge, but that due > to the setup of Git, we would know exactly that the base is really a base > version from which two different lines of development started. > > So there is effectively 1 (or 0.5, depending on your interpretation) line > overlap, since if boundaries touch, the diffs are evaluated as conflicting > (unless some enterprisey person managed to slip changes to the core merge > machinery by me ever since I wrote it). That's an interesting approach. Boundaries touching is sufficient? No need for a higher value? -- Shawn.
Back to the top