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

[Jonathan M Davis]

On Tuesday 25 January 2011 18:24:56 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.950.1296005459.4748.digitalmars-d-announce at puremagic.com...
> 
> > On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:
> >> "Ulrik Mikaelsson" <ulrik.mikaelsson at gmail.com> wrote in message
> >> news:mailman.949.1295999711.4748.digitalmars-d-announce at 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?

I don't know how encouraged it is or isn't. The way I use it most often is to do 
multiple small commits as I'm working on something and then squash them into one 
when I'm done. I could also see circumstances where it would be advantageous to 
reorder some commits - particularly if you wanted to create a branch with some 
of the newer changesets but not some of the ones just prior to them. So, I think 
that it's a highly useful feature. Still, beyond squashing multiple smaller 
commits together when I'm done working on something, I don't see a whole lot of 
value in using rebase regularly. Perhaps there's a good reason for it that I'm 
not aware of though.

Regardless, rebasing changes the tree, resulting in new SHA1 hashes for each 
commit, so it's not like you can screw up a repository without anyone who has 
branched off from it noticing. So, I'm not sure how abusable it really is on 
anything other than a one man project. So, while I can understand why rebase 
could be considered a potential problem, I think that it's well worth having.

Still, I don't really know what the "encouraged under some particular 
circumstances" would be referring to.

- Jonathan M Davis