I'm the author of Bttf. I just wanted to share a really cool example of something that Bttf can do that I _think_ is kinda hard to do otherwise. (And also, I want to make an assertion about it and I hope this will lead to me being wrong and learning something new.)
The use case is: "I want to see a list of all files in a repository, sorted in ascending order of when it was most recently changed according to source control. I also want to highlight the time with color, make it be in local time and format it in my own bespoke way using strftime." Here's the full command (run from the root of https://github.com/BurntSushi/ripgrep):
$ git ls-files |
bttf tag exec git log -n1 --format='%aI' |
bttf time in system |
bttf time sort |
bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
bttf untag -f '{tag}|t{data}'
...
Thu 2025-10-30 13:30:14 crates/ignore/Cargo.toml
Sat 2025-11-29 14:11:38 crates/core/flags/lowargs.rs
Wed 2025-12-17 11:38:12 tests/misc.rs
Wed 2025-12-17 11:38:12 tests/util.rs
Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
Fri 2026-02-27 11:25:19 GUIDE.md
Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs
Mon 2026-05-25 23:56:53 CONTRIBUTING.md
Tue 2026-05-26 08:32:43 AI_POLICY.md
$ git ls-files |
bttf tag exec git log -n1 --format='%aI' |
bttf time in system |
bttf time cmp ge 2026-01-01 |
bttf time cmp lt 2026-04-01 |
bttf time sort |
bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
bttf untag -f '{tag}|t{data}'
Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
Fri 2026-02-27 11:25:19 GUIDE.md
Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs
> “If you run this on a big repository, it will take quite a lot of time because `git log -n1` takes a long time. I think this is the fastest way to get the most recent commit time on a single file? (That's the assertion that I hope someone can correct me on!) In any case, `bttf tag exec` is using parallelism under the hood to make this even faster.”
Instead of running `git log -n1` on every file, I think you can walk through the commits backwards, skipping any files that have been seen. Something like this (these two commands could be followed by bttf commands):
This seems to run much faster. The only problem is it'll include files that have been renamed or removed. I got an AI to fix that too, but it starts getting awkward (still fast though!):Oh interesting! That is indeed quite a bit faster.
I'll have to noodle on this one. `bttf tag exec` works with arbitrary commands that can print any kind of date. But your approach require a different access pattern. I can either specialize the use case in bttf (blech) or I can figure out how to generalize your approach.
I think the key issue here is probably that it isn't line oriented. bttf composes well, but only when you have a one-to-one relationship between date and data. (Or a many-to-one is also supported, but it's many dates to one datum, not one date to many datums.) So maybe that relational model is worth figuring out how to streamline. Then I think this use case would work better.
Also, thank you! This is exactly the kind of reply I was hoping for! :D
Pretty recent Git versions have git-last-modified(1) which can list all files along with the last modified commit.
Oh neat! TIL about `git last-modified`. That looks like a fun one to explore. Thank you.
> I think [`git log -n1 -- <path>`] is the fastest way to get the most recent commit time on a single file?
In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).
Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.
Yeah totally right. I just don't know enough about git to figure it out. But a sibling commenter helped a lot.
And yeah perf probably doesn't matter much. But, like, running my approach on the Rust compile repo takes at least minute on my beefly (if a little dated) machine. But lukasgelbmann's approach only takes about 11 seconds. That's a big improvement.
Yeah though, perf here may not matter much. It's just an example use of bttf that is less than instant. (And it's not really bttf. It's my examples access pattern of git.)
Thank you for making cool stuff and sharing it with us.
This is pretty neat. My proficiency with the command line is woefully underdeveloped and seeing examples like this help me see the possibilities.
Quick Note: You can put the pipe operator where your backslash is and you won’t have to escape the newline character. Works in bash, zsh and ksh (what I’ve tested).
Oh nice thank you!
[flagged]