Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >>> I am beginning to think using "graft" to cauterize history >>> for this, while it technically would work, would not be so >>> helpful to users, so the design needs to be worked out again. >> >> Perhaps use comment for marking graft as cauterizing history? > > ? For example: # begin shallow clone <sha1 of commit 1> # no parents... - cut-off commit <sha1 of commit 2> ... <sha1 of commmit n> # end shallow clone I don't think it is very good idea, though... >> There was also talk about proposed git-splithist, which would move some >> of the history to other (historical, archive) repository. > > I stayed out from that discussion, but my impression was that > you could essentially do the same thing as what Linus did when > he started the recent kernel history since v2.6.12-rc2 without > any tool support. > > The older kernel history from BKCVS was resurrected later by > independent parties and Linus's history can be grafted onto it, > but if you have an existing history stored in git, you could do: > (1) take a snapshot of the tip of your development with "git > tar-tree HEAD"; (2) extract it into an empty repository and > start a new history; (3) build on top of the truncated history; > and (4) graft that onto the history that stopped at (1), which > you tentatively abandoned, as needed. I have thought about splitting not at current tip(s), but for example at 1 year ago. Current repository would have history cautherized using grafts (although it would be nice to have option to omit grafts and reach to historic repository), and archive/history repository ending with commits up to (but not including) the cut-off (cauterization) points. IIRC the problem with 'shallow clone' was telling which commits the clone has, and how to join commits and recauterize history. -- Jakub Narebski Warsaw, Poland - : 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