{"thread":{"id":"21814","subject":"[PATCH] git-pull.sh: Fix call to git-merge for new command format","startedAt":"2009-12-01T22:44:11Z","lastAt":"2009-12-03T08:10:53Z","messageCount":7,"participants":["Horst H. von Brand","Junio C Hamano","Michael J Gruber"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"128935","messageId":"1259707451-20661-1-git-send-email-vonbrand@inf.utfsm.cl","threadId":"21814","inReplyTo":null,"subject":"[PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2009-12-01T22:44:11Z","receivedAt":"2009-12-01T22:44:11Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\n---\n git-pull.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex bfeb4a0..a875809 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n test true = \"$rebase\" &&\n \texec git-rebase $diffstat $strategy_args --onto $merge_head \\\n \t${oldremoteref:-$merge_head}\n-exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n-\t\"$merge_name\" HEAD $merge_head $verbosity\n+exec git-merge  $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n+\t\"$merge_name\" $merge_head\n-- \n1.6.6.rc0.114.gc8648\n"},{"id":"128937","messageId":"7vmy22qmgp.fsf@alter.siamese.dyndns.org","threadId":"21814","inReplyTo":"1259707451-20661-1-git-send-email-vonbrand@inf.utfsm.cl","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-01T23:54:46Z","receivedAt":"2009-12-01T23:54:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" <vonbrand@inf.utfsm.cl> writes:\n\n> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\n> ---\n>  git-pull.sh |    4 ++--\n>  1 files changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/git-pull.sh b/git-pull.sh\n> index bfeb4a0..a875809 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n>  test true = \"$rebase\" &&\n>  \texec git-rebase $diffstat $strategy_args --onto $merge_head \\\n>  \t${oldremoteref:-$merge_head}\n> -exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n> -\t\"$merge_name\" HEAD $merge_head $verbosity\n> +exec git-merge  $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n> +\t\"$merge_name\" $merge_head\n> -- \n> 1.6.6.rc0.114.gc8648\n\nHeh, embarrasing.\n\nBut I think you wanted to have -m immediately before \"$merge_name\", no?\n"},{"id":"128988","messageId":"4B163B49.4070606@drmicha.warpmail.net","threadId":"21814","inReplyTo":"7vmy22qmgp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-02T10:02:49Z","receivedAt":"2009-12-02T10:02:49Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 02.12.2009 00:54:\n> \"Horst H. von Brand\" <vonbrand@inf.utfsm.cl> writes:\n> \n>> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\n>> ---\n>>  git-pull.sh |    4 ++--\n>>  1 files changed, 2 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/git-pull.sh b/git-pull.sh\n>> index bfeb4a0..a875809 100755\n>> --- a/git-pull.sh\n>> +++ b/git-pull.sh\n>> @@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n>>  test true = \"$rebase\" &&\n>>  \texec git-rebase $diffstat $strategy_args --onto $merge_head \\\n>>  \t${oldremoteref:-$merge_head}\n>> -exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n>> -\t\"$merge_name\" HEAD $merge_head $verbosity\n>> +exec git-merge  $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n>> +\t\"$merge_name\" $merge_head\n>> -- \n>> 1.6.6.rc0.114.gc8648\n> \n> Heh, embarrasing.\n> \n> But I think you wanted to have -m immediately before \"$merge_name\", no?\n\nThis made me wonder a bit: Do we have a policy regarding the use of\n\"git-command\" vs. \"git command\" in git shell scripts such as this one?\nOf course, having been called through git, the dashed versions are in\nthe PATH. But I see a mix here (\"git fmt-merge-msg\" vs. \"git-merge\") and\nin other scripts, which may potentially (in broken setups) lead to parts\nof git from different installs being called. I would think the dashed\nform is even more efficient (fewer lookups)?\n\nMichael\n"},{"id":"129014","messageId":"7vws15jpe7.fsf@alter.siamese.dyndns.org","threadId":"21814","inReplyTo":"4B163B49.4070606@drmicha.warpmail.net","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-02T16:45:36Z","receivedAt":"2009-12-02T16:45:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> This made me wonder a bit: Do we have a policy regarding the use of\n> \"git-command\" vs. \"git command\" in git shell scripts such as this one?\n\nYes.  Anything that sets GIT_EXEC_PATH correctly can use git-foo form.\n"},{"id":"129025","messageId":"4B16A410.5090802@drmicha.warpmail.net","threadId":"21814","inReplyTo":"7vws15jpe7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-02T17:29:52Z","receivedAt":"2009-12-02T17:29:52Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 02.12.2009 17:45:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> This made me wonder a bit: Do we have a policy regarding the use of\n>> \"git-command\" vs. \"git command\" in git shell scripts such as this one?\n> \n> Yes.  Anything that sets GIT_EXEC_PATH correctly can use git-foo form.\n\nI know they can. That was in the part you snipped ;)\n\nThe questions is: Should they? Should we avoid mixing both forms in one\nscript?\n\nMichael\n"},{"id":"129028","messageId":"7viqcpgtbf.fsf@alter.siamese.dyndns.org","threadId":"21814","inReplyTo":"4B16A410.5090802@drmicha.warpmail.net","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-02T17:49:08Z","receivedAt":"2009-12-02T17:49:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n>> Yes.  Anything that sets GIT_EXEC_PATH correctly can use git-foo form.\n>\n> I know they can. That was in the part you snipped ;)\n\nYou asked about the presense of \"a policy\", and you got an answer.\n\n> The questions is: Should they? Should we avoid mixing both forms in one\n> script?\n\nShould we avoid it?  Yes but not very enthusiastically.  We should make\nsure that new invocations anybody adds use dashless form, but I would\nrecommend against a \"let's remove use of dashed form\" patch _unless_ you\nfind a time when the project is really quiet and there is nothing else\ngoing on.\n\nThe whole point of GIT_EXEC_PATH trick is to allow continued use of the\ndashed form, so that we do not have to suffer from code churn and patches\nto implement real changes do not have to crash with such clean-ups.\n\nAs we'll be changing \"git pull\", we should use dashless form in the\nvicinity of the real change (which is only one line) while at it, like\nthis.\n\n-- >8 --\nFrom: Horst H. von Brand <vonbrand@inf.utfsm.cl>\nDate: Tue, 1 Dec 2009 19:44:11 -0300\nSubject: [PATCH] git-pull.sh: Fix call to git-merge for new command format\n\nNow \"git merge <msg> HEAD\" is officially deprecated, we should\nclean our own use as well.\n\nSigned-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n git-pull.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex bfeb4a0..fcf6c81 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -216,7 +216,7 @@ fi\n \n merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n test true = \"$rebase\" &&\n-\texec git-rebase $diffstat $strategy_args --onto $merge_head \\\n+\texec git rebase $diffstat $strategy_args --onto $merge_head \\\n \t${oldremoteref:-$merge_head}\n-exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n-\t\"$merge_name\" HEAD $merge_head $verbosity\n+exec git merge $verbosity $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \\\n+\t-m \"$merge_name\" $merge_head\n"},{"id":"129107","messageId":"4B17728D.4070606@drmicha.warpmail.net","threadId":"21814","inReplyTo":"7viqcpgtbf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-03T08:10:53Z","receivedAt":"2009-12-03T08:10:53Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 02.12.2009 18:49:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>>> Yes.  Anything that sets GIT_EXEC_PATH correctly can use git-foo form.\n>>\n>> I know they can. That was in the part you snipped ;)\n> \n> You asked about the presense of \"a policy\", and you got an answer.\n\nI guess that was a language issue (on both sides) then, since \"can\"\ncould be \"is able to\" as well as \"is allowed to\", and I read your answer\nin the former sense; the latter makes it a policy.\n\n>> The questions is: Should they? Should we avoid mixing both forms in one\n>> script?\n> \n> Should we avoid it?  Yes but not very enthusiastically.  We should make\n> sure that new invocations anybody adds use dashless form, but I would\n> recommend against a \"let's remove use of dashed form\" patch _unless_ you\n> find a time when the project is really quiet and there is nothing else\n> going on.\n\nOK, that's all I wanted to know. Thanks.\n\nMichael\n"}]}