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

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

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

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

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.

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

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

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

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

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