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

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

Junio C Hamano <gitster@pobox.com> 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