Fossil Forum

"fossil status" output for RENAMED to laconic
Login

"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! 😛

(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.

(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. 🔁⏩➡️🔀

(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

(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

(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.

(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.

(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.

(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);

(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.

(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.

(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!