The goal of this change is to unify defaults of string patterns in revsets and
command arguments. Glob is a good default because it's largely the same as exact
matching, and we can easily express substring patterns with globs.
The hint for "jj git fetch -b<glob>" is deleted since exact:<glob> is now
required in order to trigger the error.
This patch also updates help of clone/fetch --branch patterns. Glob and operator
support in refspecs is limited.
As I'm going to deprecate git_head()/git_refs() functions, we'll need an
alternative command to debug view.git_head() movement. I think "git colocation
status" is a good place to print this kind of information.
We don't use "debug object view" because I expect git_head and git_refs will be
removed from the view object.
This paves the way to deprecate `git.auto-local-bookmark` without
adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks also tracks bookmarks that were created locally.
I think it just shows up in output snapshots as absent-tracked
bookmarks, without affecting what the test is about.
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.
When both `origin` and `upstream` are present, prefer `upstream` over `origin`
as the default remote for the `trunk()` alias.
This allows developers working on forks to have `trunk()` automatically point
to the `main` branch of the upstream repository rather than their fork's
origin. This is common when using the `gh` CLI to set up repositories.
Resolves#7228
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
We hear every now and then from users who have run `git clean -fdx`
and accidentally delete their repo. Let's at least warn users about it
when the create a colocated repo.
We could perhaps allow the `.jj/` directory to be inside a `.git/`
directory like Sapling does, but that seems a little ugly and it's a
larger change.
I often copy and run this command after running `jj git init --colocate`. Having it on a
separate line makes it stand out more and easier to copy, especially if there are many
bookmarks listed.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
In colocated repos, we set up the Git index to make `git diff` closely
match `jj diff`. However, `git diff` will not include new files. We're
long talked about using the `git add --intent-to-add` feature to make
the match closer. This patch implements that. It does so both after
updating the working copy and after snapshotting. After updating the
working copy, the new file in the working-copy commit (compared to the
parent(s)) are marked as intent-to-add. After snapshotting, newly
snapshotted files are marked as intent-to-add, and deleted ones that
were previously marked as intent-to-add are removed from the index.
Closes#6122
These helpers are going to be needed to port the git2 code in the lib
tests to gitoxide. Since the cli tests already depend on testutils, this
helps with avoiding duplicating the code
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.
With this change a warning is shown if the user does not explicitly specify the target revision, but the behavior is unchanged (it still defaults to the working copy).
In the future the warning will be turned into an error. In other words, it will be required to specify target revision.
The bulk of the changes here are to prepare tests for the upcoming change, to make the transition easier.
For additional details please see:
* https://github.com/jj-vcs/jj/issues/5374
* https://github.com/jj-vcs/jj/discussions/5363
We had documented that we support `git.auto-local-bookmark` but we
don't. The documentation has been incorrect since d9c68e08b1. This
patch fixes it by adding support for `git.auto-local-bookmark` with
fallback to the old/current `git.auto-local-branch`.
.
This was added at f5f61f6bfe "revset: resolve 'HEAD@git' just like other
pseudo @git branches." As I said in this patch, there was no practical use case
of the HEAD@git symbol.
Suppose we implement colocated workspaces/worktrees #4436, there may be multiple
Git HEAD revisions. This means HEAD can no longer be abstracted as a symbol of
the "git" remote.
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.
--at-op should be invalid on repo initialization. "init --ignore-working-copy"
could be supported by using working_copy.reset(), but I don't think it's
worth the effort. If the working directory is empty, --ignore-working-copy
is meaningless, and if the directory is not empty, the user would probably
want to do snapshot at some point.
I'm going to fix misuse of CommandHelper::for_loaded_repo(), which expects
that the given repo respects the --at-operation option.
I don't think all of the added tests are useful, but "clone
--ignore-working-copy" might be legit as a replacement for bare repos.
Otherwise, newly created default branch would be re-imported as a new Git HEAD.
This could be addressed by cmd_git_init(), but the same situation can be
crafted by using "git checkout -b".
It's copied from test_git_colocated.rs, and switched to commit_id.short()
because full-length commit_id looked too verbose. "all()" history isn't needed,
but it's easier to follow.
