I get what you're trying to do. However, I would suggest that instead of a separate sub-command which cannot stand on its own, that we try to leverage common knowledge.

If we emulate "git rebase" by implementing a "--continue" and "--abort" then when a patch fails to apply, we can tell the user that they should try and resolve conflicts and then execute one of:

git arc patch --continue
git arc patch --abort

The combination of (1) catching the error and (2) telling the user to use one of these two (3) saves the user from having to retype the diff argument, at (4) the simple cost of a small cache file that is cleaned up on success.

That would provide direct access to the final patch_commit stage without inventing a partial wrapper over the process as a new sub-command.

Also, --abort could restore the tree from before patch started.

In D59164#1356972, @dteske wrote:

I get what you're trying to do. However, I would suggest that instead of a separate sub-command which cannot stand on its own, that we try to leverage common knowledge.

If we emulate "git rebase" by implementing a "--continue" and "--abort" then when a patch fails to apply, we can tell the user that they should try and resolve conflicts and then execute one of:

git arc patch --continue
git arc patch --abort

The combination of (1) catching the error and (2) telling the user to use one of these two (3) saves the user from having to retype the diff argument, at (4) the simple cost of a small cache file that is cleaned up on success.

That would provide direct access to the final patch_commit stage without inventing a partial wrapper over the process as a new sub-command.

Also, --abort could restore the tree from before patch started.

I like this proposal. Ideally git arc patch would behave similarly to git am.

Well, this patch solved my immediate need, which was a direct access to the patch_commit shell function.

I don't think I will implement any workflow and hand-holding functions.

As it stands, the resolve function is stateless. Yes, it needs a parameter but at least it is explicit.
Initially I tried to write this as a -C option to patch, but then I realized -c might have multiple revision IDs, while -C would need one and only one.

That is why I decided to introduce another subcommand, at first I wanted to name it commit but then I opted for resolve. Maybe commit would be a better name for this function -> git arc patch D59164 + git arc commit D59164 could be roughly equivalent to git arc patch -c D59164

We would need to decide where to store the state ("current revision ID we are working on"). Unfortunately Phabricator and arc do not provide an equivalent to the refs/changes/D59164/1 references, which are git objects managed by Gerrit code review utility. If the user decides to change branches with git checkout or perform some other operation that affects where we are, the state information we store will become stale and we will probably not be able to convince other git subcommands to remove it.

Ok. I agree with your assessment. I'd like to see resolve changed to commit for clarity. I think that's all that is needed.

I also agree that storing the diff handle can bite us, say, if a stale reference got left behind. I'm fine with requiring the diff reference as an argument.

Just some minor suggestions if you have the bandwidth/desire