potential improvement to 'git log' with a range

potential improvement to 'git log' with a range

[Aghiles]

If I type:

    git log FETCH_HEAD~4..HEAD

I get something. But if I type:

    git log HEAD..FETCH_HEAD~4

I get nothing. Is there a good reason for that ?

  -- aghiles

Re: potential improvement to 'git log' with a range

[Santi Béjar]

On Sat, Apr 10, 2010 at 1:24 AM, Aghiles <aghilesk@gmail.com> wrote:
> If I type:
>
>    git log FETCH_HEAD~4..HEAD
>
> I get something. But if I type:
>
>    git log HEAD..FETCH_HEAD~4
>
> I get nothing. Is there a good reason for that ?
>

Yes.

$ git log -h
usage: git log [<options>] [<since>..<until>] [[--] <path>...]

So <since> and <until> are not equivalent. It list commits in <until>
but not in <since>.

In your case HEAD has commits not in FETCH_HEAD~4 (your first command)
while FETCH_HEAD~4 does not have commits not in HEAD. So HEAD is a
descendent of FETCH_HEAD~4.

Hope I didn't misunderstood your question.

HTH,
Santi

Re: potential improvement to 'git log' with a range

[Sverre Rabbelier]

Heya,

On Sat, Apr 10, 2010 at 01:24, Aghiles <aghilesk@gmail.com> wrote:
> If I type:
>
>    git log FETCH_HEAD~4..HEAD
>
> I get something. But if I type:
>
>    git log HEAD..FETCH_HEAD~4
>
> I get nothing. Is there a good reason for that ?

Yes, read up on the documentation as to what ".." means. Hint, a \ b
is not the same as b \ a [0].

[0] http://en.wikipedia.org/wiki/Intersection_(set_theory)

-- 
Cheers,

Sverre Rabbelier

Re: potential improvement to 'git log' with a range

[Aghiles]

Sverre Rabbelier <srabbelier@gmail.com> wrote:
>
> Yes, read up on the documentation as to what ".." means. Hint, a \ b
> is not the same as b \ a [0].
>
> [0] http://en.wikipedia.org/wiki/Intersection_(set_theory)
>

Oh, I should have read the documentation. I was certain that ".." stands
for a range but it is a ... complement.

Thanks for you help.

  -- aghiles

Re: potential improvement to 'git log' with a range

[Sverre Rabbelier]

Heya,

On Sat, Apr 10, 2010 at 02:13, Aghiles <aghilesk@gmail.com> wrote:
> Oh, I should have read the documentation. I was certain that ".." stands
> for a range but it is a ... complement.

Err, yes, sorry, wrong link, should have been [0] :). Teaches me for
copy/pasting links from [1] without checking what I copy/paste,
they're right next to eachother :)

[0] http://en.wikipedia.org/wiki/Complement_(set_theory)
[1] http://en.wikipedia.org/wiki/Set_theory

-- 
Cheers,

Sverre Rabbelier

Re: potential improvement to 'git log' with a range

[Linus Torvalds]

On Fri, 9 Apr 2010, Aghiles wrote:
> 
> Oh, I should have read the documentation. I was certain that ".." stands
> for a range but it is a ... complement.

Well, technically ".." means two different things

 - for "set operations" (ie "git log" and friends) it's the "relative 
   complement" of two sets (or "'reachable from A' \ 'reachable from B'").

 - for "edge operations" (ie "git diff" and friends) it's just two 
   end-points (aka "range"). A diff doesn't work on sets, it only works on 
   the two endpoints.

It's arguably a bit confusing, but quite frankly, the room for confusion 
is very small, and the biggest source of confusion is probably not so much 
that ".." means two different things in two (clearly different) contexts, 
as much as just the fact that people aren't used to thinking in terms of 
set operations at all. 

Most SCM's really talk about "ranges". Once you think in those terms, 
complex history doesn't work. Git very fundamentally is much about set 
theory, and "ranges" is a bad word to use.

