On Thu, May 18, 2006 at 02:46:16PM -0700, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> 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@altern.org> | Debian-related: <dirson@debian.org> | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/ | Check <http://www.debian.org/> - 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.htmlReceived on Fri May 19 08:09:35 2006
This archive was generated by hypermail 2.1.8 : 2006-05-19 08:09:54 EST