I'm working on a project with a new Fossil user. Right now it's just the two of us. He was able to create the Fossil repository on Chiselapp without any fuss, but since then it's been all my work, aside from his wiki edits. Until today. Now is the first time he tried cloning the repository onto his computer and checking in edits. With his permission, I'm going to share some of his experiences here.
The first thing he said was "Got fossil ui working. Added, merged and committed website_design.md." I thought it interesting that he spoke of merging as if it were a distinct task in the workflow for adding a file.
Then a bit later, regarding that same file: "Ah, I'm seeing this would be better suited as an addition to the roadmap [a separate document]. I'm reading the best practice for fossil is to leave the deprecated .md in place?" I'm not sure where he got the idea that it's best to not delete files, but he did. Maybe I should ask.
I explained to him a bit about fossil changes, commit, rm, extras, etc. "'fossil changes' lists all the changes that will be committed the next time you do a 'fossil commit'. By default, 'fossil rm' doesn't delete the file from disk, only marks it to be removed in the next commit. It'll still stay on disk until you delete the file for real. People don't much like this behavior, but it's what we have, and it can be changed."
Regarding fossil changes, he said, "If I get a carriage return/new line with no prompt, does that mean there are no changes to apply?" So there seems to be a bit of confusion, or at least hesitancy, about fossil changes (probably also fossil extras) printing nothing.
Then the big challenge: "I've been trying to get the file removed from the online repo, ran fossil rm here and now am having difficulty committing."
We went around on this for a while until I was able to correctly guess that he had typed "fossil sync website_design.md" in order to "sync" the file to Chiselapp. This was easily fixed with fossil remote-url.
He said, "okay, I want to remove website_design.md and sync." I responded, "Type 'fossil rm -hard website_design.md' and 'fossil commit'. The '-hard' will go ahead and delete the file from disk for you. I can change the default to do that all the time if you like, since that's what people usually expect." He said, "Yes please." From that, I take it that the default of not deleting the file from disk is confusing to new users. As for me, "I've gotten used to just typing '-hard'."
I then looked at the history and found that he actually added and deleted website_design.md twice. He explained, "Yes, I was trying to work off of a git tutorials as I had found the Fossil resources to be a bit more sparse. Even after removing a file you run git add to apply those changes." Interesting.
At that point I asked his permission to share and if he had anything to add. His advice: "Take it a bit further with the quick start tutorial. Past the point of cloning or initing I'd like to have a step by step through adding, commits, and how the auto feature changes the experience from git or how it works in general."
I pointed him to the /md_rules page, and he said, "This will come in handy, thank you." So perhaps we could do better highlighting the resources we already have.
Lastly, a technical problem. I have a markdown document with an image in it, but it wasn't showing up for him. The solution was to look at it using /doc since /artifact was preventing the relative URL from resolving to a usable resource.
-- Andy Goth | <andrew.m.goth/at/gmail/dot/com> _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
