Hi,
The 'git diff ' 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 t
Ramkumar Ramachandra 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 wa
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
Ramkumar Ramachandra 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
On Wed, Apr 24, 2013 at 11:41 PM, Junio C Hamano wrote:
> Ramkumar Ramachandra 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
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 beaut
Ramkumar Ramachandra 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 default
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/m
Ramkumar Ramachandra 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 default
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.
Ramkumar Ramachandra wrote:
> 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?
Nope. I just do "git log master..topic".
--
To unsubscribe from this list: se
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> 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?
>
> Nope. I just do "git log master..topic".
Why
Ramkumar Ramachandra 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"?
On Wed, Apr 24, 2013 at 3:00 PM, Ramkumar Ramachandra
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 [near
Ramkumar Ramachandra 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 s
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 firs
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 help
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
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
Ramkumar Ramachandra 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 outli
Ramkumar Ramachandra 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 actuall
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
> t
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 i
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-cr
Thomas Rast 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
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
th
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
Jonathan Nieder 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 $comm
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/s
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 fr
On Thu, Apr 25, 2013 at 3:54 AM, Ramkumar Ramachandra
wrote:
> On a related note- In my opinion, :/ is broken, because it blocks
> composition completely. I would've really liked {:/quuxery}~3.
For composition, you should be able to combine a ref set with @{}
syntax, so you can choose to apply @
Ramkumar Ramachandra 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 yo
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
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.
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 m
Ramkumar Ramachandra 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 us
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 commit
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 a
Ramkumar Ramachandra 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 mi
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
39 matches
Mail list logo
