Short option -u for --user-override?
(1.2) By Ferran Jorba (fjorba) on 2025-04-22 04:54:51 edited from 1.1 [source]
First of all, thank you very much for Fossil. Finally I found a SCM that makes me feel safe and not scared.
As we have started to use it in our environment, we have seen that we will be heavy users of --user-override, and we'd appreciate having a shorter version. Yes, we know that we can shorten it to --user, but certainly -u is even shorter. If you think that it may be of general interest, I attach a patch that implements it, against current tip. Hopefully it is trivial enough that does not require further paperwork.
I'm "attaching" it inline at it seems that there is no option to do a proper attachment. Please tell me if I should do something different.
Best regards,
Ferran Jorba
Index: src/branch.c
==================================================================
--- src/branch.c
+++ src/branch.c
@@ -87,11 +87,11 @@
noSign = find_option("nosign","",0)!=0;
if( find_option("nosync",0,0) ) g.fNoSync = 1;
zColor = find_option("bgcolor","c",1);
isPrivate = find_option("private",0,0)!=0;
zDateOvrd = find_option("date-override",0,1);
- zUserOvrd = find_option("user-override",0,1);
+ zUserOvrd = find_option("user-override","u",1);
verify_all_options();
if( g.argc<5 ){
usage("new BRANCH-NAME BASIS ?OPTIONS?");
}
db_find_and_open_repository(0, 0);
@@ -517,11 +517,11 @@
int argPos = nStartAtArg; /* g.argv pos with first branch/ci name */
char * zUuid = 0; /* Resolved branch UUID. */
const int fVerbose = find_option("verbose","v",0)!=0;
const int fDryRun = find_option("dry-run","n",0)!=0;
const char *zDateOvrd = find_option("date-override",0,1);
- const char *zUserOvrd = find_option("user-override",0,1);
+ const char *zUserOvrd = find_option("user-override","u",1);
verify_all_options();
db_begin_transaction();
for( ; argPos < g.argc; fossil_free(zUuid), ++argPos ){
const char * zName = g.argv[argPos];
@@ -557,11 +557,11 @@
int argPos = nStartAtArg; /* g.argv pos with first branch name */
char * zUuid = 0; /* Resolved branch UUID. */
const int fVerbose = find_option("verbose","v",0)!=0;
const int fDryRun = find_option("dry-run","n",0)!=0;
const char *zDateOvrd = find_option("date-override",0,1);
- const char *zUserOvrd = find_option("user-override",0,1);
+ const char *zUserOvrd = find_option("user-override","u",1);
verify_all_options();
db_begin_transaction();
for( ; argPos < g.argc; fossil_free(zUuid), ++argPos ){
const char * zName = g.argv[argPos];
@@ -606,15 +606,15 @@
** It accepts arbitrary unambiguous symbolic names but
** will only resolve check-in names and skips any which resolve
** to non-leaf check-ins.
**
** Options:
-** -n|--dry-run Do not commit changes, but dump artifact
-** to stdout
-** -v|--verbose Output more information
-** --date-override DATE DATE to use instead of 'now'
-** --user-override USER USER to use instead of the current default
+** -n|--dry-run Do not commit changes, but dump artifact
+** to stdout
+** -v|--verbose Output more information
+** --date-override DATE DATE to use instead of 'now'
+** -u|--user-override USER USER to use instead of the current default
**
** > fossil branch current
**
** Print the name of the branch for the current check-out
**
@@ -664,17 +664,17 @@
** preferred idiom in Fossil is to create new branches at the point
** of need, using the "--branch NAME" option to the "fossil commit"
** command.
**
** Options:
-** --private Branch is private (i.e., remains local)
-** --bgcolor COLOR Use COLOR instead of automatic background
-** --nosign Do not sign the manifest for the check-in
-** that creates this branch
-** --nosync Do not auto-sync prior to creating the branch
-** --date-override DATE DATE to use instead of 'now'
-** --user-override USER USER to use instead of the current default
+** --private Branch is private (i.e., remains local)
+** --bgcolor COLOR Use COLOR instead of automatic background
+** --nosign Do not sign the manifest for the check-in
+** that creates this branch
+** --nosync Do not auto-sync prior to creating the branch
+** --date-override DATE DATE to use instead of 'now'
+** -u|--user-override USER USER to use instead of the current default
**
** Options:
** -R|--repository REPO Run commands on repository REPO
*/
void branch_cmd(void){
Index: src/checkin.c
==================================================================
--- src/checkin.c
+++ src/checkin.c
@@ -2473,11 +2473,11 @@
** --private Never sync the resulting check-in and make
** all descendants private too.
** --proxy PROXY Use PROXY as http proxy during sync operation
** --tag TAG-NAME Add TAG-NAME to the check-in. May be repeated.
** --trace Debug tracing
-** --user-override USER Record USER as the login that created the
+** -u|--user-override USER Record USER as the login that created the
** new check-in, rather that the current user.
**
** See also: [[branch]], [[changes]], [[update]], [[extras]], [[sync]]
*/
void commit_cmd(void){
@@ -2591,11 +2591,11 @@
sCiInfo.azTag[nTag++] = zTag;
sCiInfo.azTag[nTag] = 0;
}
zComFile = find_option("message-file", "M", 1);
sCiInfo.zDateOvrd = find_option("date-override",0,1);
- sCiInfo.zUserOvrd = find_option("user-override",0,1);
+ sCiInfo.zUserOvrd = find_option("user-override","u",1);
noSign = db_get_boolean("omitsign", 0)|noSign;
if( db_get_boolean("clearsign", 0)==0 ){ noSign = 1; }
useCksum = db_get_boolean("repo-cksum", 1);
bIgnoreSkew = find_option("ignore-clock-skew",0,0)!=0;
outputManifest = db_get_manifest_setting(0);
Index: src/fileedit.c
==================================================================
--- src/fileedit.c
+++ src/fileedit.c
@@ -714,11 +714,11 @@
** non-leaf parent. Note that no autosync
** is performed beforehand.
** --allow-merge-conflict Allows check-in of a file even if it
** appears to contain a fossil merge conflict
** marker
-** --user-override USER USER to use instead of the current
+** -u|--user-override USER USER to use instead of the current
** default
** --date-override DATETIME DATE to use instead of 'now'
** --allow-older Allow a commit to be older than its
** ancestor
** --convert-eol-inherit Convert EOL style of the check-in to match
@@ -768,11 +768,11 @@
CheckinMiniInfo_init(&cimi);
zComment = find_option("comment","m",1);
zCommentFile = find_option("comment-file","M",1);
zAsFilename = find_option("as",0,1);
zRevision = find_option("revision","r",1);
- zUser = find_option("user-override",0,1);
+ zUser = find_option("user-override","u",1);
zDate = find_option("date-override",0,1);
zManifestFile = find_option("save-manifest",0,1);
if(find_option("wet-run",0,0)==0){
cimi.flags |= CIMINI_DRY_RUN;
}
Index: src/import.c
==================================================================
--- src/import.c
+++ src/import.c
@@ -1158,11 +1158,11 @@
fossil_free(zParentUuid);
}
if( gsvn.zUser ){
blob_appendf(&manifest, "U %F\n", gsvn.zUser);
}else{
- const char *zUserOvrd = find_option("user-override",0,1);
+ const char *zUserOvrd = find_option("user-override","u",1);
blob_appendf(&manifest, "U %F\n", zUserOvrd ? zUserOvrd : login_name());
}
md5sum_blob(&manifest, &mcksum);
blob_appendf(&manifest, "Z %b\n", &mcksum);
blob_reset(&mcksum);
Index: src/info.c
==================================================================
--- src/info.c
+++ src/info.c
@@ -3936,11 +3936,11 @@
** -m|--comment COMMENT Make COMMENT the check-in comment
** -M|--message-file FILE Read the amended comment from FILE
** -n|--dry-run Print control artifact, but make no changes
** --no-verify-comment Do not validate the check-in comment
** --tag TAG Add new TAG to this check-in
-** --user-override USER Set the user name on the control artifact
+** -u|--user-override USER Set the user name on the control artifact
**
** DATETIME may be "now" or "YYYY-MM-DDTHH:MM:SS.SSS". If in
** year-month-day form, it may be truncated, the "T" may be replaced by
** a space, and it may also name a timezone offset from UTC as "-HH:MM"
** (westward) or "+HH:MM" (eastward). Either no timezone suffix or "Z"
@@ -3999,11 +3999,11 @@
fClose = find_option("close",0,0)!=0;
fHide = find_option("hide",0,0)!=0;
fDryRun = find_option("dry-run","n",0)!=0;
zChngTime = find_option("date-override",0,1);
if( zChngTime==0 ) zChngTime = find_option("chngtime",0,1);
- zUserOvrd = find_option("user-override",0,1);
+ zUserOvrd = find_option("user-override","u",1);
noVerifyCom = find_option("no-verify-comment",0,0)!=0;
db_find_and_open_repository(0,0);
user_select();
verify_all_options();
if( g.argc<3 || g.argc>=4 ) usage(AMEND_USAGE_STMT);
Index: src/tag.c
==================================================================
--- src/tag.c
+++ src/tag.c
@@ -408,11 +408,11 @@
** -n|--dry-run Display the tag text, but do not
** actually insert it into the database
** --propagate Propagating tag
** --raw Raw tag name. Ignored for
** non-CHECK-IN artifacts.
-** --user-override USER Name USER when adding the tag
+** -u|--user-override USER Name USER when adding the tag
**
** The --date-override and --user-override options support
** importing history from other SCM systems. DATETIME has
** the form 'YYYY-MMM-DD HH:MM:SS'.
**
@@ -432,11 +432,11 @@
** --date-override DATETIME Set date and time deleted
** -n|--dry-run Display the control artifact, but do
** not insert it into the database
** --raw Raw tag name. Ignored for
** non-CHECK-IN artifacts.
-** --user-override USER Name USER when deleting the tag
+** -u|--user-override USER Name USER when deleting the tag
**
** > fossil tag find ?OPTIONS? TAGNAME
**
** List all objects that use TAGNAME.
**
@@ -515,11 +515,11 @@
int dryRun = 0;
int fRaw = find_option("raw","",0)!=0;
const char *zPrefix = "";
int fPropagate = find_option("propagate","",0)!=0;
const char *zDateOvrd = find_option("date-override",0,1);
- const char *zUserOvrd = find_option("user-override",0,1);
+ const char *zUserOvrd = find_option("user-override","u",1);
const char *zTag;
const char *zObjId;
int objType;
if( find_option("dry-run","n",0)!=0 ) dryRun = TAG_ADD_DRYRUN;
if( g.argc!=5 && g.argc!=6 ){
@@ -553,11 +553,11 @@
if( strncmp(g.argv[2],"cancel",n)==0 ){
int dryRun = 0;
int fRaw = find_option("raw","",0)!=0;
const char *zPrefix = "";
const char *zDateOvrd = find_option("date-override",0,1);
- const char *zUserOvrd = find_option("user-override",0,1);
+ const char *zUserOvrd = find_option("user-override","u",1);
const char *zTag;
const char *zObjId;
int objType;
if( find_option("dry-run","n",0)!=0 ) dryRun = TAG_ADD_DRYRUN;
if( g.argc!=5 ){
@@ -794,11 +794,11 @@
** So the reparent operation will be undone by the next
** "fossil rebuild" command.
** -n|--dry-run Print the tag that would have been created but do not
** actually change the database in any way.
** --date-override DATETIME Set the change time on the control artifact
-** --user-override USER Set the user name on the control artifact
+** -u|--user-override USER Set the user name on the control artifact
*/
void reparent_cmd(void){
int bTest = find_option("test","",0)!=0;
int rid;
int i;
@@ -808,11 +808,11 @@
const char *zDateOvrd; /* The change time on the control artifact */
const char *zUserOvrd; /* The user name on the control artifact */
if( find_option("dry-run","n",0)!=0 ) dryRun = TAG_ADD_DRYRUN;
zDateOvrd = find_option("date-override",0,1);
- zUserOvrd = find_option("user-override",0,1);
+ zUserOvrd = find_option("user-override","u",1);
db_find_and_open_repository(0, 0);
verify_all_options();
if( g.argc<4 ){
usage("[OPTIONS] CHECK-IN PARENT ...");
}
Index: src/tkt.c
==================================================================
--- src/tkt.c
+++ src/tkt.c
@@ -1583,11 +1583,11 @@
/* do some ints, we want to be inside a check-out */
db_find_and_open_repository(0, 0);
user_select();
- zUser = find_option("user-override",0,1);
+ zUser = find_option("user-override","u",1);
if( zUser==0 ) zUser = login_name();
zDate = find_option("date-override",0,1);
if( zDate==0 ) zDate = "now";
zDate = date_in_standard_format(zDate);
zTktUuid = find_option("uuid-override",0,1);
Index: tools/fossil-autocomplete.zsh
==================================================================
--- tools/fossil-autocomplete.zsh
+++ tools/fossil-autocomplete.zsh
@@ -345,27 +345,27 @@
(all)
__fossil_all
;;
(amend)
- _arguments \
- ':hash:' \
- "(--help --author)"--author'[USER Make USER the author for check-in]:user:($(__fossil_users))' \
- "(--help -m --comment)"{-m,--comment}'[COMMENT Make COMMENT the check-in comment]:comment:' \
- "(--help -M --message-file)"{-M,--message-file}'[FILE Read the amended comment from FILE]:file:_files' \
- "(--help -e --edit-comment)"{-e,--edit-comment}'[Launch editor to revise comment]' \
- "(--help --date)"--date'[DATETIME Make DATETIME the check-in time]:datetime:(now)' \
- "(--help --bgcolor)"--bgcolor'[COLOR Apply COLOR to this check-in]:color:' \
- "(--help --branchcolor)"--branchcolor'[COLOR Apply and propagate COLOR to the branch]:color:' \
- "(--help --tag)"--tag'[TAG Add new TAG to this check-in]:tag:($(__fossil_tags))' \
- "(--help --cancel)"--cancel'[TAG Cancel TAG from this check-in]:tag:($(__fossil_tags))' \
- "(--help --branch)"--branch'[NAME Make this check-in the start of branch NAME]:name:($(__fossil_branches))' \
- "(--help --hide)"--hide'[Hide branch starting from this check-in]' \
- "(--help --close)"--close'[Mark this "leaf" as closed]' \
- "(--help -n --dry-run)"{-n,--dry-run}'[Print control artifact, but make no changes]' \
- "(--help --date-override)"--date-override'[DATETIME Set the change time on the control artifact]:datetime:(now)' \
- "(--help --user-override)"--user-override'[USER Set the user name on the control artifact]:user:($(__fossil_users))' \
+ _arguments \
+ ':hash:' \
+ "(--help --author)"--author'[USER Make USER the author for check-in]:user:($(__fossil_users))' \
+ "(--help -m --comment)"{-m,--comment}'[COMMENT Make COMMENT the check-in comment]:comment:' \
+ "(--help -M --message-file)"{-M,--message-file}'[FILE Read the amended comment from FILE]:file:_files' \
+ "(--help -e --edit-comment)"{-e,--edit-comment}'[Launch editor to revise comment]' \
+ "(--help --date)"--date'[DATETIME Make DATETIME the check-in time]:datetime:(now)' \
+ "(--help --bgcolor)"--bgcolor'[COLOR Apply COLOR to this check-in]:color:' \
+ "(--help --branchcolor)"--branchcolor'[COLOR Apply and propagate COLOR to the branch]:color:' \
+ "(--help --tag)"--tag'[TAG Add new TAG to this check-in]:tag:($(__fossil_tags))' \
+ "(--help --cancel)"--cancel'[TAG Cancel TAG from this check-in]:tag:($(__fossil_tags))' \
+ "(--help --branch)"--branch'[NAME Make this check-in the start of branch NAME]:name:($(__fossil_branches))' \
+ "(--help --hide)"--hide'[Hide branch starting from this check-in]' \
+ "(--help --close)"--close'[Mark this "leaf" as closed]' \
+ "(--help -n --dry-run)"{-n,--dry-run}'[Print control artifact, but make no changes]' \
+ "(--help --date-override)"--date-override'[DATETIME Set the change time on the control artifact]:datetime:(now)' \
+ "(--help -u --user-override)"--user-override'[USER Set the user name on the control artifact]:user:($(__fossil_users))' \
'(- *)'--help'[Show help and exit]'
;;
(annotate|blame|praise)
_arguments \
@@ -490,38 +490,38 @@
'(- *)'--help'[Show help and exit]' \
'*:files:_files'
;;
(ci|commit)
- _arguments \
- "(--help --allow-conflict)"--allow-conflict'[Allow unresolved merge conflicts]' \
- "(--help --allow-empty)"--allow-empty'[Allow a commit with no changes]' \
- "(--help --allow-fork)"--allow-fork'[Allow the commit to fork]' \
- "(--help --allow-older)"--allow-older'[Allow a commit older than its ancestor]' \
- "(--help --baseline)"--baseline'[Use a baseline manifest in the commit process]' \
- "(--help --bgcolor)"--bgcolor'[COLOR Apply COLOR to this one check-in only]:color:' \
- "(--help --branch)"--branch'[NEW-BRANCH-NAME check in to this new branch]:new branch:' \
- "(--help --branchcolor)"--branchcolor'[COLOR Apply given COLOR to the branch]:color:' \
- "(--help --close)"--close'[Close the branch being committed]' \
- "(--help --date-override)"--date-override'[DATETIME DATE to use instead of '"'"'now'"'"']:datetime:' \
- "(--help --delta)"--delta'[Use a delta manifest in the commit process]' \
- "(--help --hash)"--hash'[Verify file status using hashing]' \
- "(--help --integrate)"--integrate'[Close all merged-in branches]' \
- "(--help -m --comment)"{-m,--comment}'[COMMENT Use COMMENT as commit comment]:comment:' \
- "(--help -M --message-file)"{-M,--message-file}'[FILE Read the commit comment from given file]:file:_files' \
- "(--help --mimetype)"--mimetype'[MIMETYPE Mimetype of check-in comment]:mimetype:' \
- "(--help -n --dry-run)"{-n,--dry-run}'[If given, display instead of run actions]' \
- "(--help --no-prompt)"--no-prompt'[Assume NO for every question]' \
- "(--help --no-warnings)"--no-warnings'[Omit all warnings about file contents]' \
- "(--help --no-verify)"--no-verify'[Do not run before-commit hooks]' \
- "(--help --nosign)"--nosign'[Do not attempt to sign this commit with gpg]' \
- "(--help --override-lock)"--override-lock'[Allow a check-in even though parent is locked]' \
- "(--help --private)"--private'[Do not sync changes and their descendants]' \
- "(--help --tag)"--tag'[TAG-NAME Assign given tag TAG-NAME to the check-in]:tag:($(__fossil_tags))' \
- "(--help --trace)"--trace'[Debug tracing]' \
- "(--help --user-override)"--user-override'[USER Use USER instead of the current default]:user:($(__fossil_users))' \
- '(- *)'--help'[Show help and exit]' \
+ _arguments \
+ "(--help --allow-conflict)"--allow-conflict'[Allow unresolved merge conflicts]' \
+ "(--help --allow-empty)"--allow-empty'[Allow a commit with no changes]' \
+ "(--help --allow-fork)"--allow-fork'[Allow the commit to fork]' \
+ "(--help --allow-older)"--allow-older'[Allow a commit older than its ancestor]' \
+ "(--help --baseline)"--baseline'[Use a baseline manifest in the commit process]' \
+ "(--help --bgcolor)"--bgcolor'[COLOR Apply COLOR to this one check-in only]:color:' \
+ "(--help --branch)"--branch'[NEW-BRANCH-NAME check in to this new branch]:new branch:' \
+ "(--help --branchcolor)"--branchcolor'[COLOR Apply given COLOR to the branch]:color:' \
+ "(--help --close)"--close'[Close the branch being committed]' \
+ "(--help --date-override)"--date-override'[DATETIME DATE to use instead of '"'"'now'"'"']:datetime:' \
+ "(--help --delta)"--delta'[Use a delta manifest in the commit process]' \
+ "(--help --hash)"--hash'[Verify file status using hashing]' \
+ "(--help --integrate)"--integrate'[Close all merged-in branches]' \
+ "(--help -m --comment)"{-m,--comment}'[COMMENT Use COMMENT as commit comment]:comment:' \
+ "(--help -M --message-file)"{-M,--message-file}'[FILE Read the commit comment from given file]:file:_files' \
+ "(--help --mimetype)"--mimetype'[MIMETYPE Mimetype of check-in comment]:mimetype:' \
+ "(--help -n --dry-run)"{-n,--dry-run}'[If given, display instead of run actions]' \
+ "(--help --no-prompt)"--no-prompt'[Assume NO for every question]' \
+ "(--help --no-warnings)"--no-warnings'[Omit all warnings about file contents]' \
+ "(--help --no-verify)"--no-verify'[Do not run before-commit hooks]' \
+ "(--help --nosign)"--nosign'[Do not attempt to sign this commit with gpg]' \
+ "(--help --override-lock)"--override-lock'[Allow a check-in even though parent is locked]' \
+ "(--help --private)"--private'[Do not sync changes and their descendants]' \
+ "(--help --tag)"--tag'[TAG-NAME Assign given tag TAG-NAME to the check-in]:tag:($(__fossil_tags))' \
+ "(--help --trace)"--trace'[Debug tracing]' \
+ "(--help -u --user-override)"--user-override'[USER Use USER instead of the current default]:user:($(__fossil_users))' \
+ '(- *)'--help'[Show help and exit]' \
'*:files:_files'
;;
(clean)
_arguments \
@@ -903,17 +903,17 @@
(remote|remote-url)
__fossil_remote
;;
(reparent)
- _arguments \
- "(--help --test)"--test'[Make database entries but do not add the tag artifact]' \
- "(--help -n --dryrun)"{-n,--dryrun}'[Do not actually change the database]' \
- "(--help --date-override)"--date-override'[DATETIME Set the change time on the control artifact]:datetime:' \
- "(--help --user-override)"--user-override'[USER Set the user name on the control artifact]:user:($(__fossil_users))' \
- '(- *)'--help'[Show help and exit]' \
- '1:check-in:' \
+ _arguments \
+ "(--help --test)"--test'[Make database entries but do not add the tag artifact]' \
+ "(--help -n --dryrun)"{-n,--dryrun}'[Do not actually change the database]' \
+ "(--help --date-override)"--date-override'[DATETIME Set the change time on the control artifact]:datetime:' \
+ "(--help -u --user-override)"--user-override'[USER Set the user name on the control artifact]:user:($(__fossil_users))' \
+ '(- *)'--help'[Show help and exit]' \
+ '1:check-in:' \
'*:parents:'
;;
(revert)
_arguments \
@@ -1493,11 +1493,11 @@
${_common_options[@]} \
"(--help --private)"--private'[Branch is private]' \
"(--help --bgcolor)"--bgcolor'[COLOR Use COLOR instead of automatic background]:color:' \
"(--help --nosign)"--nosign'[Do not sign contents on this branch]' \
"(--help --date-override)"--date-override'[DATE Use DATE instead of '"'"'now'"'"']:date:(now)' \
- "(--help --user-override)"--user-override'[USER Use USER instead of the default]:user:($(__fossil_users))' \
+ "(--help -u --user-override)"--user-override'[USER Use USER instead of the default]:user:($(__fossil_users))' \
'1:branch name:' \
'2:base check-in:'
;;
*)
@@ -2176,30 +2176,30 @@
;;
(options)
case $line[1] in
(add)
- _arguments \
- ${_common_options[@]} \
- "(--help --raw)"--raw'[Raw tag name]' \
- "(--help --propagate)"--propagate'[Propagating tag]' \
- "(--help --date-override)"--date-override'[DATETIME Set date and time added]:datetime:' \
- "(--help --user-override)"--user-override'[USER Name USER when adding the tag]:user:($(__fossil_users))' \
- "(--help --dryrun -n)"{--dryrun,-n}'[Display the tag text, but do not]' \
- '1:tag name:($(__fossil_tags))' \
- '2:check-in:' \
+ _arguments \
+ ${_common_options[@]} \
+ "(--help --raw)"--raw'[Raw tag name]' \
+ "(--help --propagate)"--propagate'[Propagating tag]' \
+ "(--help --date-override)"--date-override'[DATETIME Set date and time added]:datetime:' \
+ "(--help --user-override -u)"--user-override'[USER Name USER when adding the tag]:user:($(__fossil_users))' \
+ "(--help --dryrun -n)"{--dryrun,-n}'[Display the tag text, but do not]' \
+ '1:tag name:($(__fossil_tags))' \
+ '2:check-in:' \
'3::value:'
;;
(cancel)
- _arguments \
- ${_common_options[@]} \
- "(--help --raw)"--raw'[Raw tag name]' \
- "(--help --date-override)"--date-override'[DATETIME Set date and time deleted]:datetime:' \
- "(--help --user-override)"--user-override'[USER Name USER when deleting the tag]:user:($(__fossil_users))' \
- "(--help --dryrun -n)"{--dryrun,-n}'[Display the control artifact, but do]' \
- '1:tag name:($(__fossil_tags))' \
+ _arguments \
+ ${_common_options[@]} \
+ "(--help --raw)"--raw'[Raw tag name]' \
+ "(--help --date-override)"--date-override'[DATETIME Set date and time deleted]:datetime:' \
+ "(--help --user-override -u)"--user-override'[USER Name USER when deleting the tag]:user:($(__fossil_users))' \
+ "(--help --dryrun -n)"{--dryrun,-n}'[Display the control artifact, but do]' \
+ '1:tag name:($(__fossil_tags))' \
'2:check-in:'
;;
(find)
_arguments \
@@ -2677,11 +2677,11 @@
"(--help --comment -m)"{--comment,-m}'[COMMENT Required checkin comment]:comment:' \
"(--help --comment-file -M)"{--comment-file,-M}'[FILE Reads checkin comment from the given file]:file:_files' \
"(--help --revision -r)"{--revision,-r}'[VERSION Commit from this version]:version:' \
"(--help --allow-fork)"--allow-fork'[Allow commit against a non-leaf parent]' \
"(--help --allow-merge-conflict)"--allow-merge-conflict'[Allow checkin of a file with conflict markers]' \
- "(--help --user-override)"--user-override'[USER User to use instead of the default]:user:($(__fossil_users))' \
+ "(--help --user-override -u)"--user-override'[USER User to use instead of the default]:user:($(__fossil_users))' \
"(--help --date-override)"--date-override'[DATETIME Date to use instead of '"'"'now'"'"']:datetime:(now)' \
"(--help --allow-older)"--allow-older'[Allow a commit to be older than its ancestor]' \
"(--help --convert-eol-inherit)"--convert-eol-inherit'[Inherit EOL style from previous content]' \
"(--help --convert-eol-unix)"--convert-eol-unix'[Convert the EOL style to Unix]' \
"(--help --convert-eol-windows)"--convert-eol-windows'[Convert the EOL style to Windows]' \
(2) By Richard Hipp (drh) on 2025-04-15 13:38:34 in reply to 1.0 [link] [source]
I deliberately made --user-override long and hard to type because I didn't want newbies to think this is something they ought to be doing. The original design purpose of --user-overwrite was to facilitate importing content from other version control systems.
You must have some other use-case for --user-override in mind. Can you explain why you think you will be using this option frequently? How is your workflow different from what I have previously envisioned?
(3.2) By Ferran Jorba (fjorba) on 2025-04-15 13:52:40 edited from 3.1 in reply to 2 [link] [source]
I understand your motivation.
We are not full-time developers working on a product, but a team of two working as devops. So we work mainly in the server (mostly development, but sometimes also production when there are problems) in shared accounts, one per service, and there we take care of the systems, do some some development (mostly short or medium sized scripts), import, export, maintenance, error or performance diagnostics, etc.
We saw the solution using Fossil's ability to commit to the repository as each of us, even if we share the same account.
(4) By Richard Hipp (drh) on 2025-04-15 14:21:57 in reply to 3.2 [link] [source]
Another option you have is to set the FOSSIL_USER environment variable. Each of the two developers could set that variable upon login. Maybe add lines to your ~/.bashrc file (or similar) that prompts you on login:
(1) Ferran. (2) The other guy. Who are you?
And then you must enter either 1 or 2 in order to continue. That way you don't forget to add the --user-override (or -u) option when you commit.
(5) By Ferran Jorba (fjorba) on 2025-04-15 14:26:03 in reply to 4 [link] [source]
That's an interesting alternative. Thanks again, Mr. Hipp!
(6.2) By Andy Bradford (andybradford) on 2025-04-15 16:21:21 edited from 6.1 in reply to 3.2 [link] [source]
> We saw the solution using Fossil's ability to commit to the repository > as each of us, even if we share the same account. You can use the FOSSIL_USER environment variable to control the name that gets stamped on commits. If you are using SSH and specifically SSH keys to login this becomes extremely simple to setup. To accomplish this, you can enable the sshd_config PermitUserEnvironment and then in the shared account ~/.ssh/authorized_keys you can have entries like: environment="FOSSIL_USER=X" ssh-ed25519 ... environment="FOSSIL_USER=Y" ssh-rsa ... Or if you want to setup even more things based upon the key, you could use: environment="SSH_OWNER=X" ssh-ed25519 ... environment="SSH_OWNER=Y" ssh-rsa ... And then in the shared ~/.profile you would do something like: case "$SSH_OWNER" in X) export FOSSIL_USER=X; other things for X ;; Y) export FOSSIL_USER=Y; other things for Y ;; esac I you aren't using SSH keys, then you could use Match conditionals in the sshd_config to match whatever you are doing (hopefully). You can also embed the FOSSIL_USER environment variable in scripts based upon other conditional things. Andy
(7) By Ferran Jorba (fjorba) on 2025-04-15 14:56:31 in reply to 6.1 [link] [source]
That's interesting, yes. As I'm very fan of tmux, that also helps "isolating" sessions in a shared account, I was thinking about customizing some tmux setting, but all those ideas will help us to choose the best option. Thanks for your ideas.
(8.1) By Andy Bradford (andybradford) on 2025-04-15 16:09:09 edited from 8.0 in reply to 7 [link] [source]
> As I'm very fan of tmux, that also helps "isolating" sessions in a
> shared account
Yes, and in fact, you could do something similar as mentioned
previously; in your shared ~/.profile you could have something like:
case "$SSH_OWNER" in
X)
export FOSSIL_USER=X
alias tmux='tmux -L X'
;;
esac
This keeps your tmux sessions "isolated" between the different users and
also enables the FOSSIL_USER for keeping your commits "isolated".
Also, if you want different settings for tmux, unfortunately there is no
tmux environment variable that controls which configuration file to
load, but you could change the alias assignment above to be:
alias tmux='tmux -L X -f ~/.tmux.conf-X'
Or something like that (untested).
Andy
(11.1) By Ferran Jorba (fjorba) on 2025-04-16 05:46:25 edited from 11.0 in reply to 8.1 [link] [source]
Unfortunatelly, I've just discovered that the technique of setting FOSSIL_USER for tmux is not enough for Emacs vc Fossil mode. I've tried both syntaxes:
$ FOSSIL_USER=fjorba tmux
$ export FOSSIL_USER=fjorba && tmux
and in both cases the commits do not appear under my name but the Linux account. Even though calling the Emacs shell command echo $FOSSIL_USER indeed outputs my name.
[Edit]
It is not enough even for the shell:
ddd@estrada:~/src$ echo $FOSSIL_USER
fjorba
ddd@estrada:~/src$ f commit lib/ruby/fitxers.rb -m 'fitxers: fix Emacs headers'
ddd@estrada:~/src$ f timeline -n 1
=== 2025-04-16 ===
05:43:38 [6e1ce0731a] *CURRENT* fitxers: fix Emacs headers (user: ddd tags: trunk)
--- entry limit (1) reached ---
(20) By Andy Bradford (andybradford) on 2025-04-16 15:59:30 in reply to 11.1 [link] [source]
> Unfortunatelly, I've just discovered that the technique of setting > FOSSIL_USER for tmux is not enough You're right, you'll also need to have a Fossil user in the repository that matches the name in your FOSSIL_USER environment variable. So for example, in my test repository, I added a user: $ fossil user new fjorba contact-info: password: Retype new password: Now, let's see what happens without the FOSSIL_USER: $ unset FOSSIL_USER $ echo $RANDOM >> file $ fossil ci -m seventh New_Version: 53b822136f2db74d9baebe9997753d401606ebd172ed3aefec522f55bf6b9393 $ fossil whatis current | grep ^type: type: Check-in by amb on 2025-04-16 15:55:32 It committed with my normal Fossil username which was created when I created the repository. Now, let's set FOSSIL_USER: $ echo $RANDOM >> file $ FOSSIL_USER=fjorba fossil ci -m eighth New_Version: 31000fc3684104de5d1eea546633f88bcc0b2be24a4519e261f8f4687465bfe1 $ fossil whatis current | grep ^type: type: Check-in by fjorba on 2025-04-16 15:56:55 You'll need to make sure that your Fossil repositories have the user that you are trying to emulate before FOSSIL_USER will be respected. Andy
(9) By Mike Swanson (chungy) on 2025-04-15 17:33:34 in reply to 1.1 [link] [source]
As an alternative to everything said, Fossil is a DVCS. Could both of your developers instead clone the repository with a ssh://... URL, so that the user-name is always recorded locally, and on push/sync operations, it'll just go over to the server as needed?
(12) By Ferran Jorba (fjorba) on 2025-04-16 05:35:38 in reply to 9 [link] [source]
At the begginning of our Fossil experiments we tried to clone via ssh, but finally we considered that via https was simpler, it was accessible out of the vpn, and because we also wanted the web interface in the server. So, we don't have much experience with it.
(14) By Mike Swanson (chungy) on 2025-04-16 07:00:28 in reply to 12 [link] [source]
http takes a little bit of more work (but not much, it's just fossil server in the most basic case), but the point remains to let Fossil's distributed nature work for you, instead of trying to have multiple developers share the same user account on the same system.
(15.1) By Ferran Jorba (fjorba) on 2025-04-16 13:16:40 edited from 15.0 in reply to 14 [link] [source]
The point is that some of the code can only be tested (and sometimes developed) in the (development) server, because only there there are the conditions to be run, either because the logs are there, the multiple databases we need to access are only available from the server, or because the network constrains are in the server, not in our laptops. And sometimes the constrain is also the username, because only that one can access restricted resources. That's why most of the times we work on the development server in the shared accounts (not only one, but one per service).
As our servers already have as an Apache web server, setting up Fossil as cgi is trivial. So yes, Fossil being a distribute SCM, and we do have replicas, we consider one being the canonical one; so use it mostly like a centralized one.
(10) By Florian Balmer (florian.balmer) on 2025-04-16 04:50:47 in reply to 1.1 [link] [source]
Yes, we know that we can shorten it to
--user, but certainly-uis even shorter.
For that matter, -U is short for --user.
But note that this isn't the same: --user-override records an arbitrary
username in artifacts. --user tries to run the command on behalf of the
specified user, and this only succeeds if the specified user is valid for the
repository.
(13.1) By Ferran Jorba (fjorba) on 2025-04-16 05:41:25 edited from 13.0 in reply to 10 [link] [source]
I understood that -U was for setting the default user, and so it will be stored as a default for our shared account, so it would defeat the objective of distinguising who did the commit. So did I misunderstand it?
(16) By Florian Balmer (florian.balmer) on 2025-04-16 13:06:08 in reply to 13.1 [link] [source]
The --user option changes the default user only for the duration of the
command for which the option is set. The fossil user default command changes
the default user permanently.
These two steps are only available if the specified user is valid for the
repository, i.e. it's listed by fossil user ls.
Even if you're using shared machine accounts, you can still have multiple Fossil user accounts in the repository, and switch between them using the above methods, but I don't know if you're doing this.
The --user-override option allows recording an arbitrary user name for
check-ins (or other commands that support it), no matter if the repository
really has a user with the same name. But --user-override doesn't change the
user recorded with actions in the Artifact Receipts Log, for example.
(17.3) By Ferran Jorba (fjorba) on 2025-04-22 05:20:16 edited from 17.2 in reply to 16 [link] [source]
Yes, we do have the system account user, and a couple of personal accounts in our fossils that appear in fossil user ls, and yes, we use --user-override to switch among them.
Mr. Hipp suggested using the envornmental variable FOSSIL_USER, but if I understand well the logic in https://fossil-scm.org/home/file?ci=trunk&name=src/user.c&ln=496-549, the preference is lower than the default user, that in our (main) case is ddd:
ddd@estrada:~/src$ f user default
ddd
Do you know if it is possible to delete or unset the default user? So far I haven't found the way. If I could, setting the right FOSSIL_USER would solve our situation.
(18) By Florian Balmer (florian.balmer) on 2025-04-16 14:19:44 in reply to 17.1 [link] [source]
If you can see the users with fossil user ls, then the -U|--user option is
fine.
The --user-override option is for "hackers" to invent a new user name not
already available in the repository. This option is mostly used by scripts to
"rewrite history" or "transplant" check-ins among repositories, to preserve user
names without creating them.
I don't think it's possible to unset the default user without making another
default, so FOSSIL_USER would still have lower precedence.
I think FOSSIL_USER is handy to specify the initial default user when creating
or cloning a repository, but after that, the user is determined by the
repository. And this can't be changed without the risk of breaking stuff.
You could also add -U|--user <NAME> to your f script or alias (this could
even be the first two arguments, as global options are parsed before command
names, as in fossil -U <NAME> ls, while other options have to go after command
names).
(19.2) By Ferran Jorba (fjorba) on 2025-04-16 14:44:35 edited from 19.1 in reply to 18 [link] [source]
So, you just have made me aware that when I passed the --user option I was changing the default user, not an abbreviation of --user-override, as I thought:
ddd@estrada:~/src$ f commit --user ferran lib/ruby/uab.rb -m 'uab: improve punctuation'
no such user: ferran
ddd@estrada:~/src$ f commit --user-override ferran lib/ruby/uab.rb -m 'uab: improve punctuation'
New_Version: adf6a69fedbbdea83cfa3f6e8f95cfa655f14b593b0fec2a2e2cc63fc66fe2bd
But setting it does not change it permanently:
ddd@estrada:~/src$ f commit --user fjorba lib/ruby/confedit.rb -m 'confedit: update Emacs headers'
New_Version: 3ff24c9a86f4c4be9d24c53ae97f18449b110c21f232023be8b1b3df58b0fdb1
ddd@estrada:~/src$ f user default
ddd
(21) By Andy Bradford (andybradford) on 2025-04-16 16:03:42 in reply to 17.1 [link] [source]
> Do you know if it is possible to delete or unset the default user? This question has come up a couple times over the years, but there has never been a command added to enable it. You can unset it using something like: $ echo "DELETE FROM vvar WHERE name = 'default-user';" | fossil sql You probably don't really want a default user set in this case and just allow Fossil to autodetect the user using the methods that you discovered in user.c. Andy
(22) By Ferran Jorba (fjorba) on 2025-04-16 16:35:28 in reply to 21 [link] [source]
Oh, great, thanks! Now setting FOSSIL_USER it works even using Emacs vc Fossil backend! (I've copied our .fossil database just before deleting the record, of course, just in case)
Thank you all that have contributed to solve our situation.
(23) By Richard Hipp (drh) on 2025-04-22 11:04:35 in reply to 17.3 [link] [source]
I traced user_select() on my check-out of Fossil itself, running fossil commit -n --allow-empty
and found that I do not have a default-user. It got down to checking the USER environment variable
before figuring out
The default-user is an entry in the CONFIG table of the repository. You can delete it by
running fossil sql and then typing:
DELETE FROM config WHERE name='default-user';
There might be a copy in your per-checkout database too. That is the VVAR table. If it is there, the command to delete that is:
DELETE FROM vvar WHERE name='default-user';
A little later...
There is a command to set the default user: fossil user set USERNAME.
You could ran that command every time you log in, I suppose... That seems like
a less-desirable solution, though. There is not currently a command to unset
the default user. But that might change later today....
(24) By Richard Hipp (drh) on 2025-04-22 11:36:51 in reply to 23 [link] [source]
As of check-in 2025-04-22T11:29Z you can
run "fossil user default """ (set the default user to an empty string) and it
clears the current default-user setting from the repository and from the local
check-out. You can also run "fossil user default -v" and it tells you not
only who the default user is, but how that user was computed. Experiment, for
example, by running:
FOSSIL_USER=other fossil user default -v
Note that any alternative user specified by the FOSSIL_USER environment variable
must in fact be a user named in the USER table. You can get a list of all such
users with the "fossil user list" command. If the value you give to FOSSIL_USER
is not found in the USER table, then the environment variable is ignored.
(25) By Ferran Jorba (fjorba) on 2025-04-22 13:54:25 in reply to 24 [link] [source]
Again, thank you very much, Mr. Hipp.
(26) By Florian Balmer (florian.balmer) on 2025-04-22 14:43:36 in reply to 24 [link] [source]
As of check-in 2025-04-22T11:29Z ...
While the date/time notation is a nifty technical feature that is used more and more on this forum, I'm just realizing that I don't "trust" it:
Does it really resolve to the intended check-in, now and forever? Theoretically, in a DVCS, other users could add check-ins with the same date/time (at the date/time granularity used by the link, i.e. only down to minutes in the example above), or the date/time of check-ins can be modified later.
In contrast, hashes are eternal, and the probability to of later ambiguity for (reasonably) abbreviated forms seems small.With eyes trained to hashes, it's usually possible to tell apart check-ins by the very first (or maybe the few first) digit(s), whereas dealing with a list of check-ins in date/time notation seems to be quite a mental challenge, as the differing positions are subtle and may only become apparent after many digits.
(27.1) By Richard Hipp (drh) on 2025-04-22 15:09:49 edited from 27.0 in reply to 26 [link] [source]
The first point is valid and has been considered by me. My choice is to use the hash in cases where precision is desired - mostly in check-in comments. In a forum post, saying things like "check-in 2025-04-22T11:29Z" is more acceptable, I think, for the following reasons:
It is more human-readable. And the whole point of the forum is to be read by humans.
In my example above, the hyperlink is src:/timeline?c=2025-04-22T11:25Z, but I could have kept the timestamp in the display text and yet made the hyperlink be src:/timeline?c=064d20ee382ec777, guaranteeing the correct link. I have done that on occasion, but it didn't seem necessary in this instance.
Even if the date/time of the check-in of interest is changed, or if another check-in occurs nearby, the link will still be "close enough". Part of the beauty of timestamp names is that even if you are a few seconds or minutes off from the actual time, it still resolves to something nearby.
The hyperlink gives additional information about the check-in; specifically the timestamp on the check-in. This is particularly relevant when used in a context such as "For check-in 2025-04-22T11:29Z and later...".
I did consider always displaying timestamp names everywhere, instead of hashes, because the timestamp names are more readable and hold additional useful information. However, I rejected that idea for the reasons you cite.
Summary: Timestamp names can be useful when used carefully, but hash names are still important and do need to be used where extra precision, accuracy, and long-term stability are needed. How convenient that we have the choice to use either timestamp names or hash names, as circumstances dictate!
PS: If you visit the download page and mouse-over the hyperlinks to the source tarballs, you'll see that they use the full 64-character hash - I don't even abbreviate the hash - because in that context precision is critical. It's all about context.
(29) By Mike Swanson (chungy) on 2025-04-22 18:02:52 in reply to 27.1 [link] [source]
Ambiguous time-stamps in the minute precision can probably happen frequently, but it also should normally only take a minute to see if anything comes down the wire that would mess with your reference. You can always go down to the second precision if necessary, and millisecond if really necessary.
There are only two legitimate instances where these references might become ambiguous or change "far" into the future: autosync is turned off, or someone was performing offline development and now came online. Autosync should probably never be turned off, assuming you have push access to the original server1, and offline development is just an extended form of autosync being off by temporary lack of network access.
Florian's first point is not just about accidental date/time collisions, but potentially malicious ones as well. It is actually difficult for me to imagine a legitimate use-case to altering the date/time of a check-in in a future amendment. I suppose it might assist in scripts that convert check-ins from a foreign VCS, but even that case is satisfied with fossil commit --date-override instead of doing it after-the-fact. Are there examples of legitimate modifications to a check-in's date/time in the SQLite or Fossil repositories? I think some SQL-foo could answer that, but I'm not sure how to search for it effectively.
For truly malicious scenarios, I believe it is best handled with a removal of the user from the server and perhaps even /shun. If someone wants to be malicious, there's a whole host of offenses that are more serious than messing with time stamps, too.
PS: If you visit the download page and mouse-over the hyperlinks to the source tarballs, you'll see that they use the full 64-character hash - I don't even abbreviate the hash - because in that context precision is critical. It's all about context
That seems sensible for the snapshot build, but is there a pressing need to use a hash instead of tags like version-2.24 and version-2.25 for the actual releases? Similar to a point above, Fossil tags aren't unique and can change the reference, but I highly doubt anyone is going to make a new tag named version-2.25 to replace the original reference (a version-2.25.1 is a plausible hypothetical, but not a new version-2.25).
- ^ I suppose you could do local development and get added to the server's user table at a later date, and all your changes come in at once.
(37) By Vadim Goncharov (nuclight) on 2025-07-03 17:40:10 in reply to 27.1 [link] [source]
Yes, you are right, they're more human-friendly. That's why in my sketches for ideas of future DVCS commit-ids would be not just hashes but a date-type prepended also (e.g. "tkt" or branch-name 3-letter hash) - and also more DB-friendly, for clustering in indexes (e.g. new UUID formats have appeared to solve this problem in DBs).
(28) By Andy Bradford (andybradford) on 2025-04-22 16:54:06 in reply to 23 [link] [source]
> found that I do not have a default-user. Most people don't have the "default-user" setting enabled (I'm not sure it's recommended for normal usage). Fossil automatically selects the user for them based upon a series of tests and that becomes the user that gets chosen for the commit. The first such test is "check the default-user setting" which trumps all other user checks including FOSSIL_USER. Andy
(30.1) By Ferran Jorba (fjorba) on 2025-04-23 08:08:59 edited from 30.0 in reply to 28 [link] [source]
To tell you the truth, I'm not sure when we started to have our default user, but I'm quite sure it came out out of confusion, involuntarily. For newcomers, Fossil users and passwords are confusing, specially because in previous SCM experiences (in my case, CVS and git, and very briefly GNU arch) there is no user handling. When you create your first Fossil repo suddenly you find a message with a admin-user and an initial password that you don't know much what to do with. Probably when I discovered the --user or the --user-override, or when setting some Admin values via web I did something that created our default user.
(31) By Stephan Beal (stephan) on 2025-04-23 10:47:16 in reply to 30.1 [link] [source]
When you create your first Fossil repo suddenly you find a message with a admin-user and an initial password that you don't know much what to do with.
That's a fair criticism. src:57276a518ad6449d adds a succinct snippet to that output to hopefully clarify that it's only needed for remote access.
(33) By Ferran Jorba (fjorba) on 2025-04-23 15:15:02 in reply to 31 [link] [source]
Yes, I think that it helps, thanks.
(32) By Andy Bradford (andybradford) on 2025-04-23 14:09:27 in reply to 30.1 [link] [source]
> Fossil users and passwords are confusing, I can see how that would be confusing. I added a small paragraph about the purpose of the user in the Quick Start Guide: https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki#clone It can probably use some additional documentation elsewhere (e.g. for "fossil init") which I can add later if necessary, perhaps also with a link to the discussion on Fossil users found at: https://fossil-scm.org/home/doc/trunk/www/caps/ Have you gone through the Quick Start Guide? Would you have found this paragraph helpful? In case you're not able to find the new paragraph in the section on cloning, here's the source: https://fossil-scm.org/home/info/f5b9f0153b48ad8c Thanks, Andy
(34) By Ferran Jorba (fjorba) on 2025-04-23 16:11:13 in reply to 32 [link] [source]
I read as much as I could before starting with Fossil, because that's how I proceed. Like many other people, I had heard about Fossil, not only due to SQLite repo fame, but also because is one that has survived many years. So yes, I read the quickguide, the Fossil book and all the tutorials that I have found in Internet, although there are not so many. I'm not sure I have read the pages you point me to, but if I did, probably at that time I didn't pay attention to because I was looking for something different that I didn't find, that covered the explanation I needed:
- Start with an existing software project, that can already be handled by another SCM, like git, or not. Because as Fossil has the repo outside the source tree, can easily coexist with your current SCM. Most of the tutorials start with an empty project or a clone of an existing one, not with existing code that you need for your daily job. Now I know the steps, but after failing several times. Keep in mind that at this time the newbie is somebody without previous Fossil exposure, so it is difficult to judge if he is following the right path or a wrong way.
- Very early, I think, should be which files to ignore, how to set your
fossil settings ignore-glob "*~,*.pyc". In git tutorials show it early on, but in Fossil it took me a while to find it. That was another test repo deleted, because I imported too many unwanted files. - Probably some paragraphs about this particular Fossil characteristic, the users and passwords.
That said, I started commiting many errors, and I deleted the repos and started over several times. I have thought to write a tutorial like the one, and I may do it, and propose to post it somewhere in this site. The older I get, the more I'm convinced that everybody learn in different ways, and having more tutorials, written for different kind of people is good. Of course, my English should be more thoroughly revised for a document like that, I'm very aware.
(35) By Richard Hipp (drh) on 2025-04-23 16:22:37 in reply to 34 [link] [source]
I have thought to write a tutorial [and] to post it somewhere in this site.
That would be most welcomed. I will add it to the official Fossil documentation if you will send me a manuscript by direct email to drh at sqlite dot org.
Don't worry about your language skills. I'm pretty weak at English too, even though it is my mother tongue and the only language I speak :-). There are plenty of other people here who will jump in and correct our grammar.
(36) By Ferran Jorba (fjorba) on 2025-04-23 16:34:12 in reply to 35 [link] [source]
I'll try my best, thanks for the invitation.