From: Yann Dirson Date: Mon, 21 Nov 2005 22:30:00 GMT Subject: Re: [RFC] Applying a graft to a tree and "rippling" the changes through Message-ID: <20051121223000.GK3393@nowhere.earth> In-Reply-To: <20051121022428.GB7902@kiste.smurf.noris.de> On Mon, Nov 21, 2005 at 03:24:28AM +0100, Matthias Urlichs wrote: > If you need a new HEAD *anyway*, then re-basing your trees would > IMHO be a better solution. Hell, that does look like a nice solution using current git - thanks. I'll have to dig into that, and I'll come back if/when I hit its limits too hard ;) > I seriously doubt that all of this is worth the effort, given that you > can do the same thing with a graft line... Well, unfortunately there is still some things to get ironed out before we have grafts propagated without yet another wrapper - which ends up with them being still really private at that time. But then, grafts may povide an inexpensive scratch space, which could then be carved into rebased objects when the historian gets happy with his work. > and most people could care > less whether their histor starts at 2.6.11-whatever, 2.4, or 0.11. Right ! But then someone will occasionally want to use a release before the start of his history, and it would be a shame to force full kernel history on all poor developers who only need fresh-enough code. But I still think we could reconcile those 2 approaches, if we would allow partial history lines (ie, signing eg. commit chain from 2.6.n to 2.6.(n+1), with the initial commit starting on a tree and not a faked "commit from nil"). This would indeed a generalisation of what we have, since we only have a signed chain of commits from 2.6.12rc2 in the official repo - and maybe one more ancient from bk history. It would even formally acknowledge that we do not have the whole of the real history, and it would leave the Unknown to be well-delimited, for any explorers who would want to rebuild it, in case it would have any value, IP-wise. And, more practically, where will the current kernel repo be when its size will be 100 or 10000 times its current size ? That would allow to split it without too many problems. Best regards, -- Yann Dirson | Debian-related: | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/ | Check