On 27 Mar 2009 at 7:09, Jakub Narebski wrote: > "Ulrich Windl" <ulrich.windl@xxxxxxxxxxxxxxxxxxxx> writes: > > On 27 Mar 2009 at 13:49, Michael J Gruber wrote: > > > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21: > > > > [...] > > > > > Keyword substitution and cvs/svn style version numbers are independent > > > issues. The sha1 describes a commit uniquely, one could use that as a > > > keyword. > > > > However version numbers and time stamps have the property of being at least > > partially ordered in respect of "newer/older". That property does not hold for > > SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft > > Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft > > Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-) > > That is why people use output of git-describe and _tag_ their releases, > and make embedding version number in released version (tarball / binary) > the job of make: see GIT-VERSION-GEN script in git sources, and how it > is used in Makefile. OK, but imaginge someone sends you some file that originated from some git version, maybe with minor modifications. Is there a way to find out from what git version that file was derived? IMHO that's where "automatically replaced placeholders" (like $id$) make sense. > > > > > > > > > Increasing version numbers are meaningless in a true DVCS world. What is > > > your 100th commit may not be someone else's, even if both your master's > > > heads are the same! This is why hg version numbers are a local thing. > > > They are merely a local shortcut for specifying a revision and serve the > > > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them > > > work permanently, not even in a local repo, if you allow rebasing. > > > > Maybe I didn't fully understand, but having a version number that is larger than > > any parent's version numbers when doing a merge/commit doesn't look wrong to me. > > I'm sorry to dissapoint you, but without central server assigning > numbers to commits it wouldn't simply work in distributed version > control world. Take for example the following situation: somebody > clones your repository, and creates new commit on 'master' (trunk) and > it gets version number N. Meanwhile you also independently create new > commit on 'master'... and without central authority it would also get > version number N. Then you would merge (pull) his/her changes, and > you would have two commits with the same number; not something you want. Anyway the result would have number "N+1". Maybe you misunderstood: I'm not proposing to replace git's internal version numbering (SHA-1), but so introduce some more comprehensible, primitive user-level numbering. > > 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. I truly believe in unique IDs, but they are just not handy in every situation. [...] Regards, Ulrich -- 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
