From: Vincent van Ravesteijn <vfr@lyx.org>
Date: Thu, 06 Feb 2014 16:08:16 GMT
Subject: Re: Confusing git log --- First time bug submission please advise on best practices
Message-ID: <CAAH6HY8unuytrKpEA-eisojUkG=X4D+o+vQDO5bC5YCSmusoHw@mail.gmail.com>
In-Reply-To: <CAJaBJzJeeEKpaTVXv+LnZd49xjnDjU25y9i_3kKNOrRPVbP-wg@mail.gmail.com>

On Thu, Feb 6, 2014 at 3:02 PM, Francis Stephens
<francisstephens@gmail.com> wrote:
>
> My co-worker has an inconsistent git log output. Please see that
> attached files for output (I've made a best effort to remove
> confidential info from them).
>
> Comparing the two log commands we can see that master and
> originssh/master have a shared common commit at
>
> <John Doe> (4 hours ago) d85832d
> More pom fixes
>
> The top commit for originssh/master and the second to top for master.
>
> I would expect that both logs would share an _identical_ history from
> that commit onward. But the log for master contains the following
>
> <Jeremy Doe> (27 hours ago) 239ea21 (my-work)
> renamed class
>
> <Jeremy Doe> (28 hours ago) 27750b2
> Merge branch 'master' of
> http://githost.companyname-dev.local/trading-development/sports-container-framework
>
> and
>
> <Jeremy Doe> (2 days ago) a933acb
> white space changes
>
> <Jeremy Doe> (2 days ago) b5e51e7
> Merge branch 'master' of
> http://githost.companyname-dev.local/trading-development/sports-container-framework
>
> <Jeremy Doe> (2 days ago) 3a0f787
> removed public methods
>
> <Jeremy Doe> (2 days ago) 4e91130
> added the xml deserialisation
>
> None of which appear in the originssh/master log. Is there a scenario
> in which this is expected. It was my understanding that any two
> commits with the same hash have exactly the same history.
>
> Thanks for your time.

The commits that are in the log for master and which are not in the
log for originssh/master are merged in at "6833fd4 (HEAD, master);
Completed merge".

As "git log" can only present the commits in a linear way, it shows
the commits from the ancentry of both parents of HEAD in a reverse
chronological order. This means that the commits from the two
ancestries are mixed and commits that are shown after each other don't
have to be parent and child. See the documentation of "git log" and
the section "Commit Ordering": "By default, the commits are shown in
reverse chronological order."

Vincent