* 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).