From: "Duy Nguyen" <pclo...@gmail.com>
Sent: Tuesday, July 23, 2013 2:28 AM
On Tue, Jul 23, 2013 at 2:23 AM, Philip Oakley <philipoak...@iee.org> wrote:
From: "Nguyễn Thái Ngọc Duy" <pclo...@gmail.com>
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to