"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?

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

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

"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?

"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.

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

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

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

"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.