Dennis Kaarsemaker <[email protected]> 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".
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.
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?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
