Petr Baudis wrote: >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? Not in direct documentation, but it is what breaths down from posts on the mailinglist like: http://kerneltrap.org/mailarchive/git/2008/6/10/2085624 Jakub Narebski: >Then if possible use git-filter-branch to make history recorded in >grafts file permanent... Petr Baudis wrote: >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. That depends on the project, of course, and is not a valid statement in general. Part of the charm of full history is that git-blame and git-bisect work, at arbitrary points in the past. >Second, you don't need to worry about doing perfect conversion at the >moment of the switch. Well, you do, if you intend to make it cloneable. >Third, even if you think you have done it perfectly, it will turn out >later that something is wrong anyway. Not necessarily. I have automated the checkout-verification-process which basically checks out every revision from the respective old repository and binary-compares it with the corresponding revision in the git repository. This ensures a full binary match across the board. With respect to historical merges, I agree, those might not be completely correctly grafted, but the level of correctness can be determined at will, and once we achieve somewhere around 99% accuracy, we consider it done (for this project). >Fourth, it may not be actually _clear_ what the canonical history should >be. That depends on the project. In my project it *is* clear, so this point doesn't make any difference. -- Sincerely, Stephen R. van den Berg. This is a day for firm decisions! Or is it? -- 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
