Perhaps, non-trivial keywords can be extracted to free functions, and both
parsing and property functions can be eventually moved to a commit templater
module?
This allows us to use "if(description,)" to test empty description. And
I think this change is unavoidable if we want to add support for commit
template.
This allows us to merge parse_boolean_commit_property() into
parse_commit_term(). We'll probably need similar type coercion methods
for the other basic types.
I considered adding something like Property::Template(), which could be
reused for map operation (e.g. 'revset().map(commit_id).join(" ")'.)
However, a mapped commit template would be different from the top-level
commit template regarding the lifetime of the context.
"Expression::<Commit>::Template()" takes "for<'b> &'b Commit" as an argument,
whereas a mapped template property would capture Commit object somewhere.
I keep calling it `underline` by mistake, so that probably means that
it's a more natural name for it. We haven't made a release of it yet,
so I didn't mention it in the changelog.
I didn't update all variables to also use `underline`, because I felt
that `underlined` was usually more natural there, plus crossterm calls
it `Attribute::Underlined`.
Many template keywords and methods are one liners, and I think that's actually
good because writing tests for templater would be more involved than for pure
functions.
This patch introduces a wrapper for such one-line functions, and migrates
method parser to that. Some of the commit keyword structs can also be ported
to this wrapper.
This refactors the unique prefix functionality and extracts a function
that will be reused by the styled prefix highlighting.
This also includes a minor change in functionality: if the unique prefix
of an id does not fit into the space provided, it is still printed.
Currently, this would happen if the prefix is more than 12 characters
long, which takes a huge repository. However, I'm hoping that in the
future we'll make this number customizeable.
I think this is the same bug as reported in #922, just simplified a
bit further. The branches in the repo actually look good after the
`undo` operation, but the reverted `master` branch doesn't get
exported to the git repo even though our recorded `refs/heads/master`
in the repo was moved back. Then the next automatic import on `log`
notices that the `master` branch in the git repo still points to the
new commit, and that commit becomes visible again.
Git's HEAD ref is similar to other refs and can logically have
conflicts just like the other refs in `git_refs`. As with the other
refs, it can happen if you run concurrent commands importing two
different updates from Git. So let's treat `git_head` the same as
`git_refs` by making it an `Option<RefTarget>`.
Fix a bug where `jj git push` would print "No current branch." when
there is a current branch but it is unchanged. We were conflating the
two because we print the message when no updates were performed, instead
of only when no branches were found.
Add a new git.auto-local-branch config option. When set to false, a
remote-tracking branch imported from Git will not automatically create a
local branch target. This is implemented by a new GitSettings struct
that passes Git-related settings from UserSettings.
This behavior is particularly useful in a co-located jj and Git repo,
because a Git remote might have branches that are not of everyday
interest to the user, so it does not make sense to export them as local
branches in Git. E.g. https://github.com/gitster/git, the maintainer's
fork of Git, has 379 branches, most of which are topic branches kept
around for historical reasons, and Git developers wouldn't be expected
to have local branches for each remote-tracking branch.
I don't think there's a good reason not to write the
`.jj/working_copy/tree_state` file on init. Being able to assume that
the file exists means that we won't need the store object to to lazily
load the `TreeState` object. Well, except that `TreeState` keeps an
`Arc<Store>`, but I'm trying to change that.
Before, "f()" was parsed as a function call with one empty argument. In
practice, this change means "if(divergent,,false_template)" is no longer
valid.
When building an initial index from an existing Git repo, for example,
we walk parents and predecessors to find all commits to index. Part of
that code was looking up the whole parent and predecessor commits even
though it only needed the ids. I don't know if this has a measurable
impact on performance, but it's not really any more complex to just
get the ids anyway.
Suppose "template" is a sequence of "term"s, it makes more sense to handle
an empty sequence there. It might be even better to disallow empty template
other than the top-level one.
A "list" is a sequence of more than one "term" nodes, so it shouldn't contain
a single parenthesized node.
Also, a parenthesized "term" rule wasn't handled.
