View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"Kagamin" <spam@here.lot> wrote in message 
news:ihpjji$115f$1@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> official public repo: r184
>> official public repo: r185
>> ...etc.
>>
>> Versus:
>>
>> 9f4e5ac4f0a3
>> 13cf8da225ce
>> ...etc.
>>
>> I don't know about other people, but I find the former to be far more
>> readable, far more descriptive, and actually possible to reason about. 
>> Sure,
>> the latter can be copy-pasted and it still refers to the same changeset, 
>> but
>> other then that it's meaningless gibberish.
>
> A little example: today I commited changeset 35912, and 35780 - 10 day 
> ago. Try to recall these random-looking numbers after reading a couple of 
> posts in this NG.

1. That's obviously a *lot* easier than 9f4e5ac4f0a3 and 13cf8da225ce

2. 35912 and 35780 are obviously related to each other in a certain way. I 
can tell just buy glancing that 35912 is a little over 100 commits after 
35780. And I can immediately tell that they're both *far* newer than, say, 
243. And far older than, say, 54928. Try doing that with hashes.
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"Kagamin" <spam@here.lot> wrote in message 
news:ihp46m$b3$1@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> official public repo: r184
>> official public repo: r185
>> ...etc.
>>
>> Versus:
>>
>> 9f4e5ac4f0a3
>> 13cf8da225ce
>> ...etc.
>>
>> I don't know about other people, but I find the former to be far more
>> readable, far more descriptive, and actually possible to reason about. 
>> Sure,
>> the latter can be copy-pasted and it still refers to the same changeset, 
>> but
>> other then that it's meaningless gibberish.
>
> LOL, this meaningless gibberish is usually called a unique identifier.

I don't care what it's called. *Both* of the above examples are obviously 
unique. Repo name + revision number *does* uniquey identify one and only one 
changeset. Are you deliberately missing that point?
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a@a.a> wrote:

> 2. 35912 and 35780 are obviously related to each other in a certain  
> way.  I
> can tell just buy glancing that 35912 is a little over 100 commits after
> 35780. And I can immediately tell that they're both *far* newer than,  
> say, 243. And far older than, say, 54928. Try doing that with hashes.

None of these assertions hold in a DVCS repository. Merging in or rebasing  
an old branch ruins everything.

-- 
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 22:46:44 +0200, Nick Sabalausky <a@a.a> wrote:

> Are you deliberately missing that point?

I think everyone's just annoyed how you're fiercely defending an idea that  
has a single advantage (terseness - I consider hashes unique in practice),  
but a whole slew of disadvantages, and then criticizing Git & co. for  
being "horrid" because they don't use your idea.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote:
> On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam@nospam.com> wrote:
> 
>> I think this is a fallacy. It only applies if you
>> (1) *completely disallow* any centralisation -- which I don't think 
>> ever happens in practice!
> 
> What about the Linux kernel? There's Linus's git repo, and lots of repos 
> maintained by others (e.g. Linux distros). The other distros are not a 
> superset of Linus's repo, they have their own branches with various 
> project-specific patches and backports. Git was written for this 
> specifically.

Yes, but each distro has a trunk, in which all commits are ordered by 
time. There's always an official version of every branch.

> 
>> and (2) demand that cloning a repository be an entirely read-only 
>> operation (so that the repository doesn't know how many times it has 
>> been cloned)
>> and (3) demand that the revision numbers behave exactly as they do in 
>> svn.
> 
> Then you're suggesting that the commit identifiers basically contain the 
> clone history?

Yes, I think it could be done that way. Identifier would be composed of 
clonenumber+commitnumber. Where it is the location of the original 
change. Yes, there are difficulties with this scheme, but I think they 
are the same challenges as for implementing merges on a centralised VCS 
such as Subversion. I don't think there's anything insurmountable.
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.vpxo9jz4tuzx1w@cybershadow.mshome.net...
> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a@a.a> wrote:
>
>> 2. 35912 and 35780 are obviously related to each other in a certain  way. 
>> I
>> can tell just buy glancing that 35912 is a little over 100 commits after
>> 35780. And I can immediately tell that they're both *far* newer than, 
>> say, 243. And far older than, say, 54928. Try doing that with hashes.
>
> None of these assertions hold in a DVCS repository. Merging in or rebasing 
> an old branch ruins everything.
>

I don't see how merging would cause a problem. A merge is a new commit, so 
it would get the next new revision number just like any other new commit 
would.

And from what people have been saying, rebasing is only kosher on private 
repos so any little bit of awkwardness in there woudn't be a big deal (and 
I'm not sure how awkward it would be anyway since if if you're shuffling 
history around you'd *expect* the revision numbers to change since that's 
exactly what you're doing anyway).
January 26, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a@a.a> wrote:

> "Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message
> news:op.vpxo9jz4tuzx1w@cybershadow.mshome.net...
>> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a@a.a> wrote:
>>
>>> 2. 35912 and 35780 are obviously related to each other in a certain   
>>> way.
>>> I
>>> can tell just buy glancing that 35912 is a little over 100 commits  
>>> after
>>> 35780. And I can immediately tell that they're both *far* newer than,
>>> say, 243. And far older than, say, 54928. Try doing that with hashes.
>>
>> None of these assertions hold in a DVCS repository. Merging in or  
>> rebasing
>> an old branch ruins everything.
>>
>
> I don't see how merging would cause a problem. A merge is a new commit,  
> so
> it would get the next new revision number just like any other new commit
> would.

