Re: [PATCH] Make repack less likely to corrupt repository

Junio C Hamano [off-list ref] wrote:

If you were arguing for using a different but still non-zero exit status
to signal the "you asked us to repack but I refused to do so because I
couldn't move the in-use packs away; by the way I did not corrupt your
repository because I successfully rolled back everything I did, so do not
worry to much about it" case, I agree that such a change would be better
than what we have.  It would allow an automated process to tell a more
grave repository error and "I need to kill the git object server that is
pinning some of the packfiles open and re-run the repack" situation apart.

I can live with that. So what are our exit codes then?

0 = successful, repack did what we wanted it to

1 = serious error, no idea really, user should investigate
	(now we know they don't anyway, but that's another problem).

2 = not too good, we didn't succeed in repacking, but we didn't destroy
	anything and the user does not necessarily have to do anything.
	GUI's should probably flag this differently from exit code 1.

This would simply introduce a new error code, but the drawback is that
they are "out of order", i.e. most severe does not have the highest code.

-- robin