Re: [PATCH] Shallow clone: low level machinery.

From: Junio C Hamano <junkio@cox.net>
Date: Feb 1, 2006, 20:27 UTC
Message-ID: <7vbqxqbz9q.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0602011528030.28923@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 11 quoted lines

>> > 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?