Again, it was hard to read and edit this text when it was in a string inside an echo command inside a bash script inside a heredoc inside a Ruby script wrapped in a mystery. It also gives me space to write some actual comments.
Having it all echo-ed into the file like that made it hard to read *and* hard to maintain. My initial aversion to it was that I didn’t want there to be an executable script in the main repository that only worked when you were in the VM, because people would just run it anyway. But this can be avoided by leaving it non-executable, and having a command in the VM that runs it instead.
The ‘package-exa’ script’s zip contained /vagrant/exa-linux-x86_64 instead of just exa-linux-x86_64, and I never noticed.
https://stackoverflow.com/a/9710181/3484614 told me what to do.
This doesn’t *completely* work: it seems to have trouble with ignored paths beginning with slashes, possibly amongst others. Also, .gitignore scanning could be made more efficient.
I changed my mind about which way round sorting by “newest” or by “oldest” should actually go. If you’re listing a large directory, you see the last lines of the output first, so these files should be the ones with the largest whatever the sort field is. It’s about sorting *last*, not sorting *first*. Sorting by size wouldn’t say “sorts smallest files first”, it would say “sorts largest files last”. Right?
Also, add a new suggestion that warns against “ls -lt”.
This commit changes the definition of Arg so that it knows about which values it can accept, and can display them in the help text. They were already being shown in the help text, but they were passed in separately, so one argument could show two different sets of options if it wanted. Now, the argument itself knows whether there are suggestions, so it doesn’t have to be passed in separately.
This means we can use it for other things, including listing choices when an option is missed out, without having to repeat the list.
With Misfire::BadArgument now only having two fields, it’s not worth using a constructor function anymore.
Raised in #243 and #284. exa isn’t able to override the -t option like this, so the least it can do is detect that case (which is going to be an error case anyway) and show a suggestion.
I don’t really see the modified date as the *modified* date, rather just the *date* field, because it’s the date field I refer to like 99.9% of the time. So now it has aliases to match.
Also are included are aliases for the reverse order, because I’d rather write “new” than “the reverse of old”.
It said “(Choices: (choices: this, that, other))” instead of “(choices: this, that, other)”. Also improve the same error elsewhere: options more have ‘settings’ than ‘values’.
This commit adds to the parsing of the LS_COLORS and EXA_COLORS variables so that non-two-letter codes (keys other than things like ‘di’ or ‘ln’ or ‘ex’) will be treated as file name globs, and get used to colour files accordingly.
Fixes#116 for good.
This is more annoying than it should be because it has to work with Styles rather than with strings, which means parsing them, and parsing is always tricky business.
This merges in the new Git code, which now uses a global cache rather than being per-repository. This lets exa keep the Git column when listing files outside of a directory and when in recursive or tree views.
Fixes#24 and #183.
This is all a big commit because it took a lot more work than I thought it would! The commit basically moves Git repositories from being per-directory to living for the whole life of the program. This allows for several directories in the same repository to be listed in the same invocation; before, it would try to rediscover the repository each time! This is why two of the tests “broke”: it suddenly started working with --recurse.
The Dir type does now not use Git at all; because a Dir doesn’t have a Git, then a File doesn’t have one either, so the Git cache gets passed to the render functions which will put them in the Table to render them.
This uses the Git module’s newfound powers of getting actual GitRepo values from a factory to cache repositories a bit more. Now, when querying two directories under the same repository, it’ll open both, see that they have the same workdir, and only use the first one.
This commit adds a cache for Git repositories based on the path being queried.
Its only immediate effect is that when you query the same directory twice (such as /testcases/git /testcases/git), it won’t need to check that the second one is a Git directory the second time. So, a minuscule optimisation for something you’d never do anyway? Wrong! It’s going to let us combine multiple entries over the same repository later, letting us use --tree and --recurse, because now Git scanning is behind a factory.
- Two different repositories being queried at once
- The same one being queried twice, at different depths
- Tests for --tree and --recurse that should break in the future when that’s implemented
- Also just more tests in general
