Attachment (screen shot picture) as attachment to a commit
(1) By MBL (RoboManni) on 2023-04-16 17:12:29 [link] [source]
I often want to commit changes together with some short documentation. While the text description can be given I miss the option to attach one or more files, which in my case would be .gif or .png files from screen shots, which I made with the feature tests.
Is there a way to use attachment together with a commit?
The attachment files would be unversioned files bound to a commit for versioned files, something similar like a technote - but linked to a single commit hash code.
Binding a technote not only by time stamp in the timeline but with a given hash code of one or more check-in(s) would do the same (or even better), I guess. Is this possible other than only being contained in the text (=clickable from a list)?
Adding files with an option --attach to a checkout before committing could do the same.
Once the attachment files are somehow bound to a check-in the next question would be how the markdown syntax is to make them displayed; straight or only on demand by a special checkbox or button-press.
What is the best way to store and attach screen-shots to a check-in ?
(2) By John Rouillard (rouilj) on 2023-04-16 20:00:32 in reply to 1 [link] [source]
The wiki supports check-in wiki pages.
See the end of: https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki
Your images could be wiki attachments referenced inside the check-in wiki page.
I guess in theory if you did a:
fossil ci --attach foo.png -m "message here"
Note the images aren't unversioned as you requested. They would be part of the repo and synced normally just like any other documentation artifact. Which I think is really what should be done.
The display of the attachment would depend on what wiki markup is added to the page. It would only be shown if the info page for that check-in or the wiki page is displayed. The timeline views of that checkin (family, ancestor) don't seem to show the wiki page.
This is different from timeline branch views where the branch wiki page is displayed. But this makes sense as a branch wiki page really describes multiple checkins on a timeline. A single commit has a time but no timeline.
(3) By MBL (RoboManni) on 2023-04-17 06:47:28 in reply to 2 [link] [source]
fossil ci --attach foo.png -m "message here"
could autocreate the 'checkin/[hash]' wiki page, adding the commit message ("message here") as the default text.
Would be great but unfortunately such an option does not exist yet. Thanks for the reminder about the check-in wiki page's attachment capability.
What could be a sequence of commands to achieve the same on command line?
(4) By Stephan Beal (stephan) on 2023-04-17 13:43:29 in reply to 3 [source]
What is the best way to store and attach screen-shots to a check-in ?
If "best," in this context, is to mean easiest and/or most flexible then: by adding the screenshot files to the checkin as normal SCM'd content. Any other approach is like to require repository-specific acrobatics and will increase the maintenance burden.
Would be great but unfortunately such an option does not exist yet.
And seems unlikely to be added. What would, however, perhaps be both generically useful and move you a step forward in your desired direction is new --branch-wiki FILENAME and --checkin-wiki FILENAME flags which create or update a branch- or checkin-specific wiki page.
What could be a sequence of commands to achieve the same on command line?
Without having actually tried this, something along the lines of:
$ f ci ...
$ THE_HASH=$(f status | awk '/^checkout:/{print $2}')
$ echo "initial content" > TEMP_FILE
$ f wiki create checkin/$THE_HASH TEMP_FILE
$ rm TEMP_FILE
There are no great/straightforward ways for working with attachments in fossil. They're an ancient and rarely-used feature only available in very limited contexts (not checkins). Trying to use its attachment mechanism for this, instead of using normal checked-in content, would be unduly painful for little or no gain. For one, the CLI attachment command only offers the ability to add them, not extract them, and there's never been a compelling use case for extending that support.