To make things even more exciting triple-dot, "A...B" has two different 
meanings too, again one that is about sets ("symmetric difference") for 
the log-based ones, and one that is a somewhat badly defined range for the 
diff based ones (where the end-points are "one common nearest ancestor of 
A and B" and "B" respectively).

It's all actually very natural when you get used to it, although that 
"A...B" as a range really isn't well-defined, since there can be more than 
one common nearest ancestors. It's still often enough useful in practice 
that I wouldn't get rid of it, but it's not the greatest feature.

		Linus

Re: potential improvement to 'git log' with a range

[Aghiles]

On Fri, Apr 9, 2010, Linus Torvalds wrote:
> Well, technically ".." means two different things
>
>  - for "set operations" (ie "git log" and friends) it's the "relative
>   complement" of two sets (or "'reachable from A' \ 'reachable from B'").
>
>  - for "edge operations" (ie "git diff" and friends) it's just two
>   end-points (aka "range"). A diff doesn't work on sets, it only works on
>   the two endpoints.

OK.

> Most SCM's really talk about "ranges". Once you think in those terms,
> complex history doesn't work. Git very fundamentally is much about set
> theory, and "ranges" is a bad word to use.

I see how ranges are not powerful enough for complex history. It is just
that for me (and maybe for some others), the ".." sign has a strong
association with "range".

Thank you very much for the explanation,

  -- aghiles

Re: potential improvement to 'git log' with a range

[Jakub Narebski]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Fri, 9 Apr 2010, Aghiles wrote:
> > 
> > Oh, I should have read the documentation. I was certain that ".." stands
> > for a range but it is a ... complement.
> 
> Well, technically ".." means two different things
> 
>  - for "set operations" (ie "git log" and friends) it's the "relative 
>    complement" of two sets (or "'reachable from A' \ 'reachable from B'").
> 
>  - for "edge operations" (ie "git diff" and friends) it's just two 
>    end-points (aka "range"). A diff doesn't work on sets, it only works on 
>    the two endpoints.

[...]
> Most SCM's really talk about "ranges". Once you think in those terms, 
> complex history doesn't work. Git very fundamentally is much about set 
> theory, and "ranges" is a bad word to use.

For example from I have got from asking on #mercurial IRC channel on
FreeNode (a bit of self promotion: I have done this research to write
an answer to "Git and Mercurial - Compare and Contrast" question on
StackOverflow[1]), Mercurial implements its ".." equivalent in the
term of _numeric range_, even for "hg log" (sic!).  It turns revision
identifiers used in range (-r <rev1>:<rev2>) to LOCAL number of
revision, and generates range based on numeric range, IIRC inclusive
on both sides (in Git range is exclusive from bottom, inclusive from
top).

Which is plain useless for anything but linear subsets of history
(compare e.g. "master..next", which in Git shows everything in "next"
that is not in "master"; "master" and "next" are not direct
descendants of one oanother, at least not usually).

[1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930

P.S. I wonder if Mercurial development list is subscribe-only...
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: potential improvement to 'git log' with a range

[Martin Geisler]

[-- Attachment #1.1: Type: text/plain, Size: 1581 bytes --]

Jakub Narebski <jnareb@gmail.com> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Fri, 9 Apr 2010, Aghiles wrote:
>> >
>> > Oh, I should have read the documentation. I was certain that ".."
>> > stands for a range but it is a ... complement.
>>
>> Well, technically ".." means two different things
>>
>>  - for "set operations" (ie "git log" and friends) it's the "relative
>>    complement" of two sets (or "'reachable from A' \ 'reachable from B'").
>>
>>  - for "edge operations" (ie "git diff" and friends) it's just two
>>    end-points (aka "range"). A diff doesn't work on sets, it only
>>    works on the two endpoints.
>
> [...]
>> Most SCM's really talk about "ranges". Once you think in those terms,
>> complex history doesn't work. Git very fundamentally is much about
>> set theory, and "ranges" is a bad word to use.
>
> For example from I have got from asking on #mercurial IRC channel on
> FreeNode (a bit of self promotion: I have done this research to write
> an answer to "Git and Mercurial - Compare and Contrast" question on
> StackOverflow[1]), Mercurial implements its ".." equivalent in the
> term of _numeric range_, even for "hg log" (sic!).

This is fixed with Mercurial 1.6: we now have a query language where
'X..Y' (or 'X::Y') is understood as the set of changesets that are both
descendents of X and ancestors of Y.

> [1]
> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930


-- 
Martin Geisler

Mercurial links: http://mercurial.ch/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

Re: potential improvement to 'git log' with a range

[Jakub Narebski]

On Wed, 23 Jun 2010, Martin Geisler wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>>
>>> Well, technically ".." means two different things
>>>
>>>  - for "set operations" (ie "git log" and friends) it's the "relative
>>>    complement" of two sets (or "'reachable from A' \ 'reachable from B'").
>>>
>>>  - for "edge operations" (ie "git diff" and friends) it's just two
>>>    end-points (aka "range"). A diff doesn't work on sets, it only
>>>    works on the two endpoints.
>>
>> [...]
>>> Most SCM's really talk about "ranges". Once you think in those terms,
>>> complex history doesn't work. Git very fundamentally is much about
>>> set theory, and "ranges" is a bad word to use.
>>
>> For example from I have got from asking on #mercurial IRC channel on
>> FreeNode (a bit of self promotion: I have done this research to write
>> an answer to "Git and Mercurial - Compare and Contrast" question on
>> StackOverflow[1]), Mercurial implements its ".." equivalent in the
>> term of _numeric range_, even for "hg log" (sic!).
> 
> This is fixed with Mercurial 1.6: we now have a query language where
> 'X..Y' (or 'X::Y') is understood as the set of changesets that are both
> descendents of X and ancestors of Y.

Thanks.  It looks like Mercurial's 'X::Y' is equivalent to Git's 
'--ancestry-path X..Y' (the --ancestry-path option is a new feature).
 
>> [1]
>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930

Fixed.  Could you please take a look if it is correct, and if there
are errors, either correct it yourself, or ask me to do it (either via
comments for this question, or via email)?  Thanks in advance.

P.S. Isn't mercurial-devel subscribe only?
-- 
Jakub Narebski
Poland

Re: potential improvement to 'git log' with a range

[Martin Geisler]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Jakub Narebski <jnareb@gmail.com> writes:

> On Wed, 23 Jun 2010, Martin Geisler wrote:
>
>> This is fixed with Mercurial 1.6: we now have a query language where
>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are
>> both descendents of X and ancestors of Y.
>
> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's
> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).

Yeah, it is equivalent to --ancestry-path. I had no idea Git's range
operator worked the way it does :-)

For mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn
means ancestors of Y, excluding ancestors of X (and excluding X).

>>> [1]
>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
>
> Fixed. Could you please take a look if it is correct, and if there are
> errors, either correct it yourself, or ask me to do it (either via
> comments for this question, or via email)? Thanks in advance.

Yes, its correct now. But would you object if I or someone else took out
all those personal opinions and rewrote it from a neutral point of view?

> P.S. Isn't mercurial-devel subscribe only?

No, not really -- you will be whitelisted the first time you post.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: potential improvement to 'git log' with a range

[Jakub Narebski]

On Wed, 23 Jun 2010, Martin Geisler wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Wed, 23 Jun 2010, Martin Geisler wrote:
>>
>>> This is fixed with Mercurial 1.6: we now have a query language where
>>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are
>>> both descendents of X and ancestors of Y.
>>
>> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's
>> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).
> 
> Yeah, it is equivalent to --ancestry-path. I had no idea Git's range
> operator worked the way it does :-)
> 
> For mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn
> means ancestors of Y, excluding ancestors of X (and excluding X).

