I was a bit surprised to see the message when I used `jj git push
--change @-` on a commit that already had a branch because I had
pushed it earlier.
The fix means that we instead print the message even if we later
abandon the transaction (so the branch-creation is not persisted)
because the commit is open, for example. That's already what happens
if the commit is missing a description, and since we're planning to
remove the open/closed concept, I don't think this patch makes it much
worse. We probably should improve it later by printing the message
only once the push has succeeded.
This patch prevents perhaps pushing commits with an empty description
or the placeholder "(no user/email configured)" values for
author/committer.
Closes#322.
This adds `jj git push --change <revision>` which creates a branch
with a name based on the revision's change ID, and then pushes that
like with `--branch`. That can be useful so you don't have to manually
add the branch (and come up with a name for it). The created branch
behaves like any other branch, so it's possible to make it point to a
commit with a different change ID.
We very often expect success, and we sometimes want to get the stdout,
too. Let's add a convenience function for that. It saves a lot of
lines of code.
Open commits are work-in-progress and `jj git push --branch <name>`
therefore errors out if the branch points to an open commit. However,
we don't do the same check if you run `jj git push` to push all
branches. This patch introduces such a check. Rather than error out,
we skip such branches instead.
I didn't make it check for open commits in ancestors. It's quite
unusual (at least in my workflow) to have a closed commit on top of an
open one. We can revisit if users get surprised by it.
It rarely makes sense to push commits with conflicts to a remote Git
repo (which is the only kind of remote we support so far), so let's
just error out instead of pushing a commit that others pulling from
the remote probably can't make sense of.
I've only added a simple test for the error case for now. `libgit2`
doesn't support pushing to a local repo, so it's harder to test the
success case. I suppose we'll have to have the regular `git` binary
running local servers in test eventually.
Closes#60.
