Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:18

Possibly related (same subject, not in this thread)

Johannes Schindelin [off-list ref] writes:
quoted
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help