Junio C Hamano wrote: > > Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes: > > > Here's my stance on it. Grafts should be a local matter. And they alter > > the world view, with a pronounciation on *view*. That's why I proposed > > that only log familiy of commands obey them[*]. And probably rev-list so > > that gitk et.al. have a way to obey them. And also the ref parser (so > > that master~20 is what it looks it is). Everything else should disregard > > grafts: repack, prune, fetch, <transfer>-pack, push etc. No nasty side > > effects anymore. > > I said you are not agreeing, but I should have said you are not > understanding. Oh, I think I understand very well. It may just be that I cannot express myself that well ;) I propose that grafts are only about *view*, not database integrity. There are no tools that manipulate grafts, that would stop the user to make some blunder; the user has to edit the file *manually*. It is wrong, wrong, wrong to let such a file dictate database integrity. > grafts can bring otherwise disconnected commits into the > altered history, so if you want your log to honor grafts, your > prune and repack need to be aware of them lest you would not > lose them. Sure, if I connect my linux repo with a graft to the historical BK tree, then toss the ref that pointed to the historical tree, then git prune: - then currently it won't prune the historical tree - but under my proposal it would. Silly me. Why did I remove that ref? -- Hannes - To unsubscribe from this list: 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