January 26, 2011
"Ulrik Mikaelsson" <ulrik.mikaelsson@gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce@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?


January 26, 2011
Robert Clipsham wrote:
> You have much to learn young Padawan! May the source be with you.
                                                ^^^^^^

Fixed that for you.
January 26, 2011
On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:
> "Ulrik Mikaelsson" <ulrik.mikaelsson@gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce@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.

- Jonathan M Davis
January 26, 2011
On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky <a@a.a> wrote:

> That's the same exact concept, isn't it? My understanding is that a clone of
> a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, you
> have to specify "which repository". The "common dev" repository. The "main
> stable repository". The "only shared repository this small project actually
> has". Or "Bob's repository" for what little that would be worth.

OK, I see your point. However, I would avoid using such a way to refer to commits, where mistaking one half of it may still point towards a commit, however a completely unrelated one.

> But it's extremely rare not to have at least one *common* repository that
> everyone pushes/pulls to.

Um, why do you think people wrote DVCS systems? They could have just souped up SVN with local commits and proper merging etc. (I heard SVN was going to do that anyway.)

> I don't understand why you think I'm claiming anything of the sort.

I was under the impression you thought commit numbers somehow magically propagated themselves throughout all clones of the repository ("distinct repository was ambiguous"), since I saw no point in referring to a revision number that's only valid for the copy on your hard drive. I didn't think you implied the scenario of making your repository remotely accessible.

> There are plenty of things about *any* DVCS that are going to confuse people
> who try to treat it like SVN. If that was a valid reason not to do something
> a certain way, then Hg/Git/etc would all have to *be* SVN.

An analogy to this mis-feature would be D compiling valid C code in a subtly different manner than C. D explicitly avoids this, with good reason.

>> Also, saying that SHA-1 hash collisions are "very  rare" is a bit of an
>> understatement.
>>
>
> Point is, it's possible and it's going to happen at least to someone, and
> frankly, such things *have* happened. Winning the lottery and getting hit by
> lighting are *extremely* rare, and yet there are a *lot* of people who have
> had it happen. The problem is they're taking "rare" (doesn't matter what
> superlative is used) and pretending it's the same as "impossible". Airplane
> crashes and major earthquakes are extremely rare, but they sure as hell plan
> for what happens should such an event occur.

I think you're more likely to simultaneously get hit by a lightning and crushed by a falling airplane during an earthquake than encountering a hash collision in your repository.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
January 26, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.950.1296005459.4748.digitalmars-d-announce@puremagic.com...
> On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:
>> "Ulrik Mikaelsson" <ulrik.mikaelsson@gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce@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?



January 26, 2011
"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:op.vpv8w0pctuzx1w@cybershadow.mshome.net...
> On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky <a@a.a> wrote:
>
>> I don't understand why you think I'm claiming anything of the sort.
>
> I was under the impression you thought commit numbers somehow magically propagated themselves throughout all clones of the repository ("distinct repository was ambiguous"), since I saw no point in referring to a revision number that's only valid for the copy on your hard drive. I didn't think you implied the scenario of making your repository remotely accessible.
>

Well, normally there's at least *some* repository that's remotely accessible, otherwise nobody would (or even could) be doing any cloning or pulling or pushing (and you'd be left with a single-user private SVN with better merging).

I agree that referring to a revision number that's only valid on your own local repo is of questionable benefit if it's not remotely accessible. However, I do think it makes sense to refer to a revision number on whatever remotely accessible repo inevitably does exist.



January 26, 2011
On Tuesday 25 January 2011 18:24:56 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.950.1296005459.4748.digitalmars-d-announce@puremagic.com...
> 
> > On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:
> >> "Ulrik Mikaelsson" <ulrik.mikaelsson@gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce@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
January 26, 2011
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:vladimir@thecybershadow.net
January 26, 2011
On Wed, 26 Jan 2011 04:40:03 +0200, Nick Sabalausky <a@a.a> wrote:

> Well, normally there's at least *some* repository that's remotely
> accessible, otherwise nobody would (or even could) be doing any cloning or
> pulling or pushing (and you'd be left with a single-user private SVN with
> better merging).

Thus the question is - does Hg even allow you to (easily) inspect revision numbers of an arbitrary remote repository? Are they preserved while cloning? Also, how would you look up the revision number of a specific commit in another repository? By its hash? Why not just give other people the hash directly? :)

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
January 26, 2011
"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:op.vpwb01qttuzx1w@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.