ok/jj
1
0
Fork 0
forked from mirrors/jj
Commit graph

10 commits

Author SHA1 Message Date
Emily Fox
9ba9ecd708 revset: add function mine() 2023-08-16 11:00:14 -05:00
Martin von Zweigbergk
a8de6f3695 docs: revert to using revset operator : instead of ::
Since our latest release doesn't support `::`, we shouldn't tell the
user to use it.

This commit should be backed out once we've released jj 0.9.0.
2023-08-01 21:58:43 +00:00
Martin von Zweigbergk
48580ed8b1 revsets: allow :: as synonym for :
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.
2023-07-28 22:30:40 -07:00
Aaron Bull Schaefer
239f879caf docs: fix minor typos in GitHub example commands 2023-04-11 14:41:00 -07:00
David Barnett
22306af17a Add docs on how to use GitHub CLI in repos that aren't co-located 2023-04-05 21:22:49 -06:00
Samuel Tardieu
a7aed0171d style: fix typos found by codespell 2023-01-28 07:23:45 -08:00
Philip Metzger
c252f3eb04 Docs: Fix a dangling ref.
During the initial review, we missed that I wrote `detached head` 
in the link to https://www.git-scm.com/docs/git-checkout#_detached_head 
instead of `detached`. This corrects the link.
2023-01-20 20:05:05 +01:00
Martin von Zweigbergk
f7324768a7 docs: fix some typos in github.md, and reformat it 2023-01-19 09:45:10 -08:00
Samuel Tardieu
2832d7c739 config: allow configuration of git remotes for fetch and push operations
The `git.fetch` and `git.push` keys can be used in the configuration file
for the default to use in `jj git fetch` and `jj git push` operations.

By defaut, "origin" is used in both cases.
2023-01-17 19:04:11 +01:00
Philip Metzger
48356817ba [Docs]: Add some more documentation on how to work with github.
The document roughly describes some workflows, which help new users
to start with github.
2023-01-01 16:36:09 +01:00