{"thread":{"id":"49389","subject":"bug with git merge-base","startedAt":"2018-09-19T22:25:29Z","lastAt":"2018-09-21T04:59:16Z","messageCount":4,"participants":["Alexander Mills","Eric Sunshine","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"358492","messageId":"CA+KyZp4G6WCXjp_9x+NBWZysfg+Fu_PtF4qrhipT8UuLNnsCHA@mail.gmail.com","threadId":"49389","inReplyTo":null,"subject":"bug with git merge-base","fromName":"Alexander Mills","fromEmail":"alexander.d.mills@gmail.com","sentAt":"2018-09-19T22:25:14Z","receivedAt":"2018-09-19T22:25:29Z","isPatch":false,"sender":{"key":"alexander.d.mills@gmail.com","avatar":"https://gravatar.com/avatar/8accf19b85aa1020f85582e1f001860f853ce55767c226545a0825a2fcd99f04?d=mp&s=160"},"body":"The following command sequence exits with 1, and no stderr\n\nbase='remotes/origin/dev';\nfork_point=\"$(git merge-base --fork-point \"$base\")\";\n\nI cannot figure out why it's exiting with 1, but there is no stdout/stderr\n\n-alex\n\n-- \n\nAlexander D. Mills\n¡¡¡ New cell phone number: (415)730-1805 !!!\nalexander.d.mills@gmail.com\n\nwww.linkedin.com/pub/alexander-mills/b/7a5/418/\n"},{"id":"358554","messageId":"CAPig+cS+8+uGQTfxmq1XGMt5FBM1oq72d3N=3BkjhrA9ui+EWw@mail.gmail.com","threadId":"49389","inReplyTo":"CA+KyZp4G6WCXjp_9x+NBWZysfg+Fu_PtF4qrhipT8UuLNnsCHA@mail.gmail.com","subject":"Re: bug with git merge-base","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-09-21T02:31:06Z","receivedAt":"2018-09-21T02:31:20Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills\n<alexander.d.mills@gmail.com> wrote:\n> The following command sequence exits with 1, and no stderr\n>\n> base='remotes/origin/dev';\n> fork_point=\"$(git merge-base --fork-point \"$base\")\";\n>\n> I cannot figure out why it's exiting with 1, but there is no stdout/stderr\n\nUnable to reproduce the problem. Perhaps you can provide more context.\n"},{"id":"358556","messageId":"xmqqsh23xzoy.fsf@gitster-ct.c.googlers.com","threadId":"49389","inReplyTo":"CAPig+cS+8+uGQTfxmq1XGMt5FBM1oq72d3N=3BkjhrA9ui+EWw@mail.gmail.com","subject":"Re: bug with git merge-base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-21T04:05:33Z","receivedAt":"2018-09-21T04:06:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills\n> <alexander.d.mills@gmail.com> wrote:\n>> The following command sequence exits with 1, and no stderr\n>>\n>> base='remotes/origin/dev';\n>> fork_point=\"$(git merge-base --fork-point \"$base\")\";\n>>\n>> I cannot figure out why it's exiting with 1, but there is no stdout/stderr\n>\n> Unable to reproduce the problem. Perhaps you can provide more context.\n\nWell, reading builtin/merge-base.c::handle_fork_point(), I think the\nintended behaviour is:\n\n - die() when input is not well formed (e.g. bad commit object,\n   ambigous ref name, etc.); there is an error worth reporting in\n   this case.\n\n - show one that used to sit at the tip of the ref, if exists, and\n   signal success with exit status 0; there of course is no error in\n   this case.\n\n - if there is no such fork point found, signal failure with exit\n   status 1; nothing is written to the standard output as there is\n   no fork point to be shown, and nothing is written to the standard\n   error.\n\nI do not think the code considers the last case as an error, i.e. it\nis just as natural not to have any fork point, as there is one.\n\nIt might be OK to teach the command to say \"no fork point found\" to\nthe standard error under \"--verbose\" mode in the last case, but\nsince the command does not take --verbose or --quiet, I have a\nfeeling that everything is working as designed.\n"},{"id":"358557","messageId":"xmqqo9crxx7l.fsf@gitster-ct.c.googlers.com","threadId":"49389","inReplyTo":"xmqqsh23xzoy.fsf@gitster-ct.c.googlers.com","subject":"Re: bug with git merge-base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-21T04:59:10Z","receivedAt":"2018-09-21T04:59:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Well, reading builtin/merge-base.c::handle_fork_point(), I think the\n> intended behaviour is:\n>\n>  - die() when input is not well formed (e.g. bad commit object,\n>    ambigous ref name, etc.); there is an error worth reporting in\n>    this case.\n>\n>  - show one that used to sit at the tip of the ref, if exists, and\n>    signal success with exit status 0; there of course is no error in\n>    this case.\n>\n>  - if there is no such fork point found, signal failure with exit\n>    status 1; nothing is written to the standard output as there is\n>    no fork point to be shown, and nothing is written to the standard\n>    error.\n>\n> I do not think the code considers the last case as an error, i.e. it\n> is just as natural not to have any fork point, as there is one.\n>\n> It might be OK to teach the command to say \"no fork point found\" to\n> the standard error under \"--verbose\" mode in the last case, but\n> since the command does not take --verbose or --quiet, I have a\n> feeling that everything is working as designed.\n\nI forgot to say that the behaviour above used by the \"fork point\"\nmode seems to match the behaviour of the more established normal\n\"merge base\" mode.  builtin/merge-base.c::show_merge_base() also\nfollows the same \"die if the input is faulty, give output and\nsucceed if a merge base is found, otherwise be silent and signal\nfailure with exit code\" pattern.\n"}]}