{"thread":{"id":"6284","subject":"I just pulled and built 'next'...","startedAt":"2007-01-08T13:32:30Z","lastAt":"2007-01-10T13:24:16Z","messageCount":9,"participants":["Theodore Ts'o","Junio C Hamano","Theodore Tso","Shawn O. Pearce","Andreas Ericsson","Uwe Kleine-König","Uwe Kleine-Koenig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31139","messageId":"E1H3uc2-0004m1-Ua@think.thunk.org","threadId":"6284","inReplyTo":null,"subject":"I just pulled and built 'next'...","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2007-01-08T13:32:30Z","receivedAt":"2007-01-08T13:32:30Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"I just pulled and built 'next' and it reported a version number of\n1.4.4.4.g71bb6 -- and not one v1.5.0-rc0.g71bb6.  I can understand why,\nsince it found the changes pulled in from the maint branch before it\nfound the v1.5.0-rc0 tag --- but it could be more than a little\nmisleading.  Is this something that can be fixed in any way, short of\nfinding all of the tags reachable from HEAD and then doing a sort?  That\nseems like a gross kludge, but I can't think of any other way of fixing\nit.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"31157","messageId":"7vvejhwa6g.fsf@assigned-by-dhcp.cox.net","threadId":"6284","inReplyTo":"E1H3uc2-0004m1-Ua@think.thunk.org","subject":"Re: I just pulled and built 'next'...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-08T20:11:35Z","receivedAt":"2007-01-08T20:11:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Theodore Ts'o\" <tytso@mit.edu> writes:\n\n> I just pulled and built 'next' and it reported a version number of\n> 1.4.4.4.g71bb6 -- and not one v1.5.0-rc0.g71bb6.  I can understand why,\n> since it found the changes pulled in from the maint branch before it\n> found the v1.5.0-rc0 tag --- but it could be more than a little\n> misleading.  Is this something that can be fixed in any way, short of\n> finding all of the tags reachable from HEAD and then doing a sort?  That\n> seems like a gross kludge, but I can't think of any other way of fixing\n> it.\n\nOne question is how you would sort the result.  If you sort them\nby taggerdate, you would get v1.4.4.4 anyway ;-).\n\nIf we go with topology, we do not necessarily have to find all\nthe tags.  When we hit a commit that is tagged, we can stop the\ntraversal (so after finding v1.5.0-rc0, we do not have to go\nback along the 'master' lineage to find v1.4.4 tag).  Traversing\nfrom the tip of 'master' (or 'next') this way we will notice\nthat v1.5.0-rc0 and v1.4.4.4 are the candidates without going\nany further in the past.\n\nBut the question still remains which one between the two to\npick.\n"},{"id":"31162","messageId":"20070108210002.GA15121@thunk.org","threadId":"6284","inReplyTo":"7vvejhwa6g.fsf@assigned-by-dhcp.cox.net","subject":"Re: I just pulled and built 'next'...","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-08T21:00:02Z","receivedAt":"2007-01-08T21:00:02Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jan 08, 2007 at 12:11:35PM -0800, Junio C Hamano wrote:\n> One question is how you would sort the result.  If you sort them\n> by taggerdate, you would get v1.4.4.4 anyway ;-).\n\nI was assuming either lexigraphically, or via some really complicated\nrpm/dpkg version number comparison scheme.  :-)\n\n> If we go with topology, we do not necessarily have to find all\n> the tags.  When we hit a commit that is tagged, we can stop the\n> traversal (so after finding v1.5.0-rc0, we do not have to go\n> back along the 'master' lineage to find v1.4.4 tag).  Traversing\n> from the tip of 'master' (or 'next') this way we will notice\n> that v1.5.0-rc0 and v1.4.4.4 are the candidates without going\n> any further in the past.\n> \n> But the question still remains which one between the two to\n> pick.\n\nYeah, that is the question.  If we're willing to look at the tag name,\nit's pretty clear that if both v1.5.0-rc0 and v1.4.4.4 is reachable\nfrom the head, it should be based on the \"newer\" version, i.e.,\nv1.5.0-rc0.  A human can figure this out easily, but algorithimically\nwe end up having to use something like the rpm or dpkg version\ncomparison algorithm, both of which are hueristics that will sometimes\nget thigns wrong.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"31182","messageId":"20070109032124.GA1904@spearce.org","threadId":"6284","inReplyTo":"20070108210002.GA15121@thunk.org","subject":"Re: I just pulled and built 'next'...","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-09T03:21:24Z","receivedAt":"2007-01-09T03:21:24Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Mon, Jan 08, 2007 at 12:11:35PM -0800, Junio C Hamano wrote:\n> > One question is how you would sort the result.  If you sort them\n> > by taggerdate, you would get v1.4.4.4 anyway ;-).\n> \n> I was assuming either lexigraphically, or via some really complicated\n> rpm/dpkg version number comparison scheme.  :-)\n> \n> > If we go with topology, we do not necessarily have to find all\n> > the tags.  When we hit a commit that is tagged, we can stop the\n> > traversal (so after finding v1.5.0-rc0, we do not have to go\n> > back along the 'master' lineage to find v1.4.4 tag).  Traversing\n> > from the tip of 'master' (or 'next') this way we will notice\n> > that v1.5.0-rc0 and v1.4.4.4 are the candidates without going\n> > any further in the past.\n> > \n> > But the question still remains which one between the two to\n> > pick.\n> \n> Yeah, that is the question.  If we're willing to look at the tag name,\n> it's pretty clear that if both v1.5.0-rc0 and v1.4.4.4 is reachable\n> from the head, it should be based on the \"newer\" version, i.e.,\n> v1.5.0-rc0.  A human can figure this out easily, but algorithimically\n> we end up having to use something like the rpm or dpkg version\n> comparison algorithm, both of which are hueristics that will sometimes\n> get thigns wrong.\n\n  $ git rev-list v1.5.0-rc0..next | wc -l\n  687\n  $ git rev-list v1.4.4.4..next | wc -l\n  1051\n\nSo what about doing Junio's suggestion of going by topology and\ncoming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\nright now), and if more than one is found compute the number of\ncommits between each tag and the requested revision, and take the\ntag that has a smallest number of commits?\n\nI think it would come up right more often than not and avoids\nany sort of tag name parsing algorithm.  It is also somewhat\nexplainable to users as it does have some common sense: the tag\n\"nearest\" to the requested revision is the one that has the most\nnumber of commits in common with the requested revision.\n\n-- \nShawn.\n"},{"id":"31217","messageId":"45A362D0.7090304@op5.se","threadId":"6284","inReplyTo":"20070109032124.GA1904@spearce.org","subject":"Re: I just pulled and built 'next'...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-09T09:39:28Z","receivedAt":"2007-01-09T09:39:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Theodore Tso <tytso@mit.edu> wrote:\n>> On Mon, Jan 08, 2007 at 12:11:35PM -0800, Junio C Hamano wrote:\n>>> One question is how you would sort the result.  If you sort them\n>>> by taggerdate, you would get v1.4.4.4 anyway ;-).\n>> I was assuming either lexigraphically, or via some really complicated\n>> rpm/dpkg version number comparison scheme.  :-)\n>>\n>>> If we go with topology, we do not necessarily have to find all\n>>> the tags.  When we hit a commit that is tagged, we can stop the\n>>> traversal (so after finding v1.5.0-rc0, we do not have to go\n>>> back along the 'master' lineage to find v1.4.4 tag).  Traversing\n>>> from the tip of 'master' (or 'next') this way we will notice\n>>> that v1.5.0-rc0 and v1.4.4.4 are the candidates without going\n>>> any further in the past.\n>>>\n>>> But the question still remains which one between the two to\n>>> pick.\n>> Yeah, that is the question.  If we're willing to look at the tag name,\n>> it's pretty clear that if both v1.5.0-rc0 and v1.4.4.4 is reachable\n>> from the head, it should be based on the \"newer\" version, i.e.,\n>> v1.5.0-rc0.  A human can figure this out easily, but algorithimically\n>> we end up having to use something like the rpm or dpkg version\n>> comparison algorithm, both of which are hueristics that will sometimes\n>> get thigns wrong.\n> \n>   $ git rev-list v1.5.0-rc0..next | wc -l\n>   687\n>   $ git rev-list v1.4.4.4..next | wc -l\n>   1051\n> \n\n$ git rev-list v1.5.0-rc0..master | wc -l\n220\n$ git rev-list v1.4.4.4..master | wc -l\n584\n\nso that's one more case where it got things right.\n\n> So what about doing Junio's suggestion of going by topology and\n> coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\n> right now), and if more than one is found compute the number of\n> commits between each tag and the requested revision, and take the\n> tag that has a smallest number of commits?\n> \n\nSounds sensible. Without doing this, we'd more or less constantly get \nbitten by it when pulling a maintenance branch with a (as currently \ncalculated) more recent tag than the one that actually sits on the \nbranch we're tagging.\n\nThe only case we'd get it wrong is if tags are close to each other, \nsomeone tags a feature-branch before it being merged to master, then \nmerges it and cuts a release.\n\nIn my experience all software projects have a single branch used for \nreleases, and that's the one that's checked out when the tag is created.\n\n> I think it would come up right more often than not and avoids\n> any sort of tag name parsing algorithm.  It is also somewhat\n> explainable to users as it does have some common sense: the tag\n> \"nearest\" to the requested revision is the one that has the most\n> number of commits in common with the requested revision.\n> \n\nThe only problem I foresee is that v1.4.4.4 *looks* closer when viewed \nin gitk/qgit, but there it also looks like it's on a different branch, \nso we're probably safe from user harrassment there too.\n\nPossibly we'd want to have both, with the old behaviour requiring a \nswitch to obtain (--date-order ?).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"31240","messageId":"20070109135401.GB17352@thunk.org","threadId":"6284","inReplyTo":"20070109032124.GA1904@spearce.org","subject":"Re: I just pulled and built 'next'...","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-09T13:54:01Z","receivedAt":"2007-01-09T13:54:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jan 08, 2007 at 10:21:24PM -0500, Shawn O. Pearce wrote:\n> So what about doing Junio's suggestion of going by topology and\n> coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\n> right now), and if more than one is found compute the number of\n> commits between each tag and the requested revision, and take the\n> tag that has a smallest number of commits?\n\nAh, thanks for showing the example using git-rev-list.  I was assuming\n\"topology\" based on the distance as shown by gitk, and that's quite\ndifferent from what git-rev-list shows.  Agreed, that hueristic makes\na lot of sense.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"31261","messageId":"20070109173501.GA3732@cepheus","threadId":"6284","inReplyTo":"20070109032124.GA1904@spearce.org","subject":"Re: I just pulled and built 'next'...","fromName":"Uwe Kleine-König","fromEmail":"zeisberg@informatik.uni-freiburg.de","sentAt":"2007-01-09T17:35:01Z","receivedAt":"2007-01-09T17:35:01Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nShawn O. Pearce wrote:\n>   $ git rev-list v1.5.0-rc0..next | wc -l\n>   687\n>   $ git rev-list v1.4.4.4..next | wc -l\n>   1051\n> \n> So what about doing Junio's suggestion of going by topology and\n> coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\n> right now), and if more than one is found compute the number of\n> commits between each tag and the requested revision, and take the\n> tag that has a smallest number of commits?\nOne scenario where this will fail is when a bugfix is commited on top of\nv1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.\n\nJust my 0.02$.\n\nUwe\n\n-- \nUwe Kleine-König\n\nexit vi, lesson III:\n: x ! <CR>\n\nNB: may write current file\n"},{"id":"31315","messageId":"20070110000600.GE30023@spearce.org","threadId":"6284","inReplyTo":"20070109173501.GA3732@cepheus","subject":"Re: I just pulled and built 'next'...","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-10T00:06:00Z","receivedAt":"2007-01-10T00:06:00Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Uwe Kleine-K?nig <zeisberg@informatik.uni-freiburg.de> wrote:\n> Shawn O. Pearce wrote:\n> >   $ git rev-list v1.5.0-rc0..next | wc -l\n> >   687\n> >   $ git rev-list v1.4.4.4..next | wc -l\n> >   1051\n> > \n> > So what about doing Junio's suggestion of going by topology and\n> > coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\n> > right now), and if more than one is found compute the number of\n> > commits between each tag and the requested revision, and take the\n> > tag that has a smallest number of commits?\n>\n> One scenario where this will fail is when a bugfix is commited on top of\n> v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.\n\nActually it still works, and does what you want.  The scenario you\nare describing is exactly the one that caused this bug to appear,\nand is the one my suggestion is trying to offer a partly sane\nsolution to.\n\nTry it.  Checkout v1.4.4.4, make a trivial commit, merge it to\nmaster, then merge that to next.  You'll still come up with the fact\nthat master (or next) have less commits different from v1.5.0-rc0\nthan they have from your hypothetical v1.4.4.5.  In this case the\nthe v1.5.0-rc0 tag should still be taken.\n\nIts easy to explain this difference in terms of what the user\nsees via `git log` and `git rev-list`.  We're taking the tag which\nhas the fewest commits different.  This will hold even if `next`\nsuddenly gets another 800 new commits (changing the above counts\nto 1847 and 1851 respectively).\n\n\nWhere it might fail is if v1.4.4.5 suddenly gets another 1000 commits\nas part of its bug fix release and those all get merged into next.\nNow v1.4.4.5 is closer than v1.5.0-rc0.  But you know what, that\ndoes still make a lot of sense.  If you look at the git log (or\ngit shortlog) between v1.4.4.5 and next there's less output than\nif you look at it between v1.5.0-rc0 and next.\n\n-- \nShawn.\n"},{"id":"31389","messageId":"20070110132416.GA13156@informatik.uni-freiburg.de","threadId":"6284","inReplyTo":"20070110000600.GE30023@spearce.org","subject":"Re: I just pulled and built 'next'...","fromName":"Uwe Kleine-Koenig","fromEmail":"zeisberg@informatik.uni-freiburg.de","sentAt":"2007-01-10T13:24:16Z","receivedAt":"2007-01-10T13:24:16Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nShawn O. Pearce wrote:\n> Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> wrote:\n> > Shawn O. Pearce wrote:\n> > >   $ git rev-list v1.5.0-rc0..next | wc -l\n> > >   687\n> > >   $ git rev-list v1.4.4.4..next | wc -l\n> > >   1051\n> > > \n> > > So what about doing Junio's suggestion of going by topology and\n> > > coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4\n> > > right now), and if more than one is found compute the number of\n> > > commits between each tag and the requested revision, and take the\n> > > tag that has a smallest number of commits?\n> >\n> > One scenario where this will fail is when a bugfix is commited on top of\n> > v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.\n> \n> Actually it still works, and does what you want.  The scenario you\n> are describing is exactly the one that caused this bug to appear,\n> and is the one my suggestion is trying to offer a partly sane\n> solution to.\nOK, I got it.  I thought in \"shortest ways\", but that's obviously\ndifferent from \"commits inbetween\".  Thanks for that one more\nexplanation.  Now it really makes sense to me.\n\nBest regards\nUwe\n-- \nUwe Kleine-Koenig\n\nhttp://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2\n"}]}