Git log can not show history before rename

mkdir tt3 cd tt3 git init-db touch a.c git add a.c git commit -a -m "test1"

git mv a.c b.c git commit -a -m "rename"

modify b.c git commit -a -m "test2"

git log -C -M -- b.c
========================================
commit 8d55ed63d2048d41bde8c34dafc52c6a965d61ed
Author: Frank Li <lznuaa@gmail.com>
Date:   Fri Jan 30 19:20:10 2009 +0800
    test2
commit af0214f7d32cf97fda2743e7d906305e6de2e9a2
Author: Frank Li <lznuaa@gmail.com>
Date:   Fri Jan 30 19:19:15 2009 +0800
    rename
=========================================

I can't get history before rename.

2009/1/30 Frank Li <lznuaa@gmail.com>:

"git init"

[...]

You asked to restrict the search to the b.c path.

You want:

git log --follow -- b.c

Man git-log:
       --follow
           Continue listing the history of a file beyond renames.

HTH, Santi

Santi Béjar <santi@agolina.net> writes:

Or use

  $ git log -C -- b.c a.c

(you don't need '-M' option, as '-C' is superset of it).

Note that '--follow' works for simple histories, but (as it is quite new invention) doesn't work yet for all cases, like for example subtree merge or equivalent.

Does it conflict with --parents? When I use --follow and --parents together, parents can't rewrite. without --follow, parent can rewrite.

2009/1/30 Santi Béjar <santi@agolina.net>:

[Please, don't top post, and quote only what you are replying to]

2009/1/30 Frank Li <lznuaa@gmail.com>:

I think there are no obvious reasons to conflict and they could work together, but as Jakub just said, --follow is quite new and only works well with simple history and simple cases.

Santi

Santi Béjar wrote:

You might find this useful:

  $ git config alias.renames
  !GIT_PAGER="grep -v '^$' | sort -u" git --paginate log --follow --name-only --pretty=format:"" --

Slow and hacky, but works nice enough in practice. The intended use case is like

  $ gitk --complicated-rev-options $(git renames git-svn.perl)

On Fri, Jan 30, 2009 at 10:52:13PM +0100, Thomas Rast wrote:

Related (but also slow and hacky :) ), it is sometimes nice to see not the whole history of a file, but all of the commits, in the usual log order, that ended up affecting the outcome of a set of content (so not any commits whose work was later overwritten). I posted a short script for it a while back:

  http://article.gmane.org/gmane.comp.version-control.git/99278

-Peff

On Fri, 30 Jan 2009, Frank Li wrote:

Yes. --follow and --parents do not play well together.

That's simply because --follow is a total hack, meant to just satisfy ex-SVN users who never knew anything about things like parenthood or nice revision graphs anyway.

It's not totally fundamental, but the current implementation of "--follow" is really a quick preprocessing thing bolted onto the revision walking logic, rather than beign anything really integral.

If you want --follow to really work together with --parents (and to do the right thing wrt merges etc - different renames coming in through different branches), you'd really have to rewrite the whole --follow logic.

One approach is to use --follow as the quick hack it is - and then when you see "oh, file X was renamed from file Y", and you want to see the nice full history, you go back to the native git model (which is not --follow), which is based on pathname pattherns, and then do

	gitk -- X Y

to see the history of _both_ names, and now the rename will show up properly (and now you'll get proper parenthood because you're no longer using the hackish --follow thing).

If somebody wants to do a more intelligent --follow, I can only applaud, but I'm personally not likely to look into it.

			Linus

On Fri, 30 Jan 2009, Linus Torvalds wrote:

Side note: you can probably get a _limited_ form of parent rewriting on top of --follow by adding some more hacks. IOW, I think you can make --parents --follow work better in practice even with the hacky thing by adding some more hacks on top. But you'll never get the _true_ answer (ie get things right across renames in different branches) without totally ripping out the current --follow logic.

Interestingly, I suspect that doing --follow "right" is really quite complicated, but one sign of doing it right would be to allow multiple files to be tracked at the same time.

Because in a "correct" implementation of --follow you'd literally have to attach different filenames to different commits (rather than have one global filename that you follow and then switch for everybody when you see a rename), and also have the ability to track multiple files per commit when you reach the same commit under two filenames.

I really never wanted the pain, and never cared enough for it, which is why --follow is such a hack. It literally was designed as a "SVN noob" pleaser, not as a "real git functionality" thing. The idea was that you'd get away from the (broken) mindset of thinking that renames matter in the big picture.

			Linus