On Thu, May 18, 2006 at 02:46:16PM -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxx> writes:
>
> > Is it/does it?
> >
> > I'd assume that if you have a graft, you _want_ the history to be hidden
> > and pruned.
> >
> > That's how you'd drop history, if you wanted to do it on purpose.
>
> I haven't looked at what the test does, but I think he is
> talking about the opposite. fsck by design does not honor
> grafts, and if you grafted a history back to your true root
> commit, that "older" history will be lost.
I'm not sure I understand what you're saying. AFACT fsck does not
ignore grafts: if a rev is not accessible from heads because of a
graft, prune drops it, and fsck does not see a problem.
Linus, I understand your point, but the current situation is
problematic: a graft does not get propagated by cg-clone (and I
suppose not by git-clone or git-fetch either), so cloning a tree which
has undergone such a pruning operation results in an incomplete clone
(indeed it is how I met the problem). Since grafts are supposed to
have local effect only (as far as I understand), I see it as a bad
indication to have such a remote effect.
Maybe to make things safe, prune should by default consider both
physical and grafted parents as accessible, and a flag could be added
to get the current behaviour for people really knowing what they're
doing ?
Best regards,
--
Yann Dirson <ydirson@xxxxxxxxxx> |
Debian-related: <dirson@xxxxxxxxxx> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
-
: 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