From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>, Jeff King <peff@peff.net>,
Lars Schneider <larsxschneider@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail
Date: Thu, 3 Dec 2015 12:03:37 -0800 [thread overview]
Message-ID: <CAGZ79kbtOEMk2woY5rovvC4xduiQRsKp+BXVt=5h9d76tpLWSA@mail.gmail.com> (raw)
In-Reply-To: <xmqq7fkx7qsa.fsf@gitster.mtv.corp.google.com>
On Tue, Dec 1, 2015 at 2:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not think you would need a new option for this, by the way.
>> Just add a new syntax for the LFS of a refspec that cannot possibly
>> be confused with existing choices of what can come there (i.e. an
>> empty string to denote deletion, or a partial refname), e.g. come up
>> with an appropriate string in $sign and allow the following:
>>
>> $ git fetch ${sign}c78f7b5ed9dc
>> $ git fetch ${sign}c78f7b5ed9dc:refs/remotes/origin/frotz
That looks good to me.
>
> Instead, we should limit us to 40-hex object name and nothing else
> in the initial incarnation.
ok, will do.
>
> i.e.
>
> $ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
> $ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07:refs/remotes/origin/frotz
>
> If the remote end (which, as Peff pointed out earlier, already knows
> how to respond to a fetch request for an exact object when
> configured to do so) allows such a fetch to go through, "fetch" can
> (and will) update the ref named by the RHS of storing refspec with
> the current code, so there is no need to do anything special to
> support this.
>
> As to ${sign}, I was tempted to say an empty string might be
> sufficient (i.e. "do not use 40-hex as your branch name"), but it
> probably is a bad idea.
I would think if sign is empty string the server will check if the given
40-hex is unique (either a branch named so, while there is no such
object or just that object and not branch/tag) or the remote would
reject due to disambiguation. This possibility can be done later though.
> A single dot "." would be a possibility
> (i.e. a ref component cannot begin with a dot), but squating on it
> and saying "anything that begins with . must be followed by 40-hex
> (and in the future by an extended SHA-1)" would rob extensibility
> from us, so perhaps ".@c78f7b5ed9dc1c6edc8db06ac65860151d54fd07" or
> something?
My gut reaction is to reject that notation, as it is very cryptic.
Looking at the @ sign, it reminds me of the reflog notion such as HEAD@{-1}.
So maybe it would be more appealing to specify
HEAD@{c78f7b5ed9dc1c6edc8db06ac65860151d54fd07}
to mean a specific commit. By saying HEAD we indicate it is not meant as
a branch (both on the remote as well as locally).
By having the @{ sequence this would also be dis-ambiguous from any
branch.
> That is leading "." denotes "this is an extended refspec"
> and the next character denotes what kind of extended refspec it is.
> For now we say that "@" denotes "exact object name is used instead
> of a(n abbreviated) refname".
So using @ as you propose I could also specify .@refs/heads/master as
an un-abbreviated ref?
Did you have any reason to pick . specifically or are we welcome to bikeshed
why a colon might be better? (or ":", "?", "[", "\", "^", "~", SP, or TAB)
We could use [id]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
or [const]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07 ?
Looking at the big picture here, this being a preparation for improving
submodule cloning, we also want to allow tags here?
next prev parent reply other threads:[~2015-12-03 20:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 9:37 [PATCH v2] add test to demonstrate that shallow recursive clones fail larsxschneider
2015-11-12 23:34 ` Stefan Beller
2015-11-15 12:43 ` Lars Schneider
2015-11-13 5:35 ` Jeff King
2015-11-13 18:41 ` Stefan Beller
2015-11-13 23:16 ` Stefan Beller
2015-11-13 23:38 ` Jeff King
2015-11-13 23:41 ` Jeff King
2015-11-14 0:10 ` Stefan Beller
2015-11-16 18:59 ` Jens Lehmann
2015-11-16 19:25 ` Stefan Beller
2015-11-16 21:42 ` Jens Lehmann
2015-11-16 22:56 ` Stefan Beller
2015-11-17 19:46 ` Jens Lehmann
2015-11-17 20:04 ` Stefan Beller
2015-11-17 20:39 ` Jens Lehmann
2015-11-17 20:49 ` Stefan Beller
2015-11-17 21:00 ` Jens Lehmann
2015-11-17 20:17 ` Duy Nguyen
2015-11-17 21:43 ` Jeff King
2015-11-18 12:32 ` Duy Nguyen
2015-11-18 21:11 ` Jeff King
2015-11-18 21:36 ` Stefan Beller
[not found] ` <CAOE36qj2m4e3hw73-QoLbbpGv4RiyhBt_ou7eN4i4q8pF15rdA@mail.gmail.com>
2015-11-19 13:58 ` Jeff King
2015-11-30 18:11 ` Junio C Hamano
2015-12-01 0:47 ` Stefan Beller
2015-12-01 12:15 ` Duy Nguyen
2015-12-01 21:47 ` Junio C Hamano
2015-12-01 22:22 ` Junio C Hamano
2015-12-03 20:03 ` Stefan Beller [this message]
2015-12-04 15:32 ` Junio C Hamano
2015-12-04 16:15 ` Junio C Hamano
2015-12-04 7:52 ` Duy Nguyen
2015-11-15 12:53 ` Lars Schneider
2015-11-17 21:34 ` Jeff King
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='CAGZ79kbtOEMk2woY5rovvC4xduiQRsKp+BXVt=5h9d76tpLWSA@mail.gmail.com' \
--to=sbeller@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/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).