feat: add resolve cmd

[Rudxain]

closes #1234

Note

I'll push -f only while in draft state, to add missing docs

[hyperupcall]

Thank you for the pull request - just a few general questions, assuming all maintainers agree on adding this feature: #1234 (comment)

• Is it required to ignore files outside the working directory to "avoid overload"? In my opinion this is unintuitive and I don't think it causes overload: the command should behave the same no matter where the user is in the git repository.
• I assume the git diff --check ensures that no files with conflict markers are committed. However, it looks like it also checks if there are whitespace errors. I worry that for some user-supplied files, a "whitespace error" (false positive) will always be activated, is there some way to avoid this?

Code comments:

• I don't think many other bash programs in this repository set IFS to $' \t', so I would prefer if this file would be consistent with that.
• Would removing the git continue at the bottom avoid the potential pitfall that you mention? I think it would be better to not run git continue in general and let the user do it when they are ready.

[Rudxain]

Is it required to ignore files outside the working directory [...]

Not really, it's a preventive measure in case there are too many conflicted files. It ensures EDITOR doesn't use too much memory and reduces cognitive load for the user. I believe it's a sensible default since the user can easily change their CWD (and if CWD = worktree-root, then no files are ignored), but I agree that consistency is important as well.

git diff --check [...] also checks if there are whitespace errors. I worry that for some user-supplied files, a "whitespace error" (false positive) will always be activated, is there some way to avoid this?

I have the same concern. I haven't tested, but this command should work as alternative:

git -c core.whitespace='' diff --check

I don't think many other bash programs in this repository set IFS to $' \t', so I would prefer if this file would be consistent with that.
d
I agree, but it has an effect on xargs -0r $(git var GIT_EDITOR) as I removed \n just in case, but it doesn't seem necessary.

Would removing the git continue at the bottom avoid the potential pitfall that you mention?

IIRC, yes

I think it would be better to not run git continue in general and let the user do it when they are ready

I agree. I can remove it now. It can be re-added in the future if a workaround for rerere is found