git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Shallow clone: low level machinery.
Date: Wed, 01 Feb 2006 12:27:29 -0800	[thread overview]
Message-ID: <7vbqxqbz9q.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: Pine.LNX.4.63.0602011528030.28923@wbgn013.biozentrum.uni-wuerzburg.de

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > Worse, you cannot pull from older servers into shallow repos.
>> 
>> "have X" means different thing if you do not have matching
>> grafts information, so I suspect that is fundamentally
>> unsolvable.
>
> If the shallow-capable client could realize that the server is not 
> shallow-capable *and* the local repo is shallow, and refuse to operate 
> (unless called with "-f", in which case the result may or may not be a 
> broken repo, which has to be fixed up manually by copying 
> over ORIG_HEAD to HEAD).

"If ... refuse to operate" then?  If "Then that is OK" is what
you meant to say I agree (I meant to code the client code that
way but I started only with the initial clone).  I said
"fundamentally unsolvable" because I thought you wanted it to do
something sensible without refusing even in such a case.

> Of course, the client has to know that the local repo is shallow, which it 
> must not determine by looking at the grafts file.

Sorry, I fail to understand this requirement.  Why is it "it must not"?

> If you introduce a different "have X" -- like "have-no-parent X" -- and 
> teach git-rev-list that "~A" means "traverse the tree of A, but not A's 
> parents", you'd basically have everything you need, right?

If you have such a modified rev-list, yes.  I was having doubts
about keeping an obvious correctness guarantee when doing such
"rev-list ~A".

> Yes, I agree. But again, the local repo has to know which grafts were 
> introduced by making the repo shallow.

I am not sure I understand.  grafts are grafts are grafts.  If
the other side has grafts to connect otherwise unrelated commit
objects, I suspect the cloner needs to know about them, all of
them, in order to use the resulting clone.  Also the upstream
side would need to know the altered world view the cloner has to
adjust the commit ancestry graph, at least during the cloning
and fetching, and I do not think it should be limited only to
cauterizign entries created by earlier shallow clone operations.
Manually created cauterizing entries should also count (for that
matter, grafts to stitch unrelated lines together), No?

  reply	other threads:[~2006-02-01 20:27 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
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 [this message]
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=7vbqxqbz9q.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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).