Re: Should "git log --decorate" indicate whether the HEAD is detached?
On Thu, Feb 19, 2015 at 3:13 AM, Julien Cretel wrote: > On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano wrote: > >> Julien's "HEAD=master, other" vs "HEAD, master, other" may be >> subdued enough to be undistracting, I would guess. I do not think >> the distinction between "HEAD = master" and "HEAD -> master" would >> be useful, on the other hand. > > Just to clarify, I suggested these two notations as alternatives for > denoting the same state: "HEAD is attached to master". They were not > meant to denote different states. Accordingly, a detached HEAD could > be denoted by "HEAD, master, other" (i.e. the same as the current > output of "git log --decorate"). That makes it even better than my misunderstood version ;-) A list that is usually "A, B, C" that sometimes has "A, B=C" is inconspicuous enough not to be distracting too much, I would say. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano wrote: > Julien's "HEAD=master, other" vs "HEAD, master, other" may be > subdued enough to be undistracting, I would guess. I do not think > the distinction between "HEAD = master" and "HEAD -> master" would > be useful, on the other hand. Just to clarify, I suggested these two notations as alternatives for denoting the same state: "HEAD is attached to master". They were not meant to denote different states. Accordingly, a detached HEAD could be denoted by "HEAD, master, other" (i.e. the same as the current output of "git log --decorate"). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Junio C Hamano venit, vidit, dixit 18.02.2015 20:49:
> Michael J Gruber writes:
>
>> Yep, it very well is. Also, that approach would tell you which branch is
>> checked out, though I don't consider that git log's business.
>>
>> OTOH, it's "backwards" in the sense that it marks the "ordinary" case
>> (HEAD is symref, branch is checked out) specially compared to the
>> "exceptional/dangerous" case (HEAD is ref, detached).
>
> Both are ordinary and there is nothing exceptional or dangerous
> about your HEAD temporarily being detached during a "rebase -i"
> session, for example.
Sure, that's why I put it in quotes. That's only how it is perceived by
some users, and I suppose it's that kind of users that we are trying to
help here.
>> And status, branch
>> will point out that latter case more verbously, too.
>
> Yeah, but as you said, that is not "log"'s business.
I still think decorations "detached HEAD" resp. "HEAD" for the two cases
are more natural, if we want to include any additional information at
all. Just think of:
deadbeef (HEAD=master, topicbranch, tag: v1)
log/rev-list is about commit objects. All the refs above resolve to the
same commit, so why are only two of them equal?
In fact, they are very unequal, since HEAD would be "ref:
refs/heads/master" whereas master would "deadbeef". They are equal in
the other (detached) case! I'm not telling you any news here, I just
want to point out how badly misleading that notation is.
So, I would suggest to "decorate the decorations", by saying something
like "detached HEAD", and maybe some version of "HEAD at master" (I'd
prefer just "HEAD") and possibly more info on the tags ("s-tag" or
"signed tag" etc).
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Michael J Gruber writes: > Yep, it very well is. Also, that approach would tell you which branch is > checked out, though I don't consider that git log's business. > > OTOH, it's "backwards" in the sense that it marks the "ordinary" case > (HEAD is symref, branch is checked out) specially compared to the > "exceptional/dangerous" case (HEAD is ref, detached). Both are ordinary and there is nothing exceptional or dangerous about your HEAD temporarily being detached during a "rebase -i" session, for example. > And status, branch > will point out that latter case more verbously, too. Yeah, but as you said, that is not "log"'s business. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Junio C Hamano venit, vidit, dixit 18.02.2015 18:07: > Michael J Gruber writes: > >> "git branch" will tell you your branches and which one is checked out >> (or HEAD); "git status" will tell you the latter. >> >> "git log" is about the DAG which has absolutely nothing to do with what >> you have currently checked out. > > Yeah, that summarizes my reaction, too. More importantly, "log" is > about showing commits and "--decorate" is a way to enrich the > presentation of commits---it talks about commits in terms of refs; > the command and the option is not about describing refs and their > relationships. > > I do not terribly mind showing the fact that HEAD points at a branch > when --decorate talks about HEAD, partly because we will be showing > both HEAD and the branch name _anyway_ in the output. But I am not > sure if the extra bit of information is more helpful to the readers > or being distracting. > > Julien's "HEAD=master, other" vs "HEAD, master, other" may be > subdued enough to be undistracting, I would guess. I do not think > the distinction between "HEAD = master" and "HEAD -> master" would > be useful, on the other hand. We already know that the names listed > all refer to the same commit, which means that we do not have to say > "HEAD is detached" explicitly as long as we have a way to say "HEAD > points at this branch". If HEAD is listed and is not marked to > point at another branch that is shown, by definition it is detached, > no? > Yep, it very well is. Also, that approach would tell you which branch is checked out, though I don't consider that git log's business. OTOH, it's "backwards" in the sense that it marks the "ordinary" case (HEAD is symref, branch is checked out) specially compared to the "exceptional/dangerous" case (HEAD is ref, detached). And status, branch will point out that latter case more verbously, too. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Michael J Gruber writes: > "git branch" will tell you your branches and which one is checked out > (or HEAD); "git status" will tell you the latter. > > "git log" is about the DAG which has absolutely nothing to do with what > you have currently checked out. Yeah, that summarizes my reaction, too. More importantly, "log" is about showing commits and "--decorate" is a way to enrich the presentation of commits---it talks about commits in terms of refs; the command and the option is not about describing refs and their relationships. I do not terribly mind showing the fact that HEAD points at a branch when --decorate talks about HEAD, partly because we will be showing both HEAD and the branch name _anyway_ in the output. But I am not sure if the extra bit of information is more helpful to the readers or being distracting. Julien's "HEAD=master, other" vs "HEAD, master, other" may be subdued enough to be undistracting, I would guess. I do not think the distinction between "HEAD = master" and "HEAD -> master" would be useful, on the other hand. We already know that the names listed all refer to the same commit, which means that we do not have to say "HEAD is detached" explicitly as long as we have a way to say "HEAD points at this branch". If HEAD is listed and is not marked to point at another branch that is shown, by definition it is detached, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Julien Cretel venit, vidit, dixit 17.02.2015 00:40:
> On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano wrote:
>> Julien Cretel 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.
"git branch" will tell you your branches and which one is checked out
(or HEAD); "git status" will tell you the latter.
"git log" is about the DAG which has absolutely nothing to do with what
you have currently checked out.
Your expectation may come from the fact that the default argument to
"git log" is HEAD; or from what "gitk" and other ui tools do.
On the other hand, our decorations can be considered "wrong" in the
following sense: if HEAD is a symref it really points to a (branch) ref,
not a commit. In this situation, "HEAD" should be the decoration of the
branch ref, not of the commit which the branch ref resolves to.
But that would apply to annotated tags, as well: they point to tag
objects (and should decorate them by the logic above) rather than commit
objects.
So, what "log --decorate" really and consistently does is resolving
("peeling") any decorating reference until it points to a commit object,
and decorate that.
A --decorate-detailed mode which does without the peeling could be
elucidating - that would need markers for (branch) refs and tag objects
in addition to commit objects, though (and an extension of the machinery).
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano wrote: > Julien Cretel 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should "git log --decorate" indicate whether the HEAD is detached?
Julien Cretel 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? > 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? 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
