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

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

From
IDIgor Djordjevic <igor.d.djordjevic@gmail.com>
Date
Oct 17, 2017, 21:15 UTC
Message-ID
<dcddb20d-b838-0131-ea31-4ab7186dd088@gmail.com>
In-Reply-To
<d3ccfb02-004a-bbc3-af33-967db280c940@kdbg.org>
On 17/10/2017 19:30, Johannes Sixt wrote:
Show 12 quoted lines
> Am 17.10.2017 um 01:01 schrieb Rafael Ascensao:
>>> This is worth discussing, though not my preference. The picture to "pick
>>> cherries" has become quite common, and now that we use it for the name of
>>> the command, "cherry-pick", the direction of flow is quite obvious and
>>> strongly implied: from somewhere else to me (and not to somebody else).
>>
>> What if we borrow '--onto' from rebase and make it cherry-pick --onto
>> <destination>?
> 
> I actually like this. Although I would miss the convenience that the 
> source defaults to HEAD. Unless we make a special case for --onto, 
> that is, of course.
I second this.

From my point of view, I would say that "cherry-pick" in general seems to just imply "taking" commits (picking "cherries"), where direction flow is irrelevant, or at least not strongly implied. For me, it`s more "from somewhere else to somebody else", indeed.

The fact that it currently "posts" its picks "to me" (on top of current HEAD) could very well be justified/explained as the most obvious case (at time of implementation, at least), where usually one does work "here" (HEAD), thus cares to have commits picked over "here" as well - but it doesn`t have to be a restriction, where other destination besides HEAD could/should be allowed.

Anyway, I`d say current behaviour without "--onto" should stay, indeed, where HEAD destination is implied if not otherwise specified (and that seems to align well with some other Git commands, too). Also, in case "--onto" _is_ provided, maybe commit to be picked could be allowed to be omitted, defaulting to HEAD again, but as source this time.

That said, might be 'git commit' looks like a nice candidate for being taught this new trick as well (optionally commit to a revision other than HEAD, what Ævar already mentioned), following the same logic... ;) It would even be a better (more straightforward) fit for one of your previous examples:

> Another use case is when you receive a patch to be applied on a 
> different branch while you are in the middle of some work. If it can be 
> applied on the current branch, then you can post it to the destination, 
> rewind, and continue with your work.

p.s. I`m very interested in this functionality, and more - I have a beginner`s attempt in addressing a similar use-case this topic is concerned with (symptomatically using a variation of "--onto" as well :P), hopefully I`ll sent out something soon, for the sake of discussion/opinion, at least :(

Regards, Buga

Previous: Johannes Sixt
Message 8 of 8 in “git-post: the opposite of git-cherry-pick”
  1. git-post: the opposite of git-cherry-pickJohannes Sixt, Oct 5, 2017
  2. Stefan BellerOct 5, 2017
  3. Johannes SixtOct 5, 2017
  4. Ævar Arnfjörð BjarmasonOct 13, 2017
  5. Johannes SixtOct 15, 2017
  6. Rafael AscensaoOct 16, 2017
  7. Johannes SixtOct 17, 2017
  8. Igor DjordjevicOct 17, 2017

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.