From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: git log -g bizarre behaviour
Date: Tue, 02 Feb 2016 09:28:58 +0100 [thread overview]
Message-ID: <1454401738.32711.7.camel@kaarsemaker.net> (raw)
In-Reply-To: <xmqqegcwt32j.fsf@gitster.mtv.corp.google.com>
On ma, 2016-02-01 at 15:37 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
>
> > I'm attempting to understand the log [-g] / reflog code enough to
> > untangle them and make reflog walking work for more than just
> > commit
> > objects [see gmane 283169]. I found something which I think is
> > wrong,
> > and would break after my changes.
> >
> > git log -g HEAD^ and git log -g v2.7.0^ give no output. This is
> > expected, as those are not things that have a reflog.
>
> OK.
>
> > But git log -g v2.7.0 seems to ignore -g and gives the normal
> > log.
>
> That sounds clearly broken, and I think I see how that happens from
> the hacky way the "-g" traversal was bolted onto the revision
> traversal machinery.
>
> I _think_ "git log -g" (and by extension "git reflog" which is just
> a short-hand to giving a few more options to that command) ought to
>
> * Iterate over the _objects_ that used to be at the tip of the ref;
> * Show each of these objects as if they were fed to "git show".
That's what I am trying to achieve. Though not quite like 'git show', I
want to emulate the --oneline putput for non-commit objects too.
> This clearly is not possible without major surgery, including
> ripping out the hacky "-g" traversal from the revision traversal
> machinery and perhaps lifting it up a few levels in the callchain,
> as many functions in that callchain want to work on commits.
Yup. I'm planning to either split cmd_log_walk or make its behaviour
depend on whether we're traversing the reflog (don't call get_revision,
but call a new get_reflog_entry function). And then rip out the reflog
handling from revision.c and redo (parts of) reflog-walk.c to
accomodate the cmd_log_walk (split|replacement) that deals with reflogs
better.
> Contrast these two:
>
> $ git log -1 v2.7.0
> $ git show v2.7.0
>
> > I'd like to make git log -g / git reflog abort early when trying to
> > display a reflog of a ref that has no reflog. Objections?
>
> Do you mean
>
> $ git checkout -b testing
> $ rm -f .git/logs/refs/heads/testing
> $ git log -g testing
>
> will be changed from a silent no-op to an abort with error?
>
> I do not see a need for such a change--does that count as an
> objection?
No, I'd like to change:
$ ls .git/logs/refs/tags/v2.7.0
ls: cannot access .git/logs/refs/tags/v2.7.0: No such file or directory
$ git (log -g|reflog) v2.7.0
>From the bizarre behaviour above to a silent noop. But before I do that
in a rewrite (by simply not implementing it), I'd like to have that
behavior now as well and add tests for it.
--
Dennis Kaarsemaker
http://www.kaarsemaker.net
next prev parent reply other threads:[~2016-02-02 8:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-31 11:52 git log -g bizarre behaviour Dennis Kaarsemaker
2016-02-01 23:37 ` Junio C Hamano
2016-02-02 8:28 ` Dennis Kaarsemaker [this message]
2016-02-02 19:32 ` Junio C Hamano
2016-02-02 20:22 ` Dennis Kaarsemaker
2016-02-02 20:42 ` Junio C Hamano
2016-02-02 23:32 ` [PATCH] log -g: ignore revision parameters that have no reflog Dennis Kaarsemaker
2016-02-03 0:21 ` Junio C Hamano
2016-02-03 12:35 ` Dennis Kaarsemaker
2016-02-03 18:32 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1454401738.32711.7.camel@kaarsemaker.net \
--to=dennis@kaarsemaker.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).