View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Robert Clipsham wrote:
> You have much to learn young Padawan! May the source be with you.
                                                ^^^^^^

Fixed that for you.
January 26, 2011
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home