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.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
