I don't see any reason for `TestEnvironent::normalize_output()` to
just delegate to a free `normalize_output()`. By inlining it, we make
it easier to make the normalization to depend on more state.
Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
I think if a particular test sets e.g. $JJ_TIMESTAMP, they would
expect it to get used by `run_jj()` but we currently overwrite a few
variables in that method. This patch makes it so we respect all
environment added to the test environment.
I'm going to use this for a test case that attempts to create
identical commits.
This adds a command that automatically bisects a range of commits
using a specified command. By not having the interactive kind
(e.g. `jj bisect good/bad/skip/reset`), we avoid - for now at least -
having to decide where to store the state. The user can still achieve
interactive bisection by passing their shell as the bisection command.
Closes#2987.
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
A subset of cli tests could fail if the system /etc/gitconfig had
configuration interfering with the tests. The cause seems to be running
of `jj` commands that would in turn use a `git` subprocess.
Fix this by setting `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL`, like
in `hermetic_git`.
Fixes#6159
This allows the user to select a particular file when using multiple
configs. In the event that a prompt cannot be displayed, the first
file will be automatically selected.
It's super common to pair test_env with repo_path.
Some of the tests still use absolute paths because it seemed rather confusing
to mix paths relative to the repo_root and to the env_root.
It's easier to review insta snapshot diffs than scanning panic log containing
lengthy output. I think this will also help printf debugging.
test_global_opts.rs is migrated to new API as an example.
I'm going to add "[EOF]" marker to test that command output is terminated by
newline char. This patch ensures that callers who expect a raw output string
would never be affected by any normalization passes.
Some common normalization functions are extracted as CommandOutputString
methods.
