advice on a couple of changes
(1) By Kartik Agaram (akkartik) on 2024-04-26 05:29:18 [source]
Coming from git, I found a few things confusing just now. Let me lay them out, and I'd appreciate someone pointing out where my mental model needs updating for fossil.
I have two branches in a fossil repo. Let's call them A and B.
I made a commit in branch A. There were no outstanding diffs. I wanted to copy just that one commit over to B, but not other commits in A. So I switched opened branch A in a new directory and initiated a cherrypick:
$ mkdir ../B
$ cd ../B
$ fossil open ../repo.fossil B
$ fossil merge --cherrypick <versionid>
UPDATE score.c
"fossil undo" is available to undo changes to the working checkout.
Coming from git and after reading fossil help merge, I expected <versionid> to now be committed in the new branch. But I see the changes uncommitted when I run fossil diff.
So I ran fossil commit. I saw the commit message prepopulated in my editor. When I exited, I saw this:
unchanged check-in comment. continue (y/N)? y
New_Version: c3a969bdf2c464454cc176120793e0e24ef682419a0ec49fb263720e04408d65
WARNING: multiple open leaf check-ins on A:
(1) 2024-04-26 05:13:57 [c3a969bdf2] (current)
(2) 2024-04-26 00:04:00 [2ab3f7bace]
$
Does all this seem expected? Or does it seem like my repo is messed up somehow? Thanks in advance.
(2.1) By hanche on 2024-04-26 08:56:24 edited from 2.0 in reply to 1 [link] [source]
Okay, I'll give it a try.
First of all, yes, fossil merge just updates the working tree and makes a note of the merge. It does not commit anything. So it's normal to have to commit after the merge. I think that is so that you can further modify your working tree first. (Edit: And to give you a chance to check that the merge did what you expected it to, so you can fix it or back out if not.)
Second, running fossil commit should never create a fork unless you give it the --allow-fork argument. And even then, the created fork only affects the current branch.
Third, once a fork exists, many fossil commands will issue the “multiple open leaf check-ins” warning. (That is what a fork is, in fossil terminology.)
Therefore, I conlcude that the fork in A most likely already existed before you did these steps.
I highly recommend using the fossil ui command to get a nice graphical view of the current state of your repository. It might help you figure out what happened, perhaps even why.
(3) By Stephan Beal (stephan) on 2024-04-26 12:38:30 in reply to 2.1 [link] [source]
Second, running fossil commit should never create a fork unless you give it the --allow-fork argument.
Just to clarify: that's mostly true, and it's the ideal situation, but it is possible to end up with multiple unintended forks when either (A) autosync is off and multiple clones are being used or (B) two developers hit a very tiny race condition when autosync is on and both try to commit at precisely the same moment.
In the first case, both clones can commit freely, but the forks won't show up until they have both shared their work with each other. It doesn't break anything, it just means that the new forks need to be merged back into one.
The second case is extremely rare but did happen to us once in this project sometime in the past year.
(4) By Richard Hipp (drh) on 2024-04-26 12:44:22 in reply to 3 [link] [source]
Even more clarification: Forks are completely harmless, at least from Fossil's point of view. The only downside of forks is that they can be confusing to human readers, especially humans with prior exposure to Git. Fossil itself is not the least bit bothered by forks and will continue happily along with a repository full of them.
All these warnings about Forks and all the extra code added to detect and report them are purely for the benefit of human readers. These warnings do not indicate any logic problems in the underlying repository.
(5) By Andy Bradford (andybradford) on 2024-04-26 13:51:02 in reply to 1 [link] [source]
> Coming from git and after reading fossil help merge, I expected > <versionid> to now be committed in the new branch. But I see the > changes uncommitted when I run fossil diff. This is one of those differences where I think Fossil gets it right. When you cherrypick a commit, why should it be automatically committed? What if you decide that you didn't really want it because maybe it was the wrong hash? Furthermore, have you tested the code after the cherrypick and before it is committed? Yes, this is working properly. When you cherrypick in Fossil, it simply updates your working directory and prepares some information that will be used to make a permanent record once you actually do commit the change. You must then follow up with "fossil commit". Regarding the fork, if you did not see at the time of "fossil commit" output suggesting a new fork was created, then it must have existed prior to this commit. If you really want the fork then do nothing, otherwise, you can just run "fossil merge" [literally] and it will attempt to automatically merge the two. You may have to resolve conflicts if any, but you will then have to "fossil commit" the result because as mentioned before [and as you have discovered], merges do not get automatically committed to the repository. Andy
(6) By Richard Hipp (drh) on 2024-04-26 14:30:05 in reply to 5 [link] [source]
Yeah. I didn't even realize that Git automatically commits a cherry-pick.
Another downside of auto-commit after cherry-pick is that you can only cherry-pick once per check-in. In Fossil, you can cherry-pick two or more changes, plus make manual edits, plus resolve any merge conflicts, all before you commit. https://sqlite.org/src/info/7a3d0027f81e8def is an example of where I cherry-picked three separate fixes into a single check-in.
(7.1) By Marcelo Huerta (richieadler) on 2024-04-26 15:08:07 edited from 7.0 in reply to 6 [link] [source]
You can add a -n | --no-commit flag to the git cherry-pick command, but the default is committing, yes.
(8) By Warren Young (wyoung) on 2024-04-26 15:36:53 in reply to 1 [link] [source]
I've summarized this thread's responses into a new section in the Git to Fossil Translation Guide. The ideas were there before, but not as clearly expressed.
Does this help?
(9) By Andy Bradford (andybradford) on 2024-04-27 00:54:25 in reply to 8 [link] [source]
> I've summarized this thread's responses into a new section in the Git > to Fossil Translation Guide. The statement that "fossil timeline" cannot show commits from just a single branch is no longer accurate. This functionality was added here: https://www.fossil-scm.org/home/info/213ca339c2951ad1 I've updated the documentation but feel free to alter if it doesn't make sense the way I wrote it. Andy
(10) By Warren Young (wyoung) on 2024-04-27 01:13:49 in reply to 9 [link] [source]
TIL; thank you!
(11.1) By Kartik Agaram (akkartik) on 2024-04-27 22:44:16 edited from 11.0 in reply to 8 [link] [source]
Thank you! This is enormously helpful. Particularly the pointer to the Translation Guide I had somehow missed thus far.
(12) By Kartik Agaram (akkartik) on 2024-04-27 23:20:46 in reply to 4 [link] [source]
Thanks all. I think I've figured out how I ended up in this situation. I'm using git and fossil side by side, and I created a couple of manual commits on both git and fossil, and then reran git fast-export ... | fossil import ... (to import a new branch).
(13) By Konstantin Khomutov (kostix) on 2024-04-29 10:04:48 in reply to 6 [link] [source]
As Marcelo suggested, you can tell Git not to automatically commit a cherry-pick, and you can also tell it to cherry-pick any number of commits in a single run.
It's also possible to git show <commitish> | git apply any commit which would work like git cherry-pick -nc by basically producing a textual patch out of a commit and then applying it.
(14) By Warren Young (wyoung) on 2024-04-29 19:24:21 in reply to 13 [link] [source]
Yes, I was aware of these options before you replied, which is why I put “by default” into the new doc section.
Defaults matter. People tend to accept them blindly, as advice from above on “best practices”. This new section of the docs gives our position that autocommit is an objectively bad practice, at least in conjunction with autosync and no rebase.