Re: [PATCH] log: decorate detached HEAD differently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano venit, vidit, dixit 10.03.2015 03:03:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> 
>> Junio C Hamano venit, vidit, dixit 06.03.2015 20:03:
>>> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>>>>     
>>>>     Note that now a checked branch is listed twice, once as target of the
>>>>     HEAD, once as branch: They are two different refs and colored differently.
>>>
>>> The pointee of HEAD would always be branch and will always appear on
>>> the output when you show HEAD->$name_of_that_branch; is it feasible
>>> to drop the duplicate, I wonder?
>>
>> It's doable but not nice, because we cannot take the order in which refs
>> are processed for granted.
> 
> That is true, but when we format them into a single line in the
> header in response to --decorate (or %d), don't we have all of them
> already at hand---does the order still matter?
> 
> Here is an illustration of what I had in mind, made on a random
> commit I happened to have checked out that does not have your
> patches on this topic.  Half of the change is a new helper function,
> and the other half is mostly reindenting.

Yes, the patch illustrates pretty well what I meant by "doable but not
nice" :)

But I also said:

> Also, HEAD and foo are two different refs, so even if HEAD has the value
> "foo", I think we should really show them both anyways.
> 
> Alternatively, we could decorate by (HEAD, *foo, master, tag: release)
> if foo is checked out, just like branch does.

I guess I will have to apply your patch and feel what it's like in
practical use in order to change my mind...

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]