D Programming Language source (dmd, phobos, etc.) has moved to github

[Nick Sabalausky]

"Vladimir Panteleev" <vladimir at thecybershadow.net> wrote in message 
news:op.vpwb01qttuzx1w at cybershadow.mshome.net...
> On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky <a at 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.