Hi, On Wed, 20 Sep 2006, Linus Torvalds wrote: > On Wed, 20 Sep 2006, Petr Baudis wrote: > > > > I personally don't think "throwing away" history is an issue. You can > > print the old sha1 and it is still in the database so you can recover > > it. > > No it isn't. Once you've lost the reference, you can't really depend on it > any more in the long run. Exactly. And to add to that: you can lose the reference just by being not fast enough. Example: Some time ago, Junio was playing with colour in the output of git. He was doing so in some branch he pulled into 'pu'. A few days later, he dropped it. Now, I was lucky enough to have fetched pu within the short time span where colour was part of 'pu', and some days (or weeks, don't remember) later, I found some more time to play with the thing again, and eventually submitted a patch reintroducing the colour thing. So, you can lose things you actually never had! Another, even more serious problems with rebasing: You can introduce a bug by rebasing. Meaning: git-rebase can succeed, even compilation is fine, but the sum of your patches, and the patches you are rebasing on, is buggy. And there is _no_ way to bisect this, since the "good" version can be gone for good. These two problems, combined with my love of history, make me never use rebased branches myself, especially since I basically use git for projects which I work on alone, just to synchronise between different sites. As for the problem git-rebase tries to solve: you can get a clean branch by cherry-picking what you have into a temporary branch, for the sole purpose of being history clean. Ciao, Dscho - 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