* Question about git-cherry and the rev list it's using
@ 2011-05-11 16:11 Francis Moreau
2011-05-12 6:47 ` Michael J Gruber
0 siblings, 1 reply; 6+ messages in thread
From: Francis Moreau @ 2011-05-11 16:11 UTC (permalink / raw)
To: git
Hello,
I'm using "git cherry old master base" to see if all commits between
master and base have been applied in my 'old' branch.
So I expect that git cherry is using a list of commits given by : "git
rev-list --no-merges base..master".
But it looks like it's not the case:
$ git rev-list --no-merges --oneline base..master | wc -l
22
$ git cherry old master base | wc -l
12
Could anybody help me on this because I don't understand the results I have ?
Thanks
--
Francis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about git-cherry and the rev list it's using
2011-05-11 16:11 Question about git-cherry and the rev list it's using Francis Moreau
@ 2011-05-12 6:47 ` Michael J Gruber
2011-05-13 6:54 ` Francis Moreau
0 siblings, 1 reply; 6+ messages in thread
From: Michael J Gruber @ 2011-05-12 6:47 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
Francis Moreau venit, vidit, dixit 11.05.2011 18:11:
> Hello,
>
> I'm using "git cherry old master base" to see if all commits between
> master and base have been applied in my 'old' branch.
>
> So I expect that git cherry is using a list of commits given by : "git
> rev-list --no-merges base..master".
Not really.
For each commit in "--no-merges old..master ^base" (i.e. "--no-merges
master ^old ^base"), "git cherry" checks whether there is a patch
equivalent commit in "--no-merges master..old", and outputs it with + or -.
> But it looks like it's not the case:
>
> $ git rev-list --no-merges --oneline base..master | wc -l
> 22
>
> $ git cherry old master base | wc -l
> 12
>
> Could anybody help me on this because I don't understand the results I have ?
"--no-merges ^old ^base" should rev-list --count to 12.
But you may be better off with something like
git rev-list --count --cherry master...old ^base
(untested)
Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about git-cherry and the rev list it's using
2011-05-12 6:47 ` Michael J Gruber
@ 2011-05-13 6:54 ` Francis Moreau
2011-05-13 7:02 ` Francis Moreau
0 siblings, 1 reply; 6+ messages in thread
From: Francis Moreau @ 2011-05-13 6:54 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
[ resending to the mailing list too ]
On Thu, May 12, 2011 at 8:47 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Francis Moreau venit, vidit, dixit 11.05.2011 18:11:
>> Hello,
>>
>> I'm using "git cherry old master base" to see if all commits between
>> master and base have been applied in my 'old' branch.
>>
>> So I expect that git cherry is using a list of commits given by : "git
>> rev-list --no-merges base..master".
>
> Not really.
>
> For each commit in "--no-merges old..master ^base" (i.e. "--no-merges
> master ^old ^base"), "git cherry" checks whether there is a patch
> equivalent commit in "--no-merges master..old", and outputs it with + or -.
>
oh you're right, I missed the case when old has been merged in master.
Thanks !
--
Francis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about git-cherry and the rev list it's using
2011-05-13 6:54 ` Francis Moreau
@ 2011-05-13 7:02 ` Francis Moreau
2011-05-13 11:13 ` Michael J Gruber
0 siblings, 1 reply; 6+ messages in thread
From: Francis Moreau @ 2011-05-13 7:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
On Fri, May 13, 2011 at 8:54 AM, Francis Moreau <francis.moro@gmail.com> wrote:
> [ resending to the mailing list too ]
>
> On Thu, May 12, 2011 at 8:47 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Francis Moreau venit, vidit, dixit 11.05.2011 18:11:
>>> Hello,
>>>
>>> I'm using "git cherry old master base" to see if all commits between
>>> master and base have been applied in my 'old' branch.
>>>
>>> So I expect that git cherry is using a list of commits given by : "git
>>> rev-list --no-merges base..master".
>>
>> Not really.
>>
>> For each commit in "--no-merges old..master ^base" (i.e. "--no-merges
>> master ^old ^base"), "git cherry" checks whether there is a patch
>> equivalent commit in "--no-merges master..old", and outputs it with + or -.
>>
>
> oh you're right, I missed the case when old has been merged in master.
>
BTW, can't it be convenient for users if git-cherry also displays the
sha1 of the commits which have been merged upstream (the ones with the
'-' sign) ?
Thanks
--
Francis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about git-cherry and the rev list it's using
2011-05-13 7:02 ` Francis Moreau
@ 2011-05-13 11:13 ` Michael J Gruber
2011-05-13 16:29 ` Francis Moreau
0 siblings, 1 reply; 6+ messages in thread
From: Michael J Gruber @ 2011-05-13 11:13 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
Francis Moreau venit, vidit, dixit 13.05.2011 09:02:
> On Fri, May 13, 2011 at 8:54 AM, Francis Moreau <francis.moro@gmail.com> wrote:
>> [ resending to the mailing list too ]
>>
>> On Thu, May 12, 2011 at 8:47 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Francis Moreau venit, vidit, dixit 11.05.2011 18:11:
>>>> Hello,
>>>>
>>>> I'm using "git cherry old master base" to see if all commits between
>>>> master and base have been applied in my 'old' branch.
>>>>
>>>> So I expect that git cherry is using a list of commits given by : "git
>>>> rev-list --no-merges base..master".
>>>
>>> Not really.
>>>
>>> For each commit in "--no-merges old..master ^base" (i.e. "--no-merges
>>> master ^old ^base"), "git cherry" checks whether there is a patch
>>> equivalent commit in "--no-merges master..old", and outputs it with + or -.
>>>
>>
>> oh you're right, I missed the case when old has been merged in master.
>>
>
> BTW, can't it be convenient for users if git-cherry also displays the
> sha1 of the commits which have been merged upstream (the ones with the
> '-' sign) ?
(I assume you mean the sha1 of the commit as it is in upstream.)
Well, in general the map "sha1 to patchid" is not one-to-one and may not
even be two-to-one. So we possibly would have to list more than one sha1
along with the -1. Anyways, with the current implementation you can't do
that, and it is not simple to change (because we may traverse *a lot* of
commits if base and upstream are far apart or disconnected).
Note that "git cherry -v" gives you the subjects so that you can grep
for those in case they match in your work flow. Same with "git log
--cherry --oneline" etc..
Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about git-cherry and the rev list it's using
2011-05-13 11:13 ` Michael J Gruber
@ 2011-05-13 16:29 ` Francis Moreau
0 siblings, 0 replies; 6+ messages in thread
From: Francis Moreau @ 2011-05-13 16:29 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
On Fri, May 13, 2011 at 1:13 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Francis Moreau venit, vidit, dixit 13.05.2011 09:02:
>> On Fri, May 13, 2011 at 8:54 AM, Francis Moreau <francis.moro@gmail.com> wrote:
>>> [ resending to the mailing list too ]
>>>
>>> On Thu, May 12, 2011 at 8:47 AM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Francis Moreau venit, vidit, dixit 11.05.2011 18:11:
>>>>> Hello,
>>>>>
>>>>> I'm using "git cherry old master base" to see if all commits between
>>>>> master and base have been applied in my 'old' branch.
>>>>>
>>>>> So I expect that git cherry is using a list of commits given by : "git
>>>>> rev-list --no-merges base..master".
>>>>
>>>> Not really.
>>>>
>>>> For each commit in "--no-merges old..master ^base" (i.e. "--no-merges
>>>> master ^old ^base"), "git cherry" checks whether there is a patch
>>>> equivalent commit in "--no-merges master..old", and outputs it with + or -.
>>>>
>>>
>>> oh you're right, I missed the case when old has been merged in master.
>>>
>>
>> BTW, can't it be convenient for users if git-cherry also displays the
>> sha1 of the commits which have been merged upstream (the ones with the
>> '-' sign) ?
>
> (I assume you mean the sha1 of the commit as it is in upstream.)
yes.
>
> Well, in general the map "sha1 to patchid" is not one-to-one and may not
> even be two-to-one. So we possibly would have to list more than one sha1
> along with the -1.
just showing the latest one would be nice though.
> Anyways, with the current implementation you can't do
> that, and it is not simple to change (because we may traverse *a lot* of
> commits if base and upstream are far apart or disconnected).
Ah, with my naive view I would have thought that to process the
patch-id of a commit in upstream and compare it, git has the sha1.
>
> Note that "git cherry -v" gives you the subjects so that you can grep
> for those in case they match in your work flow. Same with "git log
> --cherry --oneline" etc..
yes but as you said the subjects must match which is not always the
case (otherwise that would make patch-id unneeded)
Thanks
--
Francis
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-13 16:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-11 16:11 Question about git-cherry and the rev list it's using Francis Moreau
2011-05-12 6:47 ` Michael J Gruber
2011-05-13 6:54 ` Francis Moreau
2011-05-13 7:02 ` Francis Moreau
2011-05-13 11:13 ` Michael J Gruber
2011-05-13 16:29 ` Francis Moreau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).