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.)
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@cuci.nl
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.
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
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.
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.
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).
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Stephen R. van den Berg