Err... so how it is for X..Y / X::Y in Mercurial?  "Ancestors of Y, 
excluding ancestors of X" is larger range (and default result for
X..Y in Git) than "descendants of X and ancestors of Y" (i.e. the
result of new --ancestry-path X..Y in Git).

See http://repo.or.cz/w/git.git/blob/refs/heads/pu:/Documentation/rev-list-options.txt#l582

>>>> [1]
>>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
>>
>> Fixed. Could you please take a look if it is correct, and if there are
>> errors, either correct it yourself, or ask me to do it (either via
>> comments for this question, or via email)? Thanks in advance.
> 
> Yes, its correct now. But would you object if I or someone else took out
> all those personal opinions and rewrote it from a neutral point of view?

Well, I do provide disclaimer upfront that I am biased towards Git, and
I have tried to be objective.

But I don't mind if someone who uses Mercurial fixed that side, and
tried for neutral point of view (but not introducing the opposite bias).
There would be problem with NPOV with issues without clear answer, where
personal preference matters, though.

>> P.S. Isn't mercurial-devel subscribe only?
> 
> No, not really -- you will be whitelisted the first time you post.

Nice.

-- 
Jakub Narebski
Poland

Re: potential improvement to 'git log' with a range

[Martin Geisler]

[-- Attachment #1: Type: text/plain, Size: 2812 bytes --]

Jakub Narebski <jnareb@gmail.com> writes:

Hi Jakub,

By the way: please let me know if you prefer that I keep these mails on
Mercurials mailinglist. I've just had a long chat about it with our own
moderator and he felt it was rude to cross-post like this. I, on the
other hand, value a polite cross-list discussion like this.

> On Wed, 23 Jun 2010, Martin Geisler wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> On Wed, 23 Jun 2010, Martin Geisler wrote:
>>>
>>>> This is fixed with Mercurial 1.6: we now have a query language where
>>>> 'X..Y' (or 'X::Y') is understood as the set of changesets that are
>>>> both descendents of X and ancestors of Y.
>>>
>>> Thanks. It looks like Mercurial's 'X::Y' is equivalent to Git's
>>> '--ancestry-path X..Y' (the --ancestry-path option is a new feature).
>> 
>> Yeah, it is equivalent to --ancestry-path. I had no idea Git's range
>> operator worked the way it does :-)
>> 
>> For mercurial-devel: 'X..Y' is a shorthand for '^X Y', which in turn
>> means ancestors of Y, excluding ancestors of X (and excluding X).
>
> Err... so how it is for X..Y / X::Y in Mercurial? "Ancestors of Y,
> excluding ancestors of X" is larger range (and default result for X..Y
> in Git) than "descendants of X and ancestors of Y" (i.e. the result of
> new --ancestry-path X..Y in Git).

