Git repository bug

I found a bug in the git repository:

git blame README-CVS gives the following output at the end:

9eb55816 (Mikael Brandström       2002-04-06 20:49:08 +0000 250)   o A descripti
9eb55816 (Mikael Brandström       2002-04-06 20:49:08 +0000 251)   o If you know
9eb55816 (Mikael Brandström       2002-04-06 20:49:08 +0000 252)     variables a
9eb55816 (Mikael Brandström       2002-04-06 20:49:08 +0000 253)   o Or, if you
9eb55816 (Mikael Brandström       2002-04-06 20:49:08 +0000 254)     bugfix alon

but these lines are older, and were copied from the file README.  Even
CVS gets the annotations correct here, because in fact the ,v file was
copied:

1.9          (nilsson  16-Oct-01):   o A description of what it is that bugs and when.
1.11         (jhs      15-Feb-02):   o If you know how, then also give us a backtrace and dump of vital
1.10         (nilsson  05-Nov-01):     variables at the point of crash.
1.11         (jhs      15-Feb-02):   o Or, if you found the error and corrected it, just send us the
1.10         (nilsson  05-Nov-01):     bugfix along with a description of what you did and why.

(OTOH, the CVS repository will of course give you incorrect results if
 you check out an old version of Pike, as README-CVS will appear
 alongside README even before it shoud exist.)

[Stephen R. van den Berg]

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>I found a bug in the git repository:

It's not a bug in the git repository.  The git repository is fine, and
this kind of errors never changes that (not now, and not in the future).
The bug is in the git blame command.

In this case, someone copied the file and modified it before checking in
the copy.  In order to help git, a fake commit in between, where the
file is unmodified would probably "fix" git blame (and is probably the
recommended practice for anyone copying and modifying files, if at all
possible), however, git already deals with this.

Check out the difference between:

git show 9eb55816
git show --find-copies-harder 9eb55816

There should be a similar difference between

git blame 9eb55816
git blame --find-copies-harder 9eb55816

But there isn't, so that is a bug (I'd say).  But the nice thing is, this
bug can be fixed without corrupting repositories.

I'm not quite sure how the --find-copies-harder can be made the default.

BTW, this is my /etc/gitconfig:

[alias]
        c = commit -a -m
        packall = !rm -rf .git/ORIG_HEAD .git/FETCH_HEAD .git/index .git/logs .git/info/refs .git/objects/pack/pack-*.keep .git/refs/original .git/refs/patches .git/patches .git/gitk.cache && git prune --expire now && git repack -a -d --window=200 && git gc
        copystrain = !git-copystrain
        newroot = !git-newroot
        newbranch = !git-newbranch
        removeattics = !git-removeattics
        makepatch = format-patch -k --stdout
        applypatch = am -k --whitespace=nowarn
        stgmail = !git-stgmail
        edit = !git-edit
        getcommit = !git-getcommit
        putcommit = !git-put-commit
        appendgrafts = !git-appendgrafts
        cvscommit = cvsexportcommit -v -c -u -w
[repack]
        UseDeltaBaseOffset = true
[diff]
        renames = copies
[svn]
        noMetadata = true
        addAuthorFrom = true
        useLogAuthor = true
[pack]
        compression = 9
#        threads = 2
[user]
        name = Stephen R. van den Berg
        email = srb@...


Ah yes, and one more generic tip...
If you are juggling with patches (in your local branches), I suggest you
take a look at "stg" (it's a supporting package to git).

Try the following on a branch of yours:

git checkout mybranch
stg init
stg uncommit -n 10
stg pop
stg pop
stg series

Now change a file.

stg refresh
stg push -a

Et voila, commit changed in the past without much effort.
--
Sincerely,
           Stephen R. van den Berg.

How many weeks are there in a lightyear?

[Stephen R. van den Berg]

Stephen R. van den Berg wrote:
>Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>There should be a similar difference between

>git blame 9eb55816
>git blame --find-copies-harder 9eb55816

That should have read:

git blame README-CVS
git blame --find-copies-harder README-CVS
--
Sincerely,
           Stephen R. van den Berg.

How many weeks are there in a lightyear?

[Stephen R. van den Berg]

Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>>There should be a similar difference between

>That should have read:

>git blame README-CVS
>git blame --find-copies-harder README-CVS

It turns out that git blame doesn't understand the --find-copies-harder
option (yet), but does understand the equivalent -C -C (which git diff
and show understand as well).

git blame -C -C README-CVS

will allow git to traverse back through copy-modify-commit history.
--
Sincerely,
           Stephen R. van den Berg.

How many weeks are there in a lightyear?

>git blame -C -C README-CVS
>
>will allow git to traverse back through copy-modify-commit history.

Ok.  It seems that I was right about the performance problem with git
blame though.  "git blame -C -C" on this file takes 34 seconds.
"svn blame" and "cvs annotate" both give the desired result in about 1
second.

[Stephen R. van den Berg]

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>>git blame -C -C README-CVS

>>will allow git to traverse back through copy-modify-commit history.

>Ok.  It seems that I was right about the performance problem with git
>blame though.  "git blame -C -C" on this file takes 34 seconds.
>"svn blame" and "cvs annotate" both give the desired result in about 1
>second.

True (in this case).

To address the problem in a more generic fashion:
- SVN can make note of special copy/rename/move operations in its
  repository; if you don't use those, SVN is not able to supply the
  required information at all.
- Git, in a sense, has similar special copy/rename/move operations in
  its repository; they take the form of needing a commit with the
  unmodified copied/moved/renamed file, at least one commit *prior* to
  the commit which modifies the file.  If you do so, git's performance
  is higher than SVN's when using blame or annotate.
  The nice thing is that even if you forget to tell git the file has
  moved (i.e. you modify the copied/moved/renamed file before
  committing), it still has a way of connecting history (at the cost
  of more CPU-cycles).

  This means that, in order to keep up performance for blame, I'd need
  to verify there is an unmodified commit before the actual
  modifications; this can be easily verified and retrofitted into the
  git repository (in many cases it already is).
--
Sincerely,
           Stephen R. van den Berg.

How many weeks are there in a lightyear?