Re: [RFC] git reflog show

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 24, 2006, 12:49 UTC
Message-ID: <Pine.LNX.4.63.0612241333280.19693@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20061224061151.GE7443@spearce.org>

Hi,

On Sun, 24 Dec 2006, Shawn Pearce wrote:

Show 11 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I wonder if it would make sense to teach the revision walking machinery 
> > about reflogs. A commit could be marked as coming from a reflog entry, and 
> > in that case the parents could be determined by the reflog rather than the 
> > commit itself.
> 
> The revision machinery already knows about reflogs with --reflog,
> used by git-pack-objects via git-repack.  But here its really only
> useful to seed the list of commits to be walked as part of a pack
> generation, to make sure the things referenced by the reflog stay
> around after a repacking.  And it implies --all.

Ah. I think it is a bit misnamed.

Besides, --reflog options of pack-objects, show-branch and general revision-walk based programs are independent.

I propose to change the behaviour of "--reflog" in revision.c (which should not have a big impact, since it is not even documented yet):

- if --all-reflog is passed, include all reflogs (part of the current 
  behaviour of --reflog), and
- if --reflog is passed, write the reflog messages in addition to the 
  commit lines, and rewrite the parent(s).

Show 5 quoted lines

> Rewriting the commits in memory to appear to have parents based
> on their order of appearence in the reflog would nicely generate
> a single strand of perls, but it makes it difficult to then access
> the same commit's real parents, doesn't it?  So that may make the
> revision machinary somewhat limited in some applications.

Uhm, we rewrite parents all the time. Just think about "git log Makefile".

> Besides we want the reflog message entry and not the commit message
> when we perform pretty output, etc.  So really we are then talking
> about generating synthetic commit objects for the reflog data.

Yes, but if we have to read the reflog anyway to determine the logical (local) parent, we can just as well read the message, and display it, too.

What it buys us is that we do not duplicate efforts here, and we can easily visualize the reflog in gitk, too.

Ciao, Dscho