Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Okay, so the point I was trying to make is: The range version of $(git merge-base A B) B is B ^$(git merge-base A B), and not B --not $(git merge-base --all A B) [which is equivalent to B ^A or A..B]. Junio C Hamano wrote: I dunno. The description you gave was insufficient for me to answer that question. Sorry about that. I'll rewrite it as a set of commands: [now that a few days have passed...] Please don't. All of these clayoven, LICENSE, foom, loom are mere distraction. ... goes and draws the diagram himself ... $ git clone gh:artagnon/clayoven $ cd clayoven A $ git checkout -b pu master~10 $ echo foom LICENSE B $ git commit -a -m Change in pu C $ git checkout -b rebase.autostash master~5 $ echo loom clayoven.gemspec D $ git commit -a -m Change in rebase.autostash E $ git checkout master F $ git merge pu $ git checkout rebase.autostash G $ git merge pu $ echo quux Gemfile H $ git commit -a -m Change 2 in rebase.autostash So you have this: (pu)(master-updated) .-B--F / \/ / D---G---H / / / / ---A-C--E (master~10) (master~5) (master-old) In the beginning, master was at E, but at the end, it is moved to F. The tip of your topic is at H. $ git log rebase.autostash ^master That is range F..H, which lists H G D. $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master) The merge bases between F and H are B and C, so that is range ^B ^C H, which again lists H G D. $ git log rebase.autostash ^$(git merge-base rebase.autostash master) Depending on which one of B or C is chosen it is either one of these: - range ^B H which lists H G D C - range ^C H which lists H G D B neither of which is more useful than H G D, as it shows irrelevant other merge base you did not pick. $ git diff rebase.autostash ^$(git merge-base rebase.autostash master) This will show either diff B H, which is work done by G and H, or diff C H, which is work done by D thru H. In the former, the work done by G includes what was done by A..D, which are mostly irrelevant to explain what you did on your topic, but you asked for it. In the latter, the work done by G is what was done by A..B, which again are not what D and H did. The example explains why you should not merge other's work to your topic branch [*1*], but does not say anything about usefulness of A...B vs A~B. To summarize: B ^(git merge-base A B) [the current ... syntax of git diff] has no exact equivalent in the log world. Nor does log need one. See how picking either B or C and omitting the other would produce worse result than excluding all merge bases, which log F..H would naturally does. Therefore, no matter which existing rev spec we overload, we can never get the current ... for diff in a consistent manner. As log does not need any such thing, that is irrelevant, no? We certainly know that 'git diff A~B' is going to be useful,... We certainly know it is an unnecessary there is another way to spell the same thing we have been using for a long time. You did not give anything new that hints that it might be worth spending time listening to you in this message. Should I do a kill file for a few days thing again? [Footnote] *1* Instead, you have a separate integration branch for testing that merges other's work and your topic. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: Please don't. All of these clayoven, LICENSE, foom, loom are mere distraction. ... goes and draws the diagram himself ... Sorry, I'm finding it hard to draw this thing. I'm only becoming comfortable with reading it now. $ git log rebase.autostash ^master That is range F..H, which lists H G D. $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master) The merge bases between F and H are B and C, so that is range ^B ^C H, which again lists H G D. Correct. Equivalent. $ git log rebase.autostash ^$(git merge-base rebase.autostash master) Depending on which one of B or C is chosen it is either one of these: - range ^B H which lists H G D C - range ^C H which lists H G D B neither of which is more useful than H G D, as it shows irrelevant other merge base you did not pick. Correction: Range ^B H lists H G D A..C while range ^C H lists H G D A..B. In reality, it shows A..B, which is what I want and what am claiming is useful. I want to what all happened since rebase.autostash forked off from master (at D) all the way until its current tip (at H). With master..rebase.autostash, I'm only informed about a mysterious G (but am clueless about the commits it introduced). I don't _want_ to know the difference between rebase.autostash and master (master includes the A..B commits, which is why master..rebase.autostash is refusing to show them to me). $ git diff rebase.autostash ^$(git merge-base rebase.autostash master) This will show either diff B H, which is work done by G and H, or diff C H, which is work done by D thru H. In reality, it shows diff C H, which is what I wanted to know. In other words, it tells me what happened since rebase.autostash forked off from master. Which is what I want to know. In the previous email you said you didn't understand the topology, so I explained it subsequently. In this email, your claims have varied from: - It is Wrong or Not Useful to ask tell me everything that happened since my branch forked off from master - The question I'm asking is ill-formed (?) - A..B is sufficient (for what? it's answering an entirely different question) Now, I'm not claiming that it is _definitely_ useful. I'm saying that it gives an answer to what seems to be a valid question to me. You did not give anything new that hints that it might be worth spending time listening to you in this message. Should I do a kill file for a few days thing again? I might be saying nonsense, but I don't appreciate this kind of response at all. Realize that I'm spending 3x the amount of time in crafting this. I'm the one proposing something new, and you're the one defending what exists. If anyone has the right to complain, it's me. Not you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
On Mon, Apr 29, 2013 at 09:32:51AM -0700, Junio C Hamano wrote: *1* Instead, you have a separate integration branch for testing that merges other's work and your topic. shameless-plug I wrote a script to help manage this [1]. It doesn't do everything I want it to yet but I'm using it on a daily basis to maintain a Git version consisting of pu plus a few changes that I'm working on which aren't ready for submission yet as well as for maintaining integration branches in a couple of other projects. You can create an integration branch on top of pu quickly with: git integration --create my-integration-branch pu \ --add my-feature-branch --rebuild And then whenever you want to rebuild with your latest changes (or on top of the latest pu): git integration --rebuild my-integration-branch [1] http://johnkeeping.github.io/git-integration/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: $ git log rebase.autostash ^$(git merge-base rebase.autostash master) Depending on which one of B or C is chosen it is either one of these: - range ^B H which lists H G D C - range ^C H which lists H G D B neither of which is more useful than H G D, as it shows irrelevant other merge base you did not pick. Correction: Range ^B H lists H G D A..C while range ^C H lists H G D A..B. Now you confused me. A is reachable from B (or C) and you are saying ^B H (or ^C H). Why does either of it show A? Wait. What does lists H G D A..C even mean? H, G and D I would understand, but how does log ever list A..C??? Now you really confused me. A is not listed (it is explicitly marked uninteresting by being on the left side of double-dots). So we see either H G D C or H G D B. We see no A in either case, no? In reality, it shows A..B, which is what I want and what am claiming is useful. What does it mean log In reality shows A..B? Didn't you just say it either lists H G D C or H G D B? Neither B nor C is what you did since you forked? Now, what did you do since you folked (which is the question you are asking)? You made commit D, back-merged from upstream to record G, and then made another commit H. That H G D, which is what you get from log F..H, isn't it?? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: Wait. What does lists H G D A..C even mean? H, G and D I would understand, but how does log ever list A..C??? Now you really confused me. What you said was technically correct. I was pointing out that the graph was misleading because it didn't show any commits between A and B/C. A is ofcourse UNINTERESTING. What does it mean log In reality shows A..B? Didn't you just say it either lists H G D C or H G D B? Neither B nor C is what you did since you forked? Now, what did you do since you folked (which is the question you are asking)? You made commit D, back-merged from upstream to record G, and then made another commit H. That H G D, which is what you get from log F..H, isn't it?? Okay, so the question is ill-formed. The technically correct version is which commits are reachable from my branch since I forked off?, but I don't know if anyone will want to ask that question. If you have no more inputs, I'll concede that it's not useful in the log case. I'm trying to look for one more command that will find A~B useful, so we can remove the A...B wart from diff; inventing it just to replace the wart isn't reason enough. Do you disagree with the approach? What are your thoughts on overloading it for rebase? git rebase master~ to rebase onto the merge-base of master and HEAD? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: What are your thoughts on overloading it for rebase? git rebase master~ to rebase onto the merge-base of master and HEAD? I just realized that I meant git rebase master.. and not git rebase master~ I want to rebase the merge commit, not the merge-base along with it! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Wait. What does lists H G D A..C even mean? H, G and D I would understand, but how does log ever list A..C??? Now you really confused me. What you said was technically correct. I was pointing out that the graph was misleading because it didn't show any commits between A and B/C. A is ofcourse UNINTERESTING. What does it mean log In reality shows A..B? Didn't you just say it either lists H G D C or H G D B? Neither B nor C is what you did since you forked? Now, what did you do since you folked (which is the question you are asking)? You made commit D, back-merged from upstream to record G, and then made another commit H. That H G D, which is what you get from log F..H, isn't it?? Okay, so the question is ill-formed. The technically correct version is which commits are reachable from my branch since I forked off?, but I don't know if anyone will want to ask that question. OK, I missed what you wanted to say with A..C, which only had B in the concrete depiction. Omitting all other merge bases and picking only one (say C) at random will include not just B but all the other commits that are not what you did since you forked before C. Which I think makes the example even less interesting, and you seem to agree to that. Thanks for clarification. I was really getting worried if I was missing something fundamental in what you were saying. I'm trying to look for one more command that will find A~B useful, so we can remove the A...B wart from diff; inventing it just to replace the wart isn't reason enough. Do you disagree with the approach? Have you ever seen me saying it sounds like a good idea to a solution that is looking for a problem? ;-) diff A...B works already, and stopping to refer to diff A..B (the documentation patch you sent out) hopefully will make it less confusing. I do not see a huge upside in replacing it with yet another notation people need to learn (and possibly make them unlearn a working notation). The downside of it feels far worse. What are your thoughts on overloading it for rebase? git rebase master~ to rebase onto the merge-base of master and HEAD? Not very interested [*0*], but I haven't thought things through. In order to express only what we can currently express (i.e. not extending for a DAG with a single bottom and multiple refs at tops), I think it is sufficient to allow rebase [--onto=$there] origin.. [*1*]; we can infer what ref is being rebased from the range we get from the command line by asking rev_cmdline, and it may be more natural to people who grew up with git log origin... That approach would express the DAG with the usual revision range specifier on the command line, limited to those range notations that have a single bottom and a single top. That range defines the DAG that will be replayed, and its single top defines what ref is updated as the result. When --onto is not specified, we could choose to use two- vs three- dot notations to select what onto to use by default [*2*]. For example, rebase origin.. could be a way to replay your work on top of their work you fetched, while rebase -i origin... could be a way to identify your work since you forked from them, and tweak then without changing the base, i.e. the fork point (the latter of which would match what you would get from diff A...B naturally). If we later want to add a DAG with a single bottom and multiple refs at tops, it could be spelled as rebase --multi --onto=$there ^origin rr/rebase-doc rr/triangle or something [*3*]. But footnote *2* turns out to be the most important point in this message. Earlier I said I haven't thought things through, but I think I have now. [Footnote] *0* git rebase master~ would rebase your current history on top of one commit before master, but you could choose to use some line noise character other than tilde. *1* This is similar to the way we taught origin.. and -3 HEAD to format-patch that originally only took origin. *2* Having said that, I do not particularly like the approach to exploit the difference between two- and three-dot forms and use it in choosing which commit to use as the default onto. It might be more useful to have the distinction between rebase -i and rebase make that decision. Replaying on top of the merge base would not be useful unless we are doing rebase -i (it would be a no-op by definition). From that point of view, rebase origin (or rebase origin.. or rebase origin...), because it is replaying your work on top of others, may use --onto=origin by default. On the other hand, rebase -i origin (or rebase -i origin.. or rebase -i origin...), because you use the command in order to tweak your work, and you mention 'origin' merely to let Git know where your fork point is, may replay on the original fork point it discovers with merge-base. Or something like that. The above makes me think that focusing on the revision range notation
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: Have you ever seen me saying it sounds like a good idea to a solution that is looking for a problem? ;-) I'll try to avoid that approach in the future. diff A...B works already, and stopping to refer to diff A..B (the documentation patch you sent out) hopefully will make it less confusing. I do not see a huge upside in replacing it with yet another notation people need to learn (and possibly make them unlearn a working notation). The downside of it feels far worse. So, my question is about whether A..B is really that confusing. We might exploit the differences between .. and ... in all the commands, and document it properly. We just have to stop calling .. and ... canonical range commands. We can stick to overriding these two for now. What does consistency even mean? What does it mean for rebase A..B to have logical similarity to log A..B? If this similarity cannot be precisely defined, consistency is just an illusion. Not very interested [*0*], but I haven't thought things through. Yeah, neither have I. I'm asking for input. In order to express only what we can currently express (i.e. not extending for a DAG with a single bottom and multiple refs at tops), I think it is sufficient to allow rebase [--onto=$there] origin.. [*1*]; we can infer what ref is being rebased from the range we get from the command line by asking rev_cmdline, and it may be more natural to people who grew up with git log origin... That's fine. The tricky part is: what is it rebased onto? origin? That approach would express the DAG with the usual revision range specifier on the command line, limited to those range notations that have a single bottom and a single top. That range defines the DAG that will be replayed, and its single top defines what ref is updated as the result. Okay. When --onto is not specified, we could choose to use two- vs three- dot notations to select what onto to use by default [*2*]. For example, rebase origin.. could be a way to replay your work on top of their work you fetched, while rebase -i origin... could be a way to identify your work since you forked from them, and tweak then without changing the base, i.e. the fork point (the latter of which would match what you would get from diff A...B naturally). If we later want to add a DAG with a single bottom and multiple refs at tops, it could be spelled as rebase --multi --onto=$there ^origin rr/rebase-doc rr/triangle or something [*3*]. I'm an idiot. What I was bouting as consistency was artificial constraints _I_ imposed on the rev spec. Why shouldn't the command behave differently for: 1. One positive and one negative. 2. Multiple positives and one negative. 2.1 When there are two positives, and --multi isn't on. 2.2 When --multi is on. What is it violating? The UI you have proposed is very compelling, although I'm surprised you did it top-down. [Footnote] *0* git rebase master~ would rebase your current history on top of one commit before master, but you could choose to use some line noise character other than tilde. Not urgent. *1* This is similar to the way we taught origin.. and -3 HEAD to format-patch that originally only took origin. Okay. *2* Having said that, I do not particularly like the approach to exploit the difference between two- and three-dot forms and use it in choosing which commit to use as the default onto. It might be more useful to have the distinction between rebase -i and rebase make that decision. Replaying on top of the merge base would not be useful unless we are doing rebase -i (it would be a no-op by definition). From that point of view, rebase origin (or rebase origin.. or rebase origin...), because it is replaying your work on top of others, may use --onto=origin by default. On the other hand, rebase -i origin (or rebase -i origin.. or rebase -i origin...), because you use the command in order to tweak your work, and you mention 'origin' merely to let Git know where your fork point is, may replay on the original fork point it discovers with merge-base. I'll have to think about this. Or something like that. The above makes me think that focusing on the revision range notation is not terribly productive when exploring how to make rebase easier to use to end users. You managed a top-down version quite quickly, while I was stuck at consistency :) *3* --multi is merely an example to make it easy to tell the command line from the traditional form that has an extra switch to this branch before starting anything argument. Cute way of putting it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: The range version of $(git merge-base A B) B is B ^$(git merge-base A B), and not B --not $(git merge-base --all A B) [which is equivalent to B ^A or A..B]. Let me make this easier for you, and everyone else. In git.git, checkout master and merge 9915605c^2 (rr/shortlog-doc). So, my changeset has graduated from 'pu' to 'master' (I know 'master' is directly ahead of 'pu', and this is not what you do; but this is just an exercise). Now, I execute git log master..pu and search for the author Ramkumar Ramachandra. I can see that my shortlog-doc commits aren't present; so I infer that my changes have graduated to master. I can also see the merge commit corresponding to rr/shortlog-doc, and infer that master merged in rr/shortlog-doc differently. If I execute git log pu ^$(git merge-base master pu), I see the merge commit rr/shortlog-doc _and_ the shortlog-doc commits. Here, I don't want to know if my change graduated to master or not: I just want to know what changes were introduced by the pu branch since the last fork. Think of it as a time-truncated version of git log pu: it has nothing to do with reachability. The only reason that master even appears in the command is because I need to specify where pu forked off from. I would argue that this is incredibly useful: to see what changes were introduced by my branch independent of everything else. What do you think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: Think of it as a time-truncated version of git log pu: it has nothing to do with reachability. Er, scratch that out. I don't like talking in vague terms, and this feature has nothing to do with git log --since (which is what time-truncated is). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
I personally think we have enough magic revision syntax to last at least
another decade. If you propose to add some, please make a patch that we
can cook in next for a few release cycles and then conduct a straw poll
if people actually use it.
Isn't it obviously incredibly useful? I'm working on a topic branch I
need to send out to git.git, and I want see how my WIP looks: should I
have to rebase on master just to see this?
Why such a huge resistance against such a small feature? Can you
think of ways in which it is myopic (and therefore a pain to keep
supporting, if we find it undesirable)?
What's the problem with cooking it for a while? You can start using it
immediately. I'm just somewhat annoyed that the syntax is rapidly
converging to Perl-style line noise.
I already hate half of the existing syntax, and I cannot remember using
^! (except while investigating what 'git diff C^!' does and why not),
^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},
^{}, :/foo, and ^{/foo}, *at all*.
In fact I had to look up the second half of that list on the manpage.
That's not to say that they are not useful for *someone*. But it does
motivate my suggestion that unless we have tried it and *found* that
someone for a new syntax, let's not make it any more magic.
On a related note- In my opinion, :/ is broken, because it blocks
composition completely. I would've really liked {:/quuxery}~3.
I guess this constitutes an argument in my favor (i.e. that the syntax
is too convoluted to understand and know):
^{/foo} is the same as :/foo, except it properly groups.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Okay, so the point I was trying to make is: The range version of $(git merge-base A B) B is B ^$(git merge-base A B), and not B --not $(git merge-base --all A B) [which is equivalent to B ^A or A..B]. Junio C Hamano wrote: I dunno. The description you gave was insufficient for me to answer that question. Sorry about that. I'll rewrite it as a set of commands: $ cd /tmp $ git clone gh:artagnon/clayoven $ cd clayoven $ git checkout -b pu master~10 $ echo foom LICENSE $ git commit -a -m Change in pu $ git checkout -b rebase.autostash master~5 $ echo loom clayoven.gemspec $ git commit -a -m Change in rebase.autostash $ git checkout master $ git merge pu $ git checkout rebase.autostash $ git merge pu $ echo quux Gemfile $ git commit -a -m Change 2 in rebase.autostash $ git log rebase.autostash ^master $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master) $ git log rebase.autostash ^$(git merge-base rebase.autostash master) $ git diff rebase.autostash ^$(git merge-base rebase.autostash master) Note that git diff can only take two endpoints so git merge-base --all is meaningless in this case. To summarize: B ^(git merge-base A B) [the current ... syntax of git diff] has no exact equivalent in the log world. Therefore, no matter which existing rev spec we overload, we can never get the current ... for diff in a consistent manner. We certainly know that 'git diff A~B' is going to be useful, and have an exact equivalent 'git log A~B' (but I'm not sure how useful it will be, because I don't work with merges much). The point is that it can be overloaded in a consistent manner for other commands like 'rebase -i' too. I recently caved to overloading .. [1] because there's so much resistance to inventing a new rev spec. I'm not exactly elated with that. [1]: http://thread.gmane.org/gmane.comp.version-control.git/222343 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Thomas Rast wrote:
I already hate half of the existing syntax, and I cannot remember using
^! (except while investigating what 'git diff C^!' does and why not),
^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},
^{}, :/foo, and ^{/foo}, *at all*.
I'm actually totally in love with the existing syntax (with the
possible exception of :/). I think it's extremely terse and
expressive. People who don't care about such flexibility and power
can stick to using ~ and ^. Enabling other users with additional
syntax doesn't harm them in any way.
^{/foo} is the same as :/foo, except it properly groups.
No, not at all. First of all, ^{/foo} is invalid: you need to specify
a ref to dig through, like HEAD^{/foo}. OTOH, :/foo returns a match
from any ref.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: $ git diff rebase.autostash ^$(git merge-base rebase.autostash master) So, Thomas pointed out on IRC that there is one edge-case: a criss-cross merge. So, we can define A~B as B ^$(git-merge-base --closest-to=B A B). If both A and B are equidistant from the criss-cross merge [will that ever happen in practice?], we have no choice but to error out. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Thomas Rast tr...@inf.ethz.ch writes:
What's the problem with cooking it for a while? You can start using it
immediately. I'm just somewhat annoyed that the syntax is rapidly
converging to Perl-style line noise.
Not quite, not quite, and a mild agreement.
Adding an obscure feature that may not be useful at all behind a
command line option will fall into the you can afford to cook for a
while, you can use it immediately yourself, nobody will get hurt
category. Adding a configuration to turn such a feature by default
on already is a more severe problem because we need to adjust and
protect scripted Porcelains from getting hurt by an unexpected new
behaviour user may trigger by setting such a configuration before it
fully cooks, which is annoying maintenance burden for an obscure
feature with an unknown value.
Piling cruft on syntax is in a totally different league. If not
carefully thought out, adding a random new syntax on a whim can
paint us into a corner we cannot later get out of, like the :/ we
recently discussed (which does have an escape hatch planned, but
imagine a world without one).
I already hate half of the existing syntax, and I cannot remember using
^! (except while investigating what 'git diff C^!' does and why not),
^@, @{-N} (only the related 'git checkout -'), @{date} and @{relative},
^{}, :/foo, and ^{/foo}, *at all*.
In fact I had to look up the second half of that list on the manpage.
I would have actually expected that people are more familiar with
the second half, i.e. @{2.weeks.ago}, @{4} and :/string, than ^!/^@
which I agree were more-or-less let's add a random cruft on a whim
without thinking things through mistakes.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: than ^!/^@ which I agree were more-or-less let's add a random cruft on a whim without thinking things through mistakes. I thought ^@ was invented for scripting, but can't imagine a usecase for ^!. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: I thought ^@ was invented for scripting, but can't imagine a usecase for ^!. I use git diff $commit^! from time to time to get the diff between a merge and its first parent. For comparison, I haven't found ^@ or git log $commit^! useful. The commit introducing the former says | I needed it to do the multi-tree diff on Len's infamous 12-way | Octopus; typing diff --cc funmerge funmerge^1 funmerge^2 funmerge^3 | ... was too painful. which is spelled as git show --cc funmerge these days. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Jonathan Nieder jrnie...@gmail.com writes: Ramkumar Ramachandra wrote: I thought ^@ was invented for scripting, but can't imagine a usecase for ^!. I use git diff $commit^! from time to time to get the diff between a merge and its first parent. For comparison, I haven't found ^@ or git log $commit^! useful. The commit introducing the former says | I needed it to do the multi-tree diff on Len's infamous 12-way | Octopus; typing diff --cc funmerge funmerge^1 funmerge^2 funmerge^3 | ... was too painful. which is spelled as git show --cc funmerge these days. The more important part of the message comes before that part ;-) This might be just my shiny new toy that is not very useful in practice. I needed it to do the multi-tree diff on Len's ... So I was right --- from the very beginning, this was let's add a random cruft on a whim without thinking things through as I said. It is not satisfactory to be right in saying that I am sure this was a stupid mistake X-. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Highly inconsistent diff UI
Hi,
The 'git diff commit commit' form is perfectly fine: I can
understand that diff takes two commit^{tree}s to compare.
Unfortunately, it also shows off the examples 'git diff A..B' and 'git
diff A...B', where A..B and A...B do not correspond to the meaning
specified in gitrevisions.txt. There's a note in the documentation
saying this, but I'm very unhappy.
I can understand that rev-parse parses A..B into ^A B. 'git diff
A..B' is the same as 'git diff A B', 'git diff B ^A', and 'git diff ^A
B'? (Yeah, I saw the code and found out that it swaps the arguments
only if the second argument is UNINTERESTING)
rev-parse parses A...B into A B ^$(merge-base --all A B). But 'git
diff A...B' means 'git diff $(git merge-base A B) B'? And the
merge-base is picked at random (found out that from the code)?
What about other things like 'git diff ^A ^B' and 'git diff A^!'? Why
is diff so inconsistent with everything else? Why are A..B and A...B
almost coded in as special cases? What should we do to improve the
situation?
Thanks for listening.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: What should we do to improve the situation? The first thing to do is to eradicate diff A..B from the documentation, and a dozen or more lines in your complaint will go away with that single change. As you know, diff is about two endpoints, and A..B is not a way to specify two endpoints, and not erroring it out whenever we see a negative revision is a mere courtesy to old timers who knew the command line parser was shared with rev-list machinery. There is no reason to forbid the syntax, but encouraging its use is counterproductive and will lead to confusions to new people as you pointed out. The only issue is to come up with a concise alternative way to express diff A...B, perhaps diff --compare-with-base A B, and then you can choose not to say anything but an object name (and no range notation) on the command line (if you do not diff A...B, it can already be done by not using diff A..B). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: The first thing to do is to eradicate diff A..B from the documentation, and a dozen or more lines in your complaint will go away with that single change. As you know, diff is about two endpoints, and A..B is not a way to specify two endpoints, and not erroring it out whenever we see a negative revision is a mere courtesy to old timers who knew the command line parser was shared with rev-list machinery. There is no reason to forbid the syntax, but encouraging its use is counterproductive and will lead to confusions to new people as you pointed out. Excellent. I agree wholeheartedly with this reasoning. The only issue is to come up with a concise alternative way to express diff A...B, perhaps diff --compare-with-base A B, and then you can choose not to say anything but an object name (and no range notation) on the command line (if you do not diff A...B, it can already be done by not using diff A..B). What are your thoughts on inventing a new syntax A~B = $(git merge-base A B) B which can be used by both range commands like log and non-range commands like diff ? (In other words, why shouldn't log be able to do this?). Does it matter which merge base we pick though? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: What are your thoughts on inventing a new syntax A~B = $(git merge-base A B) B which can be used by both range commands like log and non-range commands like diff ? (In other words, why shouldn't log be able to do this?). The idea for a new syntax to denote a merge base may be an interesting one. log is inherently about ranges, so you do not need a new operator to denote a merge base. Between log A..B and log A...B with or without --left-right, --left-only and --right-only, you should be able to ask questions about histories leading to commit A and B without having to worry about a single merge base between A and B, no? So I do not think A~B would help log. Because diff is inherently about endpoints, you DO have to have a single merge base that gives you a point to compare something else against. The reason why diff A...B was invented was primarily because we wanted to avoid having to say A twice on the command line, be it diff $(git merge-base A B) B or diff A~B B. In other words, A~B will not help diff at all, either [*1*]. There isn't always a single merge base between an arbitrary pair of commits (there may be 0, or 2 or more). When used in the context of diff A...B, we know that the user is more interested in using one merge base (among possibly many) to get some diff, than seeing the command fail [*2*]. Taking that as a context cue, diff A...B can (and did) choose to use one picked at random, even though the design is fully aware that the chosen one may not be the best one. A generic A~B syntax implemented at the revision parser level may not have that luxury of assuming that it is fine to pick any, and may have to fail when there is not a unique merge-base. [Footnote] *1* That does not mean nobody needs that syntax. It just means that it is still a solution looking for a problem. *2* Otherwise the user can more carefully script what he wants to do using the merge-base command himself, choosing to do different things when there are 0, or 2 or more merge bases. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
On Wed, Apr 24, 2013 at 11:41 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
What are your thoughts on inventing a new syntax A~B = $(git
merge-base A B) B which can be used by both range commands like log
and non-range commands like diff ? (In other words, why shouldn't log
be able to do this?).
The idea for a new syntax to denote a merge base may be an
interesting one.
Sorry I wasn't clear. A~B = $(git merge-base A B) B to diff and $(git
merge-base A B)..B to log. I don't mind a hybrid command as long as
we document it properly. rev-parse will parse it into B ^${git
merge-base A B) just fine. Implementation: diff should swap the
arguments if the second argument is UNINTERESTING: it already does
this :)
Basically, I want to be able to do git log master~rebase.autostash
(without having to rebase). I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
What do you think?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: I'm also considering making the first argument optional (just git log ~rebase.autostash), and defaulting to mean [nearest fork point]. Actually both can be optional. In A~B, A defaults to [nearest fork point] and B defaults to HEAD. git log ~ Isn't it beautiful? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Ramkumar Ramachandra wrote: I'm also considering making the first argument optional (just git log ~rebase.autostash), and defaulting to mean [nearest fork point]. Actually both can be optional. In A~B, A defaults to [nearest fork point] and B defaults to HEAD. git log ~ Isn't it beautiful? I now have to go and wash my eyes. You will stay in my killlist for the coming few days ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: You will stay in my killlist for the coming few days ;-). Now, now. What is your objection, objectively? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
Actually both can be optional. In A~B, A defaults to [nearest fork
point] and B defaults to HEAD.
git log ~
Isn't it beautiful?
Please don't. The syntax you propose doesn't work for several reasons,
but do we really need one? How often would you actually use it?
Ok, since you ask, the reasons are:
* Looking for the nearest fork point is expensive and subject to change
by simply fetching. I hope you meant ... and exclude its upstream,
i.e., A defaults to @{u}, which might be at least somewhat useful.
* ~ is already taken; in your syntax, A~1234567 is ambiguous because
1234567 can both be a SHA1 and a number of generations to go back.
I personally think we have enough magic revision syntax to last at least
another decade. If you propose to add some, please make a patch that we
can cook in next for a few release cycles and then conduct a straw poll
if people actually use it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Thomas Rast wrote:
* Looking for the nearest fork point is expensive and subject to change
by simply fetching. I hope you meant ... and exclude its upstream,
i.e., A defaults to @{u}, which might be at least somewhat useful.
I'm not proposing anything different from :/ in this aspect.
* ~ is already taken; in your syntax, A~1234567 is ambiguous because
1234567 can both be a SHA1 and a number of generations to go back.
I'm not married to ~. It can be any character.
I personally think we have enough magic revision syntax to last at least
another decade. If you propose to add some, please make a patch that we
can cook in next for a few release cycles and then conduct a straw poll
if people actually use it.
Isn't it obviously incredibly useful? I'm working on a topic branch I
need to send out to git.git, and I want see how my WIP looks: should I
have to rebase on master just to see this?
Why such a huge resistance against such a small feature? Can you
think of ways in which it is myopic (and therefore a pain to keep
supporting, if we find it undesirable)?
On a related note- In my opinion, :/ is broken, because it blocks
composition completely. I would've really liked {:/quuxery}~3.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Sorry I wasn't clear. A~B = $(git merge-base A B) B to diff and $(git merge-base A B)..B to log. Basically, I want to be able to do git log master~rebase.autostash (without having to rebase). How is it different from git log master..rebase.autostash? git log A..B is already a perfectly fine way to spell your A~B, which is git log B --not $(git merge-base --all A B) when written in longhand [*1*], no? So I do not think your A~B helps log. It does not help diff either, because we already have A...B and we are not going to remove it (people are used to what it means). So I think your A~B is still a solution that is looking for a problem. [Footnote] *1* You need to understand what merge-base is in order to analyse the equivalence of these two. A..B asks for those that are reachable from B that are not reachable from A. What does the other form ask, by saying ones that can be reached from B but exclude the ones that are reachable from any merge base of A and B? On the history leading to A, there are two kinds of commits: those that are not reachable from B and those that are. The ones closer to A may not be reachable from B but if you dig the history starting from A and keep finding ancestors, you will eventually hit one that can be reached from B. Once you hit such a commit, everything beyond that point are reachable from both A and B. E.g. ---o---*---a---a---a---A \ b---b---B And we call that a merge base between A and B (e.g. '*'). Any ancestor of a merge base, e.g. 'o', is reachable from A and is excluded from A..B. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
On Wed, Apr 24, 2013 at 3:00 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Ramkumar Ramachandra wrote: I'm also considering making the first argument optional (just git log ~rebase.autostash), and defaulting to mean [nearest fork point]. Actually both can be optional. In A~B, A defaults to [nearest fork point] and B defaults to HEAD. git log ~ Isn't it beautiful? Sure, but we'll forever be explaining to users that they will need to quote the tilde to avoid shell expansion. $ echo ~ ~ ~ ~ /home/hordp ~ P -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: You will stay in my killlist for the coming few days ;-). Now, now. What is your objection, objectively? I do not think any further explanation is necessary. My Git time is more useful to the Git development community than educating somebody with demonstrated lack of design taste by calling the log ~ that has an irregular default beautiful. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: My Git time is more useful to the Git development community than educating somebody with demonstrated lack of design taste by calling the log ~ that has an irregular default beautiful. Why are you caught up in the character and the defaults (I just put down the first thing that came to my mind)? What I'm calling beautiful is the idea to be able to tersely express I want to know what changes I made to this branch. We can change the character and the defaults; do you think the feature is useful? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Junio C Hamano wrote: How is it different from git log master..rebase.autostash? git log A..B is already a perfectly fine way to spell your A~B, which is git log B --not $(git merge-base --all A B) when written in longhand [*1*], no? So I do not think your A~B helps log. They are equivalent if you use --all, which I didn't originally propose. I'll present a slightly contrived example, because I don't personally merge much in the real world: pu is based on master~10. rebase.autostash is based on master~5 and master~3 merges in pu. I merge pu into rebase.autostash while working. Now, master..rebase.autostash will exclude commits reachable from master (and therefore pu), but master~rebase.autostash will show the commits in pu that I merged in. Ofcourse, I now see that this is probably useless, and .. fits my bill. When packaged with a good default for LHS (which .. currently doesn't have), it might be a slightly better candidate. I was thinking origin instead of [nearest-fork-commit]. It does not help diff either, because we already have A...B and we are not going to remove it (people are used to what it means). Yeah, the invention arose as way to find a replacement for this inconsistency. So I think your A~B is still a solution that is looking for a problem. Yeah, so it looks like the problem is entirely a minor cosmetic detail: we're just clothing existing functionality with a consistent new refspec. We might still want it. I mean what are we losing? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote:
Ofcourse, I now see that this is probably useless, and .. fits my bill.
Would you find it potentially useful? You do a lot of merging
back-and-fourth juggling feature branches, pu, next, master.
When packaged with a good default for LHS (which .. currently doesn't
have), it might be a slightly better candidate. I was thinking origin
instead of [nearest-fork-commit].
Er, I meant HEAD@{u}, not origin. HEAD@{u}~HEAD doesn't sound like a
bad default at all.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra wrote: We might still want it. I mean what are we losing? Actually, let's just look at extending the rev specs we currently have. I'll gather up a list of real itches and post it to the list. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Highly inconsistent diff UI
Ramkumar Ramachandra artag...@gmail.com writes: Ramkumar Ramachandra wrote: Ofcourse, I now see that this is probably useless, and .. fits my bill. Would you find it potentially useful? I dunno. The description you gave was insufficient for me to answer that question. The part of your message that outlines the scenario you thought A~B might help you was read by me like the following. pu is based on master~10. rebase.autostash is based on master~5 and master~3 merges in pu. So which one is 'pu' based on? master~10, or master~3? You cannot have both. I merge pu into rebase.autostash while working. So from pu the top two commit on 'master' are missing, but your branch was forked way before that from 'master', so these two do not concern you. Now, master..rebase.autostash will exclude commits reachable from master (and therefore pu), Whoa. Earlier you said 'pu' is based on master~10, but changed your mind to say master~3 is in 'pu', and now you mean the tip of 'master' is also in 'pu'? What is going on? Can you draw a picture to illustrate the topology you are trying to describe, like I did in a few message upthread? E.g. ---o---*---a---a---a---a---A (master) \ \ b---Y---X---B (topic) / shows a topic B that forked from master and merged from irrelevant branch at Y and merged from master at X [*1*]. In the above sample topology, even if you pulled irrelevant (for the purpose of completing your topic) commits at X from 'master', neither log A..B or log $(merge-base A B)..B (aka log A~B) would exclude any of your commit that is not yet in the 'master', so I do not think there is anything you gain by using A~B over A..B. If you pulled something unrelated to your topic that is not in 'master', both log A..B and log A~B would show these unrelated changes, so again I do not see how A~B would help you over A..B, either. Perhaps in a particular topology you have in mind, it might make a difference, but I cannot read what that topology is from your description. [Footnote] *1* I do not think this particular topology is what you have in mind. It is meant to demonstrate one way to illustrate the history to help other people understand the example you are trying to give. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
