"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:op.vpxqmbpftuzx1w@cybershadow.mshome.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?

Why wouldn't it be? It didn't exist in that branch befoe, and then it was added to that branch.  "Feature X was introduced in Version 2.31 and didn't exist in the 1.x line. But then Feature X was backported to the 1.x line at time Y / revision Y, which was right after we fixed 1.x's bug A and right before we fixed 1.x's bug B". What's wrong with that? Seems perfectly sensible to me.

On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:
> "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!!

LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it.

Personally, I'm not about to claim that git does everything the best way possible, but I find it much more pleasant to deal with than svn. Other distributed VC systems may be better. There may be a better way that hasn't been found yet. I don't know. But I _do_ find git to be a major improvement over svn.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.974.1296080574.4748.digitalmars-d-announce@puremagic.com...
> On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:
>> "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!!
>
> LOL. I think that part of what it comes down to is that you're making a
> big deal
> out of what other people don't consider to be a big deal at all.

Heh, fair enough :)

> Personally, I
> don't care much about the revision number. Having incrementally increasing
> ones
> might be nice, but if you don't have them, oh well. Obviously, you feel
> much
> more strongly about it.
>

I tend to be really bothered by "steps backwards" that I don't see as being necessary. Seems to be a common theme with me.

Mercurial gives every revision two numbers:

"""
changeset: This field has the format of a number, followed by a colon,
followed by a hexadecimal (or hex) string. These are identifiers for
the changeset. The hex string is a unique identifier: the same hex
string will always refer to the same changeset in every copy of this
repository. The number is shorter and easier to type than the hex
string, but it isn't unique: the same number in two different clones
of a repository may identify different changesets.
"""
example--
changeset:   0:0a04b987be5a

http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html -- see section: "A Tour Through History"

Is that the kind of thing you're wanting?

--bb

On Wed, Jan 26, 2011 at 2:37 PM, Nick Sabalausky <a@a.a> wrote:
>
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.974.1296080574.4748.digitalmars-d-announce@puremagic.com...
> > On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:
> >> "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!!
> >
> > LOL. I think that part of what it comes down to is that you're making a
> > big deal
> > out of what other people don't consider to be a big deal at all.
>
> Heh, fair enough :)
>
> > Personally, I
> > don't care much about the revision number. Having incrementally increasing
> > ones
> > might be nice, but if you don't have them, oh well. Obviously, you feel
> > much
> > more strongly about it.
> >
>
> I tend to be really bothered by "steps backwards" that I don't see as being necessary. Seems to be a common theme with me.
>
>
>

Nick Sabalausky Wrote:

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

Well, I was talking more about the "gibberish" statement. I was surprised how a programmer calls unique identifier - a well known concept - a gibberish.

As to revision numbers, well, it could be a nice feature to support hash identifiers with any attached text, which is just ignored by git, but helps people think about them... does hg work this way, I wonder?

Vladimir Panteleev wrote:
> 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).

Yes, in theory that's true. In practice, I don't believe it.
Just because you're using a DVCS doesn't mean you have no project organisation whatsoever. There's always going to be a repository that the release is made from.

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

No. Just one repository number, and one revision number. You just need to be sensible in how the clone numbers are assigned. That's easy.
Basically every repository has a number of clone numbers it can assign.
Every clone gets a subset of that range. Dealing with the situation when the range has run out is a bit complicated, but quite doable, and there are steps you can take to make it a very rare occurence.

I'm not have almost zero interest in this stuff, so I won't say any more. I'm really just commenting that it's not difficult to envisage an algorithm which makes exposing a random hash unnecessary.

"Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.977.1296083661.4748.digitalmars-d-announce@puremagic.com...
>
>Mercurial gives every revision two numbers:
>
>Is that the kind of thing you're wanting?
>

Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.

On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a@a.a> wrote:
> "Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.977.1296083661.4748.digitalmars-d-announce@puremagic.com...
>>
>>Mercurial gives every revision two numbers:
>>
>>Is that the kind of thing you're wanting?
>>
>
> Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.

I think it's very handy for all the reasons you said.  I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max.  Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system.  Globally unique identifiers aren't needed for that.  It looks like Bzr does something similar.  Not sure why Git hasn't gotten this particular nicety.

--bb

Nick Sabalausky wrote:
> "Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.977.1296083661.4748.digitalmars-d-announce@puremagic.com...
>> Mercurial gives every revision two numbers:
>>
>> Is that the kind of thing you're wanting?
>>
> 
> Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.
> 
	Of course, Git does not have it! Svn has it so it *must* be a bad
idea ;)

		Jerome

PS: FWIW, I agree with you. Plus, there is another use case where sequential number are very useful: each time you want to operate on a past revision in your own repository (e.g "hg up n" or "hg diff -r n"), it is much easier to designate that revision with a sequential number than with the hash.
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:
> On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a@a.a> wrote:
[ . . . ]
> > Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.
> 
> I think it's very handy for all the reasons you said.  I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max.  Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system.  Globally unique identifiers aren't needed for that.  It looks like Bzr does something similar.  Not sure why Git hasn't gotten this particular nicety.

Bazaar does indeed have revision numbers per branch.  Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder