From: Julien Cretel <j.cretel@umail.ucc.ie>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Should "git log --decorate" indicate whether the HEAD is detached?
Date: Mon, 16 Feb 2015 23:40:27 +0000 [thread overview]
Message-ID: <CACdBeKnWJvUmFaHNrzcX7LtovOLu3PFaeTyoUAUeC7wmYUboDg@mail.gmail.com> (raw)
In-Reply-To: <xmqqa90d4fdp.fsf@gitster.dls.corp.google.com>
On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Julien Cretel <j.cretel@umail.ucc.ie> writes:
>
>> As of Git 2.3.0, the output of "git log --decorate" is ambiguous as to
>> whether the HEAD is detached or not.
>
> It sounds as if you are reporting some regression, but has any
> version of Git ever done so, or is this just a new feature that
> does not exist yet?
Apologies; I should have explained myself better. I'm not reporting a
regression;
as far as I can tell, "git log --decorate" has always been ambiguous
in that way.
>
>> More specifically, consider the following output of "git log --decorate":
>>
>> 4d860e9 (HEAD, master, dev) Remove trailing whitespace
>>
>> Whether the HEAD is attached to master or detached, the output is the same.
>> Could/should "git log --decorate" be modified to provide this information?
>> Perhaps something along the lines of
>>
>> 4d860e9 (HEAD -> master, dev) Remove trailing whitespace
>>
>> or
>>
>> 4d860e9 (HEAD = master, dev) Remove trailing whitespace
>>
>
> I personally do not see a need for such a differenciation. Why does
> one even need to know, and is it worth the cost of computing at the
> runtime?
I believe the "--decorate" flag to be quite popular. I personally like to run
"git log --decorate --graph --oneline --all" to quickly get an idea of the state
of a repo. In my experience, many users do the same, to the point that they
feel the need to define an alias for this command; see the top answers to
http://stackoverflow.com/q/1057564/2541573.
My problem with the current output of "git log --decorate" is the asymmetry,
so to speak. If the HEAD is detached but pointing at a commit that isn't any
branch's tip, then the user can be sure the HEAD detached; however, if at
least one branch points to the current commit, there is no way to tell.
I must admit I haven't given much thought about the cost involved, but I can't
imagine performance would take a big hit. Would it?
>
> Most of the time when I am on detached HEAD it is either a few
> commits behind a tip, or a few commits ahead of a tip.
next prev parent reply other threads:[~2015-02-16 23:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 22:42 Should "git log --decorate" indicate whether the HEAD is detached? Julien Cretel
2015-02-16 23:15 ` Junio C Hamano
2015-02-16 23:40 ` Julien Cretel [this message]
2015-02-18 10:15 ` Michael J Gruber
2015-02-18 13:19 ` [RFC/PATCH] log: decorate detached HEAD differently Michael J Gruber
2015-02-18 17:07 ` Should "git log --decorate" indicate whether the HEAD is detached? Junio C Hamano
2015-02-18 19:45 ` Michael J Gruber
2015-02-18 19:49 ` Junio C Hamano
2015-02-19 9:52 ` Michael J Gruber
2015-02-19 11:13 ` Julien Cretel
2015-02-20 8:13 ` Junio C Hamano
2015-03-06 16:15 ` [PATCH] log: decorate detached HEAD differently Michael J Gruber
2015-03-06 16:20 ` Michael J Gruber
2015-03-06 19:03 ` Junio C Hamano
2015-03-09 9:16 ` Michael J Gruber
2015-03-10 2:03 ` Junio C Hamano
2015-03-10 10:34 ` Michael J Gruber
2015-03-10 13:53 ` [PATCHv2 0/2] log decorations for HEAD Michael J Gruber
2015-03-10 13:53 ` [PATCHv2 1/2] log-tree: properly reset colors Michael J Gruber
2015-03-10 13:53 ` [PATCHv2 2/2] log: decorate HEAD with branch name Michael J Gruber
2015-03-10 17:06 ` [PATCHv2 0/2] log decorations for HEAD Junio C Hamano
2015-03-11 8:02 ` Michael J Gruber
2015-03-23 10:36 ` Julien Cretel
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACdBeKnWJvUmFaHNrzcX7LtovOLu3PFaeTyoUAUeC7wmYUboDg@mail.gmail.com \
--to=j.cretel@umail.ucc.ie \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).