Path filtered history not maximally simplified

Path filtered history not maximally simplified

[Johannes Sixt]

While investigating a path-filtered history in gitk, I noticed a layout
like this:

     --A---------M--4--N
        \       /     /
         1--2--3-----5

There are no commits displayed on the upper line between A and M.
Shouldn't this have been simplified to:

                  4--N
                 /  /
     --A--1--2--3--5

The gitk command used is simply:

     $ gitk some/file

and if I run

     $ git log some/file

then M is reported with two parents (so it's not gitk's fault). The above
is just the most recent part of the history; there's a lot more older
history, and it is non-trivial with numerous merges (in the complete
history). In particular, there _are_ commits on the upper branch between A
and M, but none of them touches some/file.

Do I need to adjust my expectations or does this look like a bug?

-- Hannes

PS: This is with 1.5.5.rc0.21.g740fd.

Re: Path filtered history not maximally simplified

[Johannes Sixt]

Johannes Sixt schrieb:
> While investigating a path-filtered history in gitk, I noticed a layout
> like this:
> 
>      --A---------M--4--N
>         \       /     /
>          1--2--3-----5
> 
> There are no commits displayed on the upper line between A and M.
> Shouldn't this have been simplified to:
> 
>                   4--N
>                  /  /
>      --A--1--2--3--5

Ok, it turns out that M is an evil merge, i.e. the file in M is different
from both A and 3, but in such a way that it does not show up in a diff
--cc that has only 3 lines of context. In particular, one of the commits
1, 2, 3 added a single line at an isolated spot in the file, and I undid
that addition in the merge commit M.

Sorry for the noise.

-- Hannes

(So, *that's* why they are called "evil"!)

Re: Path filtered history not maximally simplified

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Ok, it turns out that M is an evil merge, i.e. the file in M is different
> from both A and 3, but in such a way that it does not show up in a diff
> --cc that has only 3 lines of context. In particular, one of the commits
> 1, 2, 3 added a single line at an isolated spot in the file, and I undid
> that addition in the merge commit M.
>
> Sorry for the noise.
>
> -- Hannes
>
> (So, *that's* why they are called "evil"!)

Just a nomenclature, but independent changes merged trivially cleanly are
"normal" merges, not evil.

Evil merges are the ones that actually change the result in such a way
that new lines in --cc output do not have _any_ counterpart in any of the
parents.