I described Git's X..Y for people on mercurial-devel. Mercurial's X..Y
is like Git's --ancestry-path X..Y (except that Mercurial include both
endpoints whereas Git excludes X).

Mercurial's X..Y behave the way it does because it felt natural and
because I though Git's X..Y behaved that way.

> See http://repo.or.cz/w/git.git/blob/refs/heads/pu:/Documentation/rev-list-options.txt#l582

Yes, that was the document I read in order to see how Git's X..Y works.

>>>>> [1]
>>>>> http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
>>>
>>> Fixed. Could you please take a look if it is correct, and if there
>>> are errors, either correct it yourself, or ask me to do it (either
>>> via comments for this question, or via email)? Thanks in advance.
>> 
>> Yes, its correct now. But would you object if I or someone else took
>> out all those personal opinions and rewrote it from a neutral point
>> of view?
>
> Well, I do provide disclaimer upfront that I am biased towards Git,
> and I have tried to be objective.
>
> But I don't mind if someone who uses Mercurial fixed that side, and
> tried for neutral point of view (but not introducing the opposite
> bias). There would be problem with NPOV with issues without clear
> answer, where personal preference matters, though.

Great, then I may edit it a bit sometime...

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: potential improvement to 'git log' with a range

[Jay Soffian]

On Fri, Apr 9, 2010 at 9:20 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> To make things even more exciting triple-dot, "A...B" has two different
> meanings too, again one that is about sets ("symmetric difference") for
> the log-based ones, and one that is a somewhat badly defined range for the
> diff based ones (where the end-points are "one common nearest ancestor of
> A and B" and "B" respectively).
>
> It's all actually very natural when you get used to it, although that
> "A...B" as a range really isn't well-defined, since there can be more than
> one common nearest ancestors. It's still often enough useful in practice
> that I wouldn't get rid of it, but it's not the greatest feature.

Speaking of which, I'd love a switch to "git show $merge_commit" which
does "git log $merge_commit^..$merge_commit^2" but I've been too lazy
to write it. 9/10 times that I use .., it's in this context. :-)

j.

Re: potential improvement to 'git log' with a range

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> Speaking of which, I'd love a switch to "git show $merge_commit" which
> does "git log $merge_commit^..$merge_commit^2" but I've been too lazy
> to write it. 9/10 times that I use .., it's in this context. :-)

Doesn't "git show -p --first-parent $merge" work for you?

Re: potential improvement to 'git log' with a range

[Jay Soffian]

On Wed, Jun 23, 2010 at 4:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Speaking of which, I'd love a switch to "git show $merge_commit" which
>> does "git log $merge_commit^..$merge_commit^2" but I've been too lazy
>> to write it. 9/10 times that I use .., it's in this context. :-)
>
> Doesn't "git show -p --first-parent $merge" work for you?

I don't understand at all. Isn't -p redundant with git show? And how
is --first-parent $merge equivalent to
$merge_commit^..$merge_commit^2? I literally want a list of all the
commits brought in by the merge.

Confusedly yours,

j.

Re: potential improvement to 'git log' with a range

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Speaking of which, I'd love a switch to "git show $merge_commit" which
>> does "git log $merge_commit^..$merge_commit^2" but I've been too lazy
>> to write it. 9/10 times that I use .., it's in this context. :-)
>
> Doesn't "git show -p --first-parent $merge" work for you?

Heh, this is a totally different operation to compare the tree before and
after the merge.

What "log merge^..merge^2" does is to list the commits we merged from the
point of view of the person who did the merge.  I haven't found the need
for a short-cut for that myself, but in any case, I think such a feature
belongs less to "show" (which is about "inspecting a single object") than
to "log" (which is about "give me the sequence").

You may want to look into merge.log variable if you find yourself wanting
to do that often with your history, though.

Re: potential improvement to 'git log' with a range

[Jay Soffian]

On Thu, Jun 24, 2010 at 4:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Heh, this is a totally different operation to compare the tree before and
> after the merge.
>
> What "log merge^..merge^2" does is to list the commits we merged from the
> point of view of the person who did the merge.  I haven't found the need
> for a short-cut for that myself, but in any case, I think such a feature
> belongs less to "show" (which is about "inspecting a single object") than
> to "log" (which is about "give me the sequence").
>
> You may want to look into merge.log variable if you find yourself wanting
> to do that often with your history, though.

Familiar with that and sadly insufficient. My merges often contain
100+ commits which is beyond what merge.log truncates. But more
importantly, I'm often inspecting the commits:

git log ..MERGE_HEAD -Scontent_to_watch_out_for
git log ..MERGE_HEAD -- /path/to/watch/out/for

etc. But sometimes I have to do this type of inspection after the
fact, which is what leads to the merge^..merge^2.

Perhaps the right place for such syntactic sugar would be in
rev-parse. Something like:

o A suffix ^{m..n} (i.e. rev^{1..2}) when rev is a merge commit
expands to rev^m..rev^n and is only valid in contexts that take a
range. 'm' and 'n' may be left out in which case they are assume to be
1 and 2. (i.e rev^{..} is rev^1..rev^2).

But I haven't entirely thought this through. :-)

j.