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

[ message continues ]

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

[ message continues ]

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

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


--

[ message continues ]

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


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

[ message continues ]

You might find this useful:

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

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

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

=2D-=20
Thomas Rast
trast@{inf,student}.ethz.ch
[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]