"Vladimir Panteleev" <vladi...@thecybershadow.net> wrote in message news:op.vpwb01qttuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky <a@a.a> wrote: > >> 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. > > History rewriting in public repositories is very rare. It's a hassle for > everyone - if someone forked off the rewritten branch, they'll need to > rebase that branch on the new one. However, history rewriting can be > extremely useful for local commits. Here are a few typical use cases: > > 1) You made a typo in a commit message a few commits ago. > 2) You wish to fix something in a local commit from a while ago. This can > be done by editing the commit directly (as above), or by making the fix as > a new commit, an merging the two commits together. > 3) You wish to clean up and reorder your development history into atomic > commits, ready to be sent upstream as a patchset (very common with > open-source projects). > 4) You wish to split a subdirectory of the repository, along with all of > its history, to a separate repository. > etc. > > git provides many ways of automating common history edits - see the man > page for git-filter-branch, for some examples. >
Ahh, I see. That does sound useful then. But that does mean that any implications that would have on an incremented changeset number shouldn't be a problem in practice since it's mainly just done on private repos.