# git log broken?

3 messages from 2010-09-22 to 2010-09-22. Participants: Torgny Nyblom, Matthieu Moy, Michael J Gruber.
Thread: https://gitlist.dev/t/25194

## Torgny Nyblom, 2010-09-22 07:48

Subject: git log broken?
Message-ID: <20100922094808.07be1757@explosive.nyblom.org>
URL: https://gitlist.dev/e/20100922094808.07be1757%40explosive.nyblom.org

```
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, 2010-09-22 08:05

Subject: Re: git log broken?
Message-ID: <vpqk4mecie8.fsf@bauges.imag.fr>
URL: https://gitlist.dev/e/vpqk4mecie8.fsf%40bauges.imag.fr
In-Reply-To: <20100922094808.07be1757@explosive.nyblom.org>

```
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, 2010-09-22 08:15

Subject: Re: git log broken?
Message-ID: <4C99BB1B.90101@drmicha.warpmail.net>
URL: https://gitlist.dev/e/4C99BB1B.90101%40drmicha.warpmail.net
In-Reply-To: <20100922094808.07be1757@explosive.nyblom.org>

```
Torgny Nyblom venit, vidit, dixit 22.09.2010 09:48:
> 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

```