git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] exit code from git fetch
@ 2006-03-17  6:01 Junio C Hamano
  2006-03-17  6:23 ` Andrew Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Junio C Hamano @ 2006-03-17  6:01 UTC (permalink / raw)
  To: git

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
 	    }

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [RFC] exit code from git fetch
  2006-03-17  6:01 [RFC] exit code from git fetch Junio C Hamano
@ 2006-03-17  6:23 ` Andrew Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2006-03-17  6:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <junkio@cox.net> 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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-03-17  6:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-17  6:01 [RFC] exit code from git fetch Junio C Hamano
2006-03-17  6:23 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).