Giters

torbiak / git-autofixup

create fixup commits for topic branches

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Should return non-zero in case of failure

DamienCassou opened this issue · comments

commented

When autofixup fails to find a target for unstaged changes, it would be more standard to return a non-zero value and print its error message to standard errror. The current behavior prevents other tools from detecting failure.

commented

Currently a non-zero exit status is only returned for unrecoverable errors and bad args. I haven't expected git-autofixup to be able to assign all unstaged hunks, so if it correctly decides not to assign a hunk I've been considering that a success. I wouldn't expect it to be able to assign all hunks for a large proportion of what I imagined as normal cases. For example, if I have a mix of changes that can and cannot be assigned, then I might run git-autofixup to assign what it can so it's easier to create new commits for what's left. And if not assigning some hunks doesn't deserve a non-zero exit code, being unable to assign any hunks doesn't seem like it should either.

What's the argument for unassigned hunks being an error?

We could add another exit code for unassigned hunks, perhaps enabled by an new option, but checking whether anything has been left unstaged seems closer to your actual purpose.

commented

I understand your rationale. Thanks for explaining. You can close the issue.

commented

It's not a big deal I think, because

@DamienCassou said:

when autofixup can't find any target commit, it doesn't do anything and magit won't tell us that something failed.

Magit users can see that this is what happened because no fixup! commits appear in the status buffer.

But I would still argue that it would make sense to communicate what has happened using different exit codes, e.g.

  • 0 All hunks have been assigned.
  • 1 Only some hunks have been assigned.
  • 2 No hunks have been assigned.
  • 3 There was nothing to be assigned. (user error)
  • 255 Some unexpected error occurred.

For backward compatibility maybe only use 1,2,3 instead of 0 if --exit-code is used. This would be somewhat similar to git diff --exit-code.

commented

@tarsius ok, I think I'm convinced.

commented

Thank you