These flags only apply to line-based diffs. This is easy, and seems still useful
to highlight whitespace changes (that could be ignored by line diffing.)
I've added short options only to "diff"-like commands. It seemed unclear if
they were added to deeply-nested commands such as "op log".
Closes#3781
Since we've moved the default log revset to config/*.toml at 3dab92d2, we don't
have to repeat the default value. It can be queried by "jj config list". I also
split the help paragraphs.
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.
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.
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.
It's a pretty frequent request to have support for turning off
auto-tracking of new files and to have a command to manually track
them instead. This patch adds a `snapshot.auto-track` config to decide
which paths to auto-track (defaults to `all()`). It also adds a `jj
track` command to manually track the untracked paths.
This patch does not include displaying the untracked paths in `jj
status`, so for now this is probably only useful in colocated repos
where you can run `git status` to find the untracked files.
#323
This flag implements three modes:
- `copy`: copy sparse patterns from parent
- `full`: do not copy sparse patterns from parent
- `empty`: clear all paths, equal to `set --clear`
This is useful for various tooling like tools that want to run a parallel
process that queries the build system (without running into locks/blocking.)
I think continuing to copy sparse patterns makes sense as the default behavior.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This enables workflows like "insert a commit that reformats the code in one of
my project directories".
`jj fix --include-unchanged-files` is an easy way to fix everything in the repo.
`jj fix --include-unchanged-files <file...>` fixes all of the `<files>` even if they are
unchanged.
This is mostly orthogonal to other features, so not many tests are added.
This is a significant and simple enough improvement that I think it's
appropriate to make it here instead of waiting for a `jj run`-based solution.
It seems everyone agrees that `obslog` is not an intuitive name. There
was some discussion about alternatives in #3592 and on #4146. The
alternatives included `evolution`, `evolutionlog`, `evolog`,
`rewritelog`, `revlog`, and `changelog`. It seemed like
`evolution-log`/`evolog` was the most popular option. That also
matches the command's current help text ("Show how a change has
evolved over time").
"Concurrent" operations are not necessarily actually concurrent, so
"divergent" seems like a better name. And "reconcile" seems like a
better term for merging them, though we also sometimes use "merge".
* We started with a tristate flag where:
- Auto - Maintain current behaviour. This edits if
the wc parent is not a head commit. Else, it will
create a new commit on the parent of the wc in
the direction of movement.
- Always - Always edit
- Never - Never edit, prefer the new+squash workflow.
However, consensus the review thread is that `auto` mode where we try to infer when to
switch to `edit mode`, should be removed. So `ui.movement.edit` is a boolean flag now.
- true: edit mode
- false: new+squash mode
* Also add a `--no-edit` flag as the explicit inverse of `--edit` and
ensure both flags take precedence over the config.
* Update tests that assumed edit mode inference, to specify `--edit` explicitly.
NOTE: #4302 was squashed into this commit, so see that closed PR for review history.
Part of #3947
This partially reverts 543036c753 "cli: run 'op log' without loading repo or
merging concurrent ops." User can now get around the issue by --at-op=@
--ignore-working-copy.
The idea is that --at-op specifies a certain operation, so --at-op=@ can be
interpreted as the option to select _the_ known head operation. This helps
eliminate special cases from "op log" which doesn't snapshot nor merge
concurrent ops.
The high level changes include:
- Reworking `fix_file_ids()` to loop over multiple candidate tools per file,
piping file content between them. Only the final file content is written to
the store, and content is no longer read for changed files that don't match
any of the configured patterns.
- New struct `ToolsConfig` to represent the parsed/validated configuration.
- New function `get_tools_config()` to create a `ToolsConfig` from a `Config`.
- New tests; the only old behavior that has changed is that we don't require
`fix.tool-command` if `fix.tools` defines one or more tools. The general
approach to validating the config is to fail early if anything is weird.
Co-Authored-By: Josh Steadmon <steadmon@google.com>
We now have two `cmd_show` in the repo. I think this one should become
`cmd_file_show`, but this should be done uniformly over all the commands
for consistency.
I did *not* keep `print` as an alias (I couldn't find a compelling
reason to do it), but let me know if anyone feels like keeping it.
Since "set <thing>" often adds a <thing> if not exists, it make some sense
that "branch set" does upsert. The current "branch set" use case is now covered
by "branch move", so it's okay to change the "set" behavior.
If new branch is created by "branch set", status message and hint will be
printed to help migration. The user should be able to undo creation if it was
a mistake.
Closes#3584
This allows users to jump to the next conflict in the ancestors or children of
the start commit.
Continues work on #2126
Co-Authored-By: Noah Mayr <dev@noahmayr.com>
