This adds the new --colocate flag to `jj git clone`.
```
jj git clone --colocate https://github.com/foo/bar
```
is effectively equivalent to:
```
git clone https://github.com/foo/bar
cd bar
jj init --git-repo=.
```
The `--allow-large-revset` option for `jj rebase` and `jj new` is used
for allowing a single revset to resolve to more than one destination
commit. It also means that duplicate commits between individual
revsets are allowed (e.g. `jj rebase -d x -d 'x|y'`). I'm about to
replace the first meaning of the flag by a revset function. I don't
think it's worth keeping the flag only for the second meaning, so I'm
just removing the feature instead. We can add it back under a
different name (`--allow-duplicate-destinations`?) if people care
about it.
The `--allow-large-revsets` flag we have on `jj rebase` and `jj new`
allows the user to do e.g. `jj rebase --allow-large-revsets -b
main.. -d main` to rebase all commits that are not in main onto
main. The reason we don't allow these revsets to resolve to multiple
commits by default is that we think users might specify multiple
commits by mistake. That's probably not much of a problem with `jj
rebase -b` (maybe we should always allow that to resolve to multiple
commits), but the user might want to know if `jj rebase -d @-`
resolves to multiple commits.
One problem with having a flag to allow multiple commits is that it
needs to be added to every command where we want to allow multiple
commits but default to one. Also, it should probably apply to each
revset argument those commands take. For example, even if the user
meant `-b main..` to resolve to multiple commits, they might not have
meant `-d main` to resolve to multiple commits (which it will in case
of a conflicted branch), so we might want separate
`--allow-large-revsets-in-destination` and
`--allow-large-revsets-in-source`, which gets quite cumbersome. It
seems better to have some syntax in the individual revsets for saying
that multiple commits are allowed.
One proposal I had was to use a `multiple()` revset function which
would have no effect in general but would be used as a marker if used
at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some
discussion on the PR adding that function (#1911), it seems that the
consensus is to instead use a prefix like `many:` or `all:`. That
avoids the problem with having a function that has no effect unless
it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have
no effect).
Since we already have the `:` operator for DAG ranges, we need to
change it to make room for `many:`/`all:` syntax. This commit starts
that by allowing both `:` and `::`.
I have tried to update the documentation in this commit to either
mention both forms, or just the new and preferred `::` form. However,
it's useless to search for `:` in Rust code, so I'm sure I've missed
many instances. We'll have to address those as we notice them. I'll
let most tests use `:` until we deprecate it or delete it.
It seemed awkward if merged PR is sometimes rendered as a first branch.
Instead of sorting edges in index order, let's build a HashSet only when
deduplication is needed.
This is breaking change. Old jj binary will panic if it sees a view saved by
new jj. Alternatively, we can store both new and legacy data for backward
compatibility.
The idea is simple. New heads are ignored until the node dependency resolution
stuck. Then, only the first head that will unblock the visit will be queued.
Closes#242
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
Summary: Someone on Discord mentioned that while using branches, they could
switch between branches like `m1` and `main`, but not `HEAD@git`, even though it
was color coded the same and located right next to the other branch names in the
default `jj log` output.
This confused me too at first, until I realized `jj` was telling me that the
given commit was the `HEAD` reference in the colocated git repo. Let's just
color these references differently in the default schema, to try and hint that
these aren't the same. `bright green` is arbitrary, but helps stand out; and
`green` was only picked because both it and `git` start with "g".
GitHub Issue: #1843
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I66d53ea2b9155db1fec6cae8ba8cbd0f
Almost everyone calls the project "jj", and there seeems to be
consensus that we should rename the crates. I originally wanted the
crates to be called `jj` and `jj-lib`, but `jj` was already
taken. `jj-cli` is probably at least as good for it anyway.
Once we've published a 0.8.0 under the new names, we'll release 0.7.1
versions under the old names with pointers to the new crates names.
It seemed too verbose to always include @remote branches, so synced remotes
are omitted by default. If the given symbol contained '@', all remote symbols
are populated so that the distance of remote fragment is taken into account.
Errors that may occur while loading backend would vary per backends, and
it's unlikely that these errors could be mapped to BackendError variants
other than BackendError::Other. So let's extract Other(_) of that kind as
a separate type to clarify there would be no other error variants.
Perhaps, Backend/Error will be renamed to CommitBackend/Error or
CommitStore/Error?, whereas I think BackendInit/LoadError can be shared
among store factories.
The original test is copied from @martinvonz 's [PR draft] (thanks!).
The three versions show differences in behavior due to import/export
of remote-tracking branches, and due to repo being colocated.
The former is relevant for [the discussion] of whether `jj git export` should
export remote-tracking branches. The latter will change in a follow-up commit.
Outstanding TODO: check if we have similar tests for undoing `fetch`
[PR draft]: https://github.com/martinvonz/jj/pull/1541
[the discussion]: https://github.com/martinvonz/jj/pull/1739
Typical query would be something like -r 'mine()' or -r 'branches()' to
exclude remote-only branches #1136.
The query matches against local targets only. This means there's no way to
select deleted/forgotten branches by -r option. If we add a default revset
configuration, we'll need some way to turn the default off.
Otherwise, those tests cannot use `jj git push`. This is an issue with a test
in the next commit, and I don't want people to copy these tests and be surprised.
Add the `submodule` subcommand, which will remain hidden while we are
polishing up the submodules feature. Also, add a debugging-only
sub-subcommand `print-gitmodules` that tests our .gitmodules parser with
the .gitmodules in the working copy.
Inspired by d01ecc5c46 "more detailed message describing deleted branches."
And yes, "jj git export" does propagate "jj branch forget" to the underlying
Git repository, which strengthen my feeling that git::export_refs() should
also remove "forgotten" remote tracking refs.
I thought we would need additional bookkeeping to detect forgotten branches,
but I was wrong. If a branch exists only in git_refs, it is forgotten (but not
yet exported.)
