How do we know when there are "just enough" flags?

[joyously]

I know Git has a lot of flags for every command, which I think is excessive. But jj might not have enough.
I starting reading the help for Git and found the following examples. Can jj handle these same questions?
Log

git log v2.6.12.. include/scsi drivers/scsi
   Show all commits since version v2.6.12 that changed any file in the 
   include/scsi or drivers/scsi subdirectories

git log --since="2 weeks ago" -- gitk
   Show the changes during the last two weeks to the file gitk. The -- is 
   necessary to avoid confusion with the branch named gitk

git log --name-status release..test
   Show the commits that are in the "test" branch but not yet in the "release" 
   branch, along with the list of paths each commit modifies.

git log --follow builtin/rev-list.c
   Shows the commits that changed builtin/rev-list.c, including those commits
   that occurred before the file was given its present name.

git log --branches --not --remotes=origin
   Shows all commits that are in any of local branches but not in any of
   remote-tracking branches for origin (what you have that origin doesn’t).

git log master --not --remotes=*/master
   Shows all commits that are in local master but not in any remote repository 
   master branches.

git log -L '/int main/',/^}/:main.c
   Shows how the function main() in the file main.c evolved over time.

Show

git show v1.0.0
   Shows the tag v1.0.0, along with the object the tags points at.

git show v1.0.0^{tree}
   Shows the tree pointed to by the tag v1.0.0.

git show -s --format=%s v1.0.0^{commit}
   Shows the subject of the commit pointed to by the tag v1.0.0.

git show next~10:Documentation/README
   Shows the contents of the file Documentation/README as they were current in 
   the 10th last commit of the branch next.

git show master:Makefile master:t/Makefile
   Concatenates the contents of said Makefiles in the head of the branch master.

Blame

Count the number of lines attributed to each author
 git blame --line-porcelain file |
 sed -n 's/^author //p' |
 sort | uniq -c | sort -rn

When you are interested in finding the origin for lines 40-60 for file foo, you 
can use the -L option like so (they mean the same thing — both ask for 21 lines 
starting at line 40):
   git blame -L 40,60 foo
   git blame -L 40,+21 foo

Also you can use a regular expression to specify the line range:
   git blame -L '/^sub hello {/,/^}$/' foo
which limits the annotation to the body of the hello subroutine.

When you are not interested in changes older than version v2.6.18, or changes 
older than 3 weeks, you can use revision range specifiers similar to git rev-list:
   git blame v2.6.18.. -- foo
   git blame --since=3.weeks -- foo

A particularly useful way is to see if an added file has lines created by 
copy-and-paste from existing files. Sometimes this indicates that the developer 
was being sloppy and did not refactor the code properly. You can first find the 
commit that introduced the file with:
   git log --diff-filter=A --pretty=short -- foo
and then annotate the change between the commit and its parents, using 
commit^! notation:
   git blame -C -C -f $commit^! -- foo

[arxanas]

Of course, jj would prefer to use revsets rather than flags because they can be composed more easily (e.g. pass the same value directly to jj rebase). The revset language is definitely missing important stuff. I think the structural failings are with regards to blaming/following.

---

My assessment below might have some mistakes.

git log v2.6.12.. include/scsi drivers/scsi

Yes (file).

git log --since="2 weeks ago" -- gitk

Not yet, we should add revset functions to filter based on date.

git log --name-status release..test

Not yet, we should add a template function to get the files changed in a commit.

git log --follow builtin/rev-list.c

No, currently no following/blaming/crediting implementation.

git log --branches --not --remotes=origin

Yes (I believe with branches + remote_branches somehow).

git log master --not --remotes=*/master

Yes (same as previous?).

git log -L '/int main/',/^}/:main.c

No, currently no following/blaming/crediting implementation or addressing file contents by regex.

git show v1.0.0

Yes.

git show v1.0.0^{tree}

No, currently no way to extract the tree object in the revset language, and I think jj show only shows commits.

git show -s --format=%s v1.0.0^{commit}

Yes.

git show next~10:Documentation/README

Yes, I think with jj cat? (I think jj cat is a bad name.)

git show master:Makefile master:t/Makefile

No, but I think it's probably better to use the shell to concatenate these.

Re blame commands, we have no blame functionality.