--- Linus Torvalds <torvalds@xxxxxxxx> wrote:
> Well, with history simplification, we still show merges that are required
> to make the history _complete_, ie say that you had
>
> a
> |
> b
> / \
> c d
> | |
>
> and neither "a" nor "b" actually changed the file, but both "c" and "d"
> did: in this case we have to leave "b" around just because otherwise there
> would be no way to show the _relationship_, even if "b" itself doesn't
> actually change the tree in any way what-so-ever.
I agree. If "c" and/or "d" changed the file but neither "a" nor "b" did,
then by (merge/diff/etc) "inheritance" we do need to leave "b" around.
(This is similar to git-blame/git-annotate which should show "b", so that
we can track down the change to "c" and/or "d".)
> > Can you consider the default case to be simplify_history=1,
> > which is currently the default behaviour of git-rev-list.
>
> Actually, for your case, you don't want _any_ merges, unless those merges
> literally changed the tree from all of the parents.
Yes, that's true. s/all/one or more:
Don't want to show a merge, unless one or more of the parents,
changed the file. If no parent changed the tree, then do not
show the commit.
> I think it would make sense to make that further simplification if the
> "--parents" flag wasn't present.
>
> Hmm. Maybe something like this..
>
> BTW! Junio, I think this patch actually fixes a real bug.
>
> Without this patch, the "--parents --full-history" combination (which
> you'd get if you do something like
>
> gitk --full-history Makefile
>
> or similar) will actually _drop_ merges where all children are identical.
> That's wrong in the --full-history case, because it measn that the graph
> ends up missing lots of entries.
>
> In the process, this also should make
>
> git-rev-list --full-history Makefile
>
> give just the _true_ list of all commits that changed Makefile (and
> properly ignore merges that were identical in one parent), because now
> we're not asking for "--parent", so we don't need the unnecessary merge
> commits to keep the history together.
>
> Luben, does this fix the problem for you?
Given Junio's analysis, and briefly looking at the logic, it does seem
correct. Let me apply it and see what I get, but I think it is a good thing.
Thanks for the patch!
Luben
-
: 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