Junio C Hamano <junkio@xxxxxxx> wrote:
>
> When "git fetch" fails because the remote unexpectedly rewound
> its head and fast-forward check triggers, we issued a warning
> but kept going anyway. This proposed patch makes the command
> exit with non-zero status.
>
> I think this is a sensible change and makes it easier to use
> from scripts, but it might have other issues. For example when
> you are tracking more than one heads from the remote, and the
> first one fast-forwards but the second one doesn't, it updates
> the first one and then stops. If we happen to process the
> rewound one first, neither is updated because we stop at the
> first one. I think this particular discrepancy probably is not
> worth worrying about, but there may be other more serious
> fallouts we need to fix if we did this.
>
> Comments?
>
> ---
> diff --git a/git-fetch.sh b/git-fetch.sh
> index 0346d4a..6835634 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -179,6 +179,7 @@ fast_forward_local () {
> ;;
> *)
> echo >&2 " not updating."
> + exit 1
> ;;
> esac
> }
Thanks ;)
I guess you could exit with different exit codes according to what
went wrong. So if a script writer really cared about the fine details,
appropriate decisions could be made.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html