JJ automation issues

jj-automation.md

Issues / annoyances encountered while adding jj support to Mozilla automation:

➤ had to fall back to git format-patch to get a patch in the right format.

Perhaps this could be done with a bunch of template stuff, or perhaps the upstream receiver could allow a more jj-compatible format.

➤ having to pass --no-graph to every single jj log invocation.

At least -G would be better, even though I usually only use --long-parameters in automation. I could have aliased "info" to ["log", "--no-graph"], but I don't like depending on magic config settings like that. It's harder for readers to see what the automation is doing.

Possible fix: builtin jj info?

Possible fix: "automation mode", perhaps via a command-line flag, that would default log to --no-graph and whatever else might make sense for automation usage. (By itself, it would just trade --no-graph for --auto, so it would need other things to make sense.)

➤ no equivalent to hg's modifies(path) revset.

files(path) is similar, but it includes files that were added/deleted, not just modified. Which is usually what I'd want. I was supporting an operation get_changed_files(diff_filter="AMD", revset)where "AMD" == "add, modify, delete" and one test uses modifies(foo) in the mercurial version. When using files(baz) with diff_filter="AM", I was getting an extra file foo in the output becausefiles(baz) included a change that deleted baz but also modified foo, so the "AM" filter passed it through. (The filter is too late after the revset has been resolved.)

Possible fix: add an optional filter parameter, so I could do files(foo, "add"|"modify")

➤ -T `commit_timestamp(self)' is undocumented.

Multiple times I needed to get the timestamp of a commit, and there seemed to be no way until I found commit_timestamp in the default templates. I also don't see the funky "self" parameter in the docs?

Possible fix: add a Commit.timestamp() function (and document it).

➤ datetime format

Related to the previous item, I wanted to get the same output for a timestamp that git and hg produce (for a test).

• Both git and hg (via |rfc822date) can produce dates in the RFC822 date format. jj required commit_timestamp(self).format("%a, %d %b %Y %H:%M:%S %z")
• Anoter case was commit_timestamp(self).format("%s")
• On the input side, JJ_TIMESTAMP parsing is rather strict , and I needed datetime.strptime(date, "%Y-%m-%d %H:%M:%S %z") in order to pass it as dt.isoformat() (but I was happy that isoformat() matched the expectation!)

Possible fix: add something to chrono.format.strftime to produce rfc822?

Possible fix: add Timestamp.epoch() (instead of .format("%s"))

No need to fix JJ_TIMESTAMP parsing itself, but I could have used a --timestamp or similar parameter to jj describe/jj commit multiple times now, for testing as well as automated imports of patch stacks from a different vcs. And if that existed, it might make sense to have it allow more flexible formats.

➤ newline-terminated template output

It was surprisingly hard to create a template that produced a single line of output for each relevant commit. The command I ended up with:

jj log -r <revset> --no-graph -T 'diff.files().map(|f| surround("", "\n", separate("\t", f.status(), f.source().path(), f.target().path()))).join("")'

I initially had it joining with newlines and then tacking on a final newline, but some of the changes in the revset had no results, so they produced a blank line. Without the final newline, the output from adjacent changes would run together. And I was most baffled by the default behavior of joining with spaces; I could not figure out why some lines were preceded with space and some weren't, when there were no spaces in my template.

surround("", "\n", ...).join("") works, but it's pretty cryptic.

Possible fix: maybe a terminate(suffix, t)=if(t.empty(),t ++ suffix,"") type of thing? (This particular implementation would require a String.empty() -> Boolean. Which I can't polyfill because there doesn't seem to be a way to convert a Template to a String, even if that Template is the output of separate()!).

Yes, generally the author timestamp is like a creation timestamp for the commit, while the committer timestamp is more like a last modified timestamp.

In some rare cases, jj subtracts 1 second from the committer timestamp I believe. Basically, if you create a new commit which would have an identical commit ID to an existing commit, it will subtract 1 second from the committer timestamp until the commit ID is unique. This is because jj maintains some additional metadata for each commit (predecessors and change ID), so it needs a unique ID for each commit.

I don't think this should ever happen in practice unless you are modifying a commit multiple times within a single second, and those modifications don't change any contents of the commit.