Re: What's cooking in git.git (May 2013, #05; Mon, 20)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 21, 2013, 15:35 UTC
- Message-ID
- <7vtxlwqrbg.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CALKQrgcmmaqAt-oVtFeem_xvqsjehacVoVJ2bYOyfKWTUzV0AA@mail.gmail.com>
Johan Herland <johan@herland.net> writes:
Show 21 quoted lines
> On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano <gitster@pobox.com> 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.
> The strbuf_expand refactoring is nice, but not really necessary until > we start using multi-wildcard patterns.