{"thread":{"id":"29548","subject":"Specifying revisions in the future","startedAt":"2012-02-04T15:58:55Z","lastAt":"2012-02-07T21:25:32Z","messageCount":16,"participants":["jpaugh@gmx.us","Jakub Narebski","Matthieu Moy","Andreas Schwab","Junio C Hamano","Philip Oakley","Miles Bader","Jonathan Paugh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183880","messageId":"jgjkk0$qrg$1@dough.gmane.org","threadId":"29548","inReplyTo":null,"subject":"Specifying revisions in the future","fromName":"","fromEmail":"jpaugh@gmx.us","sentAt":"2012-02-04T15:58:55Z","receivedAt":"2012-02-04T15:58:55Z","isPatch":false,"sender":{"key":"jpaugh@gmx.us","avatar":null},"body":"Hello.\n\nIs it possible to specify revisions in the future? The gitrevisions man\npage implies otherwise. Alternatively, is there a way to find out the\nnumber of commits between two revs---assuming one is an ancestor of the\nother?\n\nI want to do a certain arbitrary operation for each revision between\nwhere I am now and the tip of the branch.\n\n v1.0-a master\n \\ \\\no---o---o---o---o---o---o\n |\n I am here\n\nI've been using the following to do what I want:\n\nref=master; \\\nfor i in {5..1}; do \\\n echo; \\\n git log --stat $ref~$i^\\!; \\\n read -p 'Full diff? '; \\\n echo; \\\n if [[ $REPLY == 'y' ]]; then \\\n git diff $ref~$i^\\!; \\\n fi; \\\ndone;\n\nwhich lists the log and diffstat for last 5 commits between master and\nwhere I am (e.g. an older tag/branch) with an optional full diff. I know\nimplementing revision specifiers to the future is nontrivial. (I\nrealized that when I considered non-linear histories.) In this case,\nI've distilled it to the point that all I need is the number of commits\nbetween two revs. Can this be had without manually inspecting git log?\nOr, is there a better way to get detailed diffs like this?\n\nThanks.\nJonathan Paugh\n"},{"id":"183882","messageId":"m3ipjmknhc.fsf@localhost.localdomain","threadId":"29548","inReplyTo":"jgjkk0$qrg$1@dough.gmane.org","subject":"Re: Specifying revisions in the future","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-05T02:44:46Z","receivedAt":"2012-02-05T02:44:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"jpaugh@gmx.us writes:\n\n> Hello.\n\n> I want to do a certain arbitrary operation for each revision between\n> where I am now and the tip of the branch.\n> \n> v1.0-a master\n> \\ \\\n> o---o---o---o---o---o---o\n> |\n> I am here\n\nThat is the problem X.\n \n> Is it possible to specify revisions in the future? The gitrevisions man\n> page implies otherwise. Alternatively, is there a way to find out the\n> number of commits between two revs---assuming one is an ancestor of the\n> other?\n\nThat is your idea of a solution, Y.\n\nYou have XY problem. You need to do X, and you think you can use Y to\ndo X, so you ask about how to do Y.\n\nIf you want to list all revsions between v1.0-a and master, use\n\n git rev-list v1.0a..master\n\nor\n\n git rev-list --ancestry-path v1.0a..master\n\ndepending on definition of _between_ (see \"History simplification\" in\ngit-log(1) manpage for description of `--ancestry-path` option).\n\n> \n> I've been using the following to do what I want:\n> \n> ref=master; \\\n> for i in {5..1}; do \\\n> echo; \\\n> git log --stat $ref~$i^\\!; \\\n> read -p 'Full diff? '; \\\n> echo; \\\n> if [[ $REPLY == 'y' ]]; then \\\n> git diff $ref~$i^\\!; \\\n> fi; \\\n> done;\n> \n> which lists the log and diffstat for last 5 commits between master and\n> where I am (e.g. an older tag/branch) with an optional full diff. I know\n> implementing revision specifiers to the future is nontrivial. (I\n> realized that when I considered non-linear histories.) In this case,\n> I've distilled it to the point that all I need is the number of commits\n> between two revs. Can this be had without manually inspecting git log?\n> Or, is there a better way to get detailed diffs like this?\n\n-- \nJakub Narebski\n"},{"id":"183883","messageId":"201202050407.56612.jnareb@gmail.com","threadId":"29548","inReplyTo":"4F2DEF89.4030302@gmx.us","subject":"Re: Specifying revisions in the future","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-05T03:07:55Z","receivedAt":"2012-02-05T03:07:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonathan Paugh wrote:\n\n> > You have XY problem. You need to do X, and you think you can use Y to\n> > do X, so you ask about how to do Y.\n> > \n> > If you want to list all revsions between v1.0-a and master, use\n> > \n> > git rev-list v1.0a..master\n> > \n> > or\n> > \n> > git rev-list --ancestry-path v1.0a..master\n> Thanks. This Y' will take me to lot's of exciting destinations---and I\n> must confess I haven't messed with the plumbing heretofore.\n\nOf course you can also do\n\n git log --ancestry-path v1.0a..master \n\n-- \nJakub Narebski\nPoland\n"},{"id":"183909","messageId":"vpqipjlf309.fsf@bauges.imag.fr","threadId":"29548","inReplyTo":"jgjkk0$qrg$1@dough.gmane.org","subject":"Re: Specifying revisions in the future","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-02-05T20:18:14Z","receivedAt":"2012-02-05T20:18:14Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"jpaugh@gmx.us writes:\n\n> Hello.\n>\n> Is it possible to specify revisions in the future?\n\nYou mean, the opposite of ^ or ~n?\n\nAFAIK, there isn't, and there's a good reason for that: ^ is\nwell-defined, it's the first parent of , and it won't change\nunless one rewrites this commit.\n\n\"the successor of \", OTOH, is not well defined, since there can\nbe several successors, and one can't order them reliably (you can't\nreally know the set of successors, because they can exist in different\nrepositories).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"183924","messageId":"m21uq9x8q2.fsf@igel.home","threadId":"29548","inReplyTo":"vpqipjlf309.fsf@bauges.imag.fr","subject":"Re: Specifying revisions in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-05T21:37:25Z","receivedAt":"2012-02-05T21:37:25Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Matthieu Moy writes:\n\n> \"the successor of \", OTOH, is not well defined, since there can\n> be several successors, and one can't order them reliably (you can't\n> really know the set of successors, because they can exist in different\n> repositories).\n\nYet it would be nice to have a concise notation for \"the nth successor\nof towards \" (using --first-parent ordering when\nambiguous).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"183928","messageId":"m3ehu9kknw.fsf@localhost.localdomain","threadId":"29548","inReplyTo":"m21uq9x8q2.fsf@igel.home","subject":"Re: Specifying revisions in the future","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-05T21:57:55Z","receivedAt":"2012-02-05T21:57:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Schwab writes:\n> Matthieu Moy writes:\n> \n> > \"the successor of \", OTOH, is not well defined, since there can\n> > be several successors, and one can't order them reliably (you can't\n> > really know the set of successors, because they can exist in different\n> > repositories).\n> \n> Yet it would be nice to have a concise notation for \"the nth successor\n> of towards \" (using --first-parent ordering when\n> ambiguous).\n\nFirst, \"the nth successor\"... from which refs? Commit objects have\npointers in one direction only, from commit to its ancestors (earlier\ncommits).\n\nSecond, `--first-parent' won't help here. Take for example the\nfollowing situation:\n\n ---X<---*<---.<---A\n \\\n \\--.<---B\n\nX+3 is A or B? Note that pointers point _to_ '*' commit, so there is\nnot first or second here - no natural ordering like in the case of\ncommit parents.\n\n-- \nJakub Narebski\n"},{"id":"183929","messageId":"7v7h01eybe.fsf@alter.siamese.dyndns.org","threadId":"29548","inReplyTo":"m21uq9x8q2.fsf@igel.home","subject":"Re: Specifying revisions in the future","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-05T21:59:33Z","receivedAt":"2012-02-05T21:59:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> Matthieu Moy writes:\n>\n>> \"the successor of \", OTOH, is not well defined, since there can\n>> be several successors, and one can't order them reliably (you can't\n>> really know the set of successors, because they can exist in different\n>> repositories).\n>\n> Yet it would be nice to have a concise notation for \"the nth successor\n> of towards \" (using --first-parent ordering when\n> ambiguous).\n\nI thought that 47 different people can build on Linux v3.2 and when you\nask the children of v3.2^0, you would not know which ones to show in what\norder, let alone \"concise notation to pick one at random among them\".\n\nDid you mean --first-child?\n"},{"id":"183932","messageId":"m2wr81vsdv.fsf@igel.home","threadId":"29548","inReplyTo":"m3ehu9kknw.fsf@localhost.localdomain","subject":"Re: Specifying revisions in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-05T22:15:40Z","receivedAt":"2012-02-05T22:15:40Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jakub Narebski writes:\n\n> Andreas Schwab writes:\n>> Matthieu Moy writes:\n>> \n>> > \"the successor of \", OTOH, is not well defined, since there can\n>> > be several successors, and one can't order them reliably (you can't\n>> > really know the set of successors, because they can exist in different\n>> > repositories).\n>> \n>> Yet it would be nice to have a concise notation for \"the nth successor\n>> of towards \" (using --first-parent ordering when\n>> ambiguous).\n>\n> First, \"the nth successor\"... from which refs?\n\n>From the first given commit towards the other given commit (the latter\ndefaulting to HEAD).\n\n> Second, `--first-parent' won't help here. Take for example the\n> following situation:\n>\n> ---X<---*<---.<---A\n> \\\n> \\--.<---B\n>\n> X+3 is A or B?\n\nIf \"towards A\" then it is A, if \"towards B\", it is B. In other words,\nto get the \"nth successor of C1 towards C2\" take the leftmost possible\nparent when walking from C2 to C1, then walk back n commits along this\npath. This way you should have an unambigous definition.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"183933","messageId":"201202052324.59941.jnareb@gmail.com","threadId":"29548","inReplyTo":"m2wr81vsdv.fsf@igel.home","subject":"Re: Specifying revisions in the future","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-05T22:24:59Z","receivedAt":"2012-02-05T22:24:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 5 Feb 2012, Andreas Schwab wrote:\n> Jakub Narebski writes:\n>> Andreas Schwab writes:\n>>> Matthieu Moy writes:\n>>> \n>>>> \"the successor of \", OTOH, is not well defined, since there can\n>>>> be several successors, and one can't order them reliably (you can't\n>>>> really know the set of successors, because they can exist in different\n>>>> repositories).\n>>> \n>>> Yet it would be nice to have a concise notation for \"the nth successor\n>>> of towards \" (using --first-parent ordering when\n>>> ambiguous).\n>>\n>> First, \"the nth successor\"... from which refs?\n> \n> From the first given commit towards the other given commit (the latter\n> defaulting to HEAD).\n\nThat helps some, but not all situations, see below.\n \n> > Second, `--first-parent' won't help here. Take for example the\n> > following situation:\n> >\n> > ---X<---*<---.<---A\n> > \\\n> > \\--.<---B\n> >\n> > X+3 is A or B?\n> \n> If \"towards A\" then it is A, if \"towards B\", it is B. In other words,\n> to get the \"nth successor of C1 towards C2\" take the leftmost possible\n> parent when walking from C2 to C1, then walk back n commits along this\n> path. This way you should have an unambigous definition.\n\nNope, still ambiguous:\n\n\n\n ---X<---*<---.<---A<---.<---M<---\n \\ /\n \\--.<---B<------/\n\nIs X+3 A or B? Though '--first-parent + towards N' is I think unambiguous.\n-- \nJakub Narebski\nPoland\n"},{"id":"183938","messageId":"178AA8FDB02246D9AA9416C0D54E51A8@PhilipOakley","threadId":"29548","inReplyTo":"201202052324.59941.jnareb@gmail.com","subject":"Re: Specifying revisions in the future","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2012-02-05T22:49:59Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jakub Narebski\" \nTo: \"Andreas Schwab\" \nCc: \"Matthieu Moy\" ; ; \n\nSent: Sunday, February 05, 2012 10:24 PM\n> On Sun, 5 Feb 2012, Andreas Schwab wrote:\n>> Jakub Narebski writes:\n>>> Andreas Schwab writes:\n>>>> Matthieu Moy writes:\n>>>>\n>>>>> \"the successor of \", OTOH, is not well defined, since there \n>>>>> can\n>>>>> be several successors, and one can't order them reliably (you can't\n>>>>> really know the set of successors, because they can exist in different\n>>>>> repositories).\n>>>>\n>>>> Yet it would be nice to have a concise notation for \"the nth successor\n>>>> of towards \" (using --first-parent ordering when\n>>>> ambiguous).\n>>>\n>>> First, \"the nth successor\"... from which refs?\n>>\n>> From the first given commit towards the other given commit (the latter\n>> defaulting to HEAD).\n>\n> That helps some, but not all situations, see below.\n>\n>> > Second, `--first-parent' won't help here. Take for example the\n>> > following situation:\n>> >\n>> > ---X<---*<---.<---A\n>> > \\\n>> > \\--.<---B\n>> >\n>> > X+3 is A or B?\n>>\n>> If \"towards A\" then it is A, if \"towards B\", it is B. In other words,\n>> to get the \"nth successor of C1 towards C2\" take the leftmost possible\n>> parent when walking from C2 to C1, then walk back n commits along this\n>> path. This way you should have an unambigous definition.\n>\n> Nope, still ambiguous:\n>\n>\n>\n> ---X<---*<---.<---A<---.<---M<---\n> \\ /\n> \\--.<---B<------/\n>\n> Is X+3 A or B? Though '--first-parent + towards N' is I think \n> unambiguous.\n> -- \nIs there also a rule missing for X+2, viewed from D, in this example\n\nX<---Y<---Z<---\n \\ \\\nA<----B<----C<----D\nas to which order the first parent rule should _not_ be applied when D's \nfirst parent chain doesn't reach X (it reaches A).\nUsing 'oldest' first for alternate parent testing would make X+2 = B, whilst \n'newest' first would make X+2=Z. I have used the chain order for \n'newest/oldest', rather than commit date.\n(I'm sure that there already exists a natural rule in the dag walk order).\n\nPhilip \n"},{"id":"183939","messageId":"m2sjiox4yo.fsf@igel.home","threadId":"29548","inReplyTo":"201202052324.59941.jnareb@gmail.com","subject":"Re: Specifying revisions in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-05T22:58:39Z","receivedAt":"2012-02-05T22:58:39Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jakub Narebski writes:\n\n> Nope, still ambiguous:\n>\n>\n>\n> ---X<---*<---.<---A<---.<---M<---\n> \\ /\n> \\--.<---B<------/\n>\n> Is X+3 A or B? Though '--first-parent + towards N' is I think unambiguous.\n M\n\nX+3->M is A, if A is the leftmost ancestor of M.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"183940","messageId":"m2obtcx4i2.fsf@igel.home","threadId":"29548","inReplyTo":"178AA8FDB02246D9AA9416C0D54E51A8@PhilipOakley","subject":"Re: Specifying revisions in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-05T23:08:37Z","receivedAt":"2012-02-05T23:08:37Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"\"Philip Oakley\" writes:\n\n> Is there also a rule missing for X+2, viewed from D, in this example\n>\n>X<---Y<---Z<---\n> \\ \\\n>A<----B<----C<----D\n\nThis is difficult to interpret since it has some extra indent, let's\nassume that Z is the second parent of D and Y the second parent of B.\n\n> as to which order the first parent rule should _not_ be applied when D's\n> first parent chain doesn't reach X (it reaches A).\n> Using 'oldest' first for alternate parent testing would make X+2 = B,\n> whilst 'newest' first would make X+2=Z. I have used the chain order for\n> newest/oldest', rather than commit date.\n\nThe rule should be to follow the leftmost parent as far as possible.\nThat means that X+2->D is B.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"183963","messageId":"buosjiozity.fsf@dhlpc061.dev.necel.com","threadId":"29548","inReplyTo":"m2obtcx4i2.fsf@igel.home","subject":"Re: Specifying revisions in the future","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2012-02-06T04:28:25Z","receivedAt":"2012-02-06T04:28:25Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Andreas Schwab writes:\n> The rule should be to follow the leftmost parent as far as possible.\n> That means that X+2->D is B.\n\nIt might also be reasonable (and safer -- the user may not actually\nrealize when there's an ambiguating branch-point) to simply have it\nabort with an error (\"ambiguous future-ref specification\") when\nthere's any doubt... I suspect most uses would be very simple \"+1\"\netc., and not crossing branch points.\n\n-miles\n\n-- \n`There are more things in heaven and earth, Horatio,\n Than are dreamt of in your philosophy.'\n"},{"id":"184022","messageId":"vpq62fk89x1.fsf@bauges.imag.fr","threadId":"29548","inReplyTo":"m2obtcx4i2.fsf@igel.home","subject":"Re: Specifying revisions in the future","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-02-06T11:43:06Z","receivedAt":"2012-02-06T11:43:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andreas Schwab writes:\n\n> The rule should be to follow the leftmost parent as far as possible.\n\nBut then, if --first-parent doesn't reach the commit you want, there may\nbe several paths not following --first-parent that reach it. And you'll\nhave to invent some more rules to order them.\n\nSure, that's not impossible, but is the complexity really worth it?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"184024","messageId":"m2y5sg6ta5.fsf@igel.home","threadId":"29548","inReplyTo":"vpq62fk89x1.fsf@bauges.imag.fr","subject":"Re: Specifying revisions in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-06T12:27:46Z","receivedAt":"2012-02-06T12:27:46Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Matthieu Moy writes:\n\n> Andreas Schwab writes:\n>\n>> The rule should be to follow the leftmost parent as far as possible.\n>\n> But then, if --first-parent doesn't reach the commit you want, there may\n> be several paths not following --first-parent that reach it. And you'll\n> have to invent some more rules to order them.\n\nThe leftmost parent is not necessarily the first parent, but the\nleftmost parent that still reaches the commit. It's a depth-first\nsearch: if following the first parent doesn't reach the commit any more,\ntry again with the second parent.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"184166","messageId":"4F3196CC.9020406@gmx.us","threadId":"29548","inReplyTo":"buosjiozity.fsf@dhlpc061.dev.necel.com","subject":"Re: Specifying revisions in the future","fromName":"Jonathan Paugh","fromEmail":"jpaugh@gmx.us","sentAt":"2012-02-07T21:25:32Z","receivedAt":"2012-02-07T21:25:32Z","isPatch":false,"sender":{"key":"jpaugh@gmx.us","avatar":null},"body":"On 02/05/2012 11:28 PM, Miles Bader wrote:\n> Andreas Schwab writes:\n>> The rule should be to follow the leftmost parent as far as possible.\n>> That means that X+2->D is B.\n> \n> It might also be reasonable (and safer -- the user may not actually\n> realize when there's an ambiguating branch-point) to simply have it\n> abort with an error (\"ambiguous future-ref specification\") when\n> there's any doubt... I suspect most uses would be very simple \"+1\"\n> etc., and not crossing branch points.\n> \n> -miles\n> \n\nPerhaps default to --linear or --no-cross or such. Whenever there's\nambiguity, it will likely be harder for the user to think about than for\ngit to resolve it in some defined-as-sane way, at least for many users.\n\nAt any rate, I got the answer I needed for my use case (sorry for not\ncc-ing the list, and thanks Jakub for that:\nhttp://article.gmane.org/gmane.comp.version-control.git/189926/match=specify+revisions+future).\n\nStill, forward-refs would still be really cool.\n\nJonathan\n"}]}