From: Junio C Hamano <junkio@cox•net>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: [RFC] shallow clone
Date: Mon, 30 Jan 2006 11:25:27 -0800 [thread overview]
Message-ID: <7vzmld7c2g.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: Pine.LNX.4.63.0601301305100.20228@wbgn013.biozentrum.uni-wuerzburg.de
Johannes Schindelin <Johannes.Schindelin@gmx•de> writes:
>> > - disallow fetching from this repo, and
>>
>> Why? It's perfectly acceptable to pull from an incomplete
>> repo, as long as you don't care about the old history.
>
> Right. But should that be the default? I don't think so. Therefore:
> disable it, and if the user is absolutely sure to do dumb things, she'll
> have to enable it explicitely.
If the downstream person wants to have a shallow history of post
X.org X server core to further hack on it, I do not think of a
reason why we would want to refuse her from cloning a repository
of a fellow developer who has already done such a shallow copy.
If such a clone is done without telling the downstream that the
result is a shallow one, it is "dumb". I would agree it should
not be done. We need to propagate the grafts to the downstream
when a clone is done because of this.
By the way, please refrain from discussing .git/config vs
.git/eparate-config-files issue in this thread. My personal
feeling so far is that the information current graft represents
is good enough to support shallow clones, and if not we can
extend its semantics to support such. It can be discussed
independently if it is a good idea to move the final result
(grafts with updated semantics) to config file. Even if we end
up not doing any of the shallow cloning support we have been
discussing, moving the information in .git/info/grafts to config
might make sense. The issue is tangential.
next prev parent reply other threads:[~2006-01-30 19:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 7:18 [RFC] shallow clone Junio C Hamano
2006-01-30 11:39 ` Johannes Schindelin
2006-01-30 11:58 ` Simon Richter
2006-01-30 12:13 ` Johannes Schindelin
2006-01-30 13:25 ` Simon Richter
2006-01-30 19:25 ` Junio C Hamano [this message]
2006-01-31 11:28 ` Johannes Schindelin
2006-01-31 13:05 ` Simon Richter
2006-01-31 13:31 ` Johannes Schindelin
2006-01-31 14:23 ` Simon Richter
2006-01-30 19:25 ` Junio C Hamano
2006-01-31 8:37 ` Franck
2006-01-31 8:51 ` Junio C Hamano
2006-01-31 11:11 ` Franck
2006-01-30 18:46 ` Junio C Hamano
2006-01-31 11:02 ` [PATCH] Shallow clone: low level machinery Junio C Hamano
2006-01-31 13:58 ` Johannes Schindelin
2006-01-31 17:49 ` Junio C Hamano
2006-01-31 18:06 ` Johannes Schindelin
2006-01-31 18:22 ` Junio C Hamano
2006-02-01 14:33 ` Johannes Schindelin
2006-02-01 20:27 ` Junio C Hamano
2006-02-02 0:48 ` Johannes Schindelin
2006-02-02 1:17 ` Junio C Hamano
2006-02-02 18:44 ` Johannes Schindelin
2006-02-02 19:31 ` Junio C Hamano
2006-01-31 14:20 ` [RFC] shallow clone Johannes Schindelin
2006-01-31 20:59 ` Junio C Hamano
2006-02-01 14:47 ` Johannes Schindelin
[not found] ` <43DF1F1D.1060704@innova-card.com>
2006-01-31 9:00 ` Franck
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vzmld7c2g.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox