Shallow clones vs blame/log

Shallow clones vs blame/log

[Piotr Krukowiecki]

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

Re: Shallow clones vs blame/log

[Jeff King]

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

> 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...

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.

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

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).

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

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