"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.950.1296005459.4748.digitalmars-d-annou...@puremagic.com... > On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote: >> "Ulrik Mikaelsson" <ulrik.mikaels...@gmail.com> wrote in message >> news:mailman.949.1295999711.4748.digitalmars-d-annou...@puremagic.com... >> >> > Again, version-number + repo is not 100% when history-rewrite is >> > possible. >> >> "History-rewrite" is new to me. Does that just mean branching off from a >> past revision? If not, do you have a link that explains it? > > You can do stuff like re-order and squash commits. Look at the man page > for git- > rebase. >
Ok, I just took a look at it here: http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html Maybe it's just my inexperience with DVCSes, but everything in there seems like the sort of thing I would consider much better off accomplished by just simply creating a new branch that re-applies changesets from an existing branch (or in most cases of removing changesets, committing a new changeset that undoes the undesired ones) instead of screwing around with the history. And if some joker's been spamming a repo with a bunch of garbage commits, then ok, maybe have something to delete that old junk branch. But aside from that sort of special case, I don't see what good can come from encouraging removal of the old branch versus just simply adding a new one or committing an "undo" changeset. In other words, history-rewriting seems to trade in the reliability of a stable history for...apperently some benefit that I'm having trouble seeing (Just so that you can? I kinda doubt that would be the reason though, especially if Torvalds is heavily involved.) Ulrick mentioned that history rewriting is "encouraged under some particular circumstances". What circumstances would those be?