git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv2 0/9] --left/right-only and --cherry-mark

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 10, 2011, 10:48 UTC
Message-ID
<4D78AC8B.7010308@drmicha.warpmail.net>
In-Reply-To
<7vd3lz5me5.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 10.03.2011 10:56:
Show 52 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> Junio C Hamano venit, vidit, dixit 09.03.2011 22:49:
>> ...
>>> Conceptually revs->cherry_mark ought to be a subset of revs->cherry_pick
>>> and the code shouldn't have to do something like this:
>>>
>>> 	if (revs->cherry_pick || revs->cherry_mark)
>>>         	cherry_pick_list();
>>>
>>> Instead, the code should arrange that revs->cherry_pick is always set
>>> when revs->cherry_mark is set before the calling application enters the
>>> loop to call get_revision().
>>>
>>> But that would make the command line parsing more cumbersome (you would
>>> either waste one bit so that you can tell if you saw --cherry-pick on the
>>> command line, or keep the version of parser in this series as-is, and add
>>> postprocessing code to flip revs->cherry_pick on when revs->cherry_mark
>>> was given in prepare_revision_walk()), and I understand that is why you
>>> did it that way?
>>
>> Yes, I think so :) Another reason is that even cherry_pick_list() needs
>> to know which object flag it should set.
> 
> I didn't have trouble with "if (revs->cherry_mark)" used for that purpose
> at all.
> 
> That is what I meant by "cherry-mark is a _subset_ of cherry-pick".  In
> other words, if you are marking the cherry-pick result, you must be doing
> a cherry-pick to begin with, so having to say "cherry-pick || cherry-mark"
> is a bad taste.
> 
> But that does not contradict with the need to do something differently
> between the case where you are cherry-marking and where you are not
> cherry-marking.
> 
>> - leave the parser as is
>> - set cherry_pick when cherry_mark is set
>> - if (revs->cherry_pick) cherry_pick_list();
>> - leave cherry_pick_list() as is
> 
> I think that essentially is what I speculated in "either X or Y" part as
> solution Y.
> 
>> Would that be better? I didn't do that because it changes the meaning of
>> cherry_pick (it can mean two things then). It would introduce the
>> assumption "pick is set when mark is" instead of "at most one is set"
> 
> Well, as I said earlier, my suggestion was coming from "if you are
> cherry-marking, you must be cherry-picking in the first place", so yes, I
> am saying that "at most one is set" is a bad taste.  If the assumption has
> to change to match the better taste, that can only be a good thing ;-).

Being half-way through doing "Y" I remember why I really disliked "Y": because it breaks the association between option names (--cherry-pick, --cherry-mark) and rev flags (cherry_pick, cherry_mark). With "Y", cherry_pick would mean --cherry-pick or --cherry-mark. (Also, as mentioned, we're not "picking" when marking.)

Additionally, since parse_revision_opt (which calls handle_revision_opt) is called from other sites for individual args we would need to do the handling in the Y case (set pick when marking) right in handle_revision_opt, not just in setup_revisions. It's a matter of a few more if's and or's, but still.

Taking these together, I wonder whether we shouldn't leave it as in v2.
Michael
Previous: Junio C HamanoNext: Michael J Gruber
Message 16 of 30 in “[PATCHv2 0/9] --left/right-only and --cherry-mark”
  1. Michael J GruberMar 7, 2011
  2. 1/9 revlist.c: introduce --left/right-only for unsymmetric pickingMichael J Gruber, Mar 7, 2011
  3. 2/9 t6007: Make sure we test --cherry-pickMichael J Gruber, Mar 7, 2011
  4. 3/9 rev-list: documentation and test for --left/right-onlyMichael J Gruber, Mar 7, 2011
  5. 4/9 rev-list: --left/right-only are mutually exclusiveMichael J Gruber, Mar 7, 2011
  6. 5/9 rev-list/log: factor out revision mark generationMichael J Gruber, Mar 7, 2011
  7. 6/9 revision.c: introduce --cherry-markMichael J Gruber, Mar 7, 2011
  8. Junio C HamanoMar 9, 2011
  9. 6/9 revision.c: introduce --cherry-markMichael J Gruber, Mar 10, 2011
  10. 7/9 rev-list: documentation and test for --cherry-markMichael J Gruber, Mar 7, 2011
  11. 8/9 log --cherry: a synonymMichael J Gruber, Mar 7, 2011
  12. 9/9 t6007: test rev-list --cherryMichael J Gruber, Mar 7, 2011
  13. Junio C HamanoMar 9, 2011
  14. Michael J GruberMar 10, 2011
  15. Junio C HamanoMar 10, 2011
  16. Michael J GruberMar 10, 2011
  17. 00/10 --left/right-only and --cherry-markMichael J Gruber, Mar 10, 2011
  18. 01/10 revlist.c: introduce --left/right-only for unsymmetric pickingMichael J Gruber, Mar 10, 2011
  19. 02/10 t6007: Make sure we test --cherry-pickMichael J Gruber, Mar 10, 2011
  20. 03/10 rev-list: documentation and test for --left/right-onlyMichael J Gruber, Mar 10, 2011
  21. 04/10 rev-list: --left/right-only are mutually exclusiveMichael J Gruber, Mar 10, 2011
  22. 05/10 rev-list/log: factor out revision mark generationMichael J Gruber, Mar 10, 2011
  23. 06/10 revision.c: introduce --cherry-markMichael J Gruber, Mar 10, 2011
  24. 07/10 rev-list: documentation and test for --cherry-markMichael J Gruber, Mar 10, 2011
  25. 08/10 log --cherry: a synonymMichael J Gruber, Mar 10, 2011
  26. 09/10 t6007: test rev-list --cherryMichael J Gruber, Mar 10, 2011
  27. 10/10 git-log: put space after commit markMichael J Gruber, Mar 10, 2011
  28. Junio C HamanoMar 10, 2011
  29. Michael J GruberMar 11, 2011
  30. Junio C HamanoMar 11, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.