I think I got the current template from Google's open-sourcing
process, but I don't care about most of it (GitHub actions already
check that tests pass, for example). Let's instead tell contributors
that they don't need to write anything at all there and that they
should describe the changes in the commit message(s) instead.
I agree with @unrelentingtech's comment in #54 that the steps to
reproduce should come before the expected and actual behavior. I don't
know where I got the current template from. I think it was from
Google's process for open-sourcing the project.
I also removed the version field from the template for now since I
haven't started updating it regularly yet. I should start doing that.
It can be useful in command prompts and scripts to be able to quickly
get e.g. the `jj status` output without spending time committing the
working copy (perhaps because some background process continuously
commits the working copy). One can already do that by passing
`--at-op=<operation ID>`, but then one needs to look up the operation
ID first. That is both extra work for the user/script and it means
there's an extra `jj op log` invocation to get the operation ID. Let's
have a global flag to make it easy and efficient to do.
Since #85, we load the user's config from a path under
`dirs::config_dir()`. It's probably not obvious to all users where to
put the file, so let's describe that. (I didn't know where to put the
file on my Mac until I looked at the function's documentation.)
Originally, I had thought that these warnings would only potentially show up in nightly because there was a feature which exposed these functions, and we would be able to enable that feature and conditionally not define the conflicting methods. But it looks like these warnings also show up in stable. I've just suppressed each of them individually. Other options would be to rename them and just make them wrapper methods, or to disable `unstable_name_collisions` warnings at a higher scope (possibly including at the crate level).
1b6efdc3f8 moved `.jj/git/` into `.jj/store/` for consistency with
the layout of native stores. It provided automatic format upgrades for
repos with the old format. It's been about four months now, so let's
remove the migration code.
When running in a working copy collocated with git's, we export the
working copy's commit's parent to git after every command. However, we
forgot to update our own record of git's HEAD. That means that on
subsequent imports from git, it'll look like the user had updated HEAD
using a git command. When we detect that, we trust that the user had
taken care of the changes in the working copy and we simply abandon
our old working copy commit. That led to the bug reported in $54,
where the second commit of a `jj split` got lost.
The fix is to also update our record of where git's HEAD is when we
tell git to update it.
Closes#54.
We no longer need the commit ID, so we shouldn't make the callers pass
it. This lets us simplify several tests, because they no longer to
create commits just to check out a tree in the working copy.
We used to use the value to detect races, but we use the tree ID and
the operation ID these days, so we don't need the commit ID.
By changing this, we can avoid creating some commit IDs in tests,
which is why I tackled this issue now.
There are only two callers of `LockedWorkingCopy::check_out()`. One is
in `commands.rs`. That caller already checks after taking the lock
that the old commit ID is as expected. The other caller is
`WorkingCopy::check_out()`. We can simply move the check to that level
since it's the only caller that cares now.
