[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] "instable" diff algorithms lead to wrong merge results
|
Hi,
On Wed, 24 Nov 2010, Shawn Pearce wrote:
> On Wed, Nov 24, 2010 at 12:07 AM, Christian Halstrick
> <christian.halstrick@xxxxxxxxx> wrote:
> >> Do you consider "lines of context" when you do this?
> >
> > No, I don't. I think that is the reason why we merge differently in
> > JGit than in C Git. I'll add these checks to the merge algorithm and
> > see if we become more compatible for cases. That's my main goal - to
> > give the same results as C Git. I am glad we finally found a hint how
> > to solve this.
>
> From what Junio explained to me, it sounds like the "lines of context"
> rule used by C Git is sort of an accident. The merge algorithm is using
> the hunk header line positions for the edit blocks, and the diff
> algorithm computed those with the default lines of context setting. This
> happened as an accident of the way the diff algorithm worked and wasn't
> exactly something planned.
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.
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).
> But I think this dates back all the way through RCS diff/merge.
Why guess if asking is an option?
The merge machinery in Git is not based on any code in RCS. Everybody who
attended the "Alles wird Git" in Berlin knows the true story behind Git's
merge implementation. And if I hadn't been driven out of Git development,
everybody attending the GitTogether would have heard the story, too.
> RCS merge probably executed diff, then used the hunk headers as the
> line offsets when building the "edit list".
I haven't even looked at RCS merge because I did not want to be bound by
their license. (Someone I used to respect back then claimed that BSD is a
better license than GPL and I wanted to be free to choose a different
license.)
> Because that was easier than fixing the line numbers based on the lines
> of context presented. Later someone realized this behavior was probably
> a good thing, and started claiming it as a feature. :-)
Git's merge did not evolve like this.
Ciao,
J
