On 1 Apr 2009 at 9:54, Matthieu Moy wrote:
> "Ulrich Windl" <ulrich.windl@xxxxxxxxxxxxxxxxxxxx> writes:
>
> >> Not to mention that you can have multiple roots (multiple commits with
> >> no parent) in git repository; besides independent branches (like
> >> 'man', 'html' or 'todo') it is usually result of absorbing or
> >> subtree-merging other projects. In 'master' branch there are 5 roots
> >> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> >> and subtree-merged gitk and git-gui. And here you would again have
> >> multiple commits with the same number...
> >
> > Which would not harm, because it would be version N from committer X. Any if
> > committer X merges from anything else, the next number would be > N. I did not
> > claim that my method makes a total ordering of commits and merges possible.
>
> Neither does it make the numbers unique for committer X.
>
> If commiter X commits a successor to commit N, it's labeled N+1. If
> later, he creates another branch from commit N, and commit, the new,
> other commit will be labeled N+1.
Correct: They live in a parallel universe. But on the long term they will either
vanish or be merged in which case the number will be "> N+1" (on the main branch).
So we have a branch plus a sequence number all the time.
>
> This means even within a repository, you cannot say things like
> "commit number N", so, OK, you have numerical IDs, but you can't use
> them.
I never wanted to have such a thing (using those numbers for commit).
>
> What can be interesting is that a commit takes
> max{all commits in repository}+1, not just max{parents} + 1. Then, you
> have local revision numbers, but they're not stable. Indeed, that's
> precisely what Mercurial does.
That would be a (temporary) total ordering, which I did not want, exactly for that
reason.
[I did not intend the following use case]
Ulrich
>
> But I'm not sure how much simplicity it adds compared to the confusion
> it adds. Newbies will see Mercurial identifiers as
>
> changeset: 2:699b81a5851b
> changeset: 1:fd4b6597548f
> changeset: 0:58cff172192e
>
> And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
> stuff beside is useless". And one day, he'll send a mail, post a
> bugreport, or whatever, saying "I have a problem with revision number
> 42", and no one else but him will know which revision is called "42".
>
> > I truly believe in unique IDs, but they are just not handy in every situation.
>
> Usually, people find Git IDs to be non-handy until the find out they
> can cut-and-paste only the first few digits in most cases, like
> 442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).
>
> --
> Matthieu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
