W dniu 21 marca 2011 13:24 użytkownik Jeff King <peff@xxxxxxxx> napisał: > 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 Why commit 4 is displayed here (changes only file2) ? # git log with graph works here OK. It displays six -- five .. -- three .. - one .In this case results shouldn't be similar to gitk ? git log --graph --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 > -- Pozdrawiam, Michał Łowicki -- To unsubscribe from this list: 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