{"thread":{"id":"23403","subject":"potential improvement to 'git log' with a range","startedAt":"2010-04-09T23:24:30Z","lastAt":"2010-06-24T22:49:24Z","messageCount":18,"participants":["Aghiles","Santi Béjar","Sverre Rabbelier","Linus Torvalds","Jakub Narebski","Martin Geisler","Jay Soffian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139089","messageId":"w2j3abd05a91004091624mb2836ff4v118a1ae9ac5ca6e7@mail.gmail.com","threadId":"23403","inReplyTo":null,"subject":"potential improvement to 'git log' with a range","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-09T23:24:30Z","receivedAt":"2010-04-09T23:24:30Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"If I type:\n\n git log FETCH_HEAD~4..HEAD\n\nI get something. But if I type:\n\n git log HEAD..FETCH_HEAD~4\n\nI get nothing. Is there a good reason for that ?\n\n -- aghiles\n"},{"id":"139092","messageId":"h2gadf1fd3d1004091633qe27d49f0m2ecb461e56f405b1@mail.gmail.com","threadId":"23403","inReplyTo":"w2j3abd05a91004091624mb2836ff4v118a1ae9ac5ca6e7@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-04-09T23:33:01Z","receivedAt":"2010-04-09T23:33:01Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Sat, Apr 10, 2010 at 1:24 AM, Aghiles wrote:\n> If I type:\n>\n>    git log FETCH_HEAD~4..HEAD\n>\n> I get something. But if I type:\n>\n>    git log HEAD..FETCH_HEAD~4\n>\n> I get nothing. Is there a good reason for that ?\n>\n\nYes.\n\n$ git log -h\nusage: git log [] [..] [[--] ...]\n\nSo and are not equivalent. It list commits in \nbut not in .\n\nIn your case HEAD has commits not in FETCH_HEAD~4 (your first command)\nwhile FETCH_HEAD~4 does not have commits not in HEAD. So HEAD is a\ndescendent of FETCH_HEAD~4.\n\nHope I didn't misunderstood your question.\n\nHTH,\nSanti\n"},{"id":"139093","messageId":"i2kfabb9a1e1004091633nc70f2f19hd16ea9704f0933b0@mail.gmail.com","threadId":"23403","inReplyTo":"w2j3abd05a91004091624mb2836ff4v118a1ae9ac5ca6e7@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-09T23:33:47Z","receivedAt":"2010-04-09T23:33:47Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sat, Apr 10, 2010 at 01:24, Aghiles wrote:\n> If I type:\n>\n>    git log FETCH_HEAD~4..HEAD\n>\n> I get something. But if I type:\n>\n>    git log HEAD..FETCH_HEAD~4\n>\n> I get nothing. Is there a good reason for that ?\n\nYes, read up on the documentation as to what \"..\" means. Hint, a \\ b\nis not the same as b \\ a [0].\n\n[0] http://en.wikipedia.org/wiki/Intersection_(set_theory)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"139096","messageId":"n2t3abd05a91004091713s4d081106qd74419425b25e8e@mail.gmail.com","threadId":"23403","inReplyTo":"i2kfabb9a1e1004091633nc70f2f19hd16ea9704f0933b0@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-10T00:13:22Z","receivedAt":"2010-04-10T00:13:22Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Sverre Rabbelier wrote:\n>\n> Yes, read up on the documentation as to what \"..\" means. Hint, a \\ b\n> is not the same as b \\ a [0].\n>\n> [0] http://en.wikipedia.org/wiki/Intersection_(set_theory)\n>\n\nOh, I should have read the documentation. I was certain that \"..\" stands\nfor a range but it is a ... complement.\n\nThanks for you help.\n\n -- aghiles\n"},{"id":"139097","messageId":"g2vfabb9a1e1004091716i681a50e2k9597b57b577e1663@mail.gmail.com","threadId":"23403","inReplyTo":"n2t3abd05a91004091713s4d081106qd74419425b25e8e@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-10T00:16:01Z","receivedAt":"2010-04-10T00:16:01Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sat, Apr 10, 2010 at 02:13, Aghiles wrote:\n> Oh, I should have read the documentation. I was certain that \"..\" stands\n> for a range but it is a ... complement.\n\nErr, yes, sorry, wrong link, should have been [0] :). Teaches me for\ncopy/pasting links from [1] without checking what I copy/paste,\nthey're right next to eachother :)\n\n[0] http://en.wikipedia.org/wiki/Complement_(set_theory)\n[1] http://en.wikipedia.org/wiki/Set_theory\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"139098","messageId":"alpine.LFD.2.00.1004091807220.3558@i5.linux-foundation.org","threadId":"23403","inReplyTo":"n2t3abd05a91004091713s4d081106qd74419425b25e8e@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-04-10T01:20:03Z","receivedAt":"2010-04-10T01:20:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Apr 2010, Aghiles wrote:\n> \n> Oh, I should have read the documentation. I was certain that \"..\" stands\n> for a range but it is a ... complement.\n\nWell, technically \"..\" means two different things\n\n - for \"set operations\" (ie \"git log\" and friends) it's the \"relative \n complement\" of two sets (or \"'reachable from A' \\ 'reachable from B'\").\n\n - for \"edge operations\" (ie \"git diff\" and friends) it's just two \n end-points (aka \"range\"). A diff doesn't work on sets, it only works on \n the two endpoints.\n\nIt's arguably a bit confusing, but quite frankly, the room for confusion \nis very small, and the biggest source of confusion is probably not so much \nthat \"..\" means two different things in two (clearly different) contexts, \nas much as just the fact that people aren't used to thinking in terms of \nset operations at all. \n\nMost SCM's really talk about \"ranges\". Once you think in those terms, \ncomplex history doesn't work. Git very fundamentally is much about set \ntheory, and \"ranges\" is a bad word to use.\n\nTo make things even more exciting triple-dot, \"A...B\" has two different \nmeanings too, again one that is about sets (\"symmetric difference\") for \nthe log-based ones, and one that is a somewhat badly defined range for the \ndiff based ones (where the end-points are \"one common nearest ancestor of \nA and B\" and \"B\" respectively).\n\nIt's all actually very natural when you get used to it, although that \n\"A...B\" as a range really isn't well-defined, since there can be more than \none common nearest ancestors. It's still often enough useful in practice \nthat I wouldn't get rid of it, but it's not the greatest feature.\n\n\t\tLinus\n"},{"id":"139283","messageId":"k2r3abd05a91004111331ld522220ehfffeb65c45040a94@mail.gmail.com","threadId":"23403","inReplyTo":"alpine.LFD.2.00.1004091807220.3558@i5.linux-foundation.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-11T20:31:51Z","receivedAt":"2010-04-11T20:31:51Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"On Fri, Apr 9, 2010, Linus Torvalds wrote:\n> Well, technically \"..\" means two different things\n>\n>  - for \"set operations\" (ie \"git log\" and friends) it's the \"relative\n>   complement\" of two sets (or \"'reachable from A' \\ 'reachable from B'\").\n>\n>  - for \"edge operations\" (ie \"git diff\" and friends) it's just two\n>   end-points (aka \"range\"). A diff doesn't work on sets, it only works on\n>   the two endpoints.\n\nOK.\n\n> Most SCM's really talk about \"ranges\". Once you think in those terms,\n> complex history doesn't work. Git very fundamentally is much about set\n> theory, and \"ranges\" is a bad word to use.\n\nI see how ranges are not powerful enough for complex history. It is just\nthat for me (and maybe for some others), the \"..\" sign has a strong\nassociation with \"range\".\n\nThank you very much for the explanation,\n\n -- aghiles\n"},{"id":"139290","messageId":"m3tyrhfzg8.fsf@localhost.localdomain","threadId":"23403","inReplyTo":"alpine.LFD.2.00.1004091807220.3558@i5.linux-foundation.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-11T21:32:49Z","receivedAt":"2010-04-11T21:32:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 9 Apr 2010, Aghiles wrote:\n> > \n> > Oh, I should have read the documentation. I was certain that \"..\" stands\n> > for a range but it is a ... complement.\n> \n> Well, technically \"..\" means two different things\n> \n> - for \"set operations\" (ie \"git log\" and friends) it's the \"relative \n> complement\" of two sets (or \"'reachable from A' \\ 'reachable from B'\").\n> \n> - for \"edge operations\" (ie \"git diff\" and friends) it's just two \n> end-points (aka \"range\"). A diff doesn't work on sets, it only works on \n> the two endpoints.\n\n[...]\n> Most SCM's really talk about \"ranges\". Once you think in those terms, \n> complex history doesn't work. Git very fundamentally is much about set \n> theory, and \"ranges\" is a bad word to use.\n\nFor example from I have got from asking on #mercurial IRC channel on\nFreeNode (a bit of self promotion: I have done this research to write\nan answer to \"Git and Mercurial - Compare and Contrast\" question on\nStackOverflow[1]), Mercurial implements its \"..\" equivalent in the\nterm of _numeric range_, even for \"hg log\" (sic!). It turns revision\nidentifiers used in range (-r :) to LOCAL number of\nrevision, and generates range based on numeric range, IIRC inclusive\non both sides (in Git range is exclusive from bottom, inclusive from\ntop).\n\nWhich is plain useless for anything but linear subsets of history\n(compare e.g. \"master..next\", which in Git shows everything in \"next\"\nthat is not in \"master\"; \"master\" and \"next\" are not direct\ndescendants of one oanother, at least not usually).\n\n[1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n\nP.S. I wonder if Mercurial development list is subscribe-only...\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"144076","messageId":"87bpb1issa.fsf@hbox.dyndns.org","threadId":"23403","inReplyTo":"m3tyrhfzg8.fsf@localhost.localdomain","subject":"Re: potential improvement to 'git log' with a range","fromName":"Martin Geisler","fromEmail":"mg@lazybytes.net","sentAt":"2010-06-23T17:05:09Z","receivedAt":"2010-06-23T17:05:09Z","isPatch":false,"sender":{"key":"mg@lazybytes.net","avatar":"https://gravatar.com/avatar/0abee533a2a6717b6a685550529569023bdfde2c16d763f7a255aa1562ed62ec?d=mp&s=160"},"body":"Jakub Narebski writes:\n\n> Linus Torvalds writes:\n>\n>> On Fri, 9 Apr 2010, Aghiles wrote:\n>> >\n>> > Oh, I should have read the documentation. I was certain that \"..\"\n>> > stands for a range but it is a ... complement.\n>>\n>> Well, technically \"..\" means two different things\n>>\n>> - for \"set operations\" (ie \"git log\" and friends) it's the \"relative\n>> complement\" of two sets (or \"'reachable from A' \\ 'reachable from B'\").\n>>\n>> - for \"edge operations\" (ie \"git diff\" and friends) it's just two\n>> end-points (aka \"range\"). A diff doesn't work on sets, it only\n>> works on the two endpoints.\n>\n> [...]\n>> Most SCM's really talk about \"ranges\". Once you think in those terms,\n>> complex history doesn't work. Git very fundamentally is much about\n>> set theory, and \"ranges\" is a bad word to use.\n>\n> For example from I have got from asking on #mercurial IRC channel on\n> FreeNode (a bit of self promotion: I have done this research to write\n> an answer to \"Git and Mercurial - Compare and Contrast\" question on\n> StackOverflow[1]), Mercurial implements its \"..\" equivalent in the\n> term of _numeric range_, even for \"hg log\" (sic!).\n\nThis is fixed with Mercurial 1.6: we now have a query language where\n'X..Y' (or 'X::Y') is understood as the set of changesets that are both\ndescendents of X and ancestors of Y.\n\n> [1]\n> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n\n\n-- \nMartin Geisler\n\nMercurial links: http://mercurial.ch/\n\n\n"},{"id":"144084","messageId":"201006232002.18921.jnareb@gmail.com","threadId":"23403","inReplyTo":"87bpb1issa.fsf@hbox.dyndns.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-06-23T18:02:17Z","receivedAt":"2010-06-23T18:02:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 23 Jun 2010, Martin Geisler wrote:\n> Jakub Narebski writes:\n>> Linus Torvalds writes:\n>>>\n>>> Well, technically \"..\" means two different things\n>>>\n>>> - for \"set operations\" (ie \"git log\" and friends) it's the \"relative\n>>> complement\" of two sets (or \"'reachable from A' \\ 'reachable from B'\").\n>>>\n>>> - for \"edge operations\" (ie \"git diff\" and friends) it's just two\n>>> end-points (aka \"range\"). A diff doesn't work on sets, it only\n>>> works on the two endpoints.\n>>\n>> [...]\n>>> Most SCM's really talk about \"ranges\". Once you think in those terms,\n>>> complex history doesn't work. Git very fundamentally is much about\n>>> set theory, and \"ranges\" is a bad word to use.\n>>\n>> For example from I have got from asking on #mercurial IRC channel on\n>> FreeNode (a bit of self promotion: I have done this research to write\n>> an answer to \"Git and Mercurial - Compare and Contrast\" question on\n>> StackOverflow[1]), Mercurial implements its \"..\" equivalent in the\n>> term of _numeric range_, even for \"hg log\" (sic!).\n> \n> This is fixed with Mercurial 1.6: we now have a query language where\n> 'X..Y' (or 'X::Y') is understood as the set of changesets that are both\n> descendents of X and ancestors of Y.\n\nThanks. It looks like Mercurial's 'X::Y' is equivalent to Git's \n'--ancestry-path X..Y' (the --ancestry-path option is a new feature).\n \n>> [1]\n>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n\nFixed. Could you please take a look if it is correct, and if there\nare errors, either correct it yourself, or ask me to do it (either via\ncomments for this question, or via email)? Thanks in advance.\n\nP.S. Isn't mercurial-devel subscribe only?\n-- \nJakub Narebski\nPoland\n"},{"id":"144091","messageId":"877hlpimkq.fsf@hbox.dyndns.org","threadId":"23403","inReplyTo":"201006232002.18921.jnareb@gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Martin Geisler","fromEmail":"mg@lazybytes.net","sentAt":"2010-06-23T19:19:17Z","receivedAt":"2010-06-23T19:19:17Z","isPatch":false,"sender":{"key":"mg@lazybytes.net","avatar":"https://gravatar.com/avatar/0abee533a2a6717b6a685550529569023bdfde2c16d763f7a255aa1562ed62ec?d=mp&s=160"},"body":"Jakub Narebski writes:\n\n> On Wed, 23 Jun 2010, Martin Geisler wrote:\n>\n>> This is fixed with Mercurial 1.6: we now have a query language where\n>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are\n>> both descendents of X and ancestors of Y.\n>\n> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's\n> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).\n\nYeah, it is equivalent to --ancestry-path. I had no idea Git's range\noperator worked the way it does :-)\n\nFor mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn\nmeans ancestors of Y, excluding ancestors of X (and excluding X).\n\n>>> [1]\n>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n>\n> Fixed. Could you please take a look if it is correct, and if there are\n> errors, either correct it yourself, or ask me to do it (either via\n> comments for this question, or via email)? Thanks in advance.\n\nYes, its correct now. But would you object if I or someone else took out\nall those personal opinions and rewrote it from a neutral point of view?\n\n> P.S. Isn't mercurial-devel subscribe only?\n\nNo, not really -- you will be whitelisted the first time you post.\n\n-- \nMartin Geisler\n\nMercurial links: http://mercurial.ch/\n"},{"id":"144096","messageId":"AANLkTinPrObdQh1vZLo0tlq2bZn7BXKvHWLktI2pR5LY@mail.gmail.com","threadId":"23403","inReplyTo":"alpine.LFD.2.00.1004091807220.3558@i5.linux-foundation.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-23T19:36:51Z","receivedAt":"2010-06-23T19:36:51Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Apr 9, 2010 at 9:20 PM, Linus Torvalds\n wrote:\n> To make things even more exciting triple-dot, \"A...B\" has two different\n> meanings too, again one that is about sets (\"symmetric difference\") for\n> the log-based ones, and one that is a somewhat badly defined range for the\n> diff based ones (where the end-points are \"one common nearest ancestor of\n> A and B\" and \"B\" respectively).\n>\n> It's all actually very natural when you get used to it, although that\n> \"A...B\" as a range really isn't well-defined, since there can be more than\n> one common nearest ancestors. It's still often enough useful in practice\n> that I wouldn't get rid of it, but it's not the greatest feature.\n\nSpeaking of which, I'd love a switch to \"git show $merge_commit\" which\ndoes \"git log $merge_commit^..$merge_commit^2\" but I've been too lazy\nto write it. 9/10 times that I use .., it's in this context. :-)\n\nj.\n"},{"id":"144104","messageId":"7vmxulebr2.fsf@alter.siamese.dyndns.org","threadId":"23403","inReplyTo":"AANLkTinPrObdQh1vZLo0tlq2bZn7BXKvHWLktI2pR5LY@mail.gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-23T20:26:41Z","receivedAt":"2010-06-23T20:26:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> Speaking of which, I'd love a switch to \"git show $merge_commit\" which\n> does \"git log $merge_commit^..$merge_commit^2\" but I've been too lazy\n> to write it. 9/10 times that I use .., it's in this context. :-)\n\nDoesn't \"git show -p --first-parent $merge\" work for you?\n"},{"id":"144106","messageId":"AANLkTikcCQD9rFDscJNpLaRtX64occrXNHmrB-FdW69b@mail.gmail.com","threadId":"23403","inReplyTo":"7vmxulebr2.fsf@alter.siamese.dyndns.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-23T20:45:07Z","receivedAt":"2010-06-23T20:45:07Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Jun 23, 2010 at 4:26 PM, Junio C Hamano wrote:\n> Jay Soffian writes:\n>\n>> Speaking of which, I'd love a switch to \"git show $merge_commit\" which\n>> does \"git log $merge_commit^..$merge_commit^2\" but I've been too lazy\n>> to write it. 9/10 times that I use .., it's in this context. :-)\n>\n> Doesn't \"git show -p --first-parent $merge\" work for you?\n\nI don't understand at all. Isn't -p redundant with git show? And how\nis --first-parent $merge equivalent to\n$merge_commit^..$merge_commit^2? I literally want a list of all the\ncommits brought in by the merge.\n\nConfusedly yours,\n\nj.\n"},{"id":"144108","messageId":"201006232324.32516.jnareb@gmail.com","threadId":"23403","inReplyTo":"877hlpimkq.fsf@hbox.dyndns.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-06-23T21:24:31Z","receivedAt":"2010-06-23T21:24:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 23 Jun 2010, Martin Geisler wrote:\n> Jakub Narebski writes:\n>> On Wed, 23 Jun 2010, Martin Geisler wrote:\n>>\n>>> This is fixed with Mercurial 1.6: we now have a query language where\n>>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are\n>>> both descendents of X and ancestors of Y.\n>>\n>> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's\n>> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).\n> \n> Yeah, it is equivalent to --ancestry-path. I had no idea Git's range\n> operator worked the way it does :-)\n> \n> For mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn\n> means ancestors of Y, excluding ancestors of X (and excluding X).\n\nErr... so how it is for X..Y / X::Y in Mercurial? \"Ancestors of Y, \nexcluding ancestors of X\" is larger range (and default result for\nX..Y in Git) than \"descendants of X and ancestors of Y\" (i.e. the\nresult of new --ancestry-path X..Y in Git).\n\nSee http://repo.or.cz/w/git.git/blob/refs/heads/pu:/Documentation/rev-list-options.txt#l582\n\n>>>> [1]\n>>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n>>\n>> Fixed. Could you please take a look if it is correct, and if there are\n>> errors, either correct it yourself, or ask me to do it (either via\n>> comments for this question, or via email)? Thanks in advance.\n> \n> Yes, its correct now. But would you object if I or someone else took out\n> all those personal opinions and rewrote it from a neutral point of view?\n\nWell, I do provide disclaimer upfront that I am biased towards Git, and\nI have tried to be objective.\n\nBut I don't mind if someone who uses Mercurial fixed that side, and\ntried for neutral point of view (but not introducing the opposite bias).\nThere would be problem with NPOV with issues without clear answer, where\npersonal preference matters, though.\n\n>> P.S. Isn't mercurial-devel subscribe only?\n> \n> No, not really -- you will be whitelisted the first time you post.\n\nNice.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"144110","messageId":"87hbkth0dj.fsf@hbox.dyndns.org","threadId":"23403","inReplyTo":"201006232324.32516.jnareb@gmail.com","subject":"Re: potential improvement to 'git log' with a range","fromName":"Martin Geisler","fromEmail":"mg@lazybytes.net","sentAt":"2010-06-23T22:04:08Z","receivedAt":"2010-06-23T22:04:08Z","isPatch":false,"sender":{"key":"mg@lazybytes.net","avatar":"https://gravatar.com/avatar/0abee533a2a6717b6a685550529569023bdfde2c16d763f7a255aa1562ed62ec?d=mp&s=160"},"body":"Jakub Narebski writes:\n\nHi Jakub,\n\nBy the way: please let me know if you prefer that I keep these mails on\nMercurials mailinglist. I've just had a long chat about it with our own\nmoderator and he felt it was rude to cross-post like this. I, on the\nother hand, value a polite cross-list discussion like this.\n\n> On Wed, 23 Jun 2010, Martin Geisler wrote:\n>> Jakub Narebski writes:\n>>> On Wed, 23 Jun 2010, Martin Geisler wrote:\n>>>\n>>>> This is fixed with Mercurial 1.6: we now have a query language where\n>>>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are\n>>>> both descendents of X and ancestors of Y.\n>>>\n>>> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's\n>>> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).\n>> \n>> Yeah, it is equivalent to --ancestry-path. I had no idea Git's range\n>> operator worked the way it does :-)\n>> \n>> For mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn\n>> means ancestors of Y, excluding ancestors of X (and excluding X).\n>\n> Err... so how it is for X..Y / X::Y in Mercurial? \"Ancestors of Y,\n> excluding ancestors of X\" is larger range (and default result for X..Y\n> in Git) than \"descendants of X and ancestors of Y\" (i.e. the result of\n> new --ancestry-path X..Y in Git).\n\nI described Git's X..Y for people on mercurial-devel. Mercurial's X..Y\nis like Git's --ancestry-path X..Y (except that Mercurial include both\nendpoints whereas Git excludes X).\n\nMercurial's X..Y behave the way it does because it felt natural and\nbecause I though Git's X..Y behaved that way.\n\n> See http://repo.or.cz/w/git.git/blob/refs/heads/pu:/Documentation/rev-list-options.txt#l582\n\nYes, that was the document I read in order to see how Git's X..Y works.\n\n>>>>> [1]\n>>>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930\n>>>\n>>> Fixed. Could you please take a look if it is correct, and if there\n>>> are errors, either correct it yourself, or ask me to do it (either\n>>> via comments for this question, or via email)? Thanks in advance.\n>> \n>> Yes, its correct now. But would you object if I or someone else took\n>> out all those personal opinions and rewrote it from a neutral point\n>> of view?\n>\n> Well, I do provide disclaimer upfront that I am biased towards Git,\n> and I have tried to be objective.\n>\n> But I don't mind if someone who uses Mercurial fixed that side, and\n> tried for neutral point of view (but not introducing the opposite\n> bias). There would be problem with NPOV with issues without clear\n> answer, where personal preference matters, though.\n\nGreat, then I may edit it a bit sometime...\n\n-- \nMartin Geisler\n\nMercurial links: http://mercurial.ch/\n"},{"id":"144197","messageId":"7v8w64cguk.fsf@alter.siamese.dyndns.org","threadId":"23403","inReplyTo":"7vmxulebr2.fsf@alter.siamese.dyndns.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-24T20:31:47Z","receivedAt":"2010-06-24T20:31:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jay Soffian writes:\n>\n>> Speaking of which, I'd love a switch to \"git show $merge_commit\" which\n>> does \"git log $merge_commit^..$merge_commit^2\" but I've been too lazy\n>> to write it. 9/10 times that I use .., it's in this context. :-)\n>\n> Doesn't \"git show -p --first-parent $merge\" work for you?\n\nHeh, this is a totally different operation to compare the tree before and\nafter the merge.\n\nWhat \"log merge^..merge^2\" does is to list the commits we merged from the\npoint of view of the person who did the merge. I haven't found the need\nfor a short-cut for that myself, but in any case, I think such a feature\nbelongs less to \"show\" (which is about \"inspecting a single object\") than\nto \"log\" (which is about \"give me the sequence\").\n\nYou may want to look into merge.log variable if you find yourself wanting\nto do that often with your history, though.\n"},{"id":"144216","messageId":"AANLkTiloAQmjAMVOROzBHkLAAIDj-KNFNcfXC9pdwDf5@mail.gmail.com","threadId":"23403","inReplyTo":"7v8w64cguk.fsf@alter.siamese.dyndns.org","subject":"Re: potential improvement to 'git log' with a range","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-24T22:49:24Z","receivedAt":"2010-06-24T22:49:24Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Jun 24, 2010 at 4:31 PM, Junio C Hamano wrote:\n> Heh, this is a totally different operation to compare the tree before and\n> after the merge.\n>\n> What \"log merge^..merge^2\" does is to list the commits we merged from the\n> point of view of the person who did the merge.  I haven't found the need\n> for a short-cut for that myself, but in any case, I think such a feature\n> belongs less to \"show\" (which is about \"inspecting a single object\") than\n> to \"log\" (which is about \"give me the sequence\").\n>\n> You may want to look into merge.log variable if you find yourself wanting\n> to do that often with your history, though.\n\nFamiliar with that and sadly insufficient. My merges often contain\n100+ commits which is beyond what merge.log truncates. But more\nimportantly, I'm often inspecting the commits:\n\ngit log ..MERGE_HEAD -Scontent_to_watch_out_for\ngit log ..MERGE_HEAD -- /path/to/watch/out/for\n\netc. But sometimes I have to do this type of inspection after the\nfact, which is what leads to the merge^..merge^2.\n\nPerhaps the right place for such syntactic sugar would be in\nrev-parse. Something like:\n\no A suffix ^{m..n} (i.e. rev^{1..2}) when rev is a merge commit\nexpands to rev^m..rev^n and is only valid in contexts that take a\nrange. 'm' and 'n' may be left out in which case they are assume to be\n1 and 2. (i.e rev^{..} is rev^1..rev^2).\n\nBut I haven't entirely thought this through. :-)\n\nj.\n"}]}