On Wed, Jul 02, 2008 at 07:32:03PM +0200, Stephen R. van den Berg wrote: > Also, the graft mechanism specifically is intended as a temporary > solution until one uses filter-branch to "finalise" the result into a > proper repository which becomes cloneable. Grafts are _much_ older than filter-branch and I'm not sure where did you get this idea; do we claim that in any documentation? > >The fact that git-filter-branch (and earlier cg-admin-rewrite-hist) > >respects grafts, and rewrites history so that grafts are no-op and are > >not needed further is a bit of side-effect. > > I beg to differ. It's not a side effect, it's the proper way to get > rid of the grafts file. Grafts are temporary and ugly. In proper > repositories they are a sign of transition to a proper state. > The proper state is attained by using git filter-branch. There's nothing ugly or necessarily temporary about grafts. One example of completely valid usage is adding previous history of a project to it later. First, you don't need to carry around all the archived baggage you are probably rarely going to access anyway if you don't need to; changing a VCS is ideal cutoff point. Second, you don't need to worry about doing perfect conversion at the moment of the switch. Third, even if you think you have done it perfectly, it will turn out later that something is wrong anyway. Fourth, it may not be actually _clear_ what the canonical history should be. Consider linux-kernel, you can graft the BitKeeper history (or one of possible candidates for the ideal conversion, though one is AFAIK clearly favoured), or you could also graft commit-per-tarball history even from the times before BitKeeper; you certainly don't want either in the current main history DAG. -- Petr "Pasky" Baudis The last good thing written in C++ was the Pachelbel Canon. -- J. Olson -- 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