Yes, but the commit numbers lose any meaning beyond the order in which the  
commits are added to the repository. That's barely useful, except when you  
know they're part of the same linear development history.

> And from what people have been saying, rebasing is only kosher on private
> repos so any little bit of awkwardness in there woudn't be a big deal  
> (and
> I'm not sure how awkward it would be anyway since if if you're shuffling
> history around you'd *expect* the revision numbers to change since that's
> exactly what you're doing anyway).

I meant non-destructive rebasing (not rewriting history), for example when  
backporting a feature, or when applying a feature branch on top of the  
latest master.

-- 
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 23:22:34 +0200, Don <nospam@nospam.com> wrote:

> Vladimir Panteleev wrote:
>> On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam@nospam.com> wrote:
>>
>>> I think this is a fallacy. It only applies if you
>>> (1) *completely disallow* any centralisation -- which I don't think  
>>> ever happens in practice!
>>  What about the Linux kernel? There's Linus's git repo, and lots of  
>> repos maintained by others (e.g. Linux distros). The other distros are  
>> not a superset of Linus's repo, they have their own branches with  
>> various project-specific patches and backports. Git was written for  
>> this specifically.
>
> Yes, but each distro has a trunk, in which all commits are ordered by  
> time. There's always an official version of every branch.

Ordered by time of what? Time of merging into the branch? That's not very  
useful, is it? They can't be ordered by time of authorship, for certain.

"Official" is technically meaningless in a DVCS, because no repository is  
holy by design (otherwise it wouldn't be really distributed). If the  
maintainer of a repository becomes MIA, anyone can take over without any  
problems.

>>> and (2) demand that cloning a repository be an entirely read-only  
>>> operation (so that the repository doesn't know how many times it has  
>>> been cloned)
>>> and (3) demand that the revision numbers behave exactly as they do in  
>>> svn.
>>  Then you're suggesting that the commit identifiers basically contain  
>> the clone history?
>
> Yes, I think it could be done that way. Identifier would be composed of  
> clonenumber+commitnumber. Where it is the location of the original  
> change. Yes, there are difficulties with this scheme, but I think they  
> are the same challenges as for implementing merges on a centralised VCS  
> such as Subversion. I don't think there's anything insurmountable.

Then a clone of a clone of a clone of a clone needs four clone numbers,  
plus a revision number. It'd look something like 5:1:2:1:1056.

-- 
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.vpxphnlmtuzx1w@cybershadow.mshome.net...
> On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a@a.a> wrote:
>
>> Are you deliberately missing that point?
>
> I think everyone's just annoyed how you're fiercely defending an idea that 
> has a single advantage (terseness - I consider hashes unique in practice), 
> but a whole slew of disadvantages,

Terseness is not at all the only advantage. As I've said before, you can 
reason about them, compare them, and get a general idea of "where" they are 
in the history. I don't think merging or "changing the past" conflict with 
that. And I'm really not seeing any non-trivial disadvantages.


> and then criticizing Git & co. for  being "horrid" because they don't use 
> your idea.
>

What? Are you actually trying to claim that defending/promoting one's own 
idea when another idea exists is a *bad* thing? Seriously?

If we're going to go that absurd route, I can just make up the claim people 
are ganging up on me for having an idea that just happens to be different 
from Git's world-view. If Git does something one way then that *must* be the 
best way, right? Anything else is obviously just heresy, right? Bring on the 
stakes and torches, we're going to Salem!!
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.vpxqfimjtuzx1w@cybershadow.mshome.net...
> On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a@a.a> wrote:
>
>> "Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message
>> news:op.vpxo9jz4tuzx1w@cybershadow.mshome.net...
>>> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a@a.a> wrote:
>>>
>>>> 2. 35912 and 35780 are obviously related to each other in a certain 
>>>> way.
>>>> I
>>>> can tell just buy glancing that 35912 is a little over 100 commits 
>>>> after
>>>> 35780. And I can immediately tell that they're both *far* newer than,
>>>> say, 243. And far older than, say, 54928. Try doing that with hashes.
>>>
>>> None of these assertions hold in a DVCS repository. Merging in or 
>>> rebasing
>>> an old branch ruins everything.
>>>
>>
>> I don't see how merging would cause a problem. A merge is a new commit, 
>> so
>> it would get the next new revision number just like any other new commit
>> would.
>
> Yes, but the commit numbers lose any meaning beyond the order in which the 
> commits are added to the repository. That's barely useful, except when you 
> know they're part of the same linear development history.
>

It may not as meaningful as an SVN repo that never does any branching. But 
it's still much more meaningful than a hash.


>> And from what people have been saying, rebasing is only kosher on private
>> repos so any little bit of awkwardness in there woudn't be a big deal 
>> (and
>> I'm not sure how awkward it would be anyway since if if you're shuffling
>> history around you'd *expect* the revision numbers to change since that's
>> exactly what you're doing anyway).
>
> I meant non-destructive rebasing (not rewriting history), for example when 
> backporting a feature, or when applying a feature branch on top of the 
> latest master.
>

I guess I still don't see the problem there. It's still a new change that 
wasn't there before, hence a newly incremented revision number. And if it 
wants to add some meta-data referring to where it was copied over from, then 
ok.
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home