{"thread":{"id":"12681","subject":"git-fetch question/bug","startedAt":"2008-03-14T05:08:01Z","lastAt":"2008-03-14T15:57:20Z","messageCount":4,"participants":["Govind Salinas","Junio C Hamano","Jakub Narebski","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72034","messageId":"5d46db230803132208r3f3f9e34q80bb9c03d65ab67c@mail.gmail.com","threadId":"12681","inReplyTo":null,"subject":"git-fetch question/bug","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-03-14T05:08:01Z","receivedAt":"2008-03-14T05:08:01Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"Hey,\n\nI was wrapping git-fetch when I discovered that it does not return\nerror when the\nfetch fails due to it not being a ff...\n\n~/Desktop/Projects/test  (test2)\ngovind@gnosis: 574> git fetch . remotes/origin/gitnext:test2\nFrom .\n ! [rejected]        origin/gitnext -> test2  (non fast forward)\n~/Desktop/Projects/test  (test2)\ngovind@gnosis: 575> echo $?\n0\n~/Desktop/Projects/test  (test2)\ngovind@gnosis: 576> git version\ngit version 1.5.4.3.587.g0bdd73\n\n\nSo, is this the expected behavior?  I expect it should return non-0\nwhen it does not\nperform the requested fetch.\n\nIf this is supposed to be this way, then sorry for the noise.\n\nThanks,\nGovind.\n"},{"id":"72039","messageId":"7vbq5hub74.fsf@gitster.siamese.dyndns.org","threadId":"12681","inReplyTo":"5d46db230803132208r3f3f9e34q80bb9c03d65ab67c@mail.gmail.com","subject":"Re: git-fetch question/bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-14T05:27:43Z","receivedAt":"2008-03-14T05:27:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n\n> ... git-fetch when I discovered that it does not return\n> error when the\n> fetch fails due to it not being a ff...\n\nI think this is a regression introduced when \"git-fetch\" was\nre-implemented in C.  git-fetch--tool's native-store subcommand seems to\nhave signaled this as an error, and it is reasonable to expect an error\nexit from the command in this case.\n\nProbably something like this?\n\n builtin-fetch.c |    7 ++++---\n 1 files changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 55f611e..a2deb3e 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -297,7 +297,7 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n {\n \tFILE *fp;\n \tstruct commit *commit;\n-\tint url_len, i, note_len, shown_url = 0;\n+\tint url_len, i, note_len, shown_url = 0, err = 0;\n \tchar note[1024];\n \tconst char *what, *kind;\n \tstruct ref *rm;\n@@ -364,7 +364,8 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n \t\t\tnote);\n \n \t\tif (ref) {\n-\t\t\tupdate_local_ref(ref, what, verbose, note);\n+\t\t\tif (update_local_ref(ref, what, verbose, note))\n+\t\t\t\terr = 1;\n \t\t\tif (*note) {\n \t\t\t\tif (!shown_url) {\n \t\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n@@ -376,7 +377,7 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n \t\t}\n \t}\n \tfclose(fp);\n-\treturn 0;\n+\treturn err;\n }\n \n /*\n"},{"id":"72045","messageId":"frdasr$v81$1@ger.gmane.org","threadId":"12681","inReplyTo":"7vbq5hub74.fsf@gitster.siamese.dyndns.org","subject":"Re: git-fetch question/bug","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-14T07:52:58Z","receivedAt":"2008-03-14T07:52:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> \"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n> \n>> ... git-fetch when I discovered that it does not return\n>> error when the\n>> fetch fails due to it not being a ff...\n> \n> I think this is a regression introduced when \"git-fetch\" was\n> re-implemented in C.  git-fetch--tool's native-store subcommand seems to\n> have signaled this as an error, and it is reasonable to expect an error\n> exit from the command in this case.\n> \n> Probably something like this?\n\n[...]\n\nWouldn't it be better to distinguish somehow remote side errors (like for\nexample: could not connect to remote server) and local side errors (like\nfetch refused because of being not fast-forward)? The former are usually\nnot recoverable (unless it is URL that is mistyped), the latter could be\nusually resolved (forced for example)...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"72104","messageId":"alpine.LNX.1.00.0803141148250.19665@iabervon.org","threadId":"12681","inReplyTo":"7vbq5hub74.fsf@gitster.siamese.dyndns.org","subject":"Re: git-fetch question/bug","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-14T15:57:20Z","receivedAt":"2008-03-14T15:57:20Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 13 Mar 2008, Junio C Hamano wrote:\n\n> \"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n> \n> > ... git-fetch when I discovered that it does not return\n> > error when the\n> > fetch fails due to it not being a ff...\n> \n> I think this is a regression introduced when \"git-fetch\" was\n> re-implemented in C.  git-fetch--tool's native-store subcommand seems to\n> have signaled this as an error, and it is reasonable to expect an error\n> exit from the command in this case.\n> \n> Probably something like this?\n\nLooks right to me, although we should probably note that this probably \nmeans that if pull does a fetch that fails for some ref that you're not \nmerging, it won't do the merge, even though it obviously could. So I think \nfixing this would presently (unless fetch and pull communicate more) be a \nregression for people whose upstreams introduce a new non-ff branch that \nmatches their non-force fetch pattern.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}