From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Stefan Beller <sbeller@google.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: Tue, 01 Dec 2015 13:47:01 -0800 [thread overview]
Message-ID: <xmqqegf57sfe.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACsJy8CFCu4casNn25b1YPkV==-8kDy3wzYd5uf794R41M0Y9w@mail.gmail.com> (Duy Nguyen's message of "Tue, 1 Dec 2015 13:15:36 +0100")
Duy Nguyen <pclouds@gmail.com> writes:
> maybe
>
> git clone --commit-id <sha1> repo (*)
>
> instead. Detached head is implied, and this way you don't have to
> disambiguate sha-1 vs refname. And --commit-id can also be added in
> git-fetch. Actually the git-fetch case is even more interesting, what
> do we do with refspec..
>
> (*) as usual, we accept committish sha-1, not just comit sha-1, so
> --commit-id may be confusing..? Or maybe just go with --tag where we
> accept either tag names, tag sha-1 or commit-sha1
I agree with you that it is sensible to think this topic around
"fetch" not "clone".
I however do not think "--commit-id" is a good name for that option.
You are naming the option after what it is that is given, not after
what the commit specified with that commit-id is used for. It is
just as nonsense as renaming the "--not-merged" option used in
"branch --not-merged $commit" to "--commit-id" because the option
takes the object name for a committish.
Besides, "git fetch" can grab any object, not limited to committish,
which makes "--commit-id" a doubly unsuitable name for the option.
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
to do the obvious thing, perhaps? We could even allow some form of
extended SHA-1 expressions with some restrictions (e.g. limit its
use in a protected friendly environment to avoid excessive resource
use at the server side):
$ git fetch ${sign}c78f7b5ed9dc~12
$ git fetch ${sign}HEAD@{4}:refs/remotes/origin/frotz
The ${sign} signals two things. (1) That the endpoint of the
history (or the name of the object being fetched, be it a blob, a
tree and all its contents, a commit and everything reachable from
it, etc.) is specified and (2) that the specification will be
interpreted at the remote side.
Hmm?
next prev parent reply other threads:[~2015-12-01 21:47 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 [this message]
2015-12-01 22:22 ` Junio C Hamano
2015-12-03 20:03 ` Stefan Beller
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=xmqqegf57sfe.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/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).