Git log can not show history before rename

Git log can not show history before rename

[Frank Li]

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.

Re: Git log can not show history before rename

[Santi Béjar]

2009/1/30 Frank Li <lznuaa@gmail.com>:
> mkdir tt3
> cd tt3
> git init-db

"git init"

> 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
[...]
> I can't get history before rename.

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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Git log can not show history before rename

[Jakub Narebski]

Santi Béjar <santi@agolina.net> writes:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:

> > mkdir tt3
> > cd tt3
> > git init-db
> 
> "git init"
> 
> > 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
> [...]
> > I can't get history before rename.
> 
> 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.

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

Re: Git log can not show history before rename

[Frank Li]

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>:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:
>> mkdir tt3
>> cd tt3
>> git init-db
>
> "git init"
>
>> 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
> [...]
>> I can't get history before rename.
>
> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: Git log can not show history before rename

[Santi Béjar]

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

2009/1/30 Frank Li <lznuaa@gmail.com>:
> Does it conflict with --parents?
> When I use --follow and --parents together,  parents can't rewrite.
> without --follow, parent can rewrite.

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

Re: Git log can not show history before rename

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Santi Béjar wrote:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:
> > Does it conflict with --parents?
> > When I use --follow and --parents together,  parents can't rewrite.
> > without --follow, parent can rewrite.
> 
> 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.

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)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Git log can not show history before rename

[Jeff King]

On Fri, Jan 30, 2009 at 10:52:13PM +0100, Thomas Rast 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)

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

Re: Git log can not show history before rename

[Linus Torvalds]

On Fri, 30 Jan 2009, Frank Li wrote:
>
> Does it conflict with --parents?

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

Re: Git log can not show history before rename

[Linus Torvalds]

On Fri, 30 Jan 2009, Linus Torvalds wrote:
> 
> If somebody wants to do a more intelligent --follow, I can only applaud, 
> but I'm personally not likely to look into it.

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