Shallow clones vs blame/log

Hi,

I'd like to confirm: when doing shallow clone with --depth=n, and then using blame, git does know only about n last revisions. For each change that happened before shows "^commit" where "commit" is n+1 commit ?

I wonder if this can be more clear. I was bitten by this today. I was using blame on a file and it showed a commit and author for a line. But the line was not changed in that commit. Took me a while to understand that it's caused by shallow copy...

I could be blamed for not reading git-blame man, but luckily ^commit is not described there ;)

Also, git-log puts all not cloned commits into last not cloned commit, and there's no information that it's a "fake" commit.

Example:

/tmp$ mkdir r && cd r && git init && echo a > a && git add a && git
commit -a -m first && echo b > b && git add b && git commit -a -m
second && echo aa >> a && git commit -a -m third && echo bb >> b &&
git commit -a -m fourth  && cd ..
warning: templates not found /home/piotr/share/git-core/templates
Initialized empty Git repository in /tmp/r/.git/
[master (root-commit) 890ec47] first
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
[master f969fda] second
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 b
[master 20c3c2c] third
 1 files changed, 1 insertions(+), 0 deletions(-)
[master 9dcd745] fourth
 1 files changed, 1 insertions(+), 0 deletions(-)

/tmp$ DIR=clone1;  git clone --depth 1 file:///tmp/r $DIR && cd $DIR
&& git log --stat --oneline
Cloning into clone1...
warning: templates not found /home/piotr/share/git-core/templates
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
Receiving objects: 100% (7/7), 515 bytes, done.
remote: Total 7 (delta 0), reused 0 (delta 0)
9dcd745 fourth
 b |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
20c3c2c third
 a |    2 ++
 b |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

/tmp/clone1$ git blame a ^20c3c2c (Piotr Krukowiecki 2011-03-02 20:42:53 +0100 1) a ^20c3c2c (Piotr Krukowiecki 2011-03-02 20:42:53 +0100 2) aa

/tmp/clone1$ git blame b ^20c3c2c (Piotr Krukowiecki 2011-03-02 20:42:53 +0100 1) b 9dcd7453 (Piotr Krukowiecki 2011-03-02 20:42:53 +0100 2) bb

On Wed, Mar 02, 2011 at 08:51:27PM +0100, Piotr Krukowiecki wrote:

It's not just shallow copy, but any time you have limited the traversal. So you could do "git blame v1.5.0..v1.6.0 wt-status.c", and lines that come from v1.5.0 or before are attributed to v1.5.0 with the carat.

The magic name for this is "boundary commits". See the "-b" option for an alternative way of viewing them.

Yes, we seem not to describe the regular output in very much detail at all (nor mention the "^" syntax in the description of porcelain output), which we probably should.

We do mention in the "specifying ranges" section that unchanged lines will be blamed to the boundary commit. Part of the problem is that you didn't realize you had a range because you were using a shallow clone. But I wonder if that information would be more appropriate when introducing shallow clones in git-clone(1).

Same issue. The bottom end of a shallow clone has no parents, and log's diffs show root commits as giant creation events.

Maybe it would be nice if the log output somehow noted that it was not a real root commit, but rather the endpoint of a shallow clone, regardless of whether there is a diff being shown. Because it is also potentially confusing to do "git log", scroll to the bottom, and think that is the very first commit, when it's not (and you could deepen your repository if you wanted).

I think all of this is due to the fact that shallow clones were tacked on after the fact, and are not all that commonly used.

Patches welcome (for docs or for log), of course.

-Peff