{"thread":{"id":"21271","subject":"Creating something like increasing revision numbers","startedAt":"2009-10-18T14:41:58Z","lastAt":"2009-10-21T07:47:12Z","messageCount":23,"participants":["Norbert Preining","Johan Herland","alexandrul","Jon Smirl","demerphq","Daniel Barkalow","Junio C Hamano","Nicolas Pitre","Johannes Sixt","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125276","messageId":"20091018144158.GA9789@gandalf.dynalias.org","threadId":"21271","inReplyTo":null,"subject":"Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-18T14:41:58Z","receivedAt":"2009-10-18T14:41:58Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"Dear all,\n\n(please Cc)\n\nI am managing some of my projects with git and I am quite happy about it.\n\nThere is another project I am working that is quite big, the subversion\ncheckout is about 14Gb. Doing svn up is a pain, it has to open tens of\nthousands of files and directories traversing the whole tree, trashing\nthe fs cache and taking ages.\n\nMy idea was to move to git, from what I read it should be more capable\nin handling these type of projects.\n\nNow, there is one show-stopper I see. From our repository we create a\nset of \"packages\", and the maximum of the \"last-changed\" revisions of\nthe contained files determine the \"version\" of the package. This \nguarantees that any change in a file will increase the revision number\nof the package (some tricks for removals have to be done). This is necessary\nsince we are distributing the packages from servers and the version number\npf a package determines whether it should be upgraded (well known concept).\n\nNow my question, is there any way to set up something similar with git?\n\nMy idea is that git - like subversion - could (if asked to) count each\ncommit (global to the repository, irrelevant of the branch) and give it\na version number. Since we all will use a bare repository on a server\nand pull/push from/to there, I think that something similar could be possible.\n\nSo, before I delve into more gitty-nitty conversion, let me know if\nthere is any chance for that, or we should stay with subversion.\n\nThanks a lot and all the best\n\nNorbert\n\nPS: for those interested, it is TeX Live: www.tug.org/texlive\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nYONKERS (n.)\n(Rare.) The combined thrill of pain and shame when being caught in\npublic plucking your nostril-hairs and stuffing them into your\nside-pocket.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125277","messageId":"200910181703.20607.johan@herland.net","threadId":"21271","inReplyTo":"20091018144158.GA9789@gandalf.dynalias.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-10-18T15:03:20Z","receivedAt":"2009-10-18T15:03:20Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 18 October 2009, Norbert Preining wrote:\n> Now, there is one show-stopper I see. From our repository we create a\n> set of \"packages\", and the maximum of the \"last-changed\" revisions of\n> the contained files determine the \"version\" of the package. This\n> guarantees that any change in a file will increase the revision number\n> of the package (some tricks for removals have to be done). This is\n> necessary since we are distributing the packages from servers and the\n> version number pf a package determines whether it should be upgraded\n> (well known concept).\n> \n> Now my question, is there any way to set up something similar with git?\n> \n> My idea is that git - like subversion - could (if asked to) count each\n> commit (global to the repository, irrelevant of the branch) and give it\n> a version number. Since we all will use a bare repository on a server\n> and pull/push from/to there, I think that something similar could be\n> possible.\n> \n> So, before I delve into more gitty-nitty conversion, let me know if\n> there is any chance for that, or we should stay with subversion.\n\nA global, increasing version number ala SVN is fundamentally impossible in \nany distributed version control system (like Git).\n\nHowever, you can get a useful version specifier from the \"git describe\" \ncommand. It will give you back something like the following:\n\n $ git describe\n v1.0.4-14-g2414721\n\nwhere the \"v1.0.4\" part is the last tag that the current state is based on, \nthe \"14\" part is the number of commit between that tag and the current \nstate, and the \"2414721\" is the abbreviated object name (SHA1 id) for the \ncurrent commit itself.\n\nThis is somewhat more complex than a simple version number, but guarantees a \nglobally unique name for your current state that works in a distributed \nenvironment.\n\nAlso, I find \"v1.0.4-14...\" (i.e. 14 commits since v1.0.4) much more useful \nthan, say, \"12534\" (i.e. 12534 commits since the start of the project).\n\nSee 'git help describe for more info'\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"125278","messageId":"20091018152054.GA3956@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"200910181703.20607.johan@herland.net","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-18T15:20:54Z","receivedAt":"2009-10-18T15:20:54Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"On So, 18 Okt 2009, Johan Herland wrote:\n> A global, increasing version number ala SVN is fundamentally impossible in \n> any distributed version control system (like Git).\n\nYes, agreed. \n\nThe point is that I do not actually need the \"distributed\" part of git.\nI want one central repository and all collaborators commit to that.\nYes, that is subversion, I know.\n\nWe have no branches, no tags, nothing of that. Only trunk.\n\n> $ git describe\n> v1.0.4-14-g2414721\n> \n> where the \"v1.0.4\" part is the last tag that the current state is based on, \n> the \"14\" part is the number of commit between that tag and the current \n\nSo if we have only one tag (initial) then it would count the number\nof commits?\n\nAnd if yes, is it easy to find out at which commit a file has been changed\nlast time (svn status -v).\n\nI have read a lot on the net about the impossibility, and I agree that\nin a distributed setting it does not work.\n\nAnd in fact we would not even have revision numbers on our local\ngit repositories. Only one (the master checkout from which our \ndistribution server is updated) needs to have some commit numbers.\n\nTHe reason is that we use that as serial number for packages. One packages\nis roughly on package from CTAN (Comprehensive TeX Archive Network, \nlike CPAN), and we want to make sure that if that is updated on CTAN\nand we import it into our system, the next time we create a TeX Live\npackage for it (that will be served to quite a lot of users) we have\na new version number.\n\nWe first thought about using the version number as provided by authors,\nbut that is completely useless, because there are tooo many authors\nof packages on CTAN where the version numbers are in no way increasing ;-)\nSo we settled for the max of all the last changed revision number of\nthe contained files, whcih is guaranteed to increase.\n\nAs a lat resort I will try to use git-svn ...\n\nAgain, thanks a lot and all the best\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nQUOYNESS (n.)\nThe hatefulness of words like 'relionus' and 'easiephit'.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125279","messageId":"4ADB3452.6030508@gmail.com","threadId":"21271","inReplyTo":"20091018144158.GA9789@gandalf.dynalias.org","subject":"Re: Creating something like increasing revision numbers","fromName":"alexandrul","fromEmail":"alexandrul.ct@gmail.com","sentAt":"2009-10-18T15:29:22Z","receivedAt":"2009-10-18T15:29:22Z","isPatch":false,"sender":{"key":"alexandrul.ct@gmail.com","avatar":"https://gravatar.com/avatar/ccace5786472fd935f20e6a59cb13b6cfcb393ce897707b5681e70f8980afb91?d=mp&s=160"},"body":"Norbert Preining wrote:\n> My idea is that git - like subversion - could (if asked to) count each\n> commit (global to the repository, irrelevant of the branch) and give it\n> a version number. Since we all will use a bare repository on a server\n> and pull/push from/to there, I think that something similar could be possible.\n\nI was thinking to set a post-commit hook that reads the current version\nfrom a file, increment and save it, and also set a tag with that value.\n\nBeing a DVCS, this kind of versioning can only be trusted on a single repo,\nbut if you set it on the \"main\" repo, it should work.\n\nThe only drawback could be the ever growing number of tags,\nI don't know how it will work with thousands of tags or more.\n\nHave a nice day,\n A.\n"},{"id":"125280","messageId":"9e4733910910180837n6465af8fq83ba1aa895d649e5@mail.gmail.com","threadId":"21271","inReplyTo":"20091018144158.GA9789@gandalf.dynalias.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2009-10-18T15:37:04Z","receivedAt":"2009-10-18T15:37:04Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On Sun, Oct 18, 2009 at 10:41 AM, Norbert Preining wrote:\n> Dear all,\n>\n> (please Cc)\n>\n> I am managing some of my projects with git and I am quite happy about it.\n>\n> There is another project I am working that is quite big, the subversion\n> checkout is about 14Gb. Doing svn up is a pain, it has to open tens of\n> thousands of files and directories traversing the whole tree, trashing\n> the fs cache and taking ages.\n>\n> My idea was to move to git, from what I read it should be more capable\n> in handling these type of projects.\n>\n> Now, there is one show-stopper I see. From our repository we create a\n> set of \"packages\", and the maximum of the \"last-changed\" revisions of\n> the contained files determine the \"version\" of the package. This\n> guarantees that any change in a file will increase the revision number\n> of the package (some tricks for removals have to be done). This is necessary\n> since we are distributing the packages from servers and the version number\n> pf a package determines whether it should be upgraded (well known concept).\n>\n> Now my question, is there any way to set up something similar with git?\n>\n> My idea is that git - like subversion - could (if asked to) count each\n> commit (global to the repository, irrelevant of the branch) and give it\n> a version number. Since we all will use a bare repository on a server\n> and pull/push from/to there, I think that something similar could be possible.\n\nThere is a large LKML thread discussing this....\nhttp://lwn.net/Articles/355923/\n\n>\n> So, before I delve into more gitty-nitty conversion, let me know if\n> there is any chance for that, or we should stay with subversion.\n>\n> Thanks a lot and all the best\n>\n> Norbert\n>\n> PS: for those interested, it is TeX Live: www.tug.org/texlive\n>\n> -------------------------------------------------------------------------------\n> Dr. Norbert Preining                                        Associate Professor\n> JAIST Japan Advanced Institute of Science and Technology   preining@jaist.ac.jp\n> Vienna University of Technology                               preining@logic.at\n> Debian Developer (Debian TeX Task Force)                    preining@debian.org\n> gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094\n> -------------------------------------------------------------------------------\n> YONKERS (n.)\n> (Rare.) The combined thrill of pain and shame when being caught in\n> public plucking your nostril-hairs and stuffing them into your\n> side-pocket.\n>                        --- Douglas Adams, The Meaning of Liff\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"125281","messageId":"9b18b3110910180837h18e15f74g74626847b6ce4da3@mail.gmail.com","threadId":"21271","inReplyTo":"4ADB3452.6030508@gmail.com","subject":"Re: Creating something like increasing revision numbers","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-10-18T15:37:38Z","receivedAt":"2009-10-18T15:37:38Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/10/18 alexandrul :\n> Norbert Preining wrote:\n>> My idea is that git - like subversion - could (if asked to) count each\n>> commit (global to the repository, irrelevant of the branch) and give it\n>> a version number. Since we all will use a bare repository on a server\n>> and pull/push from/to there, I think that something similar could be possible.\n>\n> I was thinking to set a post-commit hook that reads the current version\n> from a file, increment and save it, and also set a tag with that value.\n>\n> Being a DVCS, this kind of versioning can only be trusted on a single repo,\n> but if you set it on the \"main\" repo, it should work.\n>\n> The only drawback could be the ever growing number of tags,\n> I don't know how it will work with thousands of tags or more.\n\nI think the other drawback is that the number would essentially be\nmeaningless and more or less would just be a substitute sha1.\n\nConsider when a remote adds commits and then merges and pushes. What\nnumber should those commits have?\n\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"125282","messageId":"20091018154528.GA5688@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"9b18b3110910180837h18e15f74g74626847b6ce4da3@mail.gmail.com","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-18T15:45:28Z","receivedAt":"2009-10-18T15:45:28Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"On So, 18 Okt 2009, demerphq wrote:\n> > Being a DVCS, this kind of versioning can only be trusted on a single repo,\n> > but if you set it on the \"main\" repo, it should work.\n> >\n> > The only drawback could be the ever growing number of tags,\n> > I don't know how it will work with thousands of tags or more.\n> \n> I think the other drawback is that the number would essentially be\n> meaningless and more or less would just be a substitute sha1.\n\nWell, it would be increasing for that repository. And if we always\nupdate our packages from that repository the packages will be guaranteed\nto have increasing version number, too.\n\nThat is the *only* thing I care about. The numbers don't need to have\na meaning, nothing else but that in our workflow we guarantee\nthat at the end each package progresses in version numbers.\n\n> Consider when a remote adds commits and then merges and pushes. What\n> number should those commits have?\n\nWhen using a central repository to which he pushes within that central\nrepository it would give a specific number.\n\nBest wishes\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nWIMBLEDON (n.)\nThat last drop which, no matter how much you shake it, always goes\ndown your trouser leg.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125283","messageId":"9b18b3110910180916s2a2ac751i7520e64294037817@mail.gmail.com","threadId":"21271","inReplyTo":"20091018154528.GA5688@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-10-18T16:16:39Z","receivedAt":"2009-10-18T16:16:39Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/10/18 Norbert Preining :\n> On So, 18 Okt 2009, demerphq wrote:\n>> > Being a DVCS, this kind of versioning can only be trusted on a single repo,\n>> > but if you set it on the \"main\" repo, it should work.\n>> >\n>> > The only drawback could be the ever growing number of tags,\n>> > I don't know how it will work with thousands of tags or more.\n>>\n>> I think the other drawback is that the number would essentially be\n>> meaningless and more or less would just be a substitute sha1.\n>\n> Well, it would be increasing for that repository. And if we always\n> update our packages from that repository the packages will be guaranteed\n> to have increasing version number, too.\n>\n> That is the *only* thing I care about. The numbers don't need to have\n> a meaning, nothing else but that in our workflow we guarantee\n> that at the end each package progresses in version numbers.\n>\n>> Consider when a remote adds commits and then merges and pushes. What\n>> number should those commits have?\n>\n> When using a central repository to which he pushes within that central\n> repository it would give a specific number.\n\nConsider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.\n\nIf i then make a trivial comment fix to A and then merge and push we\nend up with:\n\nA-B-C-D-E-G\n \\ /\n F------+\n\nIf i understand you right you will set F to 6 and G to 7. Thus youll\nend up with the problem that F is a descendent of A yet has a higher\n\"version number\" than E. You can repeat this process for ever.\n\nIf this suits your needs then great.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"125284","messageId":"4ADB43EA.5060901@gmail.com","threadId":"21271","inReplyTo":"9b18b3110910180916s2a2ac751i7520e64294037817@mail.gmail.com","subject":"Re: Creating something like increasing revision numbers","fromName":"alexandrul","fromEmail":"alexandrul.ct@gmail.com","sentAt":"2009-10-18T16:35:54Z","receivedAt":"2009-10-18T16:35:54Z","isPatch":false,"sender":{"key":"alexandrul.ct@gmail.com","avatar":"https://gravatar.com/avatar/ccace5786472fd935f20e6a59cb13b6cfcb393ce897707b5681e70f8980afb91?d=mp&s=160"},"body":"demerphq wrote:\n> Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.\n> \n> If i then make a trivial comment fix to A and then merge and push we\n> end up with:\n> \n> A-B-C-D-E-G\n> \\ /\n> F------+\n> \n> If i understand you right you will set F to 6 and G to 7. Thus youll\n> end up with the problem that F is a descendent of A yet has a higher\n> \"version number\" than E. You can repeat this process for ever.\n> \n> If this suits your needs then great.\n\nJust like subversion :D\n\nIt helps by ordering commits by time, not by parents, and I don't need\nrepo access to figure it out that F is the latest bug/feature/fix.\n\nThink about 2 sql servers, each has different versions of the same\nstored procedure. Which one is newer, given that you don't have\nthe git repository on the production servers? I can't make any decision\non SHA1 only, and if they belong to the same branch (\"prod\")\nI'm so out of luck. At the moment I'm saving SHA1, refs, author date,\ncomitter date and last subject. But it's easier for me to compare\nrevision numbers than dates. And don't forget that updating decisions\nmay be taken by people that have nothing to do with development.\n\nHave a nice day,\n A.\n"},{"id":"125286","messageId":"200910181923.19511.johan@herland.net","threadId":"21271","inReplyTo":"20091018152054.GA3956@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-10-18T17:23:19Z","receivedAt":"2009-10-18T17:23:19Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 18 October 2009, Norbert Preining wrote:\n> On So, 18 Okt 2009, Johan Herland wrote:\n> > $ git describe\n> > v1.0.4-14-g2414721\n> >\n> > where the \"v1.0.4\" part is the last tag that the current state is based\n> > on, the \"14\" part is the number of commit between that tag and the\n> > current\n> \n> So if we have only one tag (initial) then it would count the number\n> of commits?\n\nYes. You can create the 'initial' tag with\n\n git rev-list HEAD | tail -n1 | xargs git tag initial\n\nand from then on\n\n git describe --tags --match initial | cut -d'-' -f2\n\nwill give you the increasing \"revision\" number you're looking for. Just be \naware that if you have two parallel branches with the same number of \ncommits, they will give you the same number. I.e. this only works for a \nsingle, stable (i.e. no history rewrites), branch of development.\n\n\nHope this helps,\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"125287","messageId":"4ADB5B77.8040605@gmail.com","threadId":"21271","inReplyTo":"200910181923.19511.johan@herland.net","subject":"Re: Creating something like increasing revision numbers","fromName":"alexandrul","fromEmail":"alexandrul.ct@gmail.com","sentAt":"2009-10-18T18:16:23Z","receivedAt":"2009-10-18T18:16:23Z","isPatch":false,"sender":{"key":"alexandrul.ct@gmail.com","avatar":"https://gravatar.com/avatar/ccace5786472fd935f20e6a59cb13b6cfcb393ce897707b5681e70f8980afb91?d=mp&s=160"},"body":"Johan Herland wrote:\n> Yes. You can create the 'initial' tag with\n> \n> git rev-list HEAD | tail -n1 | xargs git tag initial\n> \n> and from then on\n> \n> git describe --tags --match initial | cut -d'-' -f2\n> \n> will give you the increasing \"revision\" number you're looking for. Just be \n> aware that if you have two parallel branches with the same number of \n> commits, they will give you the same number. I.e. this only works for a \n> single, stable (i.e. no history rewrites), branch of development.\n\n\nSo if you concatenate the branch name with the \"revision\" number you would have\npretty unique tags repo-wide, if you won't rename your branches.\n"},{"id":"125294","messageId":"alpine.LNX.2.00.0910181727130.32515@iabervon.org","threadId":"21271","inReplyTo":"20091018144158.GA9789@gandalf.dynalias.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-18T21:43:39Z","receivedAt":"2009-10-18T21:43:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 18 Oct 2009, Norbert Preining wrote:\n\n> Dear all,\n> \n> (please Cc)\n> \n> I am managing some of my projects with git and I am quite happy about it.\n> \n> There is another project I am working that is quite big, the subversion\n> checkout is about 14Gb. Doing svn up is a pain, it has to open tens of\n> thousands of files and directories traversing the whole tree, trashing\n> the fs cache and taking ages.\n> \n> My idea was to move to git, from what I read it should be more capable\n> in handling these type of projects.\n> \n> Now, there is one show-stopper I see. From our repository we create a\n> set of \"packages\", and the maximum of the \"last-changed\" revisions of\n> the contained files determine the \"version\" of the package. This \n> guarantees that any change in a file will increase the revision number\n> of the package (some tricks for removals have to be done). This is necessary\n> since we are distributing the packages from servers and the version number\n> pf a package determines whether it should be upgraded (well known concept).\n> \n> Now my question, is there any way to set up something similar with git?\n> \n> My idea is that git - like subversion - could (if asked to) count each\n> commit (global to the repository, irrelevant of the branch) and give it\n> a version number. Since we all will use a bare repository on a server\n> and pull/push from/to there, I think that something similar could be possible.\n\nIt's possible as long as you don't think of the \"version number\" as a \nproperty of the commit, but rather a property that some commits get by \nvirtue of having been at some time the commit that's what would be found \non that particular server at that particular time. Even though the history \nof the *content* is non-linear, the sequence of values stored in \nrefs/heads/master on your central server is linear, local, and easy to \nenumerate.\n\nOf course, when someone does a bunch of development in parallel with other \npeople, does a final merge, and pushes it back to the server, this only \nincreases the version by one, and only the final merge actually has a \nversion number at all. For your application, this shouldn't be a problem, \nbecause the intermediate commits don't ever get packages created of them \nto need to be compared to other packages.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"125296","messageId":"7vfx9gnwtw.fsf@alter.siamese.dyndns.org","threadId":"21271","inReplyTo":"20091018152054.GA3956@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T22:47:39Z","receivedAt":"2009-10-18T22:47:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Norbert Preining writes:\n\n> On So, 18 Okt 2009, Johan Herland wrote:\n>> A global, increasing version number ala SVN is fundamentally impossible in \n>> any distributed version control system (like Git).\n>\n> Yes, agreed. \n>\n> The point is that I do not actually need the \"distributed\" part of git.\n> I want one central repository and all collaborators commit to that.\n> Yes, that is subversion, I know.\n>\n> We have no branches, no tags, nothing of that. Only trunk.\n\nNo, it is not subversion at all. Don't say \"I know\" until you really\nknow. Anybody who thinks that is not distributed does not understand\ndistributedness of git.\n\nDistributedness does _not_ come from not having a central shared\nrepository, nor not using more than one branch.\n\nDistrubutedness comes the moment any and all of your people can make their\ncommits _locally_. And the fundamental lack of \"increasing global version\nnumber\" is one implication of the distributedness.\n\nSuppose you and Alice collaborate that way. You make the initial commit,\nthat is pushed to the central shared repository, and alice clones.\n\n norb$ git commit -m 'first one'\n norb$ git push\n alice$ git clone $central\n\nNow Norb and Alice share that the 'first one' is the current and only\ncommit at the tip of their history. The central repository also shares\nthat notion. You work and produce a few commits.\n\n norb$ edit; git commit -a -m 'second norb'\n norb$ edit; git commit -a -m 'third norb'\n norb$ edit; git commit -a -m 'fourth norb'\n\nwhile Alice does the same.\n \n alice$ edit; git commit -a -m 'second alice'\n alice$ edit; git commit -a -m 'third alice'\n\nYou happened to push first:\n\n norb$ git push\n\nYou and the central repository shares the view of the history in which\nthe mapping between \"revision sequence number\" and commits looks like:\n\n 1. first one\n 2. second norb\n 3. third norb\n 4. fourth norb\n\nImagine what view of the history Alice has at this point and think for a\nwhile. Recall Alice hasn't pulled from the central repository since she\ncloned. There are two possible things you may want to do.\n\n #1 Some sequential number is given but that is useless as global\n identifier.\n\n 1. first one\n 2. second alice\n 3. third alice\n\n #2 Do not give such sequential number locally; the central repository is\n the _only_ place that assigns such a number. '?' stands for\n 'unnumbered'\n\n 1. first one\n ?. second alice\n ?. third alice\n\nThen Alice fetches from the central and integrates her history with it.\nShe can do one of two things. \"pull\" to create a non-linear history by\nmerging, or \"pull --rebase\" to keep the history linear.\n\nSince you are imitating subversion, you may choose the latter route to\nrebase, and now the linearlized history would become:\n\n 1. first one\n 2. second norb\n 3. third norb\n 4. fourth norb\n ?. second alice\n ?. third alice\n\nAlice's two commits may stay unnumbered (if you chose #2---no local\nversions), or changes from 2/3 to 5/6 (if you chose #1).\n\nIf you instead use merges, then there won't be 'sequence' number you can\nusefully compare anymore.\n\n 1 first one\n /|\n second alice 2 2 second norb\n | |\n | 3 third norb\n | |\n third alice 3 4 fourth norb\n |/\n fourth alice 5\n\nScheme #1 inherently cannot give you stable and unique numbers in a\ndistributed environment where you can commit locally without talking to\nthe central \"number naming authority\". By rebasing, you can keep the\nlong-term numbering unique (by renaming some new ones), but rebase has its\nown downsides besides the name of the commit.\n\nScheme #2 is a way to get some stablility; give the authority of numbering\nto the central repository and commits that haven't hit the central\nrepository are left unnumbered. But that is generally not very useful\nfor your purpose of giving incrementing version number for building (the\ndevelopers would want to build for testing before finally committing to\npublish the result to the central place).\n\nRunning describe using one tag on the 'initial' would give you a rough\nequivalent of #1 (i.e. you get tentative numbers on the local commits),\nboth in the case you rebase (i.e. your numbers change) and you merge\n(i.e. you can have more than one \"second\" commits and numbers are not\nunique), which would be the best compromise you can get.\n"},{"id":"125312","messageId":"20091019004447.GC11739@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"alpine.LNX.2.00.0910181727130.32515@iabervon.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-19T00:44:47Z","receivedAt":"2009-10-19T00:44:47Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"Hi all,\n\nthanks everyone for the nice feedback!\n\nOn So, 18 Okt 2009, Daniel Barkalow wrote:\n> It's possible as long as you don't think of the \"version number\" as a \n> property of the commit, but rather a property that some commits get by \n> virtue of having been at some time the commit that's what would be found \n> on that particular server at that particular time. Even though the history \n\nRight! That is a good point. In fact I don't care about (local) commits,\nbut about the pushes to the central server.\n\n> of the *content* is non-linear, the sequence of values stored in \n> refs/heads/master on your central server is linear, local, and easy to \n> enumerate.\n\nThat is exactely what I need.\n\n> Of course, when someone does a bunch of development in parallel with other \n> people, does a final merge, and pushes it back to the server, this only \n> increases the version by one, and only the final merge actually has a \n\nAs it is now with svn, we have to live with that. The point is that we\nstill would see many different commits pushed to the server, so \ngit log would show the single items, but the \"versioning sequence number\"\nis only increased by one. That would be *absolutely*perfect* for me!\n\n> because the intermediate commits don't ever get packages created of them \n> to need to be compared to other packages.\n\nRight!\n\nNow my follow-up questions:\n- how would one access this \"sequence\" number on the server\n- is there a way to determine at which of this \"sequence\" numbers a specific\n file has been changed last?\n\n\nThanks a lot and all the best\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nDULEEK (n.)\nSudden realisation, as you lie in bed waiting for the alarm to go off,\nthat it should have gone off an hour ago.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125313","messageId":"20091019004829.GD11739@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"7vfx9gnwtw.fsf@alter.siamese.dyndns.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-19T00:48:29Z","receivedAt":"2009-10-19T00:48:29Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"On So, 18 Okt 2009, Junio C Hamano wrote:\n> #2 Do not give such sequential number locally; the central repository is\n> the _only_ place that assigns such a number. '?' stands for\n> 'unnumbered'\n\n[...]\n\n> Scheme #2 is a way to get some stablility; give the authority of numbering\n> to the central repository and commits that haven't hit the central\n> repository are left unnumbered. But that is generally not very useful\n> for your purpose of giving incrementing version number for building (the\n> developers would want to build for testing before finally committing to\n> publish the result to the central place).\n\nThat problem we have anyway with subversion, too, because as long as you\ndo not commit your changes nothing will happen on package rebuild.\nSo that is not a problem here.\n\nYes, we want server-sided linear numbers and anything *not* pushed to\nthe server is unnumbered.\n\nAnd that is also fine, because packages are built only from the server.\n\nBest wishes\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nPUDSEY (n.)\nThe curious-shaped flat wads of dough left on a kitchen table after\nsomeone has been cutting scones out of it.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125314","messageId":"alpine.LFD.2.00.0910182112200.21739@xanadu.home","threadId":"21271","inReplyTo":"200910181923.19511.johan@herland.net","subject":"Re: Creating something like increasing revision numbers","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-19T01:15:36Z","receivedAt":"2009-10-19T01:15:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 18 Oct 2009, Johan Herland wrote:\n\n> On Sunday 18 October 2009, Norbert Preining wrote:\n> > On So, 18 Okt 2009, Johan Herland wrote:\n> > > $ git describe\n> > > v1.0.4-14-g2414721\n> > >\n> > > where the \"v1.0.4\" part is the last tag that the current state is based\n> > > on, the \"14\" part is the number of commit between that tag and the\n> > > current\n> > \n> > So if we have only one tag (initial) then it would count the number\n> > of commits?\n> \n> Yes. You can create the 'initial' tag with\n> \n> git rev-list HEAD | tail -n1 | xargs git tag initial\n> \n> and from then on\n> \n> git describe --tags --match initial | cut -d'-' -f2\n\nEven simpler, without any tag:\n\n\tgit rev-list HEAD | wc -l\n\nThat should roughly give the equivalent of the SVN revision number. \nValid only in one specific repository of course.\n\n\nNicolas\n"},{"id":"125315","messageId":"alpine.LNX.2.00.0910182045580.14365@iabervon.org","threadId":"21271","inReplyTo":"20091019004447.GC11739@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-19T01:16:46Z","receivedAt":"2009-10-19T01:16:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 19 Oct 2009, Norbert Preining wrote:\n\n> Hi all,\n> \n> thanks everyone for the nice feedback!\n> \n> On So, 18 Okt 2009, Daniel Barkalow wrote:\n> > It's possible as long as you don't think of the \"version number\" as a \n> > property of the commit, but rather a property that some commits get by \n> > virtue of having been at some time the commit that's what would be found \n> > on that particular server at that particular time. Even though the history \n> \n> Right! That is a good point. In fact I don't care about (local) commits,\n> but about the pushes to the central server.\n> \n> > of the *content* is non-linear, the sequence of values stored in \n> > refs/heads/master on your central server is linear, local, and easy to \n> > enumerate.\n> \n> That is exactely what I need.\n> \n> > Of course, when someone does a bunch of development in parallel with other \n> > people, does a final merge, and pushes it back to the server, this only \n> > increases the version by one, and only the final merge actually has a \n> \n> As it is now with svn, we have to live with that. The point is that we\n> still would see many different commits pushed to the server, so \n> git log would show the single items, but the \"versioning sequence number\"\n> is only increased by one. That would be *absolutely*perfect* for me!\n> \n> > because the intermediate commits don't ever get packages created of them \n> > to need to be compared to other packages.\n> \n> Right!\n> \n> Now my follow-up questions:\n> - how would one access this \"sequence\" number on the server\n\nThere isn't currently anything built in that counts up like that; however, \nit shouldn't be too hard to add something, because the reflog gets an \nentry at the same times the sequence number would increase. In fact, you \ncould disable pruning the reflog, and use its length (in lines), except \nthat would get slow and git doesn't expect you to care about the complete \nhistory there (in fact, you only care about the amount of history past \nsome point).\n\n> - is there a way to determine at which of this \"sequence\" numbers a specific\n> file has been changed last?\n\nThere isn't a built-in way, but you can find the current hash for a \nfilename with \"git ls-tree -r \", and find the hash as \nof N changes ago with \"git ls-tree -r @{} \". You're \nlooking for the smallest N where they don't match. (And you probably \ndon't want to be a binary search or the like, because that might miss that \na file was most recently affected by having a change reverted; you'd want \nto be sure to report the version that reverted the change, not the version \nthat introduced the content the later one returned to.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"125316","messageId":"20091019013320.GD17397@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"alpine.LNX.2.00.0910182045580.14365@iabervon.org","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-19T01:33:20Z","receivedAt":"2009-10-19T01:33:20Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"Hi Daniel,\n\nOn So, 18 Okt 2009, Daniel Barkalow wrote:\n> > - how would one access this \"sequence\" number on the server\n> \n> There isn't currently anything built in that counts up like that; however, \n> it shouldn't be too hard to add something, because the reflog gets an \n> entry at the same times the sequence number would increase. In fact, you \n\nOk.\n\n> > - is there a way to determine at which of this \"sequence\" numbers a specific\n> > file has been changed last?\n> \n> There isn't a built-in way, but you can find the current hash for a \n> filename with \"git ls-tree -r \", and find the hash as \n> of N changes ago with \"git ls-tree -r @{} \". You're \n> looking for the smallest N where they don't match. (And you probably \n> don't want to be a binary search or the like, because that might miss that \n\nThat sounds like we cannot use that, because we have to do that for about\n80k files and that on each (at least daily) rebuilt. That is not feasable.\n\nAgain thanks for your helpful comments!\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nBRUMBY\nThe fake antique plastic seal on a pretentious whisky bottle.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125317","messageId":"alpine.LFD.2.00.0910182122100.21739@xanadu.home","threadId":"21271","inReplyTo":"20091019004447.GC11739@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-19T01:34:00Z","receivedAt":"2009-10-19T01:34:00Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 19 Oct 2009, Norbert Preining wrote:\n\n> Now my follow-up questions:\n> - how would one access this \"sequence\" number on the server\n\nyou can count how many commits the server has: git rev-list HEAD | wc -l\n\n> - is there a way to determine at which of this \"sequence\" numbers a specific\n> file has been changed last?\n\nYou can do: git log . That would give you a list of \ncommits that touched that file. But to find out which commit \"number\" \nit is you could do:\n\n\tgit rev-list $(git rev-list -1 HEAD ) | wc -l\n\nAgain, that is true for a particular repository only and may give a \ndifferent result in another repository with a different state even for \nthe same commit.\n\nHowever, given what you want to do is really to stick to the SVN way of \ndoing things, then why don't you simply stay with SVN? Git works in a \nfundamentally different way than SVN, and if you aren't willing/able to \nchange your workflow away from the SVN way then there is really not much \nfor you to gain by switching to Git.\n\n\nNicolas\n"},{"id":"125318","messageId":"20091019014256.GE17397@gamma.logic.tuwien.ac.at","threadId":"21271","inReplyTo":"alpine.LFD.2.00.0910182122100.21739@xanadu.home","subject":"Re: Creating something like increasing revision numbers","fromName":"Norbert Preining","fromEmail":"preining@logic.at","sentAt":"2009-10-19T01:42:56Z","receivedAt":"2009-10-19T01:42:56Z","isPatch":false,"sender":{"key":"preining@logic.at","avatar":"https://gravatar.com/avatar/4eba36d7c4ade07ae9dee53cfa4483b595282254f56d39422722e17c406baf4d?d=mp&s=160"},"body":"On So, 18 Okt 2009, Nicolas Pitre wrote:\n> However, given what you want to do is really to stick to the SVN way of \n> doing things, then why don't you simply stay with SVN? Git works in a \n\nI fear so.\n\n> fundamentally different way than SVN, and if you aren't willing/able to \n> change your workflow away from the SVN way then there is really not much \n> for you to gain by switching to Git.\n\nWell, as I said in the beginning, the metadata handling of svn is a pain\nin huge repositories like ours with thousands of subdirectories of subdirs\nof subdirs and 80k+ files. That was the reason I thought about git.\n\nBut I am coming to the conclusion that I will use git for my other projects,\nbut not for that one.\n\nBest wishes\n\nNorbert\n\n-------------------------------------------------------------------------------\nDr. Norbert Preining Associate Professor\nJAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\nVienna University of Technology preining@logic.at\nDebian Developer (Debian TeX Task Force) preining@debian.org\ngpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094\n-------------------------------------------------------------------------------\nGLASSEL (n.)\nA seaside pebble which was shiny and interesting when wet, and which\nis now a lump of rock, which children nevertheless insist on filing\ntheir suitcases with after the holiday.\n\t\t\t--- Douglas Adams, The Meaning of Liff\n"},{"id":"125319","messageId":"alpine.LNX.2.00.0910182140440.14365@iabervon.org","threadId":"21271","inReplyTo":"20091019013320.GD17397@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-19T02:41:57Z","receivedAt":"2009-10-19T02:41:57Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 19 Oct 2009, Norbert Preining wrote:\n\n> Hi Daniel,\n> \n> On So, 18 Okt 2009, Daniel Barkalow wrote:\n> > > - how would one access this \"sequence\" number on the server\n> > \n> > There isn't currently anything built in that counts up like that; however, \n> > it shouldn't be too hard to add something, because the reflog gets an \n> > entry at the same times the sequence number would increase. In fact, you \n> \n> Ok.\n> \n> > > - is there a way to determine at which of this \"sequence\" numbers a specific\n> > > file has been changed last?\n> > \n> > There isn't a built-in way, but you can find the current hash for a \n> > filename with \"git ls-tree -r \", and find the hash as \n> > of N changes ago with \"git ls-tree -r @{} \". You're \n> > looking for the smallest N where they don't match. (And you probably \n> > don't want to be a binary search or the like, because that might miss that \n> \n> That sounds like we cannot use that, because we have to do that for about\n> 80k files and that on each (at least daily) rebuilt. That is not feasable.\n\nIt's likely to be much more efficient (and maybe sufficiently efficient) \nto do them all in a single pass. In fact, it should be easy enough to keep \na cache of the latest numbers for the files, and update that to change the \nvalue for those files that differ between the old commit and the new \ncommit in the post-update hook.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"125340","messageId":"4ADC057C.708@viscovery.net","threadId":"21271","inReplyTo":"20091019004447.GC11739@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-19T06:21:48Z","receivedAt":"2009-10-19T06:21:48Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Norbert Preining schrieb:\n> On So, 18 Okt 2009, Daniel Barkalow wrote:\n>> of the *content* is non-linear, the sequence of values stored in \n>> refs/heads/master on your central server is linear, local, and easy to \n>> enumerate.\n> \n> That is exactely what I need.\n\nYou can always run 'git rev-list master | wc -l' to get a sequence number.\nYou can throw in --first-parent if you do not want to count commits that\nentered master through a merge commit.\n\nYou can configure your reflogs such that they do not expire. Then you\ncount the entries in the reflog.\n\n-- Hannes\n"},{"id":"125576","messageId":"20091021074711.GB67773@gmail.com","threadId":"21271","inReplyTo":"20091019004447.GC11739@gamma.logic.tuwien.ac.at","subject":"Re: Creating something like increasing revision numbers","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-10-21T07:47:12Z","receivedAt":"2009-10-21T07:47:12Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Oct 19, 2009 at 02:44:47AM +0200, Norbert Preining wrote:\n> Hi all,\n> \n> thanks everyone for the nice feedback!\n> \n> On So, 18 Okt 2009, Daniel Barkalow wrote:\n> > It's possible as long as you don't think of the \"version number\" as a \n> > property of the commit, but rather a property that some commits get by \n> > virtue of having been at some time the commit that's what would be found \n> > on that particular server at that particular time. Even though the history \n> \n> Right! That is a good point. In fact I don't care about (local) commits,\n> but about the pushes to the central server.\n> \n> > of the *content* is non-linear, the sequence of values stored in \n> > refs/heads/master on your central server is linear, local, and easy to \n> > enumerate.\n> \n> That is exactely what I need.\n\n\nIf you have any control over how people will use git,\nthen you can give your constantly-incrementing revision number\nmore stability by ensuring that everyone uses\n'git pull --rebase'.\n\nThat'll literally keep the history completely linear.\nIf someone forgets then it's not a big deal; you'll\njust get a merge commit and the number will increment\nby 2 instead of by 1.\n\n> Now my follow-up questions:\n> - how would one access this \"sequence\" number on the server\n\nIf you've done the \"tag the initial commit\" as suggested\nelsewhere on this thread:\n\n\tgit tag projectname $(git rev-list HEAD | tail -n1)\n\nthen you can do this with simply:\n\n\tgit describe --tags\n\n\nIt should output something like:\n\n\tprojectname-101-g20912df\n\n> - is there a way to determine at which of this \"sequence\" numbers a specific\n> file has been changed last?\n\n\tcommit=$(git log --pretty=%H -1 -- )\n\tgit describe --tags $commit\n\n\n> JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp\n> Vienna University of Technology preining@logic.at\n> Debian Developer (Debian TeX Task Force) preining@debian.org\n\n\nJust another happy Debian user here,\n\n-- \n\t\tDavid\n"}]}