From: "Duy Nguyen" <pclouds@xxxxxxxxx>
Sent: Tuesday, July 23, 2013 2:28 AM
On Tue, Jul 23, 2013 at 2:23 AM, Philip Oakley <philipoakley@xxxxxxx>
wrote:
From: "Nguyễn Thái Ngọc Duy" <pclouds@xxxxxxxxx>
Subject: [PATCH v2 15/16] config: add core.noshallow to prevent
turning a
repo into a shallow one
Surely this should be the default now that it is possible to corrupt
a
golden repo by pushing/fetching a shallow repository to it and it
then
becomes shallow, and all the followers become shallow as well, with
consequent problems (IIUC) [PATCH v2 05/16].
It would be just as easy to change the config to core.allowshallow
which
then must be enabled by the user, and can be mentioned in the shallow
clone
option's documentation.
Clarification, it's not really "corrupt". If you have full history
from a ref "A", fetching from another shallow clone does not touch the
history of ref A at all
(that is if you do _not_ specify --depth).
I hadn't appreciated this conditional.
It
may add a a shallow ref B, which is the reason the whole repo becomes
shallow.
I had read the initial commit message (in 05/16) as implying that it was
possible to fool someone into pulling a shallow repo and that would make
their repo just as shallow (that's without a --depth argument to the
command). Had that been the case then it would have been possible to
loose some data from deep in the DAG. Glad to hear I was mistaken.
Perhaps if your comment above is included in the commit message to
ensure that clarification is there.
The same goes for push. This is not implemented, but I'm
thinking of adding "clean .git/shallow" to git repack -ad. Then if you
delete ref B and repack -ad, the repo could become full again.
But yeah, maybe defaulting to no shallow is better. Will do so in the
reroll unless someone objects.
--
Duy
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html