Re: gsoc - Better git log --follow support

> On Sat, Mar 19, 2011 at 08:24:20PM +0100, Michał Łowicki wrote:
>
>> I'm looking at idea about better git log --follow support from
>> https://git.wiki.kernel.org/index.php/SoC2011Ideas .There is something
>> like this - "[.. ] it does not interact well with git's usual history
>> simplification [...]". Can someone elaborate this? I've found History
>> Simplification in git rev-list man but don't know yet about issues
>> with --follow.
>
> In short, history simplification is a way of looking at a subset of the
> commit history graph, but in a way that makes it look like a complete
> graph. Imagine I have a linear history like this:
>
>  A--B--C
>
> where "A" modifies "file1", "B" modifies "file2", and "C" modifies
> "file1" again. If I ask for the history of "file1" with "git log file1",
> then git will pretend as if the graph looks like:
>
>  A--C
>
> including rewriting the parent of "C" to point to "A" (because the
> parent pointer is basically an edge in the graph).
>
> If you are just doing a straight "git log", the actual parentage is not
> that interesting. We either show commits or we don't, and we don't show
> links between them. But try "git log --graph" or "gitk", which do care
> about the edges. They want to show you a whole connected graph.
>
> Now consider --follow. It doesn't happen during the commit limiting
> phase, but instead it happens while we're showing commits. And if it
> decides a commit isn't interesting, we don't show it. That works OK for
> "git log", but it makes the graph for other things disjointed.
>
> You can see it in this example:
>
>  # make the A-B-C repo we mentioned above
>  git init repo && cd repo
>  echo content >file1 && git add file1 && git commit -m one
>  echo content >file2 && git add file2 && git commit -m two
>  echo content >>file1 && git add file1 && git commit -m three
>
>  # Now look at it in gitk; we see a nice linear graph.
>  gitk
>
>  # Now let's try it with path limiting. We see a nice subgraph that
>  # pretends to be linear, because we "squished" out the uninteresting
>  # nodes.
>  gitk file1
>
>  # Now let's make some more commits with a rename.
>  echo content >>file2 && git commit -a -m four
>  git mv file1 newfile && git commit -m five
>  echo content >>newfile && git commit -a -m six
>
>  # If we use path limiting, we'll only see the two most recent commits.
>  # We get stopped at the rename because path limiting is just about the
>  # pathname.
>  gitk newfile
>
>  # So we can use --follow to follow the rename. First let's try simple
>  # output. You should see commits 1, 3, 5, and 6, which touched either
>  # newfile or its rename source, file1.
>  git log --oneline --follow newfile
>
>  # But now look at it in gitk. Commit 4 is included as a boundary
>  # commit, but we fail to notice that it connects to three. And we
>  # don't see commit 3 connecting to anything, and commit 1 is missing
>  # entirely.
>  gitk --follow newfile

>
> Obviously this a pretty simplistic example. But you can imagine in a
> history with a lot of branching how useful this simplification is to
> understanding what happened to a subset of the tree.
>
> Jakub mentioned another example with gitweb's subtree merge not being
> found by --follow. I haven't looked into that case, but it may be
> related (or it may simply be a defect in follow finding the right
> source).
>
> -Peff
>