Re: merge time

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Jul 30, 2007, 22:11 UTC
Message-ID: <200707310011.10935.robin.rosenberg.lists@dewire.com>
In-Reply-To: <104942.93033.qm@web51008.mail.re2.yahoo.com>

måndag 30 juli 2007 skrev Matthew L Foster:

Show 10 quoted lines

> 
> --- david@lang.hm wrote:
> 
> > On Mon, 30 Jul 2007, Matthew L Foster wrote:
> > > Local commit order is stored locally right?
> > 
> > not normally. you could enable reflogs and then mine through the reflogs 
> > to find the info, but it's not stored in any easy to access fashion.
> 
> Local merge order can be extracted from git?

Well.. depending on what your definition of merge. Yes, probably.

I dislike the term "merge" here, since no merges has to be involved, unless you include any pulled commit into the terms. Normally a merge is a commit with two or more parents. Fast forward merges are indistinguishable from normal commits.

That aside, you *can* (usually) figure the time when a commit entered the repository by examining the reflog if the set of branches are reasonably stable The reflog gives the local time when a head was modified (old and new commit) so from there you can usually go backwards. *But* that road is full of pot holes. The reflog cannot per se tell when a commit entered the local repo, it can tell when it came into view as seen from a particular head. Looking from different heads may (will) give you different times. If the head that was used to pull the commit into the repo is deleted you will not be able to tell when the commit entered the repo, nor will you be able to tell whether you can tell that or not, since the reflog for that head is gone.

The reflog doesn't list all commits, just changes to the head and it isn't necessarily linear either, ie. it may change backward in "time" forward or even to a completely separate set of commits.

The reflog is text-only: .git/logs/<ref-name>, e.g. .git/logs/refs/heads/master so you can see for yourself.

-- robin