`jj bookmark` is a frequently used command. Its subcommands already have
one letter aliases. Defining `jj b` as an alias for `jj bookmarks` make
bookmarks really easy to use.
I think it's slightly easier to follow if we calculate a diff of input bits
first. I don't know which one is faster, but I assume compiler can optimize to
similar instructions.
Comparing each byte before comparing the nibbles is more efficient. A
benchmark comparing the old and new implementations with various common
prefix lengths shows:
```
Common hex len/old/3 time: [7.5444 ns 7.5807 ns 7.6140 ns]
Common hex len/new/3 time: [1.2100 ns 1.2144 ns 1.2192 ns]
Common hex len/old/6 time: [11.849 ns 11.879 ns 11.910 ns]
Common hex len/new/6 time: [1.9950 ns 2.0046 ns 2.0156 ns]
Common hex len/old/32 time: [63.030 ns 63.345 ns 63.718 ns]
Common hex len/new/32 time: [6.4647 ns 6.4800 ns 6.4999 ns]
```
"Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here
is redundant. If we add support for pushing tags, this message will have to be
generalized anyway.
This makes it easier to work with multiple remotes at once while
tracking the default branch of the remote used to create the local
repository:
```shell
$ jj git clone --remote upstream https://github.com/upstream-org/repo
$ cd repo
$ jj git remote add origin git@github.com:your-org/repo
$ jj config set --repo git.fetch upstream
```
In the example above, `upstream` is the repository containing the
reference source code that you might want to patch, while `origin` is
your fork where pull-request will be pushed. The branch `main@upstream`
will be tracked.
We missed this when we renamed `push-branch-prefix` to
`push-bookmark-prefix`. I changed the description slightly to try to
clarify that it's about the local bookmark that's created before
pushing it to the remote as a branch.
In order for the governance working group to make progress establishing
jj's governance structure, we need the approval of the jj community.
Set up a temporary voting process to get that approval.
Additionally, set up a governance dir for other governance-related
documentation to sit in.
Later, when we have a permanent governance structure and enough policy
to let the community make changes without needing the governance working
group, we can delete this document.
This is basically "log -p" for "op log". The flag name has "op" because --diff
and --patch mean a similar thing in this context. Since -p implies --op-diff,
user can just do "op log -p" if he's okay with verbose op + content diffs.
Note that --no-graph affects both "op log" and "op diff" parts.
We might want to do some style changes later, such as inserting/deleting blank
lines, highlighting headers, etc.
Multiple graphs will be nested in "op log" output, and things would be messy if
we had to calculate graph widths lazily. Let's simply make LogContentFormat
track the current available width no matter if ui.log-word-wrap is off.
Jujutsu's branches do not behave like Git branches, which is a major
hurdle for people adopting it from Git. They rather behave like
Mercurial's (hg) bookmarks.
We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord,
where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were
reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name
the current mechanism. This may be hard break for current `jj branch` users, but it will immensly
help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]`
config option is currently left alone, to force not another large config update for
users, since the last time this happened was when `jj log -T show` was removed, which immediately
resulted in breaking users and introduced soft deprecations.
This name change will also make it easier to introduce Topics (#3402) as _topological branches_
with a easier model.
This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from
me being lazy or thankfully pointed out by reviewers.
`jj new <commit>` automatically adds the checked out commits into the view head ids. However,
`jj edit` does not.
To reproduce:
```
jj git init test
cd test
jj commit -m "my commit"
jj log -r @- -T commit_id # Save the id
jj abandon -r @-
jj edit <saved_id>
jj log -r :: # Does not show the currently editing commit
```
I'll use a similar setup in "op log", but for each log entry. We might want to
extract some parts to helper function, but I don't have a good idea right now.
CommandHelper::operation_template_extensions() is removed because it's unlikely
to parse operation template without loading a workspace.
