From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC] shallow clone
Date: Tue, 31 Jan 2006 12:28:39 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.63.0601311127490.25248@wbgn013.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <7vzmld7c2g.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 30 Jan 2006, Junio C Hamano wrote:
> 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.
Okay. But in their case, they'll probably do what was done with Linux:
start afresh. If you want to have the old history, you can import it and
merge it via a graft.
> 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.
That was my point. As long as you don't make sure the client handles the
shallow upstream gracefully, it is dangerous. At the moment, there are too
many code parts relying on the completeness of the repository (local and
remote).
Since I wrote this, I realized that the problem I saw is not limited to
shallow upstream, but there is a subtle issue with shallow downstreams,
too:
Just imagine this: Alice starts a project, Bob makes a shallow copy from
it when Alice just reverted an experimental feature. Then, Alice decides
the experimental feature was not bad at all and reverts the revert. Bob
pulls from Alice: Alice's upload-pack assumes Bob already has the original
files (now re-reverted), and Bob ends up with a broken repository.
While writing the last paragraph, it became clear to me that the shallow
thing is very fragile: IMHO it is impossible to be fully backwards
compatible (remember: you should not force anybody to upgrade).
> By the way, please refrain from discussing .git/config vs
> .git/eparate-config-files issue in this thread.
Okay. I will shut up on that issue.
> 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.
No. The grafts are more powerful. I have quite a few repos here in which I
heavily work with grafts, and they are no cutoffs for shallow repos. They
are hard links between different lines of development. For example, I use
them to map merges in cvsimported projects, thus fixing a shortcoming of
CVS. Also, you can "add" history.
If you now rely on the grafts file to determine what was a cutoff, you may
well end up with bogus cutoffs.
Ciao,
Dscho
next prev parent reply other threads:[~2006-01-31 11:28 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
2006-01-31 11:28 ` Johannes Schindelin [this message]
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
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=Pine.LNX.4.63.0601311127490.25248@wbgn013.biozentrum.uni-wuerzburg.de \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.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).