{"thread":{"id":"33588","subject":"[BUG] Highly inconsistent diff UI","startedAt":"2013-04-24T12:23:20Z","lastAt":"2013-04-29T21:12:23Z","messageCount":45,"participants":["Ramkumar Ramachandra","Jonathan Nieder","Junio C Hamano","Thomas Rast","Phil Hord","Duy Nguyen","John Keeping"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"215309","messageId":"CALkWK0n2ZZTgYxi3Fk2UxY8TXFAt1Xt3+11G98GKxbYdoMOT+Q@mail.gmail.com","threadId":"33588","inReplyTo":null,"subject":"[BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T12:23:20Z","receivedAt":"2013-04-24T12:23:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nThe 'git diff <commit> <commit>' form is perfectly fine: I can\nunderstand that diff takes two commit^{tree}s to compare.\nUnfortunately, it also shows off the examples 'git diff A..B' and 'git\ndiff A...B', where A..B and A...B do not correspond to the meaning\nspecified in gitrevisions.txt.  There's a note in the documentation\nsaying this, but I'm very unhappy.\n\nI can understand that rev-parse parses A..B into ^A B.  'git diff\nA..B' is the same as 'git diff A B', 'git diff B ^A', and 'git diff ^A\nB'?  (Yeah, I saw the code and found out that it swaps the arguments\nonly if the second argument is UNINTERESTING)\n\nrev-parse parses A...B into A B ^$(merge-base --all A B).  But 'git\ndiff A...B' means 'git diff $(git merge-base A B) B'?  And the\nmerge-base is picked at random (found out that from the code)?\n\nWhat about other things like 'git diff ^A ^B' and 'git diff A^!'?  Why\nis diff so inconsistent with everything else?  Why are A..B and A...B\nalmost coded in as special cases?  What should we do to improve the\nsituation?\n\nThanks for listening.\n"},{"id":"215327","messageId":"20130424164003.GB4119@elie.Belkin","threadId":"33588","inReplyTo":"CALkWK0n2ZZTgYxi3Fk2UxY8TXFAt1Xt3+11G98GKxbYdoMOT+Q@mail.gmail.com","subject":"Re: Highly inconsistent diff UI","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-24T16:40:03Z","receivedAt":"2013-04-24T16:40:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n>                    A..B and A...B do not correspond to the meaning\n> specified in gitrevisions.txt.  There's a note in the documentation\n> saying this, but I'm very unhappy.\n\nWhat would it mean for A..B to be treated as a revision range?\n\nSuppose I do a revision walk and come up with the commits x, y,\nand z.  What is the resulting diff?\n\nThe common syntax is just a mnemonic: in the same situations as I\nmight use \"git log A...B\", it can be handy to use \"git diff A...B\".\n\n[...]\n> What about other things like 'git diff ^A ^B' and 'git diff A^!'?  Why\n> is diff so inconsistent with everything else?\n\n\"git diff ^A ^B\" is invalid syntax.  It's a bug that it doesn't\ncomplain.\n\n\"git diff A^!\" is a very convenient shorthand for \"git diff A^ A\".\n\n\"diff\" is fundamentally about comparing two endpoints.  It is not a\ncommand for listing commits.\n\nHoping that clarifies,\nJonathan\n"},{"id":"215331","messageId":"7va9ong9oa.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0n2ZZTgYxi3Fk2UxY8TXFAt1Xt3+11G98GKxbYdoMOT+Q@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T16:44:53Z","receivedAt":"2013-04-24T16:44:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> What should we do to improve the\n> situation?\n\nThe first thing to do is to eradicate \"diff A..B\" from the\ndocumentation, and a dozen or more lines in your complaint will go\naway with that single change.\n\nAs you know, diff is about two endpoints, and A..B is not a way to\nspecify two endpoints, and not erroring it out whenever we see a\nnegative revision is a mere courtesy to old timers who knew the\ncommand line parser was shared with rev-list machinery.  \n\nThere is no reason to forbid the syntax, but encouraging its use is\ncounterproductive and will lead to confusions to new people as you\npointed out.\n\nThe only issue is to come up with a concise alternative way to\nexpress \"diff A...B\", perhaps \"diff --compare-with-base A B\", and\nthen you can choose not to say anything but an object name (and no\nrange notation) on the command line (if you do not \"diff A...B\", it\ncan already be done by not using \"diff A..B\").\n"},{"id":"215332","messageId":"CALkWK0mVDT5ESnVJAWQ83gQnmxmGDoM_Y0nE4FGybcjcenA_KA@mail.gmail.com","threadId":"33588","inReplyTo":"7va9ong9oa.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T16:51:20Z","receivedAt":"2013-04-24T16:51:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> The first thing to do is to eradicate \"diff A..B\" from the\n> documentation, and a dozen or more lines in your complaint will go\n> away with that single change.\n>\n> As you know, diff is about two endpoints, and A..B is not a way to\n> specify two endpoints, and not erroring it out whenever we see a\n> negative revision is a mere courtesy to old timers who knew the\n> command line parser was shared with rev-list machinery.\n>\n> There is no reason to forbid the syntax, but encouraging its use is\n> counterproductive and will lead to confusions to new people as you\n> pointed out.\n\nExcellent.  I agree wholeheartedly with this reasoning.\n\n> The only issue is to come up with a concise alternative way to\n> express \"diff A...B\", perhaps \"diff --compare-with-base A B\", and\n> then you can choose not to say anything but an object name (and no\n> range notation) on the command line (if you do not \"diff A...B\", it\n> can already be done by not using \"diff A..B\").\n\nWhat are your thoughts on inventing a new syntax A~B = $(git\nmerge-base A B) B which can be used by both range commands like log\nand non-range commands like diff ?  (In other words, why shouldn't log\nbe able to do this?).  Does it matter which merge base we pick though?\n"},{"id":"215340","messageId":"7va9ones4p.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"20130424164003.GB4119@elie.Belkin","subject":"Re: Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T17:49:10Z","receivedAt":"2013-04-24T17:49:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> What would it mean for A..B to be treated as a revision range?\n\nNonsense is what it means ;-)\n\n> Suppose I do a revision walk and come up with the commits x, y,\n> and z.  What is the resulting diff?\n>\n> The common syntax is just a mnemonic: in the same situations as I\n> might use \"git log A...B\", it can be handy to use \"git diff A...B\".\n\nI wish it were the case, but a very common complaint that I agree\nwith is that\n\n\tgit log origin..HEAD\n\nis a way to show what *I* did since I forked, while saying I am *not*\ninterested in what they did in the meantime.  And\n\n\tgit log -p origin..HEAD\n\nis a way to view the same history as a series of individual patches,\nwhile that output would not match what you would get from\n\n\tgit diff origin..HEAD\n\nIt would be much closer to\n\n\tgit diff $(git merge-base origin HEAD) HEAD\n\nwhich is very often useful and got its own short-hand \"origin...HEAD\".\n\nAnd it does not match \"git log origin...HEAD\" which gives both sides\nof the symmetric difference of the history.  To match it, you have\nto say \"git log --right-only origin...HEAD\" or something.\n"},{"id":"215343","messageId":"7v38ufer2x.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0mVDT5ESnVJAWQ83gQnmxmGDoM_Y0nE4FGybcjcenA_KA@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T18:11:50Z","receivedAt":"2013-04-24T18:11:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> What are your thoughts on inventing a new syntax A~B = $(git\n> merge-base A B) B which can be used by both range commands like log\n> and non-range commands like diff ?  (In other words, why shouldn't log\n> be able to do this?).\n\nThe idea for a new syntax to denote a merge base may be an\ninteresting one.\n\n\"log\" is inherently about ranges, so you do not need a new operator\nto denote a merge base.  Between \"log A..B\" and \"log A...B\" with or\nwithout --left-right, --left-only and --right-only, you should be\nable to ask questions about histories leading to commit A and B\nwithout having to worry about a single \"merge base\" between A and B,\nno?  So I do not think \"A~B\" would help \"log\".\n\nBecause \"diff\" is inherently about endpoints, you DO have to have a\nsingle \"merge base\" that gives you a point to compare something else\nagainst.\n\nThe reason why \"diff A...B\" was invented was primarily because we\nwanted to avoid having to say A twice on the command line, be it\n\"diff $(git merge-base A B) B\" or \"diff A~B B\".  In other words,\n\"A~B\" will not help \"diff\" at all, either [*1*].\n\nThere isn't always a single merge base between an arbitrary pair of\ncommits (there may be 0, or 2 or more).  When used in the context of\n\"diff A...B\", we know that the user is more interested in using one\nmerge base (among possibly many) to get some diff, than seeing the\ncommand fail [*2*].  Taking that as a context cue, \"diff A...B\" can\n(and did) choose to use one picked at random, even though the design\nis fully aware that the chosen one may not be the best one.\n\nA generic \"A~B\" syntax implemented at the revision parser level may\nnot have that luxury of assuming that it is fine to pick any, and\nmay have to fail when there is not a unique merge-base.\n\n\n[Footnote]\n\n*1* That does not mean nobody needs that syntax.  It just means that\n    it is still a solution looking for a problem.\n\n*2* Otherwise the user can more carefully script what he wants to do\n    using the merge-base command himself, choosing to do different\n    things when there are 0, or 2 or more merge bases.\n"},{"id":"215344","messageId":"CALkWK0kBenocmFb+3mQpcDj8sPCbWuAmQZ71vM8Ee=m3wjDPCQ@mail.gmail.com","threadId":"33588","inReplyTo":"7va9ones4p.fsf@alter.siamese.dyndns.org","subject":"Re: Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T18:12:50Z","receivedAt":"2013-04-24T18:12:50Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> And it does not match \"git log origin...HEAD\"\n\nExactly my problem.  Inconsistency.\n"},{"id":"215353","messageId":"CALkWK0m5Q_e3q6Yg94-K+jU_SS7ovR2wnz-_Nr3cMz_YM=SMDQ@mail.gmail.com","threadId":"33588","inReplyTo":"7v38ufer2x.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T18:48:49Z","receivedAt":"2013-04-24T18:48:49Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"On Wed, Apr 24, 2013 at 11:41 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> What are your thoughts on inventing a new syntax A~B = $(git\n>> merge-base A B) B which can be used by both range commands like log\n>> and non-range commands like diff ?  (In other words, why shouldn't log\n>> be able to do this?).\n>\n> The idea for a new syntax to denote a merge base may be an\n> interesting one.\n\nSorry I wasn't clear.  A~B = $(git merge-base A B) B to diff and $(git\nmerge-base A B)..B to log.  I don't mind a hybrid command as long as\nwe document it properly.  rev-parse will parse it into B ^${git\nmerge-base A B) just fine.  Implementation: diff should swap the\narguments if the second argument is UNINTERESTING: it already does\nthis :)\n\nBasically, I want to be able to do git log master~rebase.autostash\n(without having to rebase).  I'm also considering making the first\nargument optional (just git log ~rebase.autostash), and defaulting to\nmean [nearest fork point].\n\nWhat do you think?\n"},{"id":"215357","messageId":"CALkWK0=5tE0pXj-XTe4g9LdCO78yrPNwyom5fupF1WTToY2TZw@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0m5Q_e3q6Yg94-K+jU_SS7ovR2wnz-_Nr3cMz_YM=SMDQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T19:00:08Z","receivedAt":"2013-04-24T19:00:08Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> I'm also considering making the first\n> argument optional (just git log ~rebase.autostash), and defaulting to\n> mean [nearest fork point].\n\nActually both can be optional.  In A~B, A defaults to [nearest fork\npoint] and B defaults to HEAD.\n\n    git log ~\n\nIsn't it beautiful?\n"},{"id":"215365","messageId":"20130424192339.GH29963@google.com","threadId":"33588","inReplyTo":"7va9ones4p.fsf@alter.siamese.dyndns.org","subject":"Re: Highly inconsistent diff UI","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-24T19:23:39Z","receivedAt":"2013-04-24T19:23:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> And it does not match \"git log origin...HEAD\" which gives both sides\n> of the symmetric difference of the history.  To match it, you have\n> to say \"git log --right-only origin...HEAD\" or something.\n\nI tend to use --left-right.  All I meant is that with both diff and\nlog, ... is a way to get something meaningful when my history and\nsomeone else's history have diverged.\n\nI agree that it would be easier to explain if there were some\n\n\tgit diff --from-merge-base A B\n\nWe could say that \"git diff A...B\" is a mostly meaningless shorthand\nfor that.\n"},{"id":"215366","messageId":"7vtxmvbukv.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0=5tE0pXj-XTe4g9LdCO78yrPNwyom5fupF1WTToY2TZw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T19:24:32Z","receivedAt":"2013-04-24T19:24:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Ramkumar Ramachandra wrote:\n>> I'm also considering making the first\n>> argument optional (just git log ~rebase.autostash), and defaulting to\n>> mean [nearest fork point].\n>\n> Actually both can be optional.  In A~B, A defaults to [nearest fork\n> point] and B defaults to HEAD.\n>\n>     git log ~\n>\n> Isn't it beautiful?\n\nI now have to go and wash my eyes.\n\nYou will stay in my killlist for the coming few days ;-).\n"},{"id":"215369","messageId":"CALkWK0nmJPMJEotQ=-sSA5jXWd85mRk_Y+tbYHj1sr6ddJZsHg@mail.gmail.com","threadId":"33588","inReplyTo":"7vtxmvbukv.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T19:29:27Z","receivedAt":"2013-04-24T19:29:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> You will stay in my killlist for the coming few days ;-).\n\nNow, now.  What is your objection, objectively?\n"},{"id":"215375","messageId":"7vli87bsu3.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"20130424192339.GH29963@google.com","subject":"Re: Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T20:02:12Z","receivedAt":"2013-04-24T20:02:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> And it does not match \"git log origin...HEAD\" which gives both sides\n>> of the symmetric difference of the history.  To match it, you have\n>> to say \"git log --right-only origin...HEAD\" or something.\n>\n> I tend to use --left-right.  All I meant is that with both diff and\n> log, ... is a way to get something meaningful when my history and\n> someone else's history have diverged.\n>\n> I agree that it would be easier to explain if there were some\n>\n> \tgit diff --from-merge-base A B\n\nYeah, I am not strongly opposed to have something like that, and\nhaving a shorter (but not a single letter) option name might make it\nmore attractive than A...B at least to new users.\n\n> We could say that \"git diff A...B\" is a mostly meaningless shorthand\n> for that.\n\nYou may remember but this is not the first time we discussed that\nthree-dot in log and diff mean different things.\n\nInstead of saying \"meaningless\", I think in the past discussion the\nexplanation given was that three-dot means different things between\nthe context to specify a range (i.e. a symmetric difference) and the\ncontext to specify two endpoints (i.e. base and right end).\n\nWhich by the way is nothing new.  \"A\" means the entire history\nleading to the commit \"A\" in the context of specifying a range, and\nthe same \"A\" means a single commit \"A\" in the context of specifying\na revision.\n"},{"id":"215376","messageId":"CALkWK0m5m4maMKYfyV=rr4TWDK1FZQXXwT=cPeGoMtx6+chJsw@mail.gmail.com","threadId":"33588","inReplyTo":"7vli87bsu3.fsf@alter.siamese.dyndns.org","subject":"Re: Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T20:14:08Z","receivedAt":"2013-04-24T20:14:08Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Yeah, I am not strongly opposed to have something like that, and\n> having a shorter (but not a single letter) option name might make it\n> more attractive than A...B at least to new users.\n\nI'm not married to the single character or tilde.  What I'm saying is\nthat we should make it a rev spec, not a command-line option.\n\n> Which by the way is nothing new.  \"A\" means the entire history\n> leading to the commit \"A\" in the context of specifying a range, and\n> the same \"A\" means a single commit \"A\" in the context of specifying\n> a revision.\n\nExactly.  And I'm introducing a third context: \"when specifying two\ntrees to diff\".  Changing meaning in different contexts is not a\nproblem, as long as it is consistent and properly documented.\n"},{"id":"215378","messageId":"877gjrpsk4.fsf@hexa.v.cablecom.net","threadId":"33588","inReplyTo":"CALkWK0=5tE0pXj-XTe4g9LdCO78yrPNwyom5fupF1WTToY2TZw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-24T20:44:27Z","receivedAt":"2013-04-24T20:44:27Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Ramkumar Ramachandra wrote:\n>> I'm also considering making the first\n>> argument optional (just git log ~rebase.autostash), and defaulting to\n>> mean [nearest fork point].\n>\n> Actually both can be optional.  In A~B, A defaults to [nearest fork\n> point] and B defaults to HEAD.\n>\n>     git log ~\n>\n> Isn't it beautiful?\n\nPlease don't.  The syntax you propose doesn't work for several reasons,\nbut do we really need one?  How often would you actually use it?\n\nOk, since you ask, the reasons are:\n\n* Looking for the nearest fork point is expensive and subject to change\n  by simply fetching.  I hope you meant \"... and exclude its upstream\",\n  i.e., A defaults to @{u}, which might be at least somewhat useful.\n\n* ~ is already taken; in your syntax, A~1234567 is ambiguous because\n  1234567 can both be a SHA1 and a number of generations to go back.\n\nI personally think we have enough magic revision syntax to last at least\nanother decade.  If you propose to add some, please make a patch that we\ncan cook in next for a few release cycles and then conduct a straw poll\nif people actually use it.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"215382","messageId":"CALkWK0kn7mEosWSdWs1Jjx-L32wmL51W=X7ny9BYQMttG1LPvQ@mail.gmail.com","threadId":"33588","inReplyTo":"877gjrpsk4.fsf@hexa.v.cablecom.net","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T20:54:17Z","receivedAt":"2013-04-24T20:54:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> * Looking for the nearest fork point is expensive and subject to change\n>   by simply fetching.  I hope you meant \"... and exclude its upstream\",\n>   i.e., A defaults to @{u}, which might be at least somewhat useful.\n\nI'm not proposing anything different from :/ in this aspect.\n\n> * ~ is already taken; in your syntax, A~1234567 is ambiguous because\n>   1234567 can both be a SHA1 and a number of generations to go back.\n\nI'm not married to ~.  It can be any character.\n\n> I personally think we have enough magic revision syntax to last at least\n> another decade.  If you propose to add some, please make a patch that we\n> can cook in next for a few release cycles and then conduct a straw poll\n> if people actually use it.\n\nIsn't it obviously incredibly useful?  I'm working on a topic branch I\nneed to send out to git.git, and I want see how my WIP looks: should I\nhave to rebase on master just to see this?\n\nWhy such a huge resistance against such a small feature?  Can you\nthink of ways in which it is myopic (and therefore a pain to keep\nsupporting, if we find it undesirable)?\n\nOn a related note- In my opinion, :/ is broken, because it blocks\ncomposition completely.  I would've really liked {:/quuxery}~3.\n"},{"id":"215384","messageId":"20130424210227.GL29963@google.com","threadId":"33588","inReplyTo":"CALkWK0kn7mEosWSdWs1Jjx-L32wmL51W=X7ny9BYQMttG1LPvQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-24T21:02:27Z","receivedAt":"2013-04-24T21:02:27Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Isn't it obviously incredibly useful?  I'm working on a topic branch I\n> need to send out to git.git, and I want see how my WIP looks: should I\n> have to rebase on master just to see this?\n\nNope.  I just do \"git log master..topic\".\n"},{"id":"215385","messageId":"CALkWK0k9prS2AgqOHwkh71v9uS2varVKrU_FCx1KgnGEMdqfjw@mail.gmail.com","threadId":"33588","inReplyTo":"20130424210227.GL29963@google.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T21:10:56Z","receivedAt":"2013-04-24T21:10:56Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> Isn't it obviously incredibly useful?  I'm working on a topic branch I\n>> need to send out to git.git, and I want see how my WIP looks: should I\n>> have to rebase on master just to see this?\n>\n> Nope.  I just do \"git log master..topic\".\n\nWhy do you restate something so obvious?  Yes Jonathan, this is\ncurrently what I do:\nhttps://github.com/artagnon/dotfiles/blob/master/.gitconfig#L43\n\nI'm proposing an asymmetric difference, which is B ^$(git merge-base A\nB).  What does it have to do with A..B (aka. B ^A)?\n"},{"id":"215386","messageId":"7vvc7baahc.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0m5Q_e3q6Yg94-K+jU_SS7ovR2wnz-_Nr3cMz_YM=SMDQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T21:23:59Z","receivedAt":"2013-04-24T21:23:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Sorry I wasn't clear.  A~B = $(git merge-base A B) B to diff and $(git\n> merge-base A B)..B to log.\n>\n> Basically, I want to be able to do git log master~rebase.autostash\n> (without having to rebase).\n\nHow is it different from \"git log master..rebase.autostash\"?\n\n    git log A..B\n\nis already a perfectly fine way to spell your \"A~B\", which is\n\n    git log B --not $(git merge-base --all A B)\n\nwhen written in longhand [*1*], no?\n\nSo I do not think your A~B helps \"log\".\n\nIt does not help \"diff\" either, because we already have A...B and we\nare not going to remove it (people are used to what it means).\n\nSo I think your A~B is still a solution that is looking for a\nproblem.\n\n\n[Footnote]\n\n*1* You need to understand what merge-base is in order to analyse\n    the equivalence of these two.  A..B asks for those that are\n    reachable from B that are not reachable from A.  What does the\n    other form ask, by saying \"ones that can be reached from B but\n    exclude the ones that are reachable from any merge base of A and\n    B\"?\n\n    On the history leading to A, there are two kinds of commits:\n    those that are not reachable from B and those that are.  The\n    ones closer to A may not be reachable from B but if you dig the\n    history starting from A and keep finding ancestors, you will\n    eventually hit one that can be reached from B.  Once you hit\n    such a commit, everything beyond that point are reachable from\n    both A and B.  E.g.\n\n        ---o---*---a---a---a---A\n                \\\n                 b---b---B\n\n    And we call that a merge base between A and B (e.g. '*').  Any\n    ancestor of a merge base, e.g. 'o', is reachable from A and is\n    excluded from \"A..B\".\n"},{"id":"215387","messageId":"CABURp0qHRQvUSKMth8mZjwcX9sn-vrcf+ZUswQADW5wwzx4MWA@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0=5tE0pXj-XTe4g9LdCO78yrPNwyom5fupF1WTToY2TZw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-24T21:25:25Z","receivedAt":"2013-04-24T21:25:25Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Apr 24, 2013 at 3:00 PM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Ramkumar Ramachandra wrote:\n>> I'm also considering making the first\n>> argument optional (just git log ~rebase.autostash), and defaulting to\n>> mean [nearest fork point].\n>\n> Actually both can be optional.  In A~B, A defaults to [nearest fork\n> point] and B defaults to HEAD.\n>\n>     git log ~\n>\n> Isn't it beautiful?\n\nSure, but we'll forever be explaining to users that they will need to\nquote the tilde to avoid shell expansion.\n\n$ echo \"~\" ~ \"~\"\n~ /home/hordp ~\n\nP\n"},{"id":"215388","messageId":"7vobd3aab6.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0nmJPMJEotQ=-sSA5jXWd85mRk_Y+tbYHj1sr6ddJZsHg@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-24T21:27:41Z","receivedAt":"2013-04-24T21:27:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> You will stay in my killlist for the coming few days ;-).\n>\n> Now, now.  What is your objection, objectively?\n\nI do not think any further explanation is necessary.\n\nMy Git time is more useful to the Git development community than\neducating somebody with demonstrated lack of design taste by calling\nthe \"log ~\" that has an irregular default \"beautiful\".\n"},{"id":"215392","messageId":"CALkWK0=6A8z9HkbE=giU1BRDBq=0Hmkvhu7Eh=vAyARbs9Qt3A@mail.gmail.com","threadId":"33588","inReplyTo":"7vobd3aab6.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T22:06:30Z","receivedAt":"2013-04-24T22:06:30Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> My Git time is more useful to the Git development community than\n> educating somebody with demonstrated lack of design taste by calling\n> the \"log ~\" that has an irregular default \"beautiful\".\n\nWhy are you caught up in the character and the defaults (I just put\ndown the first thing that came to my mind)?  What I'm calling\nbeautiful is the idea to be able to tersely express \"I want to know\nwhat changes I made to this branch\".  We can change the character and\nthe defaults; do you think the feature is useful?\n"},{"id":"215396","messageId":"CALkWK0=NWSZsARu9w0DwpEmJHKnvpB8yoNfEa31LDQA=cV-90Q@mail.gmail.com","threadId":"33588","inReplyTo":"7vvc7baahc.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T22:44:55Z","receivedAt":"2013-04-24T22:44:55Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> How is it different from \"git log master..rebase.autostash\"?\n>\n>     git log A..B\n>\n> is already a perfectly fine way to spell your \"A~B\", which is\n>\n>     git log B --not $(git merge-base --all A B)\n>\n> when written in longhand [*1*], no?\n>\n> So I do not think your A~B helps \"log\".\n\nThey are equivalent if you use --all, which I didn't originally\npropose.  I'll present a slightly contrived example, because I don't\npersonally merge much in the real world:\n\npu is based on master~10.  rebase.autostash is based on master~5 and\nmaster~3 merges in pu.  I merge pu into rebase.autostash while\nworking.  Now, master..rebase.autostash will exclude commits reachable\nfrom master (and therefore pu), but master~rebase.autostash will show\nthe commits in pu that I merged in.\n\nOfcourse, I now see that this is probably useless, and .. fits my bill.\n\nWhen packaged with a good default for LHS (which .. currently doesn't\nhave), it might be a slightly better candidate.  I was thinking origin\ninstead of [nearest-fork-commit].\n\n> It does not help \"diff\" either, because we already have A...B and we\n> are not going to remove it (people are used to what it means).\n\nYeah, the invention arose as way to find a replacement for this inconsistency.\n\n> So I think your A~B is still a solution that is looking for a\n> problem.\n\nYeah, so it looks like the problem is entirely a minor cosmetic\ndetail: we're just clothing existing functionality with a consistent\nnew refspec.\n\nWe might still want it.  I mean what are we losing?\n"},{"id":"215398","messageId":"CALkWK0ntZKaEzA0Jupj6poOMydqUumEGVVJ-uhBE12sPJ0ntjw@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0=NWSZsARu9w0DwpEmJHKnvpB8yoNfEa31LDQA=cV-90Q@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-24T23:17:45Z","receivedAt":"2013-04-24T23:17:45Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Ofcourse, I now see that this is probably useless, and .. fits my bill.\n\nWould you find it potentially useful?  You do a lot of merging\nback-and-fourth juggling feature branches, pu, next, master.\n\n> When packaged with a good default for LHS (which .. currently doesn't\n> have), it might be a slightly better candidate.  I was thinking origin\n> instead of [nearest-fork-commit].\n\nEr, I meant HEAD@{u}, not origin.  HEAD@{u}~HEAD doesn't sound like a\nbad default at all.\n"},{"id":"215402","messageId":"CALkWK0=AxKnbOhmM+wAdAb4vh9HANfLHZmJ6bTWxN_8B9p_-XQ@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0=NWSZsARu9w0DwpEmJHKnvpB8yoNfEa31LDQA=cV-90Q@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T04:27:36Z","receivedAt":"2013-04-25T04:27:36Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> We might still want it.  I mean what are we losing?\n\nActually, let's just look at extending the rev specs we currently\nhave.  I'll gather up a list of real itches and post it to the list.\n"},{"id":"215407","messageId":"7vppxj6thv.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0ntZKaEzA0Jupj6poOMydqUumEGVVJ-uhBE12sPJ0ntjw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T05:59:08Z","receivedAt":"2013-04-25T05:59:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Ramkumar Ramachandra wrote:\n>> Ofcourse, I now see that this is probably useless, and .. fits my bill.\n>\n> Would you find it potentially useful?\n\nI dunno.  The description you gave was insufficient for me to answer\nthat question.\n\nThe part of your message that outlines the scenario you thought A~B\nmight help you was read by me like the following.\n\n    >  pu is based on master~10.  rebase.autostash is based on\n    >  master~5 and master~3 merges in pu.\n\n    So which one is 'pu' based on?  master~10, or master~3?  You cannot\n    have both.\n\n    >  I merge pu into rebase.autostash while working.  \n\n    So from pu the top two commit on 'master' are missing, but your\n    branch was forked way before that from 'master', so these two do not\n    concern you.\n\n    >  Now, master..rebase.autostash will exclude commits reachable\n    >  from master (and therefore pu),\n\n    Whoa. Earlier you said 'pu' is based on master~10, but changed your\n    mind to say master~3 is in 'pu', and now you mean the tip of\n    'master' is also in 'pu'?  What is going on?\n\nCan you draw a picture to illustrate the topology you are trying to\ndescribe, like I did in a few message upthread?  E.g.\n\n        ---o---*---a---a---a---a---A (master)\n                \\       \\\n                 b---Y---X---B (topic)\n                    / \n\nshows a topic B that forked from master and merged from irrelevant\nbranch at Y and merged from master at X [*1*].\n\nIn the above sample topology, even if you pulled irrelevant (for the\npurpose of completing your topic) commits at X from 'master',\nneither \"log A..B\" or \"log $(merge-base A B)..B\" (aka \"log A~B\")\nwould exclude any of your commit that is not yet in the 'master', so\nI do not think there is anything you gain by using A~B over A..B.\n\nIf you pulled something unrelated to your topic that is not in\n'master', both \"log A..B\" and \"log A~B\" would show these unrelated\nchanges, so again I do not see how A~B would help you over A..B,\neither.\n\nPerhaps in a particular topology you have in mind, it might make a\ndifference, but I cannot read what that topology is from your\ndescription.\n\n[Footnote]\n\n*1* I do not think this particular topology is what you have in\n    mind. It is meant to demonstrate one way to illustrate the\n    history to help other people understand the example you are\n    trying to give.\n"},{"id":"215411","messageId":"87li87awwc.fsf@linux-k42r.v.cablecom.net","threadId":"33588","inReplyTo":"CALkWK0kn7mEosWSdWs1Jjx-L32wmL51W=X7ny9BYQMttG1LPvQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-25T07:32:03Z","receivedAt":"2013-04-25T07:32:03Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Thomas Rast wrote:\n>> I personally think we have enough magic revision syntax to last at least\n>> another decade.  If you propose to add some, please make a patch that we\n>> can cook in next for a few release cycles and then conduct a straw poll\n>> if people actually use it.\n>\n> Isn't it obviously incredibly useful?  I'm working on a topic branch I\n> need to send out to git.git, and I want see how my WIP looks: should I\n> have to rebase on master just to see this?\n>\n> Why such a huge resistance against such a small feature?  Can you\n> think of ways in which it is myopic (and therefore a pain to keep\n> supporting, if we find it undesirable)?\n\nWhat's the problem with cooking it for a while?  You can start using it\nimmediately.  I'm just somewhat annoyed that the syntax is rapidly\nconverging to Perl-style line noise.\n\nI already hate half of the existing syntax, and I cannot remember using\n^! (except while investigating what 'git diff C^!' does and why not),\n^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},\n^{}, :/foo, and ^{/foo}, *at all*.\n\nIn fact I had to look up the second half of that list on the manpage.\n\nThat's not to say that they are not useful for *someone*.  But it does\nmotivate my suggestion that unless we have tried it and *found* that\nsomeone for a new syntax, let's not make it any more magic.\n\n> On a related note- In my opinion, :/ is broken, because it blocks\n> composition completely.  I would've really liked {:/quuxery}~3.\n\nI guess this constitutes an argument in my favor (i.e. that the syntax\nis too convoluted to understand and know):\n\n^{/foo} is the same as :/foo, except it properly groups.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"215412","messageId":"CALkWK0n9xqQr30QWEuhuM9c1xrAJ=SpYVBjkiRk+tP5E7DtBGw@mail.gmail.com","threadId":"33588","inReplyTo":"7vppxj6thv.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T07:51:57Z","receivedAt":"2013-04-25T07:51:57Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Okay, so the point I was trying to make is:\n\nThe range version of $(git merge-base A B) B is B ^$(git merge-base A\nB), and not B --not $(git merge-base --all A B) [which is equivalent\nto B ^A or A..B].\n\nJunio C Hamano wrote:\n> I dunno.  The description you gave was insufficient for me to answer\n> that question.\n\nSorry about that.  I'll rewrite it as a set of commands:\n\n$ cd /tmp\n$ git clone gh:artagnon/clayoven\n$ cd clayoven\n$ git checkout -b pu master~10\n$ echo \"foom\" >>LICENSE\n$ git commit -a -m \"Change in pu\"\n$ git checkout -b rebase.autostash master~5\n$ echo \"loom\" >> clayoven.gemspec\n$ git commit -a -m \"Change in rebase.autostash\"\n$ git checkout master\n$ git merge pu\n$ git checkout rebase.autostash\n$ git merge pu\n$ echo \"quux\" >>Gemfile\n$ git commit -a -m  \"Change 2 in rebase.autostash\"\n$ git log rebase.autostash ^master\n$ git log rebase.autostash --not $(git merge-base --all rebase.autostash master)\n$ git log rebase.autostash ^$(git merge-base rebase.autostash master)\n$ git diff rebase.autostash ^$(git merge-base rebase.autostash master)\n\nNote that git diff can only take two endpoints so git merge-base --all\nis meaningless in this case.\n\nTo summarize: B ^(git merge-base A B) [the current ... syntax of git\ndiff] has no exact equivalent in the log world.  Therefore, no matter\nwhich existing rev spec we overload, we can never get the current ...\nfor diff in a consistent manner.\n\nWe certainly know that 'git diff A~B' is going to be useful, and have\nan exact equivalent 'git log A~B' (but I'm not sure how useful it will\nbe, because I don't work with merges much).  The point is that it can\nbe overloaded in a consistent manner for other commands like 'rebase\n-i' too.\n\nI recently caved to overloading .. [1] because there's so much\nresistance to inventing a new rev spec.  I'm not exactly elated with\nthat.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/222343\n"},{"id":"215413","messageId":"CALkWK0=Mt_ko=GZouoe-XfrD4ny94dbWn0eMMZH7pSYF2MYP6g@mail.gmail.com","threadId":"33588","inReplyTo":"87li87awwc.fsf@linux-k42r.v.cablecom.net","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T08:06:20Z","receivedAt":"2013-04-25T08:06:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> I already hate half of the existing syntax, and I cannot remember using\n> ^! (except while investigating what 'git diff C^!' does and why not),\n> ^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},\n> ^{}, :/foo, and ^{/foo}, *at all*.\n\nI'm actually totally in love with the existing syntax (with the\npossible exception of :/).  I think it's extremely terse and\nexpressive.  People who don't care about such flexibility and power\ncan stick to using ~ and ^.  Enabling other users with additional\nsyntax doesn't harm them in any way.\n\n> ^{/foo} is the same as :/foo, except it properly groups.\n\nNo, not at all.  First of all, ^{/foo} is invalid: you need to specify\na ref to dig through, like HEAD^{/foo}.  OTOH, :/foo returns a match\nfrom any ref.\n"},{"id":"215420","messageId":"CALkWK0m=g3evr83ci5ZnTFHSEnCb_fRSer0j+sw1rRaaKDnY1A@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0n9xqQr30QWEuhuM9c1xrAJ=SpYVBjkiRk+tP5E7DtBGw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T09:30:51Z","receivedAt":"2013-04-25T09:30:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> $ git diff rebase.autostash ^$(git merge-base rebase.autostash master)\n\nSo, Thomas pointed out on IRC that there is one edge-case: a\ncriss-cross merge.  So, we can define A~B as B ^$(git-merge-base\n--closest-to=B A B).  If both A and B are equidistant from the\ncriss-cross merge [will that ever happen in practice?], we have no\nchoice but to error out.\n"},{"id":"215452","messageId":"7va9om5zxu.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"87li87awwc.fsf@linux-k42r.v.cablecom.net","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T16:37:33Z","receivedAt":"2013-04-25T16:37:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@inf.ethz.ch> writes:\n\n> What's the problem with cooking it for a while?  You can start using it\n> immediately.  I'm just somewhat annoyed that the syntax is rapidly\n> converging to Perl-style line noise.\n\nNot quite, not quite, and a mild agreement.\n\nAdding an obscure feature that may not be useful at all behind a\ncommand line option will fall into the \"you can afford to cook for a\nwhile, you can use it immediately yourself, nobody will get hurt\"\ncategory.  Adding a configuration to turn such a feature by default\non already is a more severe problem because we need to adjust and\nprotect scripted Porcelains from getting hurt by an unexpected new\nbehaviour user may trigger by setting such a configuration before it\nfully cooks, which is annoying maintenance burden for an obscure\nfeature with an unknown value.\n\nPiling cruft on syntax is in a totally different league.  If not\ncarefully thought out, adding a random new syntax on a whim can\npaint us into a corner we cannot later get out of, like the \":/\" we\nrecently discussed (which does have an escape hatch planned, but\nimagine a world without one).\n\n> I already hate half of the existing syntax, and I cannot remember using\n> ^! (except while investigating what 'git diff C^!' does and why not),\n> ^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},\n> ^{}, :/foo, and ^{/foo}, *at all*.\n>\n> In fact I had to look up the second half of that list on the manpage.\n\nI would have actually expected that people are more familiar with\nthe second half, i.e. @{2.weeks.ago}, @{4} and :/string, than ^!/^@\nwhich I agree were more-or-less \"let's add a random cruft on a whim\nwithout thinking things through\" mistakes.\n"},{"id":"215457","messageId":"CALkWK0mMvUXnMDY87h3US0gRuM44ADEYXPh+JVP23Ja1=yz=VQ@mail.gmail.com","threadId":"33588","inReplyTo":"7va9om5zxu.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T17:11:35Z","receivedAt":"2013-04-25T17:11:35Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> than ^!/^@\n> which I agree were more-or-less \"let's add a random cruft on a whim\n> without thinking things through\" mistakes.\n\nI thought ^@ was invented for scripting, but can't imagine a usecase for ^!.\n"},{"id":"215523","messageId":"20130425232145.GM29963@google.com","threadId":"33588","inReplyTo":"CALkWK0mMvUXnMDY87h3US0gRuM44ADEYXPh+JVP23Ja1=yz=VQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-25T23:21:45Z","receivedAt":"2013-04-25T23:21:45Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> I thought ^@ was invented for scripting, but can't imagine a usecase for ^!.\n\nI use \"git diff $commit^!\" from time to time to get the diff between a\nmerge and its first parent.\n\nFor comparison, I haven't found ^@ or \"git log $commit^!\" useful.  The\ncommit introducing the former says\n\n| I needed it to do the multi-tree diff on Len's infamous 12-way\n| Octopus; typing \"diff --cc funmerge funmerge^1 funmerge^2 funmerge^3\n| ...\" was too painful.\n\nwhich is spelled as \"git show --cc funmerge\" these days.\n"},{"id":"215525","messageId":"7vzjwmyycb.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"20130425232145.GM29963@google.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:39:16Z","receivedAt":"2013-04-25T23:39:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Ramkumar Ramachandra wrote:\n>\n>> I thought ^@ was invented for scripting, but can't imagine a usecase for ^!.\n>\n> I use \"git diff $commit^!\" from time to time to get the diff between a\n> merge and its first parent.\n>\n> For comparison, I haven't found ^@ or \"git log $commit^!\" useful.  The\n> commit introducing the former says\n>\n> | I needed it to do the multi-tree diff on Len's infamous 12-way\n> | Octopus; typing \"diff --cc funmerge funmerge^1 funmerge^2 funmerge^3\n> | ...\" was too painful.\n>\n> which is spelled as \"git show --cc funmerge\" these days.\n\nThe more important part of the message comes before that part ;-)\n\n    This might be just my shiny new toy that is not very useful in\n    practice.  I needed it to do the multi-tree diff on Len's ...\n\nSo I was right --- from the very beginning, this was \"let's add a\nrandom cruft on a whim without thinking things through\" as I said.\n\nIt is not satisfactory to be right in saying that \"I am sure this\nwas a stupid mistake\" X-<.\n"},{"id":"215586","messageId":"CALkWK0kSWHS0JJ9E4PPihRru0-H13mNffJ5Hndg+LqvFzsYG8Q@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0n9xqQr30QWEuhuM9c1xrAJ=SpYVBjkiRk+tP5E7DtBGw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T10:47:20Z","receivedAt":"2013-04-26T10:47:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> The range version of $(git merge-base A B) B is B ^$(git merge-base A\n> B), and not B --not $(git merge-base --all A B) [which is equivalent\n> to B ^A or A..B].\n\nLet me make this easier for you, and everyone else.\n\nIn git.git, checkout master and merge 9915605c^2 (rr/shortlog-doc).\nSo, my changeset has graduated from 'pu' to 'master' (I know 'master'\nis directly ahead of 'pu', and this is not what you do; but this is\njust an exercise).  Now, I execute git log master..pu and search for\nthe author \"Ramkumar Ramachandra\".  I can see that my shortlog-doc\ncommits aren't present; so I infer that my changes have graduated to\nmaster.  I can also see the merge commit corresponding to\nrr/shortlog-doc, and infer that master merged in rr/shortlog-doc\ndifferently.\n\nIf I execute git log pu ^$(git merge-base master pu), I see the merge\ncommit rr/shortlog-doc _and_ the shortlog-doc commits.  Here, I don't\nwant to know if my change graduated to master or not: I just want to\nknow what changes were introduced by the pu branch since the last\nfork.  Think of it as a time-truncated version of git log pu: it has\nnothing to do with reachability.  The only reason that master even\nappears in the command is because I need to specify where pu forked\noff from.\n\nI would argue that this is incredibly useful: to see what changes were\nintroduced by \"my branch\" independent of everything else.  What do you\nthink?\n"},{"id":"215587","messageId":"CALkWK0mLdGPAJZC=KgYrTS3pCOacEdNyS3XT1eOPKjTbvRk3cQ@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0kSWHS0JJ9E4PPihRru0-H13mNffJ5Hndg+LqvFzsYG8Q@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T11:35:04Z","receivedAt":"2013-04-26T11:35:04Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Think of it as a time-truncated version of git log pu: it has\n> nothing to do with reachability.\n\nEr, scratch that out.  I don't like talking in vague terms, and this\nfeature has nothing to do with git log --since (which is what\ntime-truncated is).\n"},{"id":"215591","messageId":"CACsJy8B1yfqVmaBZ0A=Yfxx+As_+JzBzWr4LqrEwhr5qGZ7+Aw@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0kn7mEosWSdWs1Jjx-L32wmL51W=X7ny9BYQMttG1LPvQ@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-26T12:34:00Z","receivedAt":"2013-04-26T12:34:00Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Apr 25, 2013 at 3:54 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> On a related note- In my opinion, :/ is broken, because it blocks\n> composition completely.  I would've really liked {:/quuxery}~3.\n\nFor composition, you should be able to combine a ref set with @{}\nsyntax, so you can choose to apply @{} on refs/heads/*, or all refs. I\nguess it's not worth the trouble because, except the case of :/ that\nsearches and returns 1 sha-1, other @{} may return multiple sha-1s on\na ref set.\n--\nDuy\n"},{"id":"215863","messageId":"7vhaipl2ks.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0n9xqQr30QWEuhuM9c1xrAJ=SpYVBjkiRk+tP5E7DtBGw@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T16:32:51Z","receivedAt":"2013-04-29T16:32:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Okay, so the point I was trying to make is:\n>\n> The range version of $(git merge-base A B) B is B ^$(git merge-base A\n> B), and not B --not $(git merge-base --all A B) [which is equivalent\n> to B ^A or A..B].\n>\n> Junio C Hamano wrote:\n>> I dunno.  The description you gave was insufficient for me to answer\n>> that question.\n>\n> Sorry about that.  I'll rewrite it as a set of commands:\n\n[now that a few days have passed...]\n\nPlease don't.  All of these clayoven, LICENSE, foom, loom are mere\ndistraction.\n\n\t... goes and draws the diagram himself ...\n\n   > $ git clone gh:artagnon/clayoven\n   > $ cd clayoven\nA  > $ git checkout -b pu master~10\n   > $ echo \"foom\" >>LICENSE\nB  > $ git commit -a -m \"Change in pu\"\nC  > $ git checkout -b rebase.autostash master~5\n   > $ echo \"loom\" >> clayoven.gemspec\nD  > $ git commit -a -m \"Change in rebase.autostash\"\nE  > $ git checkout master\nF  > $ git merge pu\n   > $ git checkout rebase.autostash\nG  > $ git merge pu\n   > $ echo \"quux\" >>Gemfile\nH  > $ git commit -a -m  \"Change 2 in rebase.autostash\"\n\nSo you have this:\n\n                        (pu)        (master-updated)\n        .-----------------B--------------F\n       /                   \\            /\n      /                 D---G---H      /\n     /                 /              / \n ---A-----------------C--------------E\n  (master~10)     (master~5)      (master-old) \n\nIn the beginning, master was at E, but at the end, it is moved to\nF. The tip of your topic is at H.\n\n> $ git log rebase.autostash ^master\n\nThat is range \"F..H\", which lists \"H G D\".\n\n> $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master)\n\nThe merge bases between F and H are B and C, so that is\nrange \"^B ^C H\", which again lists \"H G D\".\n\n> $ git log rebase.autostash ^$(git merge-base rebase.autostash master)\n\nDepending on which one of B or C is chosen it is either one of these:\n\n - range \"^B H\" which lists \"H G D C\"\n - range \"^C H\" which lists \"H G D B\"\n\nneither of which is more useful than \"H G D\", as it shows irrelevant\n\"other merge base\" you did not pick.\n\n> $ git diff rebase.autostash ^$(git merge-base rebase.autostash master)\n\nThis will show either \"diff B H\", which is work done by G and H, or\n\"diff C H\", which is work done by D thru H.  In the former, \"the\nwork done by G\" includes what was done by A..D, which are mostly\nirrelevant to explain what you did on your topic, but you asked for\nit.  In the latter, \"the work done by G\" is what was done by A..B,\nwhich again are not what D and H did.\n\nThe example explains why you should not merge other's work to your\ntopic branch [*1*], but does not say anything about usefulness of\nA...B vs A~B.\n\n> To summarize: B ^(git merge-base A B) [the current ... syntax of git\n> diff] has no exact equivalent in the log world.  \n\nNor does \"log\" need one.  See how picking either B or C and omitting\nthe other would produce worse result than excluding all merge bases,\nwhich log F..H would naturally does.\n\n> Therefore, no matter\n> which existing rev spec we overload, we can never get the current ...\n> for diff in a consistent manner.\n\nAs \"log\" does not need any such thing, that is irrelevant, no?\n\n> We certainly know that 'git diff A~B' is going to be useful,...\n\nWe certainly know it is an unnecessary \"there is another way to\nspell the same thing we have been using for a long time\".\n\nYou did not give anything new that hints that it might be worth\nspending time listening to you in this message. Should I do a \"kill\nfile for a few days\" thing again?\n\n\n[Footnote]\n\n*1* Instead, you have a separate integration branch for testing that\nmerges other's work and your topic.\n"},{"id":"215895","messageId":"CALkWK0npQwFnFNpEzT5mgh5HvGUKf=Jz7v4Mn62BDBzb+qjY_A@mail.gmail.com","threadId":"33588","inReplyTo":"7vhaipl2ks.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-29T18:21:03Z","receivedAt":"2013-04-29T18:21:03Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Please don't.  All of these clayoven, LICENSE, foom, loom are mere\n> distraction.\n>\n>         ... goes and draws the diagram himself ...\n\nSorry, I'm finding it hard to draw this thing.  I'm only becoming\ncomfortable with reading it now.\n\n>> $ git log rebase.autostash ^master\n>\n> That is range \"F..H\", which lists \"H G D\".\n>\n>> $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master)\n>\n> The merge bases between F and H are B and C, so that is\n> range \"^B ^C H\", which again lists \"H G D\".\n\nCorrect.  Equivalent.\n\n>> $ git log rebase.autostash ^$(git merge-base rebase.autostash master)\n>\n> Depending on which one of B or C is chosen it is either one of these:\n>\n>  - range \"^B H\" which lists \"H G D C\"\n>  - range \"^C H\" which lists \"H G D B\"\n>\n> neither of which is more useful than \"H G D\", as it shows irrelevant\n> \"other merge base\" you did not pick.\n\nCorrection:\n\nRange \"^B H\" lists \"H G D A..C\" while range \"^C H\" lists \"H G D A..B\".\n\nIn reality, it shows A..B, which is what I want and what am claiming\nis \"useful\".\n\nI want to what all happened since rebase.autostash forked off from\nmaster (at D) all the way until its current tip (at H).  With\nmaster..rebase.autostash, I'm only informed about a mysterious G (but\nam clueless about the commits it introduced).  I don't _want_ to know\nthe \"difference\" between rebase.autostash and master (master includes\nthe A..B commits, which is why master..rebase.autostash is refusing to\nshow them to me).\n\n>> $ git diff rebase.autostash ^$(git merge-base rebase.autostash master)\n>\n> This will show either \"diff B H\", which is work done by G and H, or\n> \"diff C H\", which is work done by D thru H.\n\nIn reality, it shows \"diff C H\", which is what I wanted to know.  In\nother words, it tells me \"what happened since rebase.autostash forked\noff from master\".  Which is what I want to know.\n\nIn the previous email you said you didn't understand the topology, so\nI explained it subsequently.  In this email, your claims have varied\nfrom:\n\n- It is Wrong or Not Useful to ask \"tell me everything that happened\nsince my branch forked off from master\"\n\n- The question I'm asking is ill-formed (?)\n\n- A..B is \"sufficient\" (for what?  it's answering an entirely\ndifferent question)\n\nNow, I'm not claiming that it is _definitely_ useful.  I'm saying that\nit gives an answer to what seems to be a valid question to me.\n\n> You did not give anything new that hints that it might be worth\n> spending time listening to you in this message. Should I do a \"kill\n> file for a few days\" thing again?\n\nI might be saying nonsense, but I don't appreciate this kind of\nresponse at all.  Realize that I'm spending 3x the amount of time in\ncrafting this.  I'm the one proposing something new, and you're the\none defending what exists.  If anyone has the right to complain, it's\nme.  Not you.\n"},{"id":"215898","messageId":"20130429183205.GO472@serenity.lan","threadId":"33588","inReplyTo":"7vhaipl2ks.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-29T18:32:05Z","receivedAt":"2013-04-29T18:32:05Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Apr 29, 2013 at 09:32:51AM -0700, Junio C Hamano wrote:\n> *1* Instead, you have a separate integration branch for testing that\n> merges other's work and your topic.\n\n<shameless-plug>\n\nI wrote a script to help manage this [1].  It doesn't do everything I\nwant it to yet but I'm using it on a daily basis to maintain a Git\nversion consisting of pu plus a few changes that I'm working on which\naren't ready for submission yet as well as for maintaining integration\nbranches in a couple of other projects.\n\nYou can create an integration branch on top of pu quickly with:\n\n    git integration --create my-integration-branch pu \\\n        --add my-feature-branch --rebuild\n\nAnd then whenever you want to rebuild with your latest changes (or on\ntop of the latest pu):\n\n    git integration --rebuild my-integration-branch\n\n[1] http://johnkeeping.github.io/git-integration/\n"},{"id":"215899","messageId":"7vmwshi3dv.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0npQwFnFNpEzT5mgh5HvGUKf=Jz7v4Mn62BDBzb+qjY_A@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T18:43:40Z","receivedAt":"2013-04-29T18:43:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n>>> $ git log rebase.autostash ^$(git merge-base rebase.autostash master)\n>>\n>> Depending on which one of B or C is chosen it is either one of these:\n>>\n>>  - range \"^B H\" which lists \"H G D C\"\n>>  - range \"^C H\" which lists \"H G D B\"\n>>\n>> neither of which is more useful than \"H G D\", as it shows irrelevant\n>> \"other merge base\" you did not pick.\n>\n> Correction:\n>\n> Range \"^B H\" lists \"H G D A..C\" while range \"^C H\" lists \"H G D A..B\".\n\nNow you confused me.  A is reachable from B (or C) and you\nare saying \"^B H\" (or \"^C H\").  Why does either of it show A?\n\nWait.  What does \"lists H G D A..C\" even mean?  H, G and D I would\nunderstand, but how does \"log\" ever \"list\" A..C???\n\nNow you really confused me.\n\nA is not listed (it is explicitly marked uninteresting by being on\nthe left side of double-dots).  So we see either \"H G D C\" or \"H G D\nB\".  We see no A in either case, no?\n\n> In reality, it shows A..B, which is what I want and what am claiming\n> is \"useful\".\n\nWhat does it mean \"log\" \"In reality\" shows A..B?  Didn't you just\nsay it either lists \"H G D C\" or \"H G D B\"?  Neither B nor C is what\nyou did since you forked?  Now, what did you do since you folked\n(which is the question you are asking)?  You made commit D,\nback-merged from upstream to record G, and then made another commit\nH.  That \"H G D\", which is what you get from \"log F..H\", isn't it??\n"},{"id":"215901","messageId":"CALkWK0nNb1CSR6EHxtnvBd3VXVPNb_JDqk2Kfa5VA1RMG1u0Ng@mail.gmail.com","threadId":"33588","inReplyTo":"7vmwshi3dv.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-29T19:03:15Z","receivedAt":"2013-04-29T19:03:15Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Wait.  What does \"lists H G D A..C\" even mean?  H, G and D I would\n> understand, but how does \"log\" ever \"list\" A..C???\n>\n> Now you really confused me.\n\nWhat you said was technically correct.  I was pointing out that the\ngraph was misleading because it didn't show any commits between A and\nB/C.  A is ofcourse UNINTERESTING.\n\n> What does it mean \"log\" \"In reality\" shows A..B?  Didn't you just\n> say it either lists \"H G D C\" or \"H G D B\"?  Neither B nor C is what\n> you did since you forked?  Now, what did you do since you folked\n> (which is the question you are asking)?  You made commit D,\n> back-merged from upstream to record G, and then made another commit\n> H.  That \"H G D\", which is what you get from \"log F..H\", isn't it??\n\nOkay, so the question is ill-formed.  The technically correct version\nis \"which commits are reachable from my branch since I forked off?\",\nbut I don't know if anyone will want to ask that question.  If you\nhave no more inputs, I'll concede that it's not useful in the log\ncase.\n\nI'm trying to look for one more command that will find A~B useful, so\nwe can remove the A...B wart from diff; inventing it just to replace\nthe wart isn't reason enough.  Do you disagree with the approach?\n\nWhat are your thoughts on overloading it for rebase?  git rebase\nmaster~ to rebase onto the merge-base of master and HEAD?\n"},{"id":"215904","messageId":"CALkWK0=QviF2TbY3hePQJxkmG1QPpG=EyUVqoCbmj7uqFJ29ow@mail.gmail.com","threadId":"33588","inReplyTo":"CALkWK0nNb1CSR6EHxtnvBd3VXVPNb_JDqk2Kfa5VA1RMG1u0Ng@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-29T19:17:46Z","receivedAt":"2013-04-29T19:17:46Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> What are your thoughts on overloading it for rebase?  git rebase\n> master~ to rebase onto the merge-base of master and HEAD?\n\nI just realized that I meant\n\n    git rebase master..\n\nand not\n\n    git rebase master~\n\nI want to rebase the merge commit, not the merge-base along with it!\n"},{"id":"215910","messageId":"7vehdti00w.fsf@alter.siamese.dyndns.org","threadId":"33588","inReplyTo":"CALkWK0nNb1CSR6EHxtnvBd3VXVPNb_JDqk2Kfa5VA1RMG1u0Ng@mail.gmail.com","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T19:56:15Z","receivedAt":"2013-04-29T19:56:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Wait.  What does \"lists H G D A..C\" even mean?  H, G and D I would\n>> understand, but how does \"log\" ever \"list\" A..C???\n>>\n>> Now you really confused me.\n>\n> What you said was technically correct.  I was pointing out that the\n> graph was misleading because it didn't show any commits between A and\n> B/C.  A is ofcourse UNINTERESTING.\n>\n>> What does it mean \"log\" \"In reality\" shows A..B?  Didn't you just\n>> say it either lists \"H G D C\" or \"H G D B\"?  Neither B nor C is what\n>> you did since you forked?  Now, what did you do since you folked\n>> (which is the question you are asking)?  You made commit D,\n>> back-merged from upstream to record G, and then made another commit\n>> H.  That \"H G D\", which is what you get from \"log F..H\", isn't it??\n>\n> Okay, so the question is ill-formed.  The technically correct version\n> is \"which commits are reachable from my branch since I forked off?\",\n> but I don't know if anyone will want to ask that question.\n\nOK, I missed what you wanted to say with A..C, which only had B in\nthe concrete depiction.  Omitting all other merge bases and picking\nonly one (say C) at random will include not just B but all the other\ncommits that are not what you did since you forked before C.  Which\nI think makes the example even less interesting, and you seem to\nagree to that.\n\nThanks for clarification.  I was really getting worried if I was\nmissing something fundamental in what you were saying.\n\n> I'm trying to look for one more command that will find A~B useful, so\n> we can remove the A...B wart from diff; inventing it just to replace\n> the wart isn't reason enough.  Do you disagree with the approach?\n\nHave you ever seen me saying \"it sounds like a good idea\" to a\nsolution that is looking for a problem? ;-)\n\n\"diff A...B\" works already, and stopping to refer to \"diff A..B\"\n(the documentation patch you sent out) hopefully will make it less\nconfusing.  I do not see a huge upside in replacing it with yet\nanother notation people need to learn (and possibly make them\nunlearn a working notation). The downside of it feels far worse.\n\n> What are your thoughts on overloading it for rebase?  git rebase\n> master~ to rebase onto the merge-base of master and HEAD?\n\nNot very interested [*0*], but I haven't thought things through.\n\nIn order to express only what we can currently express (i.e. not\nextending for a DAG with a single bottom and multiple refs at tops),\nI think it is sufficient to allow \"rebase [--onto=$there] origin..\"\n[*1*]; we can infer what ref is being rebased from the range we get\nfrom the command line by asking rev_cmdline, and it may be more\nnatural to people who grew up with \"git log origin..\".\n\nThat approach would express the DAG with the usual revision range\nspecifier on the command line, limited to those range notations that\nhave a single bottom and a single top.  That range defines the DAG\nthat will be replayed, and its single top defines what ref is\nupdated as the result.\n\nWhen --onto is not specified, we could choose to use two- vs three-\ndot notations to select what \"onto\" to use by default [*2*].  For\nexample, \"rebase origin..\" could be a way to replay your work on top\nof their work you fetched, while \"rebase -i origin...\" could be a\nway to identify your work since you forked from them, and tweak then\nwithout changing the base, i.e. the fork point (the latter of which\nwould match what you would get from \"diff A...B\" naturally).\n\nIf we later want to add \"a DAG with a single bottom and multiple\nrefs at tops\", it could be spelled as \"rebase --multi --onto=$there\n^origin rr/rebase-doc rr/triangle\" or something [*3*].\n\nBut footnote *2* turns out to be the most important point in this\nmessage. Earlier I said I haven't thought things through, but I\nthink I have now.\n\n\n[Footnote]\n\n*0* \"git rebase master~\" would rebase your current history on top of\none commit before master, but you could choose to use some line\nnoise character other than tilde.\n\n*1* This is similar to the way we taught \"origin..\" and \"-3 HEAD\" to\n\"format-patch\" that originally only took \"origin\".\n\n*2* Having said that, I do not particularly like the approach to\nexploit the difference between two- and three-dot forms and use it\nin choosing which commit to use as the default \"onto\".\n\nIt might be more useful to have the distinction between \"rebase -i\"\nand \"rebase\" make that decision. \n\nReplaying on top of the merge base would not be useful unless we are\ndoing \"rebase -i\" (it would be a no-op by definition). From that\npoint of view, \"rebase origin\" (or \"rebase origin..\" or \"rebase\norigin...\"), because it is replaying your work on top of others, may\nuse --onto=origin by default. On the other hand, \"rebase -i origin\"\n(or \"rebase -i origin..\" or \"rebase -i origin...\"), because you use\nthe command in order to tweak your work, and you mention 'origin'\nmerely to let Git know where your fork point is, may replay on the\noriginal fork point it discovers with merge-base.\n\nOr something like that.  The above makes me think that focusing on\nthe revision range notation is not terribly productive when\nexploring how to make \"rebase\" easier to use to end users.\n\n*3* \"--multi\" is merely an example to make it easy to tell the\ncommand line from the traditional form that has an extra \"switch to\nthis branch before starting anything\" argument.\n"},{"id":"215919","messageId":"CALkWK0nPrc41Z4-Jebwywx28x64QCm_010U_vpxa-K8XZOUpbA@mail.gmail.com","threadId":"33588","inReplyTo":"7vehdti00w.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Highly inconsistent diff UI","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-29T21:12:23Z","receivedAt":"2013-04-29T21:12:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Have you ever seen me saying \"it sounds like a good idea\" to a\n> solution that is looking for a problem? ;-)\n\nI'll try to avoid that approach in the future.\n\n> \"diff A...B\" works already, and stopping to refer to \"diff A..B\"\n> (the documentation patch you sent out) hopefully will make it less\n> confusing.  I do not see a huge upside in replacing it with yet\n> another notation people need to learn (and possibly make them\n> unlearn a working notation). The downside of it feels far worse.\n\nSo, my question is about whether A..B is really that confusing.  We\nmight exploit the differences between .. and ... in all the commands,\nand document it properly.  We just have to stop calling .. and ...\ncanonical \"range\" commands.  We can stick to overriding these two for\nnow.\n\nWhat does consistency even mean?  What does it mean for rebase A..B to\nhave logical similarity to log A..B?  If this similarity cannot be\nprecisely defined, consistency is just an illusion.\n\n> Not very interested [*0*], but I haven't thought things through.\n\nYeah, neither have I.  I'm asking for input.\n\n> In order to express only what we can currently express (i.e. not\n> extending for a DAG with a single bottom and multiple refs at tops),\n> I think it is sufficient to allow \"rebase [--onto=$there] origin..\"\n> [*1*]; we can infer what ref is being rebased from the range we get\n> from the command line by asking rev_cmdline, and it may be more\n> natural to people who grew up with \"git log origin..\".\n\nThat's fine.  The tricky part is: what is it rebased onto?  origin?\n\n> That approach would express the DAG with the usual revision range\n> specifier on the command line, limited to those range notations that\n> have a single bottom and a single top.  That range defines the DAG\n> that will be replayed, and its single top defines what ref is\n> updated as the result.\n\nOkay.\n\n> When --onto is not specified, we could choose to use two- vs three-\n> dot notations to select what \"onto\" to use by default [*2*].  For\n> example, \"rebase origin..\" could be a way to replay your work on top\n> of their work you fetched, while \"rebase -i origin...\" could be a\n> way to identify your work since you forked from them, and tweak then\n> without changing the base, i.e. the fork point (the latter of which\n> would match what you would get from \"diff A...B\" naturally).\n>\n> If we later want to add \"a DAG with a single bottom and multiple\n> refs at tops\", it could be spelled as \"rebase --multi --onto=$there\n> ^origin rr/rebase-doc rr/triangle\" or something [*3*].\n\nI'm an idiot.  What I was bouting as consistency was artificial\nconstraints _I_ imposed on the rev spec.  Why shouldn't the command\nbehave differently for:\n\n1. One positive and one negative.\n2. Multiple positives and one negative.\n2.1 When there are two positives, and --multi isn't on.\n2.2 When --multi is on.\n\nWhat is it violating?\n\nThe UI you have proposed is very compelling, although I'm surprised\nyou did it top-down.\n\n> [Footnote]\n>\n> *0* \"git rebase master~\" would rebase your current history on top of\n> one commit before master, but you could choose to use some line\n> noise character other than tilde.\n\nNot urgent.\n\n> *1* This is similar to the way we taught \"origin..\" and \"-3 HEAD\" to\n> \"format-patch\" that originally only took \"origin\".\n\nOkay.\n\n> *2* Having said that, I do not particularly like the approach to\n> exploit the difference between two- and three-dot forms and use it\n> in choosing which commit to use as the default \"onto\".\n>\n> It might be more useful to have the distinction between \"rebase -i\"\n> and \"rebase\" make that decision.\n>\n> Replaying on top of the merge base would not be useful unless we are\n> doing \"rebase -i\" (it would be a no-op by definition). From that\n> point of view, \"rebase origin\" (or \"rebase origin..\" or \"rebase\n> origin...\"), because it is replaying your work on top of others, may\n> use --onto=origin by default. On the other hand, \"rebase -i origin\"\n> (or \"rebase -i origin..\" or \"rebase -i origin...\"), because you use\n> the command in order to tweak your work, and you mention 'origin'\n> merely to let Git know where your fork point is, may replay on the\n> original fork point it discovers with merge-base.\n\nI'll have to think about this.\n\n> Or something like that.  The above makes me think that focusing on\n> the revision range notation is not terribly productive when\n> exploring how to make \"rebase\" easier to use to end users.\n\nYou managed a top-down version quite quickly, while I was stuck at\nconsistency :)\n\n> *3* \"--multi\" is merely an example to make it easy to tell the\n> command line from the traditional form that has an extra \"switch to\n> this branch before starting anything\" argument.\n\nCute way of putting it.\n"}]}