"fossil status" output for RENAMED to laconic
(1) By Alfred M. Szmidt (ams) on 2022-06-30 07:17:08 [source]
It would be really useful to know what a file was renamed from in the output of "fossil status/changes", maybe via -v?
(2) By Stephan Beal (stephan) on 2022-06-30 10:58:07 in reply to 1 [link] [source]
It would be really useful to know what a file was renamed from...
While you wait on that to be added (i'm looking into what that would require right now), libfossil's f-status
app does that:
[stephan@nuc:~/fossil/fossil/www]$ fst # <=== alias for f-status
...
No local changes.
[stephan@nuc:~/fossil/fossil/www]$ f-mv -mv webui.wiki xxxx.wiki
MOVE: www/webui.wiki ==> www/xxxx.wiki
Renamed 1 file(s).
[stephan@nuc:~/fossil/fossil/www]$ fst
...
Local changes compared to this version:
RENAMED www/webui.wiki
-> www/xxxx.wiki
(3) By Stephan Beal (stephan) on 2022-06-30 11:03:36 in reply to 1 [link] [source]
It would be really useful to know what a file was renamed from...
Please voice any objections...
[stephan@nuc:~/fossil/fossil/www]$ f chan
EDITED ../src/checkin.c
RENAMED xxxx.wiki
from www/webui.wiki
If there are none, i'll let that sit for a day or two to give folks a chance to chime in before committing it (or not, depending on the feedback).
(4) By Martin Gagnon (mgagnon) on 2022-06-30 11:13:39 in reply to 3 [link] [source]
The only thing I see is that may be having the "from .....
" on a separate line have more chance to break some people wrapper script ?
Since each change
entries otherwise are always in a single line.
What do you think ?
(5) By Warren Young (wyoung) on 2022-06-30 12:03:59 in reply to 4 [link] [source]
Agreed. Try "RENAMED xxxx.wiki → www/webui.wiki
" instead.
Yes, put UTF-8 in the program output. Let the refactory anti-Unicode faction suffer! Muuuaaahhaha! 😛
(7) By Stephan Beal (stephan) on 2022-06-30 12:14:49 in reply to 5 [link] [source]
Agreed. Try "RENAMED xxxx.wiki → www/webui.wiki" instead.
That filename order would be preferred but would require a more invasive change because of how that function is structured :/.
PS: i have no qualms with emoji in the output. 🔁⏩➡️🔀
(11) By Andy Bradford (andybradford) on 2022-06-30 12:58:39 in reply to 7 [link] [source]
> That filename order would be preferred but would require a more > invasive change because of how that function is structured Then: RENAMED www/newwebui.wiki <= www/oldwebui.wiki Maybe?
(12) By Martin Gagnon (mgagnon) on 2022-06-30 14:03:32 in reply to 11 [link] [source]
Or
RENAMED www/newebui.wiki (from www/oldwebui.wiki)
If someone find the backward arrow counter intuitive.
(14) By Warren Young (wyoung) on 2022-06-30 14:27:49 in reply to 12 [link] [source]
Nice; the parens make that easier to parse.
On parsing: the “from” bit should be elided in the “f changes --renamed
” case. Existing scripts that depend on current behavior are more likely to rely on that functionality subset than passing raw “status” or “changes” output.
While we should consider parse-ability of the raw output, we must absolutely protect the interfaces best suited to parsing.
(16) By Stephan Beal (stephan) on 2022-06-30 15:16:49 in reply to 14 [link] [source]
On parsing: the “from” bit should be elided in the “f changes --renamed” case.
That's a good point (and i wasn't even aware of that option), but it's beyond my patching aspirations today ;). The patch was posted in my previous reply, if one of you cares to expand upon that and maybe get the the order of the filenames swapped so that it's old==>new.
(13) By Daniel Dumitriu (danield) on 2022-06-30 14:27:47 in reply to 11 [link] [source]
I'd take this (<=
) - it's visually clear and avoids having to cut off the trailing bracket, should one need to wrap it in scripts.
(15.2) By Stephan Beal (stephan) on 2022-06-30 15:17:47 edited from 15.1 in reply to 13 [link] [source]
The left arrow just seems really weird to me (perhaps it just requires getting used to). How about:
#1:
[stephan@nuc:~/fossil/fossil/www]$ f chan
EDITED ../src/checkin.c
RENAMED xxxx.wiki [was: www/webui.wiki]
#2:
[stephan@nuc:~/fossil/fossil/www]$ f chan
EDITED ../src/checkin.c
RENAMED xxxx.wiki ->was-> www/webui.wiki
#3:
[stephan@nuc:~/fossil/fossil/www]$ f chan
EDITED ../src/checkin.c
RENAMED xxxx.wiki ==was==> www/webui.wiki
#4:
[stephan@nuc:~/fossil/fossil/www]$ f chan
EDITED ../src/checkin.c
RENAMED xxxx.wiki ~~~pikchr\nright; arrow -> "Was" aligned above~~~ www/webui.wiki
(Doh - that last one reveals a size calculation bug in pikchr!)
#3 looks the best of those 4 to me, but i'm ambivalent - i use libfossil's f-status
for the sake of dogfooding ;). Y'all decide and let me know which to check in. If you'd like to play with it locally, here's the patch:
Index: src/checkin.c
==================================================================
--- src/checkin.c
+++ src/checkin.c
@@ -153,11 +153,12 @@
blob_zero(&sql);
if( flags & C_ALL ){
/* Start with a list of all managed files. */
blob_append_sql(&sql,
"SELECT pathname, %s as mtime, %s as size, deleted, chnged, rid,"
- " coalesce(origname!=pathname,0) AS renamed, 1 AS managed"
+ " coalesce(origname!=pathname,0) AS renamed, 1 AS managed,"
+ " origname"
" FROM vfile LEFT JOIN blob USING (rid)"
" WHERE is_selected(id)%s",
flags & C_MTIME ? "datetime(checkin_mtime(:vid, rid), "
"'unixepoch', toLocal())" : "''" /*safe-for-%s*/,
flags & C_SIZE ? "coalesce(blob.size, 0)" : "0" /*safe-for-%s*/,
@@ -174,11 +175,11 @@
if( flags & C_EXTRA ){
if( blob_size(&sql) ){
blob_append_sql(&sql, " UNION ALL");
}
blob_append_sql(&sql,
- " SELECT pathname, %s, %s, 0, 0, 0, 0, 0"
+ " SELECT pathname, %s, %s, 0, 0, 0, 0, 0, NULL"
" FROM sfile WHERE pathname NOT IN (%s)%s",
flags & C_MTIME ? "datetime(mtime, 'unixepoch', toLocal())" : "''",
flags & C_SIZE ? "size" : "0",
fossil_all_reserved_names(0), blob_sql_text(&where));
}
@@ -211,10 +212,11 @@
int size = db_column_int(&q, 2);
int isDeleted = db_column_int(&q, 3);
int isChnged = db_column_int(&q, 4);
int isNew = isManaged && !db_column_int(&q, 5);
int isRenamed = db_column_int(&q, 6);
+ const char *zOrigName = 0;
char *zFullName = mprintf("%s%s", g.zLocalRoot, zPathname);
int isMissing = !file_isfile_or_link(zFullName);
/* Determine the file change classification, if any. */
if( isDeleted ){
@@ -265,10 +267,11 @@
}else if( (flags & (C_EDITED | C_CHANGED)) && isChnged
&& (isChnged<2 || isChnged>9) ){
zClass = "EDITED";
}else if( (flags & C_RENAMED) && isRenamed ){
zClass = "RENAMED";
+ zOrigName = db_column_text(&q,8);
}else if( (flags & C_UNCHANGED) && isManaged && !isNew
&& !isChnged && !isRenamed ){
zClass = "UNCHANGED";
}else if( (flags & C_EXTRA) && !isManaged ){
zClass = "EXTRA";
@@ -296,10 +299,13 @@
zDisplayName = blob_str(&rewrittenPathname);
if( zDisplayName[0]=='.' && zDisplayName[1]=='/' ){
zDisplayName += 2; /* no unnecessary ./ prefix */
}
blob_append(report, zDisplayName, -1);
+ if(zOrigName){
+ blob_appendf(report, " ==was==> %s", zOrigName);
+ }
}else{
/* If not C_RELPATH, display paths relative to project root. */
blob_append(report, zPathname, -1);
}
blob_append(report, "\n", 1);
(17) By Martin Gagnon (mgagnon) on 2022-06-30 15:37:41 in reply to 15.2 [link] [source]
I definitively prefer #1
.
Personally, I find #3 even weirder than the <==
.
As for parsing and the end bracket, it's a bit true, but really still very trivial to do with simple script in bash with cut
, sed
, awk
, etc.. or even with bash internal variable substitution.
(18) By Daniel Dumitriu (danield) on 2022-06-30 15:57:23 in reply to 15.2 [link] [source]
I am also for #1, unless you happen to like
RENAMED aaa.txt < bbb.txt
or
RENAMED aaa.txt < bbb.txt
(incidentally, '<
means 'derives/comes from' in linguistics, e.g. terse < tersum < tergere)
(19) By Alfred M. Szmidt (ams) on 2022-07-01 02:23:31 in reply to 15.2 [link] [source]
#1, the other are ... strange.
(6) By Stephan Beal (stephan) on 2022-06-30 12:11:17 in reply to 4 [link] [source]
Since each change entries otherwise are always in a single line.
My reason for not doing that is that filenames can get be arbitrarily long and may have spaces, making it more difficult for the eyes to figure out where the two fields are.
That said: if that's how the majority of people want it that's fine with me. Readability suffers, though.
(10) By Andy Bradford (andybradford) on 2022-06-30 12:52:11 in reply to 6 [link] [source]
> My reason for not doing that is that filenames can get be arbitrarily > long and may have spaces And that's a very good reason. This is one of those grey areas, maybe -v could be used to make it multi-line, or maybe even hide the additional output unless -v is specified? Personally, in line-oriented things, like lists of files (or changes to files), I find it much easier to read a long line, than to read to the end of the line and expect more data on the next line. Even if there are spaces (which if we really thought would be a problem, could be quoted). Andy
(8.1) By Andy Bradford (andybradford) on 2022-06-30 12:59:11 edited from 8.0 in reply to 3 [link] [source]
I think it would be better if the output remained all on one line: [stephan@nuc:~/fossil/fossil/www]$ f chan EDITED ../src/checkin.c RENAMED xxxx.wiki from www/webui.wiki [stephan@nuc:~/fossil/fossil/www]$ f chan EDITED ../src/checkin.c RENAMED xxxx.wiki <= www/webui.wiki Or something like that. Seems like one line per file is more appropriate. Thanks, Andy
(9.2) By Alfred M. Szmidt (ams) on 2022-06-30 12:54:21 edited from 9.1 in reply to 8.0 [link] [source]
I can only say that I agree.
[edit] That is not to say that I object to a multiple line variant. Single line might break things slightly less for programs that parse the output of "fossil status" though, and make it easier to do adhoc loops, think:
for x in $(fossil status|grep RENAMED); do
src=$(echo $x | awk '{print $1}')
dest=$(echo $x | awk '{print $3}')
## MAGIC
done
(20) By Stephan Beal (stephan) on 2022-07-04 01:03:57 in reply to 9.2 [link] [source]
Single line might break things slightly less for programs that parse the output of "fossil status" though, and make it easier to do adhoc loops, ...
"Last call": the current preference, because Alfred started this thread and he expressed it as his favorite of the posted options, is:
RENAMED foo [was: bar]
FWIW, i think y'all will find that 2-line output is more readable in practice. As far as parsing the output goes, we've never made any guarantees regarding output stability or parseability, and we've only ever accounted for that when making past changes when it hasn't been a hassle to do so.
If you have a strong opinion on some format other than the one shown above, please voice it, else i'll check that in in the next day or two (noting that anyone else is welcome to do so before then).
(21) By Andy Bradford (andybradford) on 2022-07-04 04:47:19 in reply to 20 [link] [source]
> FWIW, i think y'all will find that 2-line output is more readable in practice. I've never had a problem with a single-line output for ls (consider the output in this example): $ ls -l total 4 drwxr-xr-x 2 amb wheel 512 Jul 3 22:40 directory/ prw-r--r-- 1 amb wheel 0 Jul 3 22:40 namedpipe| -rw-r--r-- 1 amb wheel 0 Jul 3 22:40 normalfile lrwxr-xr-x 1 amb wheel 6 Jul 3 22:40 symlink@ -> target I see this kind of thing no more different than the symbolic link output. I certainly don't think that the ls output would be improved if the symbolic link spanned multiple lines. As for which rendition of the output is better for fossil RENAME, I thought the one with parentheses was better than square brackets, but either works I suppose. However, perhaps we should remove the word "was:" from the output entirely and simply make it: RENAMED foo [bar] But I can certainly see that including "was:" in there might make it easier to understand the first time it is seen. The presence of "was:" reminds me too much of an email subject that has been altered. Thanks, Andy
(22) By Stephan Beal (stephan) on 2022-07-04 04:55:37 in reply to 21 [link] [source]
(consider the output in this example):
Consider, however, that renamed files in fossil are likely to be longer on both the left and right sides of that arrow, making the border between the LHS and RHS more difficult to quickly spot. Symlinks always have ony a single filename element in their LHS.
But I can certainly see that including "was:" in there might make it easier to understand the first time it is seen.
Seeing foo [bar]
without any indication of what it's supposed to mean would just confuse me. Whether it's [was: bar]
or (was: bar)
or <was: bar>
makes no difference to me, though.
Ideally we could easily swap the order of the names, separate them with =>
, and leave out "was", but that would require more "going against the grain" of that routine's structure than i'm up for.
The presence of "was:" reminds me too much of an email subject that has been altered.
Semantically, it's not much different: a filename is kind of the "subject line" of the file.
(23) By Andy Bradford (andybradford) on 2022-07-04 05:53:51 in reply to 22 [link] [source]
> Seeing foo [bar] without any indication of what it's supposed to mean > would just confuse me. Understood. It's just a suggestion, and something that would be a "learned behavior" as I am so accustomed to being told. :-) > Ideally we could easily swap the order of the names, separate them > with =>, and leave out "was", I don't really think it's worth all that effort either. I'm fine with the order (I also like reverse polish notation). Thanks, Andy
(24) By Andy Bradford (andybradford) on 2022-07-04 05:57:06 in reply to 22 [link] [source]
> Symlinks always have ony a single filename element in their LHS. "Au contraire mon frere", it depends on how the filename is arrived at: $ find /tmp/test | xargs ls -ld drwxr-xr-x 3 amb wheel 512 Jul 3 22:40 /tmp/test drwxr-xr-x 2 amb wheel 512 Jul 3 22:40 /tmp/test/directory prw-r--r-- 1 amb wheel 0 Jul 3 22:40 /tmp/test/namedpipe -rw-r--r-- 1 amb wheel 0 Jul 3 22:40 /tmp/test/normalfile lrwxr-xr-x 1 amb wheel 6 Jul 3 22:40 /tmp/test/symlink -> target Just saying. :-) Andy
(25) By Alfred M. Szmidt (ams) on 2022-07-04 06:41:42 in reply to 20 [link] [source]
I would mainly prefer that, over multiple lines (simply because you can parse it using hacks, even if it is not supported :-). But I’d be just as fine with multiple lines as well, but if they looked something like:
RENAMED foo
from: bar
Note the alignment.
The arrow notations are a bit too much (for me anyway), unless the simple -> is used, but then one has to throw about the arguments (old to new is easier to understand than vice versa), which has its own problems implementation wise.
As for () or [], no great preferences possibly () over []. But nothing I’d care too much about.
(26) By mark on 2022-07-04 07:04:38 in reply to 25 [link] [source]
The below diff is a slightly modified version of Stephan's patch, which produces the following behaviour:
✓ release → ./fossil mv --hard README.md README
RENAME README.md README
MOVED_FILE /src/fsl/fossil/release/README.md
✓ release → ./fossil changes
RENAMED README.md -> README
✓ release → ./fossil changes --renamed
README
I already shared with Stephan offlist; if preferred, we can continue with this change.
Index: src/checkin.c
=======================================================================
hash - 987faee812d72ba9afad585d4647e28c2bd2e6031a50aa66533789ce28e34276
hash + db4f2c625945ad8aa6d21eecda243b764513edb6b8dc00f060e2e30ff5cdeeb4
--- src/checkin.c
+++ src/checkin.c
@@ -155,7 +155,8 @@ static void status_report(
/* Start with a list of all managed files. */
blob_append_sql(&sql,
"SELECT pathname, %s as mtime, %s as size, deleted, chnged, rid,"
- " coalesce(origname!=pathname,0) AS renamed, 1 AS managed"
+ " coalesce(origname!=pathname,0) AS renamed, 1 AS managed,"
+ " origname"
" FROM vfile LEFT JOIN blob USING (rid)"
" WHERE is_selected(id)%s",
flags & C_MTIME ? "datetime(checkin_mtime(:vid, rid), "
@@ -176,7 +177,7 @@ static void status_report(
blob_append_sql(&sql, " UNION ALL");
}
blob_append_sql(&sql,
- " SELECT pathname, %s, %s, 0, 0, 0, 0, 0"
+ " SELECT pathname, %s, %s, 0, 0, 0, 0, 0, NULL"
" FROM sfile WHERE pathname NOT IN (%s)%s",
flags & C_MTIME ? "datetime(mtime, 'unixepoch', toLocal())" : "''",
flags & C_SIZE ? "size" : "0",
@@ -213,6 +214,7 @@ static void status_report(
int isChnged = db_column_int(&q, 4);
int isNew = isManaged && !db_column_int(&q, 5);
int isRenamed = db_column_int(&q, 6);
+ const char *zOrigName = 0;
char *zFullName = mprintf("%s%s", g.zLocalRoot, zPathname);
int isMissing = !file_isfile_or_link(zFullName);
@@ -267,6 +269,7 @@ static void status_report(
zClass = "EDITED";
}else if( (flags & C_RENAMED) && isRenamed ){
zClass = "RENAMED";
+ zOrigName = db_column_text(&q,8);
}else if( (flags & C_UNCHANGED) && isManaged && !isNew
&& !isChnged && !isRenamed ){
zClass = "UNCHANGED";
@@ -297,7 +300,11 @@ static void status_report(
if( zDisplayName[0]=='.' && zDisplayName[1]=='/' ){
zDisplayName += 2; /* no unnecessary ./ prefix */
}
- blob_append(report, zDisplayName, -1);
+ if( (flags & C_FILTER^C_RENAMED) && zOrigName ){
+ blob_appendf(report, "%s -> %s", zOrigName, zDisplayName);
+ }else{
+ blob_append(report, zDisplayName, -1);
+ }
}else{
/* If not C_RELPATH, display paths relative to project root. */
blob_append(report, zPathname, -1);
(27) By Alfred M. Szmidt (ams) on 2022-07-15 07:46:09 in reply to 26 [link] [source]
I see that this got added to trunk! Nice! Thank you Stephan and Mark!