This code has been unused since 8e6e04b92.
I also deleted the associated tests. I considered porting them to
`MergedTree` but it looks like we have good coverage of these cases in
the existing `MergedTree` tests combined with the low-level `Merge`
tests.
I'm thinking of adding RefName(str) and RemoteName(str) newtypes, and the
templater type name would conflict with that. Since the templater RefName type
is basically a (name, target) pair, I think it should be called a "Ref", and I
added "Commit" prefix for disambiguation.
This isn't a breaking change since template type names only appear in docs and
error messages.
For `builtin_log_compact` you can specify how you want signatures to be
displayed via `format_short_signature`, but the same wasn't possible for
`builtin_log_compact_oneline` which always chose `email().local()`.
When we push a ref to a git remote, we use --force-with-lease
Our understanding was that this could fail iff the expected location of
the ref on the remote was not that of the local tracking ref
However, if the ref is from a protected branch (e.g., main) it will be
rejected by the remote for a different reason.
This commit solves this, by detecting this difference.
Adds a `templates.config.list` config option to control whether the
detailed list is shown or not.
The `builtin_config_list_detailed` template adds the config origin to
the end of the line for each config value in the list. Options coming
from files will show the file path.
It turns out that merge queues bundle auto‐merge for free, so we
can just do this the old way.
This backs out commit eba4257ab9a0268460108c234dc0d046efcd6c33.
Ideally we’d just cancel workflows entirely when they’re ejected
from the merge queue but apparently that’s kinda hard for some
inexplicable reason. This should be a cheap and harmless win. I
guess it gives you slightly less information if something fails
because of changes in the queue but you can just rebase your PR to
get everything running.
I don’t think `github.event.merge_queue.head_ref` actually does
anything useful, but I’m not sure if `github.ref` works for merge
groups and it seems better to have a fallback than not. I’d really
like to cancel PR workflows when a PR enters the merge queue, and
cancel queue workflows when a PR is ejected from the merge queue,
but apparently this simple task is high‐level wizardry when you’re
using GitHub Actions, so I’m postponing that for later.
This was running all the checks twice for pushes to pull requests,
unnecessarily limiting our concurrency and clogging up the status
report. The only benefit is if someone is pushing to a branch that
they don’t have a PR for and waiting for the checks to run. I
suspect nobody is doing this with regularity, but if it turns out
the functionality is important, we could just ask people to add this
back to the `.github/workflows/ci.yml` on the branches they want
GitHub to test, or add logic to try and cancel `push` runs that match
`pull_request` ones.
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.
std::fs::rename() and symlink() aren't added to TestWorkDir. There are few
instances of rename(). work_dir.symlink() would be a bit unclear whether the
link content path is normalized, which usually shouldn't.
This reports the status of the checks that are currently set as
required in the repository configuration, but only in the merge
queue. The advantages are twofold:
1. We can adjust required checks with our normal CI process rather
than having to bug Martin for it. (This doesn’t really place any
more trust in anyone than we do currently, because a malicious PR
could always just replace the jobs with ones that unconditionally
succeed anyway.)
2. We can make the job only ever fail in the merge queue. Currently,
we can only submit a PR into the merge queue after all its checks
pass. Those checks then immediately get run again in the merge
queue. If you do one final fix‐up to an approved PR, it takes
half an hour after that to merge instead of fifteen minutes. We
make this less painful by using auto‐merges, but it’s silly
to block on the PR checks when the actual guarantees are provided
by the merge queue.
Unfortunately GitHub demands the same jobs be required for putting
something into the merge queue and taking it out. We can work
around this by only requiring the `required-checks` job and having
it report its status depending on the context.
Tasks for Martin:
1. Go to <https://github.com/jj-vcs/jj/settings> and disable “Allow
auto-merge”. This would now only block on PR approval / discussion
resolution, so it’s probably more confusing than helpful; I’ve
hit the button and then come back an hour later to discover that
I forgot to resolve discussions.
Go to <https://github.com/jj-vcs/jj/settings/rules/3400426> and
replace all of the required GitHub Actions checks under “Require
status checks to pass” with the single `required-checks` check.
3. While you’re at it, go to
<https://github.com/jj-vcs/jj/settings/actions> and ensure that
“Workflow permissions” is set to “Read repository contents
and packages permissions”. We already handle this correctly in
all our workflows but the default is to allow write permissions
for legacy reasons.
As described in #5909, in the case where jj was initialized in a
shallowly cloned repository which was then unshallow'd, jj does not
import the fetched commits that were outside the shallow boundary.
However, it does import the ones after the boundary, which after
unshallowing do not contain the changes made before the boundary.
Therefore, when running annotate in such a case, jj would panic because
it does not find the commit from which a line originates. This sets the
empty commit as carrying the blame for that line.
All "short" formats should be able to be combined with -p/--patch. It was also
weird that "short" diff stats followed "long" color-words/git diffs.
Fixes#5986
