The way Fossil does cherry-picks now is:

fossil merge --cherrypick VERSION

But this is tedious to type if you do it a lot. And people with prior exposure to Git might instinctively try to us a separate "cherry-pick" command, because that is what Git does. So, I was thinking, why not create a new "cherry-pick" command that is just an alias for "fossil merge --cherrypick". So the example above would do exactly the same thing as the following:

fossil cherry-pick VERSION

What say you? Good idea or bad?

The proposed new command is just syntax. It introduces no new capabilities.

Even with this change, the "fossil cherry-pick" command would be different from the "git cherry-pick" command. Git pushes the merge directly into the DAG (if I understand correctly), whereas Fossil does the merge into your working check-out. Git requires that the working checkout contain no edits, but Fossil does not care and will happily do a cherry-pick merge into an edited but uncommitted checkout.

So one possible bad point is that even though the syntax of "fossil cherry-pick" would be similar to "git cherry-pick", the semantics would be quite different. I wonder would that lead to unnecessary confusion?

I would appreciate new capability to select individual file(s) from the picked cherry, not always all files of a checkin at once. Can this be included?

I would appreciate new capability to select individual file(s) from the picked cherry, not always all files of a checkin at once. Can this be included?

Recording that is not something the architecture supports. A merge, in terms of the underlying data format, is a record of a whole checkin which is merged into another checkin.

You can, of course, cherrypick all files and then revert specific files to get that effect, but the formal record of such a merge is still that the whole version was cherrypicked. Determining, later on, that only parts of that merged-in version were actually merged in requires manually going through the file listings for each version and examining each one. (Whether than can feasibly be automated is unclear to me.)

Another hiccup is that we do not have a platform-portable way to interactively select individual files, so the selection would require typing all names out on the command line.

we just need merge to check the name it was invoked as and set the --cherrypick flag if it's called with that name.

As /chat'd, that's now implemented in fossil:0421108812a73ca1.

I like this as it’s an oft used command, but “cherrypick” without the hyphen.

ETA: nvm. Too late!

The Git command has a hyphen. I suggested a hyphen in the name for familiarity.

The Git command has a hyphen. I suggested a hyphen in the name for familiarity.

It seems likely that those who use it will eventually just stop typing at "cher", so the hyphen probably won't play a big role in practice.

Yes, Stephan suggested a workaround, which is even better. I thought cherrypick for consistency with merge —cherrypick (and lazy fingers), but your reasoning makes sense too.

Understandable. But could the stash support my Intention? Stash before cherrypicking with exceptions (new Feature!) . Then after cherry pick reapply previous pending changes „around“ the picked files. The stash is all local and individual files all known by name and mtime.

Understandable. But could the stash support my Intention? Stash before cherrypicking with exceptions (new Feature!)

The core-most file format does not support cherrypicking with exceptions, so don't hold your breath waiting on a new feature for that ;). Fossil models merges as happening at the "version" level, and a version in fossil encompasses all changes made within a single checkin. A checkin is its atomic unit for purposes of fossil's record-keeping of a merge, whereas files within a checkin are subatomic particles and are not merge-tracked separately.

Then after cherry pick reapply previous pending changes „around“ the picked files. The stash is all local and individual files all known by name and mtime.

i'm not entirely clear what it is you're asking. If you mean, can you stash some files, cherry-pick copies of them from another version, then unstash them, yes, but stash will merge any changes, not replace them.

I think what is meant -to my understanding here- is to make the following sequence automatic:

1. Usage: fossil merge ?OPTIONS? ?VERSION? ?FILES...? with the enhancement similar to fossil update with an optional list of FILES

2. Usage: fossil stash snapshot ?-m

   --comment COMMENT? ?FILES...?

   to freeze all pending not yet committed changes in local check-out 'as they are' into the stash. The comment to identify in stash list can be deviated from the VERSION option of the cherry-pick command, maybe with an enhancement by time stamp - but anyhow, will be the most recent freeze of local status without alterations to files.

3. Execute the fossil cherry-pick as is supposed to work ('all files for the check-in at once').

4. NEW: revert the files from the cherry-pick, which were NOT listed on command line, to the one's which were snap-shot-frozen to stash; like a "revert to stash" BUT ONLY for the complement of FILES listed and contained in the cherry. (I assume there might be many files in such a check-in but only few listed on command line)

There does not exist yet a SUBCOMMAND like fossil stash revert ?STASHID? ?FILES...?. This REVERT with the correct selection of FILES and the automatism of these 4 steps into one is most likely meant by the recent response from anonymous.

My understanding is that the stash apply works similar to fossil update and stash revert would have more similarity to how fossil checkout --force is working; just replace the result of changes to files out of the cherry to files not listed by the snapshot frozen previous content. Drawback: The mtime may change unexpected while file content is reverted to as it was before the cherry-pick.

Maybe my understanding of the difference between stash apply and stash goto is wrong and that feature could be done already with one of these two? Can someone please help me with some explanation to better understand?

Maybe my understanding of the difference between stash apply and stash goto is wrong and that feature could be done already with one of these two? Can someone please help me with some explanation to better understand?

My (mis?)understanding is that goto and apply are the same except that goto will first run an update to the version from which that stash entry was saved.

The code for apply and goto are both small and similar:

https://fossil-scm.org/home/file?ci=trunk&name=src/stash.c&ln=706-727