Re: What's cooking in git.git (May 2013, #05; Mon, 20)

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

 



On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Johan Herland <johan@xxxxxxxxxxx> writes:
>> On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> * jh/shorten-refname (2013-05-07) 4 commits
>>>  - t1514: refname shortening is done after dereferencing symbolic refs
>>>  - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
>>>  - t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD"
>>>  - t1514: Add tests of shortening refnames in strict/loose mode
>>>
>>>  When remotes/origin/HEAD is not a symbolic ref, "rev-parse
>>>  --abbrev-ref remotes/origin/HEAD" ought to show "origin", not
>>>  "origin/HEAD", which is fixed with this series (if it is a symbolic
>>>  ref that points at remotes/origin/something, then it should show
>>>  "origin/something" and it already does).
>>>
>>>  I think this is being rerolled using strbuf_expand().
>>
>> Actually, that was not on my TODO. Sure, my other series ([PATCHv2
>> 00/10] Prepare for alternative remote-tracking branch location) builds
>> on top of this one, and changes a lot of the same code, but I
>> considered jh/shorten-refname a good set of changes in its own right,
>> and I didn't want it to be held up by the much longer (and probably
>> much longer-running) series.
>
> On the other hand, this itself is fixing the case nobody encounters
> in real life, and in that sense it is not urgent at all even though
> it may be a correct fix, no?  When was the last time you saw a
> refs/remotes/*/HEAD that is not a symbolic ref?
>
> If it makes it is easier for you to work on the follow-on series to
> have this shorter one already cast in stone, I do not mind merging
> this early post 1.8.3 cycle at all.  If on the other hand you are
> hit by a realization that this part could be done in a different and
> a better way (I am not saying that that is the likely outcome) when
> you will look at redoing the follow-on series using strbuf_expand
> post 1.8.3, we would regret it if we cast this part in stone too
> early.  I think we can go either way, and the above "I think this is
> being rerolld" was primarily keeping the options open.

You're right. No point in setting things prematurely in stone. I'll
fold jh/shorten-refname into the ongoing series.


...Johan

-- 
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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]