On 7/2/08, Stephen R. van den Berg <srb@cuci.nl> wrote:
quoted text
> Dmitry Potapov wrote:
>  >On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>  >> In that case, I will stick to extending git fsck to check grafts more
>  >> rigorously and fix git clone to *refrain* from looking at grafts.
>
>  >Linus suggested that "git-fsck and repacking should just consider
>  >it[grafts] to be an  _additional_ source of parenthood rather than
>  >a _replacement_ source."
>
>  >http://article.gmane.org/gmane.comp.version-control.git/84686
>
> Yes, I know that's what he suggested, the way it should be implemented
>  IMO though is by checking once without and once with regard to grafts.
>  And still it should be such that git clone disregards grafts completely.

I could see an argument that the only modes you really need are a) use
grafts as replacements, and b) use grafts as additions.  There is
perhaps no need for c) ignore grafts.

For example, say I wanted to give someone a copy of my repo that
includes grafts (ignoring the fact that this is probably bad to do in
general).  He could git-clone it and then install a copy of my grafts
file, as long as git-clone does (a) or (b) but not (c).  On the other
hand, if he just wants a copy of the "real" (graft-free) repo, then
git-clone needs to do (b) or (c) but not (a).  git-fsck needs (b), and
most normal git operations want (a) (since that was the original
purpose of grafts).

Based on that, (c) is redundant, unless you're really concerned about
not sending redundant objects to people who clone your repo that has
grafts installed.  But I think you probably shouldn't have people
cloning your grafted repository anyway unless you know what you're
doing, and if you know what you're doing, you probably want (b).  If
you see what I mean.

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html