fossil update silent mode
(1) By anonymous on 2024-06-14 07:29:01 [link] [source]
Hello, it would be nice if there was a silent/quiet mode for fossil update so that it will not show all the files it updates. It takes a while for the terminal to scroll through hundreds of thousands of files, atleast on windows.
(2) By Warren Young (wyoung) on 2024-06-14 15:24:40 in reply to 1 [link] [source]
silent/quiet mode for fossil update
What's wrong with…
C:\PATH\TO\CHECKOUT> fossil update > NUL
hundreds of thousands of files
May I be permitted to know why you have so many files in a single repository? Every Fossil commit artifact grows by the total number of files in the repo. Another organization might be advisable.
atleast on windows.
True. On the first-gen M1 laptop I'm typing this on:
$ ls -lR / > /tmp/lotsa-files.txt # …followed by Ctrl-C in another tab, later
$ wc -l /tmp/lotsa-files.txt
538786 /tmp/lotsa-files.txt
$ time cat /tmp/lotsa-files.txt
0.00s user 0.10s system 9% cpu 1.086 total
Round numbers, 1 second to display 500k lines.
I then copied that over to a Windows 11 ARM64 VM, opened a PowerShell instance in Microsoft Terminal and said:
PS C:\Users\wyoung> Measure-Command { type Desktop\lotsa-files.txt | Out-Default }
…
Days : 0
Hours : 0
Minutes : 0
Seconds : 59
Milliseconds : 70
Ticks : 590706845
TotalDays : 0.000683688478009259
TotalHours : 0.0164085234722222
TotalMinutes : 0.984511408333333
TotalSeconds : 59.0706845
TotalMilliseconds : 59070.6845
Sixty…times…longer!
In a WSL2 shell on the same host, running Ubuntu 22.04 LTS in the same Terminal instance, running the macOS version of the command gives:
real 0m19.149s
user 0m0.000s
sys 0m5.703s
Only nineteen times longer.
Switching to an Ubuntu 24.04 LTS VM on the same hardware:
$ time cat lotsa-files.txt
0.00s user 0.20s system 23% cpu 0.879 total
Same as under macOS, more or less.
I think the lesson is clear: ditch Windows. 🤓
(3) By anonymous on 2024-06-15 08:43:27 in reply to 2 [link] [source]
C:PATHTOCHECKOUT> fossil update > NUL
I didn't think of this, I'll use this for now thanks. But I don't get to see the summary.
May I be permitted to know why you have so many files in a single repository? > Every Fossil commit artifact grows by the total number of files in the repo. > Another organization might be advisable.
It's decompilation of software, I have no control over how many files gets created.
I think the lesson is clear: ditch Windows. 🤓
I wish I could :)
(4) By Stephan Beal (stephan) on 2024-06-15 10:33:12 in reply to 3 [link] [source]
But I don't get to see the summary
Nor will you see any warnings about merge conflicts.
(5) By spindrift on 2024-06-16 06:12:49 in reply to 1 [link] [source]
How long does it take if you redirect the output to a file instead?
Then you can still peruse if you wish to.
I've no idea if it might even be slower.
(6) By Warren Young (wyoung) on 2024-06-17 20:44:46 in reply to 3 [source]
I have no control over how many files gets created.
Then you're committing generated files, a classic mistake. Commit only inputs — the executables you're studying in this case — and script re-creation of the outputs from those presumably fewer and more compact inputs.
If the EXE files are uncompressed, as they usually are, this should still result in fairly small deltas between versions, as they will share large chunks of common code. You will lose the ability to diff generated versions, but external diff is widely available.