{"thread":{"id":"5608","subject":"Subversion-style incrementing revision numbers","startedAt":"2006-09-19T21:07:45Z","lastAt":"2006-09-20T19:07:42Z","messageCount":28,"participants":["Joel Dice","Petr Baudis","Linus Torvalds","Jakub Narebski","Shawn Pearce","Johannes Schindelin","Junio C Hamano","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27168","messageId":"Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":null,"subject":"Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T21:07:45Z","receivedAt":"2006-09-19T21:07:45Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"Hello, all.\n\nI'm considering adopting Git for a medium-sized project which is currently \nmanaged using Subversion. I've used Git for a few smaller projects \nalready, and the thing I've missed most from Subversion is the convenience \nof incrementing revision numbers. The following is a proposal to add this \nfeature to Git.\n\n\nRationale:\n\nIncrementing revision numbers (IRNs - an acronym I just made up) are \nuseful in that they can be treated as auto-generated tags which are easier \nto remember and communicate than SHA hashes, yet do not require extra \neffort to create like real tags. Also, they have the advantage of being \nchronologically ordered, so if I assert that a bug was fixed in revision \n42 of a shared repository, everyone may assume that revision 45 has that \nfix as well.\n\nProposal:\n\nAs with Subversion, the IRN state in Git would be specific to a given \nrepository and have no significance beyond that repository. Also like \nSubversion, IRN state would be global across a repository, so that a \ncommit to any branch would increment the current IRN value. Every Git \ncommand taking a revision parameter would accept an IRN using a syntax \nsuch as \"r$IRN\". Every commit would report the IRN to the user as well as \nthe SHA ID. The IRN feature could be enabled or disabled via a \nconfiguration option.\n\nImplementation:\n\nA simple, efficient implementation of this feature would be based on a \nsingle file, $GIT_DIR/history, which would contain a newline-delimited \nlist of SHA commit IDs in chronological order, oldest first. The current \nrepository IRN would be calculated as the size of that file divided by the \nSHA+newline length, and the commit ID of any IRN could be determined by \nseeking to the correct offset in that file. Every commit would cause a \nnew line to be appended to the history file with that commit's ID. \nFinally, a history file could be generated for an existing repository by \nserializing the commit history based on chronological order.\n\n\nI'd be happy to put together a patch that implements this, but first I'd \nlike to get some feedback. If something like this has already been \nproposed, please point me to the discussion. Thanks.\n\n - Joel\n"},{"id":"27171","messageId":"20060919211844.GB8259@pasky.or.cz","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-19T21:18:44Z","receivedAt":"2006-09-19T21:18:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter\nwhere Joel Dice said that...\n> Implementation:\n> \n> A simple, efficient implementation of this feature would be based on a \n> single file, $GIT_DIR/history, which would contain a newline-delimited \n> list of SHA commit IDs in chronological order, oldest first. The current \n> repository IRN would be calculated as the size of that file divided by the \n> SHA+newline length, and the commit ID of any IRN could be determined by \n> seeking to the correct offset in that file. Every commit would cause a \n> new line to be appended to the history file with that commit's ID. \n> Finally, a history file could be generated for an existing repository by \n> serializing the commit history based on chronological order.\n\nWe already have support for recording something similar, it's called a\nrevlog. You would just need to modify it to aggregate all the branches\nin a single file.\n\nAlso, multiple IRNs could refer to a single real commit if you do e.g.\ncg-admin-uncommit, since revlog logs revision updates, not new revisions\ncreated. This may or may not be considered a good thing. If you rather\nwant to just create a new IRN at commit object creation time, also note\nthat some tools _might_ validly create commit objects and then throw\nthem away, which would generate non-sensical (and after prune, invalid)\nIRNs.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27174","messageId":"Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"20060919211844.GB8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T21:42:20Z","receivedAt":"2006-09-19T21:42:20Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Tue, 19 Sep 2006, Petr Baudis wrote:\n\n> Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter\n> where Joel Dice said that...\n>> Implementation:\n>>\n>> A simple, efficient implementation of this feature would be based on a\n>> single file, $GIT_DIR/history, which would contain a newline-delimited\n>> list of SHA commit IDs in chronological order, oldest first. The current\n>> repository IRN would be calculated as the size of that file divided by the\n>> SHA+newline length, and the commit ID of any IRN could be determined by\n>> seeking to the correct offset in that file. Every commit would cause a\n>> new line to be appended to the history file with that commit's ID.\n>> Finally, a history file could be generated for an existing repository by\n>> serializing the commit history based on chronological order.\n>\n> We already have support for recording something similar, it's called a\n> revlog. You would just need to modify it to aggregate all the branches\n> in a single file.\n\nThanks - I'll look at that.\n\n> Also, multiple IRNs could refer to a single real commit if you do e.g.\n> cg-admin-uncommit, since revlog logs revision updates, not new revisions\n> created. This may or may not be considered a good thing. If you rather\n> want to just create a new IRN at commit object creation time, also note\n> that some tools _might_ validly create commit objects and then throw\n> them away, which would generate non-sensical (and after prune, invalid)\n> IRNs.\n\nI'm not too worried about cg-admin-uncommit or git-reset, since the IRN \nfeature is intended mainly for shared repositories. I would suggest that \nsuch commands simply be disallowed for such repositories.\n\nThe problem of temporary commits certainly needs to be addressed. In this \ncase, may I assume nothing under $GIT_DIR/refs is ever modified? If so, \nperhaps I could somehow hook into the git-update-ref step. Is that what \nthe revlog code does?\n\n - Joel\n"},{"id":"27175","messageId":"Pine.LNX.4.64.0609191416500.4388@g5.osdl.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-19T21:51:49Z","receivedAt":"2006-09-19T21:51:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 19 Sep 2006, Joel Dice wrote:\n> \n> I'd be happy to put together a patch that implements this, but first I'd like\n> to get some feedback. If something like this has already been proposed,\n> please point me to the discussion. Thanks.\n\nI really don't think you can do it sanely.\n\nThe thing is, the reason subversion can do it is simply that SVN is \nterminally broken.\n\nReally. SVN is crap. It may be prettier crap than CVS, but it's literaly \nno different from putting confectioners sugar on top of a cowpatty. It's \nnot really \"fixing\" anything. And the revision numbering is actually very \nmuch part of the problem.\n\nThe thing is, you can limit yourself to a single repository, and once you \nhave branches, you _still_ cannot sanely number the commits with anything \nlike \"r1.3.4.1\".\n\nHere's an example. Let's say that you start out with just a regular \n\"master\" branch, and you number the commits \"r1.1\", \"r1.2\" and so on (of \ncourse, that extra \"1.\" at the beginning doesn't actually make any \n_sense_, but let's keep it just to not confuse CVS/SVN users any more than \nthey are already confused).\n\nNow, you've done five commits, and are at \"r1.5\", and everything looks \nbeautiful, and you're getting comfy, so you start and check out a branch \ncalled \"test\". What do you call it?\n\nThe thing is, you need to call it \"r1.5\", because the _commit_ is still \nexactly the same as the master one. Creation of a branch in git doesn't \nactually create any new commits, it just creates a new pointer. \n\nSo far so fine. We can ignore that, and make the rules be:\n\n - when creating a commit, we look at the branch name. If the branch name \n is \"master\", we increment the second number, and drop all other \n numbers.\n\n - if the branch name is anything else, we look whether the current state \n is the same any other branch, in which case we just add a \".1\" at the \n end relative to the branch (or a \".2\" if a \".1\" already exists and so \n on). Otherwise we increment the last number.\n\nthat's not a wonderful set of rules, but it might work. So what happens is \nthat when we create the next commit (on the \"test\" branch), that commit \nwill be called \"r1.5.1\" (which is what you'd expect). Go along a bit, and \nyou get \"r1.5.2\" and \"r1.5.3\" too. Wonderful.\n\nNow you decide to merge this back into \"master\". Which, btw, hasn't had \nany actual development happen, so it's stil at 1.5. You check out \"master\" \nand do a \"git pull . test\" (or \"git pull . r1.5.3\", which is obviously the \nsame thing), and what happens?\n\nThat's right, we now fast-forward master to that revision, since nothing \nhappened on master. Which means that your master branch is now comprised \nof revisions \"r1.1\" .. \"r1.5\" \"r1.5.1\" .. \"r1.5.3\". That makes no sense at \nall, but it works. The next commit would be called \"r1.6\".\n\nIn other words, the SVN numbering is just insane in a git repo, although \nyou can \"make it work\" in a limited sense (but the numbering would jump in \nodd ways. The thing is, all the things that are true in a distributed \nenvironment are true in a single repository too, so limiting yourself to \na single repo doesn't really make them go away.\n\nAnother thing you CAN do, is to just number them in time in a single repo. \nEvery time you do a commit, you can create a \"r1.\" revision, and that \nwould work. It wouldn't look like the SVN numbers do, and it would only \nwork _within_ that repository, but it would work.\n\nBut it would mean that \"r1.57\" is _not_ necessarily the child of \"r1.56\". \nIt might be that \"r1.56\" was done on another branch, and is totally \nunrelated to \"r1.57\" (other than they sharing some common ancestor far \nback).\n\nSee? The SVN (and CVS) revision numbering really only makes sense because \nit's fundamentally a non-distributed model.\n\nGit is so _fundamentally_ distributed that even within one single \nrepository, each branch is totally independent (\"distributed\"). In \nCVS/SVN, branches aren't independent of each other, and that's why they \nshow up in the revision numbering.\n\nSo you can really only number things as long as you never do any branches \nat all, and just do a linear development. In that case, and in that case \nonly, does numbering work. Or you'd have to have a very \"non-git\" approach \nto branches (the above silly rules _can_ be used - possibly with some \nfixes - to give you essentially SVN-like revision numbers, if you _always_ \ngenerate a commit when you merge).\n\nIt doesn't seem to make a whole lot of sense, does it?\n\nBtw, along the same issues, BK actually had RCS/CVS/SVN-like revision \nnumbers, but to solve the distributed problem (BK didn't have branches) BK \nhad a different approach.\n\nSo BK actually _did_ number things as \"1.1\" and \"1.4.6\" etc, and was \nobviously distributed, and the revision numbers actually matched the shape \nof the development history the same way CVS/SVN does. But if you do that, \nwhat happens is that a merge will _change_ the numbers: you may have \nstarted with two different branches that both were at \"r1.2\", but at the \nend of it one of them got renamed to \"r1.1.1\", and the final result was \ncalled \"r1.3\".\n\nSo if you allow malleable revision numbers, you can definitely do it. That \nends up being _really_ confusing. I know a number of people who otherwise \nwere smart really never understood why \"r1.576\" might not stay as \"r1.576\" \nforever, but might suddenly become \"1.401.3.55\" when merged into another \nrepository.\n\nAnyway, what I'm trying to say is that you're probably better off trying \nto get used to the git numbering than trying to force the SVN model. \nYou're going to hit a few confusing issues if you really want to call \nthings \"r1.x.y.z\"\n\n\t\t\tLinus\n"},{"id":"27176","messageId":"eepp4s$rm9$1@sea.gmane.org","threadId":"5608","inReplyTo":"20060919211844.GB8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-19T21:58:42Z","receivedAt":"2006-09-19T21:58:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n \n> We already have support for recording something similar, it's called a\n> revlog. You would just need to modify it to aggregate all the branches\n> in a single file.\n\n_reflog_, not revlog.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27177","messageId":"20060919220011.GD8259@pasky.or.cz","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-19T22:00:11Z","receivedAt":"2006-09-19T22:00:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter\nwhere Joel Dice said that...\n> On Tue, 19 Sep 2006, Petr Baudis wrote:\n> >Also, multiple IRNs could refer to a single real commit if you do e.g.\n> >cg-admin-uncommit, since revlog logs revision updates, not new revisions\n> >created. This may or may not be considered a good thing. If you rather\n> >want to just create a new IRN at commit object creation time, also note\n> >that some tools _might_ validly create commit objects and then throw\n> >them away, which would generate non-sensical (and after prune, invalid)\n> >IRNs.\n> \n> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN \n> feature is intended mainly for shared repositories. I would suggest that \n> such commands simply be disallowed for such repositories.\n\n What kind of shared repositories? You yourself said that IRNs are\nlocal to a repository, thus they are not preserved over cloning/fetching\nfrom a repository, if you mean that.\n\n> The problem of temporary commits certainly needs to be addressed. In this \n> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so, \n> perhaps I could somehow hook into the git-update-ref step. Is that what \n> the revlog code does?\n\n Yes. But not every commit is always recorded to something in refs/.\nThe simplest case is if you fetch from a remote repository (or push to\nyour repository), only the latest commit is recorded.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27178","messageId":"20060919220604.GE8259@pasky.or.cz","threadId":"5608","inReplyTo":"Pine.LNX.4.64.0609191416500.4388@g5.osdl.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-19T22:06:04Z","receivedAt":"2006-09-19T22:06:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 19, 2006 at 11:51:49PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> Another thing you CAN do, is to just number them in time in a single repo. \n> Every time you do a commit, you can create a \"r1.\" revision, and that \n> would work. It wouldn't look like the SVN numbers do, and it would only \n> work _within_ that repository, but it would work.\n> \n> But it would mean that \"r1.57\" is _not_ necessarily the child of \"r1.56\". \n> It might be that \"r1.56\" was done on another branch, and is totally \n> unrelated to \"r1.57\" (other than they sharing some common ancestor far \n> back).\n\nThis is actually exactly how SVN revision numbering works. There's just\na single number (no '1.') and it indeed jumps randomly if you have\nseveral concurrent branches in your (ok, Linus does not have any, just\nsomeone's) repository.\n\n> You're going to hit a few confusing issues if you really want to call \n> things \"r1.x.y.z\"\n\nNoone does, that indeed would be horrible. But having the commits\nnumbered inside a repository would indeed make for simple usage if you\nneed to type in commit ids frequently, and could make Git a bit\nfriendlier to newcomers.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27179","messageId":"eeppkl$rm9$2@sea.gmane.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-19T22:07:08Z","receivedAt":"2006-09-19T22:07:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Joel Dice wrote:\n\n> I'm considering adopting Git for a medium-sized project which is currently \n> managed using Subversion. I've used Git for a few smaller projects \n> already, and the thing I've missed most from Subversion is the convenience \n> of incrementing revision numbers. The following is a proposal to add this \n> feature to Git.\n> \n> \n> Rationale:\n> \n> Incrementing revision numbers (IRNs - an acronym I just made up) are \n> useful in that they can be treated as auto-generated tags which are easier \n> to remember and communicate than SHA hashes, yet do not require extra \n> effort to create like real tags. Also, they have the advantage of being \n> chronologically ordered, so if I assert that a bug was fixed in revision \n> 42 of a shared repository, everyone may assume that revision 45 has that \n> fix as well.\n\nThat is true _only_ if you have linear history. If you have multiple\nconcurrent branches, revision 42 can be in branch 'next', revision '45' in\ntopic branch 'xx/topic' which forked before revision 42, and do not have\nthe fix.\n\nUnfortunately, one cannot (as of now) use result of git-describe as\n. I'd rather have it fixed, than port idea from _centralized_\nSCM do distributed SCM.\n\n> Proposal:\n> \n> As with Subversion, the IRN state in Git would be specific to a given \n> repository and have no significance beyond that repository. Also like \n> Subversion, IRN state would be global across a repository, so that a \n> commit to any branch would increment the current IRN value. Every Git \n> command taking a revision parameter would accept an IRN using a syntax \n> such as \"r$IRN\". Every commit would report the IRN to the user as well as \n> the SHA ID. The IRN feature could be enabled or disabled via a \n> configuration option.\n\nThis of course limits IRN much. Tags are valid across repositories.\nI'm not sure if many repositories are managed using shared repositories\n(centralized approach).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27180","messageId":"20060919220936.GA11601@spearce.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-19T22:09:36Z","receivedAt":"2006-09-19T22:09:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Joel Dice wrote:\n> I'm considering adopting Git for a medium-sized project which is currently \n> managed using Subversion. I've used Git for a few smaller projects \n> already, and the thing I've missed most from Subversion is the convenience \n> of incrementing revision numbers. The following is a proposal to add this \n> feature to Git.\n\nI can't say I miss that particular feature. Abbrevations of\nSHA1 IDs tend to work very well for the projects I use Git on;\n6-8 characters is easily more than enough to uniquely identify\na revision. Heck half the time even 4 hex characters is enough.\n \n> Rationale:\n> \n> Incrementing revision numbers (IRNs - an acronym I just made up) are \n> useful in that they can be treated as auto-generated tags which are easier \n> to remember and communicate than SHA hashes, yet do not require extra \n> effort to create like real tags. Also, they have the advantage of being \n> chronologically ordered, so if I assert that a bug was fixed in revision \n> 42 of a shared repository, everyone may assume that revision 45 has that \n> fix as well.\n\nBut with respect to what branch?\n\nBranches in a Git repository are very common:\n\n o------o-o-o-o-o-o--- B1\n /\n -o--o--o-----o--------o B2\n\nAssuming the branch point on the left was r60, what is the latest\ncommit on B1? On B2? What about if I merge B1 and B2 together?\n\nOr are you proposing that the commits are ordered by the time that\nthey arrive into the repository?\n\nBut even if that's the case lets say I fix the bug on B1 in r42\nbut a commit on B2 gets assigned r45. The bug isn't fixed in r45;\nnot unless B1 was merged into B2 in r43, r44 or r45. But there's\nno way to know that from just an IRN.\n\nI fail to see how IRNs simplify commit naming or determining where\na feature or bug fix is within the branching structure.\n \n> A simple, efficient implementation of this feature would be based on a \n> single file, $GIT_DIR/history, which would contain a newline-delimited \n> list of SHA commit IDs in chronological order, oldest first. The current \n> repository IRN would be calculated as the size of that file divided by the \n> SHA+newline length, and the commit ID of any IRN could be determined by \n> seeking to the correct offset in that file. Every commit would cause a \n> new line to be appended to the history file with that commit's ID. \n> Finally, a history file could be generated for an existing repository by \n> serializing the commit history based on chronological order.\n\nHow about just using bare tags under the namespace 'refs/tags/r/'?\nWith the new packed refs implemention these would cost you a tiny\namount of overhead over what you propose (due to the ref name also\nbeing stored) but its already implemented and does the job just\nas well.\n\n-- \nShawn.\n"},{"id":"27182","messageId":"20060919221111.GF8259@pasky.or.cz","threadId":"5608","inReplyTo":"eeppkl$rm9$2@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-19T22:11:11Z","receivedAt":"2006-09-19T22:11:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 20, 2006 at 12:07:08AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Joel Dice wrote:\n> > Rationale:\n> > \n> > Incrementing revision numbers (IRNs - an acronym I just made up) are \n> > useful in that they can be treated as auto-generated tags which are easier \n> > to remember and communicate than SHA hashes, yet do not require extra \n> > effort to create like real tags. Also, they have the advantage of being \n> > chronologically ordered, so if I assert that a bug was fixed in revision \n> > 42 of a shared repository, everyone may assume that revision 45 has that \n> > fix as well.\n> \n> That is true _only_ if you have linear history. If you have multiple\n> concurrent branches, revision 42 can be in branch 'next', revision '45' in\n> topic branch 'xx/topic' which forked before revision 42, and do not have\n> the fix.\n\nOops, I've completely overlooked that bit of the rationale. Of course\nIRNs cannot assure this.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"27183","messageId":"eepq7l$dc$1@sea.gmane.org","threadId":"5608","inReplyTo":"eeppkl$rm9$2@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-19T22:17:15Z","receivedAt":"2006-09-19T22:17:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Joel Dice wrote:\n> \n>> I'm considering adopting Git for a medium-sized project which is currently \n>> managed using Subversion. I've used Git for a few smaller projects \n>> already, and the thing I've missed most from Subversion is the convenience \n>> of incrementing revision numbers. The following is a proposal to add this \n>> feature to Git.\n>> \n>> \n>> Rationale:\n>> \n>> Incrementing revision numbers (IRNs - an acronym I just made up) are \n>> useful in that they can be treated as auto-generated tags which are easier \n>> to remember and communicate than SHA hashes, yet do not require extra \n>> effort to create like real tags. Also, they have the advantage of being \n>> chronologically ordered, so if I assert that a bug was fixed in revision \n>> 42 of a shared repository, everyone may assume that revision 45 has that \n>> fix as well.\n> \n> That is true _only_ if you have linear history. If you have multiple\n> concurrent branches, revision 42 can be in branch 'next', revision '45' in\n> topic branch 'xx/topic' which forked before revision 42, and do not have\n> the fix.\n\nAdditionally, what does _chronological_ mean? Time the commit is recorded?\nRemember that in distributed development commits can be fetched from other\nrepository, or arrive via email and applied using git-am. In git you can\nalso rebase branch. Git records merges, and said merges are sometimes\njust fast-forward. All those difficulties have to be solved for IRNs.\n\nBy the way, there was similar proposal to add either hidden field ('note'\nlike) to commit object denoting _generation_ of commit, or add cache of\ncommits' generation numbers. Generation number of root (parentless) commit\nis 0, generation number of a commit is maximum of generation numbers of its\nparents plus 1. But this proposal was for easier and faster generation of\ntopological order.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27184","messageId":"20060919221857.GB11601@spearce.org","threadId":"5608","inReplyTo":"eeppkl$rm9$2@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-19T22:18:57Z","receivedAt":"2006-09-19T22:18:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Unfortunately, one cannot (as of now) use result of git-describe as\n> . I'd rather have it fixed, than port idea from _centralized_\n> SCM do distributed SCM.\n\nThis doesn't work?\n\n\tgit log $(git describe | cut -d- -f2 | sed 's/^g//')\n\nIts obviously so clear and easy to type! :-)\n\nThat should be pretty easy to teach sha1_name.c:get_sha1_basic to\nlook for the pattern commonly used by git-describe, break on \"-g\",\nverify the tag, then unabbreviate the ID.\n\n-- \nShawn.\n"},{"id":"27185","messageId":"Pine.LNX.4.64.0609191519090.4388@g5.osdl.org","threadId":"5608","inReplyTo":"20060919220604.GE8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-19T22:20:19Z","receivedAt":"2006-09-19T22:20:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Sep 2006, Petr Baudis wrote:\n>\n> > It might be that \"r1.56\" was done on another branch, and is totally \n> > unrelated to \"r1.57\" (other than they sharing some common ancestor far \n> > back).\n> \n> This is actually exactly how SVN revision numbering works. There's just\n> a single number (no '1.') and it indeed jumps randomly if you have\n> several concurrent branches in your (ok, Linus does not have any, just\n> someone's) repository.\n\nOh, ok, if it's just a single numbering, then that's easy to do. It won't \n_mean_ anything, and you're seriously screwed if you ever merge anything \nelse (or use a git that doesn't update the refcache or whatever), but it \nis simple and stable within a single repo.\n\n\t\tLinus\n"},{"id":"27186","messageId":"20060919222352.GC11601@spearce.org","threadId":"5608","inReplyTo":"eeppkl$rm9$2@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-19T22:23:52Z","receivedAt":"2006-09-19T22:23:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Joel Dice wrote:\n> > Proposal:\n> > \n> > As with Subversion, the IRN state in Git would be specific to a given \n> > repository and have no significance beyond that repository. Also like \n> > Subversion, IRN state would be global across a repository, so that a \n> > commit to any branch would increment the current IRN value. Every Git \n> > command taking a revision parameter would accept an IRN using a syntax \n> > such as \"r$IRN\". Every commit would report the IRN to the user as well as \n> > the SHA ID. The IRN feature could be enabled or disabled via a \n> > configuration option.\n> \n> This of course limits IRN much. Tags are valid across repositories.\n> I'm not sure if many repositories are managed using shared repositories\n> (centralized approach).\n\nNot only that but its somewhat difficult to execute\n`git log v1.4.0..v1.4.1` on a central repository; if IRNs are only\nvalid within that repository then that's the only way they could\neven be used.\n\nNote that somewhat difficult here means you need to:\n\n\t- gain direct read-only access to the repository's files (not\n\t all systems may be able to offer this to all users);\n\n\t- set GIT_DIR environment variable OR pass --git-dir before\n\t the subcommand;\n\n\t- do all of that without doing something stupid in the\n\t repository directory such as `rm *` without realizing\n\t where you are;\n\n\t- but still maintain write access so you can push.\n\nand that latter GIT_DIR/--git-dir part users are bound to forgot as\nits not as natural as just assuming the repository is the directory\nyou are in. Of course that could be probably fixed...\n\n-- \nShawn.\n"},{"id":"27187","messageId":"Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"20060919220011.GD8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T22:24:31Z","receivedAt":"2006-09-19T22:24:31Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Wed, 20 Sep 2006, Petr Baudis wrote:\n\n> Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter\n> where Joel Dice said that...\n>> On Tue, 19 Sep 2006, Petr Baudis wrote:\n>>> Also, multiple IRNs could refer to a single real commit if you do e.g.\n>>> cg-admin-uncommit, since revlog logs revision updates, not new revisions\n>>> created. This may or may not be considered a good thing. If you rather\n>>> want to just create a new IRN at commit object creation time, also note\n>>> that some tools _might_ validly create commit objects and then throw\n>>> them away, which would generate non-sensical (and after prune, invalid)\n>>> IRNs.\n>>\n>> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN\n>> feature is intended mainly for shared repositories. I would suggest that\n>> such commands simply be disallowed for such repositories.\n>\n> What kind of shared repositories? You yourself said that IRNs are\n> local to a repository, thus they are not preserved over cloning/fetching\n> from a repository, if you mean that.\n\nThe scenario I envision is several developers, each with a clone of a \nshared repository. The clones would not have IRNs turned on, only the \nshared repository. So, when I do a \"git push\", I get an IRN back, and I \nam not confused, because I know that IRN only applies to the shared \nrepository. Then, when I mark a Bugzilla bug as fixed and attach the IRN \nto it, everybody knows that IRN refers to the shared repository. After \nall, I wouldn't mark the bug fixed if I had only committed it to my own \nprivate repository.\n\nI could also turn on IRNs on my clone if I really wanted, but not if I \nthought it would confuse myself or others.\n\n>> The problem of temporary commits certainly needs to be addressed. In this\n>> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so,\n>> perhaps I could somehow hook into the git-update-ref step. Is that what\n>> the revlog code does?\n>\n> Yes. But not every commit is always recorded to something in refs/.\n> The simplest case is if you fetch from a remote repository (or push to\n> your repository), only the latest commit is recorded.\n\nThat's what I figured. I should be able to walk the commit chain to get \nat all the commits in a push or fetch, right?\n\n - Joel\n"},{"id":"27188","messageId":"Pine.LNX.4.62.0609191625000.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"eeppkl$rm9$2@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T22:30:05Z","receivedAt":"2006-09-19T22:30:05Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Wed, 20 Sep 2006, Jakub Narebski wrote:\n\n> Joel Dice wrote:\n>\n>> I'm considering adopting Git for a medium-sized project which is currently\n>> managed using Subversion. I've used Git for a few smaller projects\n>> already, and the thing I've missed most from Subversion is the convenience\n>> of incrementing revision numbers. The following is a proposal to add this\n>> feature to Git.\n>>\n>>\n>> Rationale:\n>>\n>> Incrementing revision numbers (IRNs - an acronym I just made up) are\n>> useful in that they can be treated as auto-generated tags which are easier\n>> to remember and communicate than SHA hashes, yet do not require extra\n>> effort to create like real tags. Also, they have the advantage of being\n>> chronologically ordered, so if I assert that a bug was fixed in revision\n>> 42 of a shared repository, everyone may assume that revision 45 has that\n>> fix as well.\n>\n> That is true _only_ if you have linear history. If you have multiple\n> concurrent branches, revision 42 can be in branch 'next', revision '45' in\n> topic branch 'xx/topic' which forked before revision 42, and do not have\n> the fix.\n\nIn practice, this is not a problem. The branch referred to is usually \nunderstood from the context (ex. a Bugzilla bug for a particular version \nof a product implies a particular branch). Otherwise, yes, you must also \nexplictly state which branch the fix was applied to.\n\n> Unfortunately, one cannot (as of now) use result of git-describe as\n> . I'd rather have it fixed, than port idea from _centralized_\n> SCM do distributed SCM.\n>\n>> Proposal:\n>>\n>> As with Subversion, the IRN state in Git would be specific to a given\n>> repository and have no significance beyond that repository. Also like\n>> Subversion, IRN state would be global across a repository, so that a\n>> commit to any branch would increment the current IRN value. Every Git\n>> command taking a revision parameter would accept an IRN using a syntax\n>> such as \"r$IRN\". Every commit would report the IRN to the user as well as\n>> the SHA ID. The IRN feature could be enabled or disabled via a\n>> configuration option.\n>\n> This of course limits IRN much. Tags are valid across repositories.\n> I'm not sure if many repositories are managed using shared repositories\n> (centralized approach).\n\nI would suggest that most repositories are centralized. They're just not \nusing Git yet :)\n\n - Joel\n"},{"id":"27189","messageId":"20060919223350.GD11601@spearce.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-19T22:33:50Z","receivedAt":"2006-09-19T22:33:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Joel Dice wrote:\n> The scenario I envision is several developers, each with a clone of a \n> shared repository. The clones would not have IRNs turned on, only the \n> shared repository. So, when I do a \"git push\", I get an IRN back, and I \n> am not confused, because I know that IRN only applies to the shared \n> repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN \n> to it, everybody knows that IRN refers to the shared repository. After \n> all, I wouldn't mark the bug fixed if I had only committed it to my own \n> private repository.\n\nHow about recording the Bugzilla bug id in the commit message (such\nas by simply mentioning \"bug 123\") and having an update hook on the\ncentral repository extract that from the commits being pushed and\nposting an update to the Bugzilla database? The update can include\nthe branch name the commit(s) were pushed into and the final commit\nSHA1 (or say 8 character abbreviation).\n\nIts automatic and its easy for the developers. I'm (sort of) doing\nthis for a system that's a lot more difficult to use than Bugzilla.\nMy fellow developers are very happy.\n \n> That's what I figured. I should be able to walk the commit chain to get \n> at all the commits in a push or fetch, right?\n\nIn the update hook you get 3 args: refname oldsha1 newsha1\n\nYou can get the list of commits you are \"receiving\" during the single\npush operation from:\n\n\tgit log --pretty=raw $2..$3 \n\na quick parse for \"bug (\\d)+\" on that text, make a set of of IDs\nto update, then go update then storing the first 8 characters of\n$3 and $1 (the branch name) into your bug tracker.\n\nI said \"receiving\" in air quotes as you may already have some or\nall of those commits in the current repository; they just are part\nof other branches other than the one being pushed into.\n\n\nLater another developer can ask if the fix for bug 123 is in any\ngiven branch by looking at\n\n\tgit log master..$idfrombug\n\nwhere 'master' is any branch and $idfrombug is the 8 character\nabbreviation you stored into the bug record in the update hook.\n\nIf this returns no output then the bug fix is contained in the\nbranch master; if it returns output then those are the commits\nwhich were considered to be part of the bug fix that aren't in the\nbranch master.\n\n-- \nShawn.\n"},{"id":"27190","messageId":"20060919223905.GE11601@spearce.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-19T22:39:05Z","receivedAt":"2006-09-19T22:39:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Joel Dice wrote:\n> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN \n> feature is intended mainly for shared repositories. I would suggest that \n> such commands simply be disallowed for such repositories.\n> \n> The problem of temporary commits certainly needs to be addressed. In this \n> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so, \n> perhaps I could somehow hook into the git-update-ref step. Is that what \n> the revlog code does?\n\n$GIT_DIR/refs is always modified. Its probably the most heavily\nmodified part of a GIT_DIR, aside from the index. Simply because\nthe ref files must be modified every time a commit, fetch or merge\ncompletes. Its also a directory you don't want to delete; I once\ndid an `rm -rf .git/refs` in a repository with a many branches.\nThat was no fun to recover.\n\ngit-update-ref is used by pretty much all non-C code to update a\nref file. The APIs it calls invoke the reflog code to record the\nupdate being made to the ref if the user has enabled logging on\nthat ref (not all users want all refs logged apparently). I don't\nthink its a great idea to plug more complex logic into that part\nof the system. The reflog code already made it more complex then\nit needed to be; Linus apparently just found out how heavily we\nuse static buffers down there...\n\n-- \nShawn.\n"},{"id":"27191","messageId":"Pine.LNX.4.62.0609191630360.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"20060919220936.GA11601@spearce.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T22:40:40Z","receivedAt":"2006-09-19T22:40:40Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Tue, 19 Sep 2006, Shawn Pearce wrote:\n\n> Joel Dice wrote:\n>> I'm considering adopting Git for a medium-sized project which is currently\n>> managed using Subversion. I've used Git for a few smaller projects\n>> already, and the thing I've missed most from Subversion is the convenience\n>> of incrementing revision numbers. The following is a proposal to add this\n>> feature to Git.\n>\n> I can't say I miss that particular feature. Abbrevations of\n> SHA1 IDs tend to work very well for the projects I use Git on;\n> 6-8 characters is easily more than enough to uniquely identify\n> a revision. Heck half the time even 4 hex characters is enough.\n>\n>> Rationale:\n>>\n>> Incrementing revision numbers (IRNs - an acronym I just made up) are\n>> useful in that they can be treated as auto-generated tags which are easier\n>> to remember and communicate than SHA hashes, yet do not require extra\n>> effort to create like real tags. Also, they have the advantage of being\n>> chronologically ordered, so if I assert that a bug was fixed in revision\n>> 42 of a shared repository, everyone may assume that revision 45 has that\n>> fix as well.\n>\n> But with respect to what branch?\n>\n> Branches in a Git repository are very common:\n>\n> o------o-o-o-o-o-o--- B1\n> /\n> -o--o--o-----o--------o B2\n>\n> Assuming the branch point on the left was r60, what is the latest\n> commit on B1? On B2? What about if I merge B1 and B2 together?\n\nBranches in Subversion are also very common. The \"last changed\" IRN for a \nbranch is the index of the head of the branch in the history.\n\n> Or are you proposing that the commits are ordered by the time that\n> they arrive into the repository?\n\nYes.\n\n> But even if that's the case lets say I fix the bug on B1 in r42\n> but a commit on B2 gets assigned r45. The bug isn't fixed in r45;\n> not unless B1 was merged into B2 in r43, r44 or r45. But there's\n> no way to know that from just an IRN.\n>\n> I fail to see how IRNs simplify commit naming or determining where\n> a feature or bug fix is within the branching structure.\n\nI'm not suggesting that an IRN stand on it's own in this way. Additional \ncontext may be necessary depending on the situation. It's intended as a \nconvenience, not a replacement for the SHA IDs.\n\n>> A simple, efficient implementation of this feature would be based on a\n>> single file, $GIT_DIR/history, which would contain a newline-delimited\n>> list of SHA commit IDs in chronological order, oldest first. The current\n>> repository IRN would be calculated as the size of that file divided by the\n>> SHA+newline length, and the commit ID of any IRN could be determined by\n>> seeking to the correct offset in that file. Every commit would cause a\n>> new line to be appended to the history file with that commit's ID.\n>> Finally, a history file could be generated for an existing repository by\n>> serializing the commit history based on chronological order.\n>\n> How about just using bare tags under the namespace 'refs/tags/r/'?\n> With the new packed refs implemention these would cost you a tiny\n> amount of overhead over what you propose (due to the ref name also\n> being stored) but its already implemented and does the job just\n> as well.\n\nGood idea. I'll try that.\n\n - Joel\n"},{"id":"27192","messageId":"Pine.LNX.4.63.0609200038120.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-19T22:40:56Z","receivedAt":"2006-09-19T22:40:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Sep 2006, Joel Dice wrote:\n\n> The scenario I envision is several developers, each with a clone of a \n> shared repository. The clones would not have IRNs turned on, only the \n> shared repository. So, when I do a \"git push\", I get an IRN back, and I \n> am not confused, because I know that IRN only applies to the shared \n> repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN \n> to it, everybody knows that IRN refers to the shared repository. After \n> all, I wouldn't mark the bug fixed if I had only committed it to my own \n> private repository.\n\nWhy not just tag the commit with something like \"bugzilla/#bugid\"? \nGranted, it makes for lots of tags. But we actually handle lots of tags.\n\nBTW if your IRN just wants to serve to be less cryptic than SHA1s, you can \ntry git-name-rev (of course, it is only immutable if you have a recent \ntag and use the --tags option).\n\nCiao,\nDscho\n"},{"id":"27196","messageId":"Pine.LNX.4.62.0609191659350.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"eepq7l$dc$1@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T23:07:59Z","receivedAt":"2006-09-19T23:07:59Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Wed, 20 Sep 2006, Jakub Narebski wrote:\n\n> Jakub Narebski wrote:\n>\n>> Joel Dice wrote:\n>>\n>>> I'm considering adopting Git for a medium-sized project which is currently\n>>> managed using Subversion. I've used Git for a few smaller projects\n>>> already, and the thing I've missed most from Subversion is the convenience\n>>> of incrementing revision numbers. The following is a proposal to add this\n>>> feature to Git.\n>>>\n>>>\n>>> Rationale:\n>>>\n>>> Incrementing revision numbers (IRNs - an acronym I just made up) are\n>>> useful in that they can be treated as auto-generated tags which are easier\n>>> to remember and communicate than SHA hashes, yet do not require extra\n>>> effort to create like real tags. Also, they have the advantage of being\n>>> chronologically ordered, so if I assert that a bug was fixed in revision\n>>> 42 of a shared repository, everyone may assume that revision 45 has that\n>>> fix as well.\n>>\n>> That is true _only_ if you have linear history. If you have multiple\n>> concurrent branches, revision 42 can be in branch 'next', revision '45' in\n>> topic branch 'xx/topic' which forked before revision 42, and do not have\n>> the fix.\n>\n> Additionally, what does _chronological_ mean? Time the commit is recorded?\n\nYes.\n\n> Remember that in distributed development commits can be fetched from other\n> repository, or arrive via email and applied using git-am. In git you can\n> also rebase branch. Git records merges, and said merges are sometimes\n> just fast-forward. All those difficulties have to be solved for IRNs.\n\nAll of these boil down to pointing the head of a branch to a new commit \nobject, right? I'm simply proposing that every time this happens, that \nnew commit object (which may not really be *new*), should be appended to \nthe IRN history file, along with any commits attached to it (as in the \ncases of fetch, etc.).\n\n - Joel\n"},{"id":"27200","messageId":"Pine.LNX.4.62.0609191709160.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"Pine.LNX.4.64.0609191519090.4388@g5.osdl.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-19T23:35:36Z","receivedAt":"2006-09-19T23:35:36Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Tue, 19 Sep 2006, Linus Torvalds wrote:\n> On Wed, 20 Sep 2006, Petr Baudis wrote:\n>> This is actually exactly how SVN revision numbering works. There's just\n>> a single number (no '1.') and it indeed jumps randomly if you have\n>> several concurrent branches in your (ok, Linus does not have any, just\n>> someone's) repository.\n>\n> Oh, ok, if it's just a single numbering, then that's easy to do. It won't\n> _mean_ anything, and you're seriously screwed if you ever merge anything\n> else (or use a git that doesn't update the refcache or whatever), but it\n> is simple and stable within a single repo.\n\nWell, what it means is \"this is the order in which commits were applied to \nthis repository\". I suggest that this information is useful for the most \ncommon development style - the kind which relies on a central repository \nas the canonical source for a project's code. \"gcc-trunk-r117064\" means a \nlot more to me than \"39282037d7cc39829f1d56bf8307b8e5430d585f\", and is no \nless precise.\n\nI do believe that distributed VCSs such as Git can improve the \nproductivity of these kinds of projects without forcing the developers to \nsuddenly and dramatically alter their workflow. I think ICNs would help \nmake this possible.\n\n - Joel\n"},{"id":"27202","messageId":"eeq14e$isu$1@sea.gmane.org","threadId":"5608","inReplyTo":"Pine.LNX.4.62.0609191709160.9752@joeldicepc.ecovate.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-20T00:15:00Z","receivedAt":"2006-09-20T00:15:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Joel Dice wrote:\n\n> On Tue, 19 Sep 2006, Linus Torvalds wrote:\n>> On Wed, 20 Sep 2006, Petr Baudis wrote:\n>>> This is actually exactly how SVN revision numbering works. There's just\n>>> a single number (no '1.') and it indeed jumps randomly if you have\n>>> several concurrent branches in your (ok, Linus does not have any, just\n>>> someone's) repository.\n>>\n>> Oh, ok, if it's just a single numbering, then that's easy to do. It won't\n>> _mean_ anything, and you're seriously screwed if you ever merge anything\n>> else (or use a git that doesn't update the refcache or whatever), but it\n>> is simple and stable within a single repo.\n> \n> Well, what it means is \"this is the order in which commits were applied to \n> this repository\". I suggest that this information is useful for the most \n> common development style - the kind which relies on a central repository \n> as the canonical source for a project's code. \"gcc-trunk-r117064\" means a \n> lot more to me than \"39282037d7cc39829f1d56bf8307b8e5430d585f\", and is no \n> less precise.\n\nWhat about \"v1.4.2.1-gf7f93e7\", or \"tags/v1.4.2-rc4^0~19\", or just\n\"39282037\"? Or \"next@{2006-09-19 22:44:33 +0000}\"?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27216","messageId":"7virjjkmkc.fsf@assigned-by-dhcp.cox.net","threadId":"5608","inReplyTo":"20060919220604.GE8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-20T07:46:11Z","receivedAt":"2006-09-20T07:46:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes, responding to Linus:\n\n>> You're going to hit a few confusing issues if you really want to call \n>> things \"r1.x.y.z\"\n>\n> Noone does, that indeed would be horrible. But having the commits\n> numbered inside a repository would indeed make for simple usage if you\n> need to type in commit ids frequently, and could make Git a bit\n> friendlier to newcomers.\n\nSVN increments the number every time anything changes in the\nwhole-tree. Typically (1) when you make a commit, anywhere, in\nthe tree or (2) when you tag or branch. An interesting property\nof SVN version number is that you can say \"at revision 1423,\nfrotz and nitfol branches existed (filfre branch did not exist\nback then) and their states were such and such\".\n\nSo if Pasky wants to help Joel to emulate it in git, it is not\nsufficient to number commits because there are fast-forwards and\nit happens rather often in reality. A closer emulation at the\nconceptual level is to run pack-refs every time you change any\nref in your repository and version control the resulting\npacked-ref file with serial number.\n\nThen when people talk about git.git repository at kernel.org\npeople can say \"the repository at revision 144 had master at\n019ba86 and next at 832e76a; tag v1.4.3 did not exist back\nthen.\"\n\nIs it useful? In general I think it is useful only as a local\nmatter, just like ref-log is useful locally. In fact, I think\nit is a natural extension of the ref-log (and it can even\ncapture where the tags were, which I sometimes find sorely\nlacking in the current ref-log scheme -- anybody want to update\ngit-tag.sh to have it use ref-log? hint hint...).\n\nBut I am not sure how you would propagate it sanely in the\ndistributed environment.\n\nI do not often pull from others, but I occasionally pull from\nPaul's gitk tree. When I see gitk's tip advance and I pull from\nhim, I may end up getting a string of two commits. In other\nwords, in Joel's serial numbered revision scheme (emulated by\npacked-ref snapshots versioned serially), there are two gitk\ncommits between my rN and r(N+1).\n\nSomebody who hasn't thought about merges might be tempted to say\nthat we should use 2 revision numbers when a pull ends up\nintegrating 2 commits from outside, but that is not really\nfeasible. When you make a merge, it is not like you are\ncherry-picking individual commits from somebody else one by one.\nIn state rN, I did not have either of these two commits, and in\nstate r(N+1) I now have both, and that is the only definition of\nrN that makes any sense.\n\n Side note: SVN does not have this \"one state change but with\n multiple revisions\" uneasiness problem, because it does not\n have a merge in distributed SCM's sense. What it has is a\n convenient way to side-port changes that happened elsewhere\n to your state and create a new commit (so it is not that\n different from \"cvs update -j\"). After a \"merge\" happens\n you are just one commit ahead from previous state, just like\n a normal commit.\n\n The difference from that and us is that \"log ORIG_HEAD..\"\n will say we got new two commits integrated with the merge\n which makes us wonder why there are multiple events between\n two states, while SVN does not record what got cherry-picked\n from the side so you cannot even worry about it if you\n wanted to ;-).\n\nBut that definition stops making sense immediately when you look\nat things from Paul's point of view. He had these two commits\ndone separately, and in his repository they are recorded as two\nseparate events, even under Joel's serial numbered revision\nscheme. So for this serially numbered revisioning scheme to\nmake any sense to you, you have to refuse the everybody-is-equal\ndistributed model of git, and instead treat one repository\n(mine) as more important than all others. If that central\nrepository says these two commits did not exist in rN and they\nappeared in r(N+1), that's the reality as far as you are\nconcerned, and what Paul says does not count to you at all.\nThat makes Paul unhappy.\n\nIn the same sense, you have to realize that the number \"144\"\nabove that came from kernel.org would mean absolutely nothing to\nme. I work on one commit at a time unless applying sequence of\npatches, and typically ref-log knows that the last time _my_ tip\nof \"master\" and \"next\" advanced were more than 30 minutes apart.\nBut I push four branches (maint/master/next/pu) out at the same\ntime to kernel.org, so between revision 143 and revision 144\nfour refs would have changed at kernel.org. But in the\nrepository I do the real work with ref-log knows that that is\nnot the way how these branches advanced at all. So it is not a\nconvenient number to work with from my point of view either.\n"},{"id":"27244","messageId":"Pine.LNX.4.62.0609200851450.9752@joeldicepc.ecovate.com","threadId":"5608","inReplyTo":"eeq14e$isu$1@sea.gmane.org","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Joel Dice","fromEmail":"dicej@mailsnare.net","sentAt":"2006-09-20T16:13:15Z","receivedAt":"2006-09-20T16:13:15Z","isPatch":false,"sender":{"key":"dicej@mailsnare.net","avatar":null},"body":"On Wed, 20 Sep 2006, Jakub Narebski wrote:\n> Joel Dice wrote:\n>> Well, what it means is \"this is the order in which commits were applied to\n>> this repository\". I suggest that this information is useful for the most\n>> common development style - the kind which relies on a central repository\n>> as the canonical source for a project's code. \"gcc-trunk-r117064\" means a\n>> lot more to me than \"39282037d7cc39829f1d56bf8307b8e5430d585f\", and is no\n>> less precise.\n>\n> What about \"v1.4.2.1-gf7f93e7\", or \"tags/v1.4.2-rc4^0~19\", or just\n> \"39282037\"? Or \"next@{2006-09-19 22:44:33 +0000}\"?\n\nThe last one is closest to what I want in that it gives me some sense of \nthe order in which commits appeared in the repository.\n\nAnyway, after some reflection, I've come to the following conclusions:\n\n 1. Although the IRN feature would be useful to people like me, it doesn't \nfit _naturally_ into Git in particular or DVCSs in general due to the \nfact that IRNs are tied to repositories.\n\n 2. There are easier, more elegant ways to solve the problem of tying \ncommits to bug numbers, as Shawn and Johannes pointed out.\n\nSo, I'm shelving the IRN idea until and unless I can reconcile it with the \nspirit of distributed version control. In the meantime, I plan to pursue \na solution along the lines of Shawn's update hook strategy for bug \ntracking, perhaps with the additional step of automatically tagging each \nsuch update.\n\nThanks for everyone's comments.\n\n - Joel\n"},{"id":"27268","messageId":"200609201928.46024.robin.rosenberg.lists@dewire.com","threadId":"5608","inReplyTo":"20060919220604.GE8259@pasky.or.cz","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-09-20T17:28:45Z","receivedAt":"2006-09-20T17:28:45Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 20 september 2006 00:06 skrev Petr Baudis:\n[...]\n> But having the commits\n> numbered inside a repository would indeed make for simple usage if you\n> need to type in commit ids frequently, and could make Git a bit\n> friendlier to newcomers.\n\nTyping those numbers is really insane, so the idea never occurred to me. Most \nenvironments have simple methods to copy and paste strings using a clipboard,\neven in a console. So typically you can left-doubleclick on a string and paste \nwith the middle button in *nix like systems (right button in cygwin/windows \ncommand line).\n\n-- robin\n"},{"id":"27274","messageId":"20060920182203.GS8259@pasky.or.cz","threadId":"5608","inReplyTo":"200609201928.46024.robin.rosenberg.lists@dewire.com","subject":"Re: Subversion-style incrementing revision numbers","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-20T18:22:03Z","receivedAt":"2006-09-20T18:22:03Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 20, 2006 at 07:28:45PM CEST, I got a letter\nwhere Robin Rosenberg said that...\n> Typing those numbers is really insane, so the idea never occurred to me. Most \n> environments have simple methods to copy and paste strings using a clipboard,\n> even in a console. So typically you can left-doubleclick on a string and paste \n> with the middle button in *nix like systems (right button in cygwin/windows \n> command line).\n\n ...which is certainly appealing for the Plan9 fans, but I'm not so\nexcited from having to grab my mouse all the time. :-) That said, typing\njust the few leading digits is not really that painful.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> Dear diary, on Wed, Sep 20, 2006 at 07:28:45PM CEST, I got a letter\n> where Robin Rosenberg said that...\n>> Typing those numbers is really insane, so the idea never occurred to me. Most \n>> environments have simple methods to copy and paste strings using a clipboard,\n>> even in a console. So typically you can left-doubleclick on a string and paste \n>> with the middle button in *nix like systems (right button in cygwin/windows \n>> command line).\n>\n> ...which is certainly appealing for the Plan9 fans, but I'm not so\n> excited from having to grab my mouse all the time. :-)\n\nI am so used to live always in \"screen\" so that is not much of a\nproblem for me.\n\nSorry for the noise ;-).\n"}]}