threads / discuss / 25194

git log broken?

Subject: git log broken?

## tl;dr

3 messages between Sep 22, 2010 and Sep 22, 2010.

replies: 2people: 3as markdown or json

Torgny Nyblom· Sep 22, 2010, 07:48 UTC · lore

Hi,

(Resend as it got no replies and I want to be sure that is wasn't lost in the noise)

I'm working on converting the KDE subversion repository to git, as a part of this I'm trying to validate that the conversion hasn't missed any revisions or merges but when I run "git log" with different options I get (in my mind) strange results.

git log <file> -> produces a list of commits git log --follow <file> -> produces an empty list (no output) git log --name-status <file> -> no info about file

It seems like this occurs when there is a merge only commit as the first commit in the list returned by the "bare" log command.

Is there any legit situation where this might happen? If so what? If not is this a bug in my convert program or in git?

/Regards Torgny

Matthieu Moy· Sep 22, 2010, 08:05 UTC · re: Torgny Nyblom · lore

Re: git log broken?

Torgny Nyblom <kde@nyblom.org> writes:

> It seems like this occurs when there is a merge only commit as the
> first commit in the list returned by the "bare" log command.

"git log --follow" is not the best part of Git :-( (especially compared to "git blame", which is excellent at following the history of lines of code).

There were some discussion already on --follow having bad behavior on merge commit, like:

  http://thread.gmane.org/gmane.comp.version-control.git/151502/focus=151664

But no one is really investing energy to make "git log --follow" what it should really be, AFAIK.

> If not is this a bug in my convert program or in git?

Your converter cannot have "mis-imported" renames, since renames do not appear in the repository with Git.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Michael J Gruber· Sep 22, 2010, 08:15 UTC · re: Torgny Nyblom · lore

Re: git log broken?

Torgny Nyblom venit, vidit, dixit 22.09.2010 09:48:

Show 20 quoted lines

> Hi,
> 
> (Resend as it got no replies and I want to be sure that is wasn't lost
> in the noise)
> 
> I'm working on converting the KDE subversion repository to git, as
> a part of this I'm trying to validate that the conversion hasn't missed
> any revisions or merges but when I run "git log" with different options
> I get (in my mind) strange results.
> 
> git log <file> -> produces a list of commits
> git log --follow <file> -> produces an empty list (no output)
> git log --name-status <file> -> no info about file
> 
> It seems like this occurs when there is a merge only commit as the
> first commit in the list returned by the "bare" log command.
> 
> Is there any legit situation where this might happen?
> If so what?
> If not is this a bug in my convert program or in git?

Can you share this repo or (even better) create a minimal test which reproduces this?

Trying with a recent git and "some" merge commit I don't see that behaviour.

Note that, e.g., subversion needs to create commits for each tag which git-svn turns into "no-op" commits (introducing no diff). They can disappear easily if your conversion process involves rebasing or filter-branching. (I'd recommend converting those commits into annotated tags.)

Michael