We have supported multiple workspaces for six months now, but I forgot
to remove a note in the revset doc saying that we don't support
it. Also update the text to descibe how to refer to the working-copy
commit in another workspace.
We have had support for workspaces for six months, but I forgot to
update the documentation.
This just adds some basic documentation; we can add more later.
Since we now allow pushing open commits, we can implement support for
pushing the "current" branch by defining a "current" branch as any
branch pointing to `@`. That definition of a current/active seems to
have been the consensus in discussion #411.
Closes#246.
Sturdy came up a while ago on lobste.rs when [jj was being discussed](https://lobste.rs/s/47zztj/jujutsu_dvcs). I'm not sure if I described it well, or if it's something you want as related-work, especially since the sturdy founder claims to be solving different problems in the very thread. But it does seem to be doing some similar things to removing the idea of an index/staging area.
It can be confusing that some commits (typically the working copy)
don't have a description. Let's show a placeholder text in such cases.
I chose the format to match the "(no email configured)" message we
already have.
The default log output of showing all commits is not very useful when
contributing to an existing repo. Let's have it default to showing
commits not on any remote branch instead. I think that's the best we
can do since we don't have a configurable main branch yet, and we
don't even have per-repo configuration..
Closes#250.
It's much easier to tell users on all platforms to put their config in
`~/.jjconfig.toml` than in a path that varies across the platforms, so
let's do that. It also seems like a less controversial location for
the file.
Closes ##233.
This adds a `jj sparse` command with options to list and manage the
set of paths to include in the working copy. It only supports includes
(postive matches) for now.
I'm not sure "sparse" is the best name for the feature. Perhaps it
would make sense as a subcommand under `jj workspace` - maybe `jj
workspace track`? However, there's also `jj untrack` for removing a
file from the working copy and leaving it in the working copy. I'm
happy to hear suggestions, or we can get back to the naming later.
This introduces a `connected(x)` function, which is simply the same as
`x:x`. It's occasionally useful if `x` is a long expression. It's also
useful as a building block for `root(x)` (coming soon).
I'm a little hesitant to do this because most tools I'm familiar with
have the config file directly in `~/`. It's also easier to describe
where to put the file if it doesn't vary across platforms. But we're
still early in the project, so let's try it and see if we get any
complaints.
It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.
Closes#87.
We used to have documention about how conflicts are implemented, but I
removed that a long time ago when I rewrote the README to target users
rather than VCS hackers. Let's have a doc for the VCS hackers (and
curious users) as well, though.
I wanted to have all the documentation available on the command line,
but that makes it harder to maintain and link to. Let's move it to
markdown instead. We may later be able to add some way of presenting
the markdown in the terminal (or maybe by first converting it to
reStructuredText).
It makes sense to omit either of the arguments of the `..` operator,
even though `..x` is equivalent to `:x`. `x..`, with a implied right
argument of `heads()` is more useful.
