Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
- From
Yann Dirson <ydirson@altern.org>
- Date
- May 18, 2006, 22:52 UTC
- Message-ID
- <20060518225216.GC6535@nowhere.earth>
- In-Reply-To
- <20060518222045.GB6535@nowhere.earth>
On Fri, May 19, 2006 at 12:20:45AM +0200, Yann Dirson wrote:
Show 26 quoted lines
> 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.
To make my point maybe more clear: if someone really wants to make a graft permanent, wouldn't some history rewriting (eg. with cg-admin-rewritehist, but see the patch I posted against it) be the way to go, instead of relying on out-of-band transfer of graft data ?
--
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/>