{"thread":{"id":"36461","subject":"[RTC/PATCH] Add 'update-branch' hook","startedAt":"2014-04-21T02:23:36Z","lastAt":"2014-04-26T19:28:43Z","messageCount":39,"participants":["Felipe Contreras","Eric Sunshine","Ilya Bobyr","Junio C Hamano","Stephen Leake"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"239202","messageId":"1398047016-21643-1-git-send-email-felipe.contreras@gmail.com","threadId":"36461","inReplyTo":null,"subject":"[RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T02:23:36Z","receivedAt":"2014-04-21T02:23:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"This hook is invoked whenever a branch is updated, either when a branch\nis created or updated with 'git branch', or when it's rebased with 'git\nrebase'. It receives two parameters; the name of the branch, and the\nSHA-1 of the latest commit, additionally, if there was a base commit the\nbranch was rebased onto, a third parameter contains it.\n\nIt can be used to verify the validity of branch names, and also to keep\ntrack of the origin point of a branch, which is otherwise not possible\nto find out [1].\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/198587\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/githooks.txt | 9 +++++++++\n branch.c | 6 ++++++\n builtin/clone.c | 7 +++++--\n git-rebase--interactive.sh | 6 +++++-\n git-rebase.sh | 6 +++++-\n t/t5408-update-branch-hook.sh | 39 +++++++++++++++++++++++++++++++++++++++\n 6 files changed, 69 insertions(+), 4 deletions(-)\n create mode 100755 t/t5408-update-branch-hook.sh\n\ndiff --git a/Documentation/githooks.txt b/Documentation/githooks.txt\nindex d954bf6..9e50697 100644\n--- a/Documentation/githooks.txt\n+++ b/Documentation/githooks.txt\n@@ -381,6 +381,15 @@ rebase::\n The commits are guaranteed to be listed in the order that they were\n processed by rebase.\n \n+update-branch\n+~~~~~~~~~~~~~\n+\n+This hook is invoked whenever a branch is updated, either when a branch is\n+created or updated with 'git branch', or when it's rebased with 'git rebase'.\n+It receives two parameters; the name of the branch, and the SHA-1 of the latest\n+commit, additionally, if there was a base commit the branch was rebased onto, a\n+third parameter contains it.\n+\n \n GIT\n ---\ndiff --git a/branch.c b/branch.c\nindex 660097b..c2058d1 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -4,6 +4,7 @@\n #include \"refs.h\"\n #include \"remote.h\"\n #include \"commit.h\"\n+#include \"run-command.h\"\n \n struct tracking {\n \tstruct refspec spec;\n@@ -304,6 +305,11 @@ void create_branch(const char *head,\n \tif (real_ref && track)\n \t\tsetup_tracking(ref.buf + 11, real_ref, track, quiet);\n \n+\tif (run_hook_le(NULL, \"update-branch\", ref.buf + 11, sha1_to_hex(sha1), NULL)) {\n+\t\tunlock_ref(lock);\n+\t\tdie(\"hook 'update-branch' returned error\");\n+\t}\n+\n \tif (!dont_change_ref)\n \t\tif (write_ref_sha1(lock, sha1, msg) < 0)\n \t\t\tdie_errno(_(\"Failed to write ref\"));\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 9b3c04d..6ec96e5 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -581,9 +581,10 @@ static void update_remote_refs(const struct ref *refs,\n \t}\n }\n \n-static void update_head(const struct ref *our, const struct ref *remote,\n+static int update_head(const struct ref *our, const struct ref *remote,\n \t\t\tconst char *msg)\n {\n+\tint err = 0;\n \tif (our && starts_with(our->name, \"refs/heads/\")) {\n \t\t/* Local default branch link */\n \t\tcreate_symref(\"HEAD\", our->name, NULL);\n@@ -591,6 +592,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n \t\t\tconst char *head = skip_prefix(our->name, \"refs/heads/\");\n \t\t\tupdate_ref(msg, \"HEAD\", our->old_sha1, NULL, 0, DIE_ON_ERR);\n \t\t\tinstall_branch_config(0, head, option_origin, our->name);\n+\t\t\terr = run_hook_le(NULL, \"update-branch\", head, sha1_to_hex(our->old_sha1), NULL);\n \t\t}\n \t} else if (our) {\n \t\tstruct commit *c = lookup_commit_reference(our->old_sha1);\n@@ -606,6 +608,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n \t\tupdate_ref(msg, \"HEAD\", remote->old_sha1,\n \t\t\t NULL, REF_NODEREF, DIE_ON_ERR);\n \t}\n+\treturn err;\n }\n \n static int checkout(void)\n@@ -987,7 +990,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tupdate_remote_refs(refs, mapped_refs, remote_head_points_at,\n \t\t\t branch_top.buf, reflog_msg.buf, transport, !is_local);\n \n-\tupdate_head(our_head_points_at, remote_head, reflog_msg.buf);\n+\terr = update_head(our_head_points_at, remote_head, reflog_msg.buf);\n \n \ttransport_unlock_pack(transport);\n \ttransport_disconnect(transport);\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 1c41cbd..084dc36 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -631,7 +631,11 @@ do_next () {\n \t\tgit update-ref -m \"$message\" $head_name $newhead $orig_head &&\n \t\tgit symbolic-ref \\\n \t\t -m \"$GIT_REFLOG_ACTION: returning to $head_name\" \\\n-\t\t HEAD $head_name\n+\t\t HEAD $head_name &&\n+\t\tif test -x \"$GIT_DIR\"/hooks/update-branch; then\n+\t\t\t\"$GIT_DIR\"/hooks/update-branch $branch_name \\\n+\t\t\t\t$newhead $onto\n+\t\tfi\n \t\t;;\n \tesac && {\n \t\ttest ! -f \"$state_dir\"/verbose ||\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 2c75e9f..ededa32 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -149,7 +149,11 @@ move_to_original_branch () {\n \t\t\t$head_name $(git rev-parse HEAD) $orig_head &&\n \t\tgit symbolic-ref \\\n \t\t\t-m \"rebase finished: returning to $head_name\" \\\n-\t\t\tHEAD $head_name ||\n+\t\t\tHEAD $head_name &&\n+\t\tif test -x \"$GIT_DIR\"/hooks/update-branch; then\n+\t\t\t\"$GIT_DIR\"/hooks/update-branch $branch_name \\\n+\t\t\t\t$(git rev-parse HEAD) $onto\n+\t\tfi ||\n \t\tdie \"$(gettext \"Could not move back to $head_name\")\"\n \t\t;;\n \tesac\ndiff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\nnew file mode 100755\nindex 0000000..d921c0e\n--- /dev/null\n+++ b/t/t5408-update-branch-hook.sh\n@@ -0,0 +1,39 @@\n+#!/bin/sh\n+\n+test_description='Test the update-branch hook'\n+\n+. ./test-lib.sh\n+\n+setup () {\n+\tmkdir -p .git/hooks &&\n+\tcat > .git/hooks/update-branch <<-'EOF' &&\n+\t#!/bin/sh\n+\techo $@ > .git/update-branch.args\n+\tEOF\n+\tchmod +x .git/hooks/update-branch &&\n+\techo one > content &&\n+\tgit add content &&\n+\tgit commit -a -m one\n+}\n+\n+setup\n+\n+test_expect_success 'creating a branch' '\n+\tgit checkout -b test master &&\n+\techo two > new &&\n+\tgit add new &&\n+\tgit commit -a -m two\n+\techo \"test $(git rev-parse master)\" > expected &&\n+\ttest_cmp expected .git/update-branch.args\n+'\n+\n+test_expect_success 'doing a rebase' '\n+\tgit checkout -b next master &&\n+\techo three > content &&\n+\tgit commit -a -m three &&\n+\tgit rebase --onto next master test &&\n+\techo \"test $(git rev-parse HEAD) $(git rev-parse next)\" > expected &&\n+\ttest_cmp expected .git/update-branch.args\n+'\n+\n+test_done\n-- \n1.9.2+fc1.1.g5c924db\n"},{"id":"239206","messageId":"CAPig+cRbP_+fBBtmyLAbbj6685+OhrG_7sOD7hD_HJSZJoAWKg@mail.gmail.com","threadId":"36461","inReplyTo":"1398047016-21643-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-04-21T07:25:39Z","receivedAt":"2014-04-21T07:25:39Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Apr 20, 2014 at 10:23 PM, Felipe Contreras\n wrote:\n> This hook is invoked whenever a branch is updated, either when a branch\n> is created or updated with 'git branch', or when it's rebased with 'git\n> rebase'. It receives two parameters; the name of the branch, and the\n> SHA-1 of the latest commit, additionally, if there was a base commit the\n> branch was rebased onto, a third parameter contains it.\n>\n> It can be used to verify the validity of branch names, and also to keep\n> track of the origin point of a branch, which is otherwise not possible\n> to find out [1].\n>\n> [1] http://thread.gmane.org/gmane.comp.version-control.git/198587\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n> new file mode 100755\n> index 0000000..d921c0e\n> --- /dev/null\n> +++ b/t/t5408-update-branch-hook.sh\n> @@ -0,0 +1,39 @@\n> +#!/bin/sh\n> +\n> +test_description='Test the update-branch hook'\n> +\n> +. ./test-lib.sh\n> +\n> +setup () {\n> + mkdir -p .git/hooks &&\n> + cat > .git/hooks/update-branch <<-'EOF' &&\n> + #!/bin/sh\n> + echo $@ > .git/update-branch.args\n> + EOF\n> + chmod +x .git/hooks/update-branch &&\n> + echo one > content &&\n> + git add content &&\n> + git commit -a -m one\n> +}\n> +\n> +setup\n> +\n> +test_expect_success 'creating a branch' '\n> + git checkout -b test master &&\n> + echo two > new &&\n> + git add new &&\n> + git commit -a -m two\n\nBroken &&-chain.\n\n> + echo \"test $(git rev-parse master)\" > expected &&\n> + test_cmp expected .git/update-branch.args\n> +'\n> +\n> +test_expect_success 'doing a rebase' '\n> + git checkout -b next master &&\n> + echo three > content &&\n> + git commit -a -m three &&\n> + git rebase --onto next master test &&\n> + echo \"test $(git rev-parse HEAD) $(git rev-parse next)\" > expected &&\n> + test_cmp expected .git/update-branch.args\n> +'\n> +\n> +test_done\n> --\n> 1.9.2+fc1.1.g5c924db\n"},{"id":"239227","messageId":"5355793A.5020000@gmail.com","threadId":"36461","inReplyTo":"1398047016-21643-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-21T20:02:02Z","receivedAt":"2014-04-21T20:02:02Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> This hook is invoked whenever a branch is updated, either when a branch\n> is created or updated with 'git branch', or when it's rebased with 'git\n> rebase'. It receives two parameters; the name of the branch, and the\n> SHA-1 of the latest commit, additionally, if there was a base commit the\n> branch was rebased onto, a third parameter contains it.\n\nAnd the old branch SHA could be found from in the reflog, correct?\nMaybe it is possible to add it as an extra argument?\nOr if reflog could be used, a note in the description that would say so.\n"},{"id":"239235","messageId":"53558476703cb_5c94d452ec4e@nysa.notmuch","threadId":"36461","inReplyTo":"5355793A.5020000@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:49:58Z","receivedAt":"2014-04-21T20:49:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> > This hook is invoked whenever a branch is updated, either when a branch\n> > is created or updated with 'git branch', or when it's rebased with 'git\n> > rebase'. It receives two parameters; the name of the branch, and the\n> > SHA-1 of the latest commit, additionally, if there was a base commit the\n> > branch was rebased onto, a third parameter contains it.\n> \n> And the old branch SHA could be found from in the reflog, correct?\n\nActually the old branch SHA-1 is actually the current one, since the branch\nhasn't been updated at that point. Personally I don't see much value in adding\nsomething the script can easily find out.\n\n-- \nFelipe Contreras\n"},{"id":"239237","messageId":"53558A54.4060801@gmail.com","threadId":"36461","inReplyTo":"53558476703cb_5c94d452ec4e@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-21T21:15:00Z","receivedAt":"2014-04-21T21:15:00Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 1:49 PM, Felipe Contreras wrote:\n> Ilya Bobyr wrote:\n>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n>>> This hook is invoked whenever a branch is updated, either when a branch\n>>> is created or updated with 'git branch', or when it's rebased with 'git\n>>> rebase'. It receives two parameters; the name of the branch, and the\n>>> SHA-1 of the latest commit, additionally, if there was a base commit the\n>>> branch was rebased onto, a third parameter contains it.\n>> And the old branch SHA could be found from in the reflog, correct?\n> Actually the old branch SHA-1 is actually the current one, since the branch\n> hasn't been updated at that point. Personally I don't see much value in adding\n> something the script can easily find out.\n\nI did not understand that from the description. That was my next\ncomment that I did not send just yet.\nAll the other hooks describe in detail if they are run before or after\nthe operation, and if it is possible to cancel the operation.\nAlso, most have names that start with either \"pre-\" or \"post-\".\nIt seems reasonable for both \"pre-update-branch\" and\n\"post-update-branch\" to exist.\nThis one would be \"pre-update-branch\", I guess.\n\nI was also wondering about \"git reset\". It could also change the branch\nposition, right?\n"},{"id":"239242","messageId":"53558a663ea74_604be1f30c2c@nysa.notmuch","threadId":"36461","inReplyTo":"53558AD0.3010602@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T21:15:18Z","receivedAt":"2014-04-21T21:15:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> > [...]\n> >\n> > diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n> > new file mode 100755\n> > index 0000000..d921c0e\n> > --- /dev/null\n> > +++ b/t/t5408-update-branch-hook.sh\n> > @@ -0,0 +1,39 @@\n> > +#!/bin/sh\n> > +\n> > +test_description='Test the update-branch hook'\n> > +\n> > +. ./test-lib.sh\n> > +\n> > +setup () {\n> > +\tmkdir -p .git/hooks &&\n> > +\tcat > .git/hooks/update-branch <<-'EOF' &&\n> > +\t#!/bin/sh\n> > +\techo $@ > .git/update-branch.args\n> > +\tEOF\n> > +\tchmod +x .git/hooks/update-branch &&\n> > +\techo one > content &&\n> > +\tgit add content &&\n> > +\tgit commit -a -m one\n> > +}\n> > +\n> > +setup\n> \n> According to t/README `setup` should be inside an assertion just as any\n> other test:\n\nI have a bunch of 'setup' calls outside such assertions already in other test\nscripts. If you know how to put single quotes inside of single quotes in a\nshell script, please share that knowledge, otherwise the setup must be outside.\n\nOf course we could do the extremely reduntant:\n\ntest_expect_success 'setup' '\n setup\n'\n\n-- \nFelipe Contreras\n"},{"id":"239238","messageId":"53558AD0.3010602@gmail.com","threadId":"36461","inReplyTo":"1398047016-21643-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-21T21:17:04Z","receivedAt":"2014-04-21T21:17:04Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> [...]\n>\n> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n> new file mode 100755\n> index 0000000..d921c0e\n> --- /dev/null\n> +++ b/t/t5408-update-branch-hook.sh\n> @@ -0,0 +1,39 @@\n> +#!/bin/sh\n> +\n> +test_description='Test the update-branch hook'\n> +\n> +. ./test-lib.sh\n> +\n> +setup () {\n> +\tmkdir -p .git/hooks &&\n> +\tcat > .git/hooks/update-branch <<-'EOF' &&\n> +\t#!/bin/sh\n> +\techo $@ > .git/update-branch.args\n> +\tEOF\n> +\tchmod +x .git/hooks/update-branch &&\n> +\techo one > content &&\n> +\tgit add content &&\n> +\tgit commit -a -m one\n> +}\n> +\n> +setup\n\nAccording to t/README `setup` should be inside an assertion just as any\nother test:\n\n> Do's, don'ts & things to keep in mind\n> -------------------------------------\n>\n> Here are a few examples of things you probably should and shouldn't do\n> when writing tests.\n>\n> Do:\n>\n> - Put all code inside test_expect_success and other assertions.\n>\n> Even code that isn't a test per se, but merely some setup code\n> should be inside a test assertion.\n"},{"id":"239244","messageId":"53558ae6f1282_604be1f30cf3@nysa.notmuch","threadId":"36461","inReplyTo":"53558A54.4060801@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T21:17:26Z","receivedAt":"2014-04-21T21:17:26Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n\n> Also, most have names that start with either \"pre-\" or \"post-\".\n> It seems reasonable for both \"pre-update-branch\" and\n> \"post-update-branch\" to exist.\n\nI don't see what would be the point in that.\n\n> This one would be \"pre-update-branch\", I guess.\n> \n> I was also wondering about \"git reset\". It could also change the branch\n> position, right?\n\nThat's right, maybe that command should call the hook as well.\n\n-- \nFelipe Contreras\n"},{"id":"239249","messageId":"53558f285f379_640076f2f094@nysa.notmuch","threadId":"36461","inReplyTo":"53558F6F.7080306@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T21:35:36Z","receivedAt":"2014-04-21T21:35:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/21/2014 2:15 PM, Felipe Contreras wrote:\n> > Ilya Bobyr wrote:\n> >> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> >>> [...]\n> >>>\n> >>> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n> >>> new file mode 100755\n> >>> index 0000000..d921c0e\n> >>> --- /dev/null\n> >>> +++ b/t/t5408-update-branch-hook.sh\n> >>> @@ -0,0 +1,39 @@\n> >>> +#!/bin/sh\n> >>> +\n> >>> +test_description='Test the update-branch hook'\n> >>> +\n> >>> +. ./test-lib.sh\n> >>> +\n> >>> +setup () {\n> >>> +\tmkdir -p .git/hooks &&\n> >>> +\tcat > .git/hooks/update-branch <<-'EOF' &&\n> >>> +\t#!/bin/sh\n> >>> +\techo $@ > .git/update-branch.args\n> >>> +\tEOF\n> >>> +\tchmod +x .git/hooks/update-branch &&\n> >>> +\techo one > content &&\n> >>> +\tgit add content &&\n> >>> +\tgit commit -a -m one\n> >>> +}\n> >>> +\n> >>> +setup\n> >> According to t/README `setup` should be inside an assertion just as any\n> >> other test:\n> > I have a bunch of 'setup' calls outside such assertions already in other test\n> > scripts. If you know how to put single quotes inside of single quotes in a\n> > shell script, please share that knowledge, otherwise the setup must be outside.\n> >\n> > Of course we could do the extremely reduntant:\n> >\n> > test_expect_success 'setup' '\n> > setup\n> > '\n> \n> Setup does not look any different from the other tests.\n> If you need single quotes you could use double quotes outside. Though,\n> you would have to quote other things as well.\n> t0000-basic.sh has a lot of tests that do that.\n> Like this, for example:\n> \n> test_expect_success 'setup' \"\n> \tmkdir -p .git/hooks &&\n> \tcat > .git/hooks/update-branch <<-\\\\EOF &&\n> \t#!/bin/sh\n> \techo \\$@ > .git/update-branch.args\n> \tEOF\n> \tchmod +x .git/hooks/update-branch &&\n> \techo one > content &&\n> \tgit add content &&\n> \tgit commit -a -m one\n> \"\n\nThat is not maintainable at all.\n\n-- \nFelipe Contreras\n"},{"id":"239250","messageId":"53558f6269f91_640076f2f08f@nysa.notmuch","threadId":"36461","inReplyTo":"53559020.1050407@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T21:36:34Z","receivedAt":"2014-04-21T21:36:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n> > Ilya Bobyr wrote:\n> >\n> >> Also, most have names that start with either \"pre-\" or \"post-\".\n> >> It seems reasonable for both \"pre-update-branch\" and\n> >> \"post-update-branch\" to exist.\n> > I don't see what would be the point in that.\n> \n> Do you see the point in the other hooks doing that?\n\nYes, there a reason for the existance of those hooks. Now tell me why would\nanybody use post-update-branch instead of pre-update-branch?\n\n-- \nFelipe Contreras\n"},{"id":"239246","messageId":"53558F6F.7080306@gmail.com","threadId":"36461","inReplyTo":"53558a663ea74_604be1f30c2c@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-21T21:36:47Z","receivedAt":"2014-04-21T21:36:47Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 2:15 PM, Felipe Contreras wrote:\n> Ilya Bobyr wrote:\n>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n>>> [...]\n>>>\n>>> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n>>> new file mode 100755\n>>> index 0000000..d921c0e\n>>> --- /dev/null\n>>> +++ b/t/t5408-update-branch-hook.sh\n>>> @@ -0,0 +1,39 @@\n>>> +#!/bin/sh\n>>> +\n>>> +test_description='Test the update-branch hook'\n>>> +\n>>> +. ./test-lib.sh\n>>> +\n>>> +setup () {\n>>> +\tmkdir -p .git/hooks &&\n>>> +\tcat > .git/hooks/update-branch <<-'EOF' &&\n>>> +\t#!/bin/sh\n>>> +\techo $@ > .git/update-branch.args\n>>> +\tEOF\n>>> +\tchmod +x .git/hooks/update-branch &&\n>>> +\techo one > content &&\n>>> +\tgit add content &&\n>>> +\tgit commit -a -m one\n>>> +}\n>>> +\n>>> +setup\n>> According to t/README `setup` should be inside an assertion just as any\n>> other test:\n> I have a bunch of 'setup' calls outside such assertions already in other test\n> scripts. If you know how to put single quotes inside of single quotes in a\n> shell script, please share that knowledge, otherwise the setup must be outside.\n>\n> Of course we could do the extremely reduntant:\n>\n> test_expect_success 'setup' '\n> setup\n> '\n\nSetup does not look any different from the other tests.\nIf you need single quotes you could use double quotes outside. Though,\nyou would have to quote other things as well.\nt0000-basic.sh has a lot of tests that do that.\nLike this, for example:\n\ntest_expect_success 'setup' \"\n\tmkdir -p .git/hooks &&\n\tcat > .git/hooks/update-branch <<-\\\\EOF &&\n\t#!/bin/sh\n\techo \\$@ > .git/update-branch.args\n\tEOF\n\tchmod +x .git/hooks/update-branch &&\n\techo one > content &&\n\tgit add content &&\n\tgit commit -a -m one\n\"\n"},{"id":"239247","messageId":"53559020.1050407@gmail.com","threadId":"36461","inReplyTo":"53558ae6f1282_604be1f30cf3@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-21T21:39:44Z","receivedAt":"2014-04-21T21:39:44Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n> Ilya Bobyr wrote:\n>\n>> Also, most have names that start with either \"pre-\" or \"post-\".\n>> It seems reasonable for both \"pre-update-branch\" and\n>> \"post-update-branch\" to exist.\n> I don't see what would be the point in that.\n\nDo you see the point in the other hooks doing that?\n"},{"id":"239251","messageId":"xmqqa9be8i4o.fsf@gitster.dls.corp.google.com","threadId":"36461","inReplyTo":"53559020.1050407@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-21T21:52:55Z","receivedAt":"2014-04-21T21:52:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ilya Bobyr writes:\n\n> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n>> Ilya Bobyr wrote:\n>>\n>>> Also, most have names that start with either \"pre-\" or \"post-\".\n>>> It seems reasonable for both \"pre-update-branch\" and\n>>> \"post-update-branch\" to exist.\n>> I don't see what would be the point in that.\n>\n> Do you see the point in the other hooks doing that?\n\npre- and post- are primarily so that people can tell that \"pre-\nhappens before the operation and its primary motivation is to stop\nan operation from happening\" as opposed to \"post- is called after\nthe fact and there is no way for it to intervene---it is too late;\nit is primarily for things like logging\" easily.\n\nAs long as you can tell what you can use it for and when it is\ncalled from the name of the hook, there is no fundamental reason why\nyou need to have pre- or post- prefix in your hook names, but unless\nthere is no other strong reason not to, it is probably a good idea\nto follow suit. There is not much value in trying to be \"original\"\nin naming things, just to be different; it will only confuse the\nusers.\n"},{"id":"239257","messageId":"53559a8333aaa_6c39e772f07f@nysa.notmuch","threadId":"36461","inReplyTo":"CADcHDF+XcWEkvyP3tL4ibicnaMVJpixUZu1Ces0BXWkzPGsodw@mail.gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T22:24:03Z","receivedAt":"2014-04-21T22:24:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <\n> felipe.contreras@gmail.com> wrote:\n> > Ilya Bobyr wrote:\n> > > test_expect_success 'setup' \"\n> > > mkdir -p .git/hooks &&\n> > > cat > .git/hooks/update-branch <<-\\\\EOF &&\n> > > #!/bin/sh\n> > > echo \\$@ > .git/update-branch.args\n> > > EOF\n> > > chmod +x .git/hooks/update-branch &&\n> > > echo one > content &&\n> > > git add content &&\n> > > git commit -a -m one\n> > > \"\n> >\n> > That is not maintainable at all.\n> \n> Maybe you could explain how is this less maintainable, compared to a separate\n> function?\n\nDo I really have to explain that manually escaping a shell script is not\nmaintainable?\n\n> This is how it is suggested by t/README and how it is done in the other\n> test suites.\n> I can not see how your case is different, but I might be missing something.\n\nLet's take a cursoy look at `git grep -l \"'EOF'\" t`.\n\n== t/t0009-prio-queue.sh ==\n\n cat >expect <<'EOF'\n 1\n 2\n 3\n 4\n 5\n 5\n 6\n 7\n 8\n 9\n 10\n EOF\n test_expect_success 'basic ordering' '\n\t test-prio-queue 2 6 3 10 9 5 7 4 5 8 1 dump >actual &&\n\t test_cmp expect actual\n '\n\nLook at that, code outside the cage, not once, but in every test.\n\n== t/t0040-parse-options.sh ==\n\n cat >>expect <<'EOF'\n list: foo\n list: bar\n list: baz\n EOF\n test_expect_success '--list keeps list of strings' '\n\t test-parse-options --list foo --list=bar --list=baz >output &&\n\t test_cmp expect output\n '\n\nOnce again.\n\n== t/t1411-reflog-show.sh ==\n== t/t2020-checkout-detach.sh ==\n== t/t3203-branch-output.sh ==\n== t/t3412-rebase-root.sh ==\n== t/t4014-format-patch.sh ==\n== t/t4030-diff-textconv.sh ==\n\nAll these do something similar, not once, but many many times.\n\n== t/t4031-diff-rewrite-binary.sh ==\n\n {\n\t echo \"#!$SHELL_PATH\"\n\t cat <<'EOF'\n \"$PERL_PATH\" -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < \"$1\"\n EOF\n } >dump\n chmod +x dump\n\nMore code outside.\n\n== t/t4042-diff-textconv-caching.sh ==\n\n cat >helper <<'EOF'\n #!/bin/sh\n sed 's/^/converted: /' \"$@\" >helper.out\n cat helper.out\n EOF\n chmod +x helper\n\n== t/t5401-update-hooks.sh ==\n\n cat >victim.git/hooks/pre-receive <<'EOF'\n #!/bin/sh\n printf %s \"$@\" >>$GIT_DIR/pre-receive.args\n cat - >$GIT_DIR/pre-receive.stdin\n echo STDOUT pre-receive\n echo STDERR pre-receive >&2\n EOF\n chmod u+x victim.git/hooks/pre-receive\n\nWould you look at that? This is actually a hook test that is changing the hook\n*outside* the cage.\n\n== t/t5402-post-merge-hook.sh ==\n\n for clone in 1 2; do\n cat >clone${clone}/.git/hooks/post-merge <<'EOF'\n #!/bin/sh\n echo $@ >> $GIT_DIR/post-merge.args\n EOF\n chmod u+x clone${clone}/.git/hooks/post-merge\n done\n\nAnother hook test with code outside.\n\n== t/t5403-post-checkout-hook.sh ==\n\nDoing the same.\n\n== t/t5516-fetch-push.sh ==\n\n mk_test_with_hooks() {\n\t repo_name=$1\n\t mk_test \"$@\" &&\n\t (\n\t\t cd \"$repo_name\" &&\n\t\t mkdir .git/hooks &&\n\t\t cd .git/hooks &&\n\n\t\t cat >pre-receive <<-'EOF' &&\n\t\t #!/bin/sh\n\t\t cat - >>pre-receive.actual\n\t\t EOF\n\n\t\t cat >update <<-'EOF' &&\n\t\t #!/bin/sh\n\t\t printf \"%s %s %s\\n\" \"$@\" >>update.actual\n\t\t EOF\n\n\t\t cat >post-receive <<-'EOF' &&\n\t\t #!/bin/sh\n\t\t cat - >>post-receive.actual\n\t\t EOF\n\n\t\t cat >post-update <<-'EOF' &&\n\t\t #!/bin/sh\n\t\t for ref in \"$@\"\n\t\t do\n\t\t\t printf \"%s\\n\" \"$ref\" >>post-update.actual\n\t\t done\n\t\t EOF\n\n\t\t chmod +x pre-receive update post-receive post-update\n\t )\n }\n\nThis one is using a function, just like I am. It's not run outside, but we can\ndo the same.\n\n== t/t5571-pre-push-hook.sh ==\n\n write_script \"$HOOK\" <<'EOF'\n echo \"$1\" >actual\n echo \"$2\" >>actual\n cat >>actual\n EOF\n\nAnhoter hook test with code outside.\n\n== t/t7004-tag.sh ==\n\n cat >fakeeditor <<'EOF'\n #!/bin/sh\n test -n \"$1\" && exec >\"$1\"\n echo A signed tag message\n echo from a fake editor.\n EOF\n chmod +x fakeeditor\n\n== t/t7008-grep-binary.sh ==\n\n cat >nul_to_q_textconv <<'EOF'\n #!/bin/sh\n \"$PERL_PATH\" -pe 'y/\\000/Q/' < \"$1\"\n EOF\n chmod +x nul_to_q_textconv\n\n== t/t7504-commit-msg-hook.sh ==\n== t/t8006-blame-textconv.sh ==\n== t/t8007-cat-file-textconv.sh ==\n== t/t9138-git-svn-authors-prog.sh ==\n\nVery similar: scripts outside the cage.\n\n\nIn fact my version is actually cleaner than these, because the code that is run\noutside the cage is clearly delimited by a function.\n\n-- \nFelipe Contreras\n"},{"id":"239258","messageId":"53559b0cc066_6c39e772f09d@nysa.notmuch","threadId":"36461","inReplyTo":"xmqqa9be8i4o.fsf@gitster.dls.corp.google.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T22:26:20Z","receivedAt":"2014-04-21T22:26:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Ilya Bobyr writes:\n> \n> > On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n> >> Ilya Bobyr wrote:\n> >>\n> >>> Also, most have names that start with either \"pre-\" or \"post-\".\n> >>> It seems reasonable for both \"pre-update-branch\" and\n> >>> \"post-update-branch\" to exist.\n> >> I don't see what would be the point in that.\n> >\n> > Do you see the point in the other hooks doing that?\n> \n> pre- and post- are primarily so that people can tell that \"pre-\n> happens before the operation and its primary motivation is to stop\n> an operation from happening\" as opposed to \"post- is called after\n> the fact and there is no way for it to intervene---it is too late;\n> it is primarily for things like logging\" easily.\n> \n> As long as you can tell what you can use it for and when it is\n> called from the name of the hook, there is no fundamental reason why\n> you need to have pre- or post- prefix in your hook names, but unless\n> there is no other strong reason not to, it is probably a good idea\n> to follow suit. There is not much value in trying to be \"original\"\n> in naming things, just to be different; it will only confuse the\n> users.\n\nIt's not original; there are _already_ hooks without pre/post. And it's not\nconfusing, \"update-branch\" doesn't tell much, not any hook name could, that's\nwhat the documentation is for.\n\n-- \nFelipe Contreras\n"},{"id":"239274","messageId":"xmqqtx9m70fh.fsf@gitster.dls.corp.google.com","threadId":"36461","inReplyTo":"53559b0cc066_6c39e772f09d@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-21T23:00:34Z","receivedAt":"2014-04-21T23:00:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> ... there are _already_ hooks without pre/post.\n\nLike commit-msg? Yes, it would have been nicer if it were named\nverify-commit-message or something.\n\nOld mistakes are harder to change because of inertia. It is not a\ngood excuse to knowingly make a new mistake to add new exceptions\nthat the users need to check documentations for, is it?\n\n> And it's not confusing,\n\nA simple fact that Ilya asked the question tells us otherwise ;-)\n\nI personally do not see an immediate need for post-update-branch,\nbut if the new hook is about intervening an operation, it would be a\ngood idea to name the hook with \"pre-\" like other \"before doing\nsomething, validate the operation and forbid\" hooks. Otherwise it\nwould be impossible to later add \"post-update-branch\" for whatever\nreason without inviting \"why does pre-update-branch hook is misnamed\nas just update-branch, when other validation and post-action pair\nare named pre-something and post-something?\".\n"},{"id":"239295","messageId":"535606A3.8040704@gmail.com","threadId":"36461","inReplyTo":"53559a8333aaa_6c39e772f07f@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-22T06:05:23Z","receivedAt":"2014-04-22T06:05:23Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 3:24 PM, Felipe Contreras wrote:\n> Ilya Bobyr wrote:\n>> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <\n>> felipe.contreras@gmail.com> wrote:\n>>> Ilya Bobyr wrote:\n>>>> test_expect_success 'setup' \"\n>>>> mkdir -p .git/hooks &&\n>>>> cat > .git/hooks/update-branch <<-\\\\EOF &&\n>>>> #!/bin/sh\n>>>> echo \\$@ > .git/update-branch.args\n>>>> EOF\n>>>> chmod +x .git/hooks/update-branch &&\n>>>> echo one > content &&\n>>>> git add content &&\n>>>> git commit -a -m one\n>>>> \"\n>>> That is not maintainable at all.\n>> Maybe you could explain how is this less maintainable, compared to a separate\n>> function?\n> Do I really have to explain that manually escaping a shell script is not\n> maintainable?\n\nThis is rude.\n\nHere is how you can do it without escaping:\n\ntest_expect_success 'setup' '\n\tmkdir -p .git/hooks &&\n\tcat > .git/hooks/update-branch <<-\\EOF &&\n\t#!/bin/sh\n\techo $@ > .git/update-branch.args\n\tEOF\n\tchmod +x .git/hooks/update-branch &&\n\techo one > content &&\n\tgit add content &&\n\tgit commit -a -m one\n'\n\nIt is not different from most of the tests, I think.\n\n>> This is how it is suggested by t/README and how it is done in the other\n>> test suites.\n>> I can not see how your case is different, but I might be missing something.\n> Let's take a cursoy look at `git grep -l \"'EOF'\" t`.\n>\n> [...]\n\nSo the point is that some existing tests violate best practices?\nI do not think this is a good justification to do the same for new tests.\n\n> In fact my version is actually cleaner than these, because the code that is run\n> outside the cage is clearly delimited by a function.\n\nIt depends on the perspective.\nIf it fails, the failure would be missed regardless of if it is in a\nfunction or not.\nMost examples that you quoted only create files outside test_expect_success.\nEven that is not necessary.\n\nI am not telling you how you should write it.\nI am just saying that you are breaking one of the recommendations on how\nto write tests.\nThere are different options that adhere to the suggestions in t/README.\n"},{"id":"239297","messageId":"53560DA6.5040202@gmail.com","threadId":"36461","inReplyTo":"1398047016-21643-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-22T06:35:18Z","receivedAt":"2014-04-22T06:35:18Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> [...]\n>\n> diff --git a/branch.c b/branch.c\n> index 660097b..c2058d1 100644\n> --- a/branch.c\n> +++ b/branch.c\n> @@ -4,6 +4,7 @@\n> #include \"refs.h\"\n> #include \"remote.h\"\n> #include \"commit.h\"\n> +#include \"run-command.h\"\n> \n> struct tracking {\n> \tstruct refspec spec;\n> @@ -304,6 +305,11 @@ void create_branch(const char *head,\n> \tif (real_ref && track)\n> \t\tsetup_tracking(ref.buf + 11, real_ref, track, quiet);\n> \n> +\tif (run_hook_le(NULL, \"update-branch\", ref.buf + 11, sha1_to_hex(sha1), NULL)) {\n> +\t\tunlock_ref(lock);\n\nlock is NULL if dont_change_ref is true. unlock_ref() would crash in\nthat case.\nYou may want to add a test for that.\n\n> +\t\tdie(\"hook 'update-branch' returned error\");\n> +\t}\n> +\n> \tif (!dont_change_ref)\n> \t\tif (write_ref_sha1(lock, sha1, msg) < 0)\n> \t\t\tdie_errno(_(\"Failed to write ref\"));\n> diff --git a/builtin/clone.c b/builtin/clone.c\n> index 9b3c04d..6ec96e5 100644\n> --- a/builtin/clone.c\n> +++ b/builtin/clone.c\n> @@ -581,9 +581,10 @@ static void update_remote_refs(const struct ref *refs,\n> \t}\n> }\n> \n> -static void update_head(const struct ref *our, const struct ref *remote,\n> +static int update_head(const struct ref *our, const struct ref *remote,\n> \t\t\tconst char *msg)\n> {\n> +\tint err = 0;\n> \tif (our && starts_with(our->name, \"refs/heads/\")) {\n> \t\t/* Local default branch link */\n> \t\tcreate_symref(\"HEAD\", our->name, NULL);\n> @@ -591,6 +592,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n> \t\t\tconst char *head = skip_prefix(our->name, \"refs/heads/\");\n> \t\t\tupdate_ref(msg, \"HEAD\", our->old_sha1, NULL, 0, DIE_ON_ERR);\n> \t\t\tinstall_branch_config(0, head, option_origin, our->name);\n> +\t\t\terr = run_hook_le(NULL, \"update-branch\", head, sha1_to_hex(our->old_sha1), NULL);\n\nThis is happening after the branch is updated and a config section for\nit is created.\n\n> \t\t}\n> \t} else if (our) {\n> \t\tstruct commit *c = lookup_commit_reference(our->old_sha1);\n> @@ -606,6 +608,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n> \t\tupdate_ref(msg, \"HEAD\", remote->old_sha1,\n> \t\t\t NULL, REF_NODEREF, DIE_ON_ERR);\n> \t}\n> +\treturn err;\n> }\n> \n> static int checkout(void)\n> @@ -987,7 +990,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n> \tupdate_remote_refs(refs, mapped_refs, remote_head_points_at,\n> \t\t\t branch_top.buf, reflog_msg.buf, transport, !is_local);\n> \n> -\tupdate_head(our_head_points_at, remote_head, reflog_msg.buf);\n> +\terr = update_head(our_head_points_at, remote_head, reflog_msg.buf);\n> \n> \ttransport_unlock_pack(transport);\n> \ttransport_disconnect(transport);\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 1c41cbd..084dc36 100644\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -631,7 +631,11 @@ do_next () {\n> \t\tgit update-ref -m \"$message\" $head_name $newhead $orig_head &&\n> \t\tgit symbolic-ref \\\n> \t\t -m \"$GIT_REFLOG_ACTION: returning to $head_name\" \\\n> -\t\t HEAD $head_name\n> +\t\t HEAD $head_name &&\n> +\t\tif test -x \"$GIT_DIR\"/hooks/update-branch; then\n> +\t\t\t\"$GIT_DIR\"/hooks/update-branch $branch_name \\\n> +\t\t\t\t$newhead $onto\n> +\t\tfi\n\nIt looks like this is also after the branch was already updated.\n\n> \t\t;;\n> \tesac && {\n> \t\ttest ! -f \"$state_dir\"/verbose ||\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 2c75e9f..ededa32 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -149,7 +149,11 @@ move_to_original_branch () {\n> \t\t\t$head_name $(git rev-parse HEAD) $orig_head &&\n> \t\tgit symbolic-ref \\\n> \t\t\t-m \"rebase finished: returning to $head_name\" \\\n> -\t\t\tHEAD $head_name ||\n> +\t\t\tHEAD $head_name &&\n> +\t\tif test -x \"$GIT_DIR\"/hooks/update-branch; then\n> +\t\t\t\"$GIT_DIR\"/hooks/update-branch $branch_name \\\n> +\t\t\t\t$(git rev-parse HEAD) $onto\n> +\t\tfi ||\n\nSame here.\n\n> \t\tdie \"$(gettext \"Could not move back to $head_name\")\"\n> \t\t;;\n> \tesac\n> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh\n> new file mode 100755\n> index 0000000..d921c0e\n> --- /dev/null\n> +++ b/t/t5408-update-branch-hook.sh\n> @@ -0,0 +1,39 @@\n> +#!/bin/sh\n> +\n> +test_description='Test the update-branch hook'\n> +\n> +. ./test-lib.sh\n> +\n> +setup () {\n> +\tmkdir -p .git/hooks &&\n> +\tcat > .git/hooks/update-branch <<-'EOF' &&\n> +\t#!/bin/sh\n> +\techo $@ > .git/update-branch.args\n> +\tEOF\n> +\tchmod +x .git/hooks/update-branch &&\n> +\techo one > content &&\n> +\tgit add content &&\n> +\tgit commit -a -m one\n> +}\n> +\n> +setup\n> +\n> +test_expect_success 'creating a branch' '\n> +\tgit checkout -b test master &&\n> +\techo two > new &&\n> +\tgit add new &&\n> +\tgit commit -a -m two\n> +\techo \"test $(git rev-parse master)\" > expected &&\n> +\ttest_cmp expected .git/update-branch.args\n> +'\n> +\n> +test_expect_success 'doing a rebase' '\n> +\tgit checkout -b next master &&\n> +\techo three > content &&\n> +\tgit commit -a -m three &&\n> +\tgit rebase --onto next master test &&\n> +\techo \"test $(git rev-parse HEAD) $(git rev-parse next)\" > expected &&\n> +\ttest_cmp expected .git/update-branch.args\n> +'\n> +\n> +test_done\n"},{"id":"239298","messageId":"53560F28.9020904@gmail.com","threadId":"36461","inReplyTo":"53558476703cb_5c94d452ec4e@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-22T06:41:44Z","receivedAt":"2014-04-22T06:41:44Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 1:49 PM, Felipe Contreras wrote:\n> Ilya Bobyr wrote:\n>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n>>> This hook is invoked whenever a branch is updated, either when a branch\n>>> is created or updated with 'git branch', or when it's rebased with 'git\n>>> rebase'. It receives two parameters; the name of the branch, and the\n>>> SHA-1 of the latest commit, additionally, if there was a base commit the\n>>> branch was rebased onto, a third parameter contains it.\n>> And the old branch SHA could be found from in the reflog, correct?\n> Actually the old branch SHA-1 is actually the current one, since the branch\n> hasn't been updated at that point. Personally I don't see much value in adding\n> something the script can easily find out.\n\nIf the hook is about a branch update, I would expect it to provide both\nold and new points for the branch, along with the name.\n\nThe fact that for rebases it also provides new base SHA is very\nconvenient. As it is an optional argument it may make further extension\nof the interface a bit awkward.\nSo, is seems reasonable to provide both from the very beginning.\nI was looking for hooks like that, to maintain certain meta-data about\nthe branches.\nOld SHA would be very useful in that case.\n\nI am not sure if both SHAs are easily available at the point where the\nhook is called.\n"},{"id":"239299","messageId":"5356100296994_268bd0b30839@nysa.notmuch","threadId":"36461","inReplyTo":"535606A3.8040704@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T06:45:22Z","receivedAt":"2014-04-22T06:45:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/21/2014 3:24 PM, Felipe Contreras wrote:\n> > Ilya Bobyr wrote:\n> >> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <\n> >> felipe.contreras@gmail.com> wrote:\n> >>> Ilya Bobyr wrote:\n> >>>> test_expect_success 'setup' \"\n> >>>> mkdir -p .git/hooks &&\n> >>>> cat > .git/hooks/update-branch <<-\\\\EOF &&\n> >>>> #!/bin/sh\n> >>>> echo \\$@ > .git/update-branch.args\n> >>>> EOF\n> >>>> chmod +x .git/hooks/update-branch &&\n> >>>> echo one > content &&\n> >>>> git add content &&\n> >>>> git commit -a -m one\n> >>>> \"\n> >>> That is not maintainable at all.\n> >> Maybe you could explain how is this less maintainable, compared to a separate\n> >> function?\n> > Do I really have to explain that manually escaping a shell script is not\n> > maintainable?\n> \n> This is rude.\n\nSo? I really don't see the need to explain that such a monstrosity would be\nunmaintainable, that's a given.\n\n> Here is how you can do it without escaping:\n> \n> test_expect_success 'setup' '\n> \tmkdir -p .git/hooks &&\n> \tcat > .git/hooks/update-branch <<-\\EOF &&\n> \t#!/bin/sh\n> \techo $@ > .git/update-branch.args\n> \tEOF\n> \tchmod +x .git/hooks/update-branch &&\n> \techo one > content &&\n> \tgit add content &&\n> \tgit commit -a -m one\n> '\n> \n> It is not different from most of the tests, I think.\n\nThis is what I originally asked for.\n\n> >> This is how it is suggested by t/README and how it is done in the other\n> >> test suites.\n> >> I can not see how your case is different, but I might be missing something.\n> > Let's take a cursoy look at `git grep -l \"'EOF'\" t`.\n> >\n> > [...]\n> \n> So the point is that some existing tests violate best practices?\n\nI don't know what you mean by \"best practices\", but these are Git's best practices.\n\n> I do not think this is a good justification to do the same for new tests.\n\nIt is not a justification to reject a patch either, specially if no better\nalternative has been put forward.\n\nFortunately a better alternative has been put forward, so this is moot.\n \n-- \nFelipe Contreras\n"},{"id":"239303","messageId":"535612a197c81_268bd0b3089a@nysa.notmuch","threadId":"36461","inReplyTo":"5356138D.9040409@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T06:56:33Z","receivedAt":"2014-04-22T06:56:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/21/2014 11:45 PM, Felipe Contreras wrote:\n> > [...]\n> >>>> This is how it is suggested by t/README and how it is done in the other\n> >>>> test suites.\n> >>>> I can not see how your case is different, but I might be missing something.\n> >>> Let's take a cursoy look at `git grep -l \"'EOF'\" t`.\n> >>>\n> >>> [...]\n> >> So the point is that some existing tests violate best practices?\n> > I don't know what you mean by \"best practices\", but these are Git's best practices.\n> \n> I am talking about recommendations in t/README that I quoted.\n\nThose are *guidelines*, best practices are defined as things you actually do,\nas in \"actually practice\".\n\n-- \nFelipe Contreras\n"},{"id":"239301","messageId":"5356138D.9040409@gmail.com","threadId":"36461","inReplyTo":"5356100296994_268bd0b30839@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-22T07:00:29Z","receivedAt":"2014-04-22T07:00:29Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/21/2014 11:45 PM, Felipe Contreras wrote:\n> [...]\n>>>> This is how it is suggested by t/README and how it is done in the other\n>>>> test suites.\n>>>> I can not see how your case is different, but I might be missing something.\n>>> Let's take a cursoy look at `git grep -l \"'EOF'\" t`.\n>>>\n>>> [...]\n>> So the point is that some existing tests violate best practices?\n> I don't know what you mean by \"best practices\", but these are Git's best practices.\n\nI am talking about recommendations in t/README that I quoted.\n"},{"id":"239339","messageId":"857g6h5ssh.fsf@stephe-leake.org","threadId":"36461","inReplyTo":"53558f6269f91_640076f2f08f@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-04-22T14:43:10Z","receivedAt":"2014-04-22T14:43:10Z","isPatch":true,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Felipe Contreras writes:\n\n> Ilya Bobyr wrote:\n>> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n>> > Ilya Bobyr wrote:\n>> >\n>> >> Also, most have names that start with either \"pre-\" or \"post-\".\n>> >> It seems reasonable for both \"pre-update-branch\" and\n>> >> \"post-update-branch\" to exist.\n>> > I don't see what would be the point in that.\n>> \n>> Do you see the point in the other hooks doing that?\n>\n> Yes, there a reason for the existance of those hooks. Now tell me why would\n> anybody use post-update-branch instead of pre-update-branch?\n\nI have a branch which should always be recompiled on update;\npost-update-branch would be a good place for that.\n\n-- \n-- Stephe\n"},{"id":"239345","messageId":"535698563b5d1_3e5aed7308da@nysa.notmuch","threadId":"36461","inReplyTo":"53560DA6.5040202@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T16:27:02Z","receivedAt":"2014-04-22T16:27:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> > [...]\n> >\n> > diff --git a/branch.c b/branch.c\n> > index 660097b..c2058d1 100644\n> > --- a/branch.c\n> > +++ b/branch.c\n> > @@ -4,6 +4,7 @@\n> > #include \"refs.h\"\n> > #include \"remote.h\"\n> > #include \"commit.h\"\n> > +#include \"run-command.h\"\n> > \n> > struct tracking {\n> > \tstruct refspec spec;\n> > @@ -304,6 +305,11 @@ void create_branch(const char *head,\n> > \tif (real_ref && track)\n> > \t\tsetup_tracking(ref.buf + 11, real_ref, track, quiet);\n> > \n> > +\tif (run_hook_le(NULL, \"update-branch\", ref.buf + 11, sha1_to_hex(sha1), NULL)) {\n> > +\t\tunlock_ref(lock);\n> \n> lock is NULL if dont_change_ref is true. unlock_ref() would crash in\n> that case.\n> You may want to add a test for that.\n\nThat should be easy to fix.\n \n> > +\t\tdie(\"hook 'update-branch' returned error\");\n> > +\t}\n> > +\n> > \tif (!dont_change_ref)\n> > \t\tif (write_ref_sha1(lock, sha1, msg) < 0)\n> > \t\t\tdie_errno(_(\"Failed to write ref\"));\n> > diff --git a/builtin/clone.c b/builtin/clone.c\n> > index 9b3c04d..6ec96e5 100644\n> > --- a/builtin/clone.c\n> > +++ b/builtin/clone.c\n> > @@ -581,9 +581,10 @@ static void update_remote_refs(const struct ref *refs,\n> > \t}\n> > }\n> > \n> > -static void update_head(const struct ref *our, const struct ref *remote,\n> > +static int update_head(const struct ref *our, const struct ref *remote,\n> > \t\t\tconst char *msg)\n> > {\n> > +\tint err = 0;\n> > \tif (our && starts_with(our->name, \"refs/heads/\")) {\n> > \t\t/* Local default branch link */\n> > \t\tcreate_symref(\"HEAD\", our->name, NULL);\n> > @@ -591,6 +592,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n> > \t\t\tconst char *head = skip_prefix(our->name, \"refs/heads/\");\n> > \t\t\tupdate_ref(msg, \"HEAD\", our->old_sha1, NULL, 0, DIE_ON_ERR);\n> > \t\t\tinstall_branch_config(0, head, option_origin, our->name);\n> > +\t\t\terr = run_hook_le(NULL, \"update-branch\", head, sha1_to_hex(our->old_sha1), NULL);\n> \n> This is happening after the branch is updated and a config section for\n> it is created.\n\nI see that now, however, I cannot find where in builtin/clone.c is the branch\nref actually updated.\n\nWorst, I don't see how I could possibly configure a hook to be triggered when\ncloning, so I cannot test.\n \n> > \t\t}\n> > \t} else if (our) {\n> > \t\tstruct commit *c = lookup_commit_reference(our->old_sha1);\n> > @@ -606,6 +608,7 @@ static void update_head(const struct ref *our, const struct ref *remote,\n> > \t\tupdate_ref(msg, \"HEAD\", remote->old_sha1,\n> > \t\t\t NULL, REF_NODEREF, DIE_ON_ERR);\n> > \t}\n> > +\treturn err;\n> > }\n> > \n> > static int checkout(void)\n> > @@ -987,7 +990,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n> > \tupdate_remote_refs(refs, mapped_refs, remote_head_points_at,\n> > \t\t\t branch_top.buf, reflog_msg.buf, transport, !is_local);\n> > \n> > -\tupdate_head(our_head_points_at, remote_head, reflog_msg.buf);\n> > +\terr = update_head(our_head_points_at, remote_head, reflog_msg.buf);\n> > \n> > \ttransport_unlock_pack(transport);\n> > \ttransport_disconnect(transport);\n> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> > index 1c41cbd..084dc36 100644\n> > --- a/git-rebase--interactive.sh\n> > +++ b/git-rebase--interactive.sh\n> > @@ -631,7 +631,11 @@ do_next () {\n> > \t\tgit update-ref -m \"$message\" $head_name $newhead $orig_head &&\n> > \t\tgit symbolic-ref \\\n> > \t\t -m \"$GIT_REFLOG_ACTION: returning to $head_name\" \\\n> > -\t\t HEAD $head_name\n> > +\t\t HEAD $head_name &&\n> > +\t\tif test -x \"$GIT_DIR\"/hooks/update-branch; then\n> > +\t\t\t\"$GIT_DIR\"/hooks/update-branch $branch_name \\\n> > +\t\t\t\t$newhead $onto\n> > +\t\tfi\n> \n> It looks like this is also after the branch was already updated.\n\nThis and the one below should be easy to fix.\n\n-- \nFelipe Contreras\n"},{"id":"239346","messageId":"535699181d3d9_3e5aed730876@nysa.notmuch","threadId":"36461","inReplyTo":"53560F28.9020904@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T16:30:16Z","receivedAt":"2014-04-22T16:30:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/21/2014 1:49 PM, Felipe Contreras wrote:\n> > Ilya Bobyr wrote:\n> >> On 4/20/2014 7:23 PM, Felipe Contreras wrote:\n> >>> This hook is invoked whenever a branch is updated, either when a branch\n> >>> is created or updated with 'git branch', or when it's rebased with 'git\n> >>> rebase'. It receives two parameters; the name of the branch, and the\n> >>> SHA-1 of the latest commit, additionally, if there was a base commit the\n> >>> branch was rebased onto, a third parameter contains it.\n> >> And the old branch SHA could be found from in the reflog, correct?\n> > Actually the old branch SHA-1 is actually the current one, since the branch\n> > hasn't been updated at that point. Personally I don't see much value in adding\n> > something the script can easily find out.\n> \n> If the hook is about a branch update, I would expect it to provide both\n> old and new points for the branch, along with the name.\n\nAgain, I don't see the the point of passing something that is easy to find out:\n`git rev-parse $branch` gives you that information.\n\n> The fact that for rebases it also provides new base SHA is very\n> convenient. As it is an optional argument it may make further extension\n> of the interface a bit awkward.\n> So, is seems reasonable to provide both from the very beginning.\n\nSo basically `git branch` would send the same SHA-1 twice.\n\n-- \nFelipe Contreras\n"},{"id":"239347","messageId":"5356996d12ede_3e5aed7308e5@nysa.notmuch","threadId":"36461","inReplyTo":"857g6h5ssh.fsf@stephe-leake.org","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T16:31:41Z","receivedAt":"2014-04-22T16:31:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Stephen Leake wrote:\n> Felipe Contreras writes:\n> \n> > Ilya Bobyr wrote:\n> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n> >> > Ilya Bobyr wrote:\n> >> >\n> >> >> Also, most have names that start with either \"pre-\" or \"post-\".\n> >> >> It seems reasonable for both \"pre-update-branch\" and\n> >> >> \"post-update-branch\" to exist.\n> >> > I don't see what would be the point in that.\n> >> \n> >> Do you see the point in the other hooks doing that?\n> >\n> > Yes, there a reason for the existance of those hooks. Now tell me why would\n> > anybody use post-update-branch instead of pre-update-branch?\n> \n> I have a branch which should always be recompiled on update;\n> post-update-branch would be a good place for that.\n\nAnd why would pre-update-branch not serve that purpose?\n\n-- \nFelipe Contreras\n"},{"id":"239350","messageId":"5356A25D.1050001@gmail.com","threadId":"36461","inReplyTo":"5356996d12ede_3e5aed7308e5@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Ilya Bobyr","fromEmail":"ilya.bobyr@gmail.com","sentAt":"2014-04-22T17:09:49Z","receivedAt":"2014-04-22T17:09:49Z","isPatch":true,"sender":{"key":"ilya.bobyr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/694419?v=4"},"body":"On 4/22/2014 9:31 AM, Felipe Contreras wrote:\n> Stephen Leake wrote:\n>> Felipe Contreras writes:\n>>\n>>> Ilya Bobyr wrote:\n>>>> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n>>>>> Ilya Bobyr wrote:\n>>>>>\n>>>>>> Also, most have names that start with either \"pre-\" or \"post-\".\n>>>>>> It seems reasonable for both \"pre-update-branch\" and\n>>>>>> \"post-update-branch\" to exist.\n>>>>> I don't see what would be the point in that.\n>>>> Do you see the point in the other hooks doing that?\n>>> Yes, there a reason for the existance of those hooks. Now tell me why would\n>>> anybody use post-update-branch instead of pre-update-branch?\n>> I have a branch which should always be recompiled on update;\n>> post-update-branch would be a good place for that.\n> And why would pre-update-branch not serve that purpose?\n\n\"pre-\" hook could be used, but if the hooks is not supposed to prevent\nthe operation, it seems reasonable to put it in the \"post-\" hook should\none be available.\nFor example, for clone and branch that would mean that that the branch\nsections are already created in .git/config, but for \"pre-\" hooks,\nshould be find the right spot, configuration could probably be absent\njust yet.\n\nI do not think that someone is objecting adding just the \"pre-\" hook first.\nBut it seems unlikely that one can envision all the possible use cases\nto say that \"post-\" hook would never be useful.\n"},{"id":"239354","messageId":"5356a6ae93668_463e11ef310e6@nysa.notmuch","threadId":"36461","inReplyTo":"5356A25D.1050001@gmail.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T17:28:14Z","receivedAt":"2014-04-22T17:28:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ilya Bobyr wrote:\n> On 4/22/2014 9:31 AM, Felipe Contreras wrote:\n> > Stephen Leake wrote:\n> >> Felipe Contreras writes:\n> >>> Yes, there a reason for the existance of those hooks. Now tell me why would\n> >>> anybody use post-update-branch instead of pre-update-branch?\n> >> \n> >> I have a branch which should always be recompiled on update;\n> >> post-update-branch would be a good place for that.\n> >> \n> > And why would pre-update-branch not serve that purpose?\n> \n> \"pre-\" hook could be used, but if the hooks is not supposed to prevent\n> the operation, it seems reasonable to put it in the \"post-\" hook should\n> one be available.\n\nIf 'pre-update-branch' can be used, then you are pretty much agreeing to the fact\nthat the 'post-udpate-branch' hook would be *useless*.\n\nSuch a script would work both as 'pre-update-branch' and 'post-update-branch',\ntherefore a single 'update-branch' would serve.\n\nSo I ask again:\n\nTell me why would anybody need 'post-update-branch' instead of\n'pre-update-branch'?\n\n-- \nFelipe Contreras\n"},{"id":"239410","messageId":"85mwfc4hab.fsf@stephe-leake.org","threadId":"36461","inReplyTo":"5356996d12ede_3e5aed7308e5@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-04-23T07:49:16Z","receivedAt":"2014-04-23T07:49:16Z","isPatch":true,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Felipe Contreras writes:\n\n> Stephen Leake wrote:\n>> Felipe Contreras writes:\n>> \n>> > Ilya Bobyr wrote:\n>> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n>> >> > Ilya Bobyr wrote:\n>> >> >\n>> >> >> Also, most have names that start with either \"pre-\" or \"post-\".\n>> >> >> It seems reasonable for both \"pre-update-branch\" and\n>> >> >> \"post-update-branch\" to exist.\n>> >> > I don't see what would be the point in that.\n>> >> \n>> >> Do you see the point in the other hooks doing that?\n>> >\n>> > Yes, there a reason for the existance of those hooks. Now tell me why would\n>> > anybody use post-update-branch instead of pre-update-branch?\n>> \n>> I have a branch which should always be recompiled on update;\n>> post-update-branch would be a good place for that.\n>\n> And why would pre-update-branch not serve that purpose?\n\nBecause the code that needs to be compiled is not yet in the workspace\n\n-- \n-- Stephe\n"},{"id":"239414","messageId":"535782d95bbed_24448772ec7a@nysa.notmuch","threadId":"36461","inReplyTo":"85mwfc4hab.fsf@stephe-leake.org","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-23T09:07:37Z","receivedAt":"2014-04-23T09:07:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Stephen Leake wrote:\n> Felipe Contreras writes:\n> \n> > Stephen Leake wrote:\n> >> Felipe Contreras writes:\n> >> \n> >> > Ilya Bobyr wrote:\n> >> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:\n> >> >> > Ilya Bobyr wrote:\n> >> >> >\n> >> >> >> Also, most have names that start with either \"pre-\" or \"post-\".\n> >> >> >> It seems reasonable for both \"pre-update-branch\" and\n> >> >> >> \"post-update-branch\" to exist.\n> >> >> > I don't see what would be the point in that.\n> >> >> \n> >> >> Do you see the point in the other hooks doing that?\n> >> >\n> >> > Yes, there a reason for the existance of those hooks. Now tell me why would\n> >> > anybody use post-update-branch instead of pre-update-branch?\n> >> \n> >> I have a branch which should always be recompiled on update;\n> >> post-update-branch would be a good place for that.\n> >\n> > And why would pre-update-branch not serve that purpose?\n> \n> Because the code that needs to be compiled is not yet in the workspace\n\nAnd it won't be in 'post-update-branch' either.\n\n % git checkout master\n % git branch feature-a stable\n <- update-branch hook will be called here\n\nThe hook will get 'feature-a' as the first argument, but the code in the\nworkspace would correspond to 'master'; the checked out branch (pre or post).\n\n-- \nFelipe Contreras\n"},{"id":"239501","messageId":"53583111dd8ad_24448772ec17@nysa.notmuch","threadId":"36461","inReplyTo":"xmqqtx9m70fh.fsf@gitster.dls.corp.google.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-23T21:30:57Z","receivedAt":"2014-04-23T21:30:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > ... there are _already_ hooks without pre/post.\n> \n> Like commit-msg? Yes, it would have been nicer if it were named\n> verify-commit-message or something.\n\nNo it wouldn't. I can use the commit-msg hook to change the commit message and\nto absolutely no verification, so verify-commit-message would be misleading.\n\nMaybe you would like modify-and-or-verify-commit-message which would be\ncorrect, but I wouldn't, I like short-and-sweet, and commit-msg is just that.\n\n> Old mistakes are harder to change because of inertia. It is not a\n> good excuse to knowingly make a new mistake to add new exceptions\n> that the users need to check documentations for, is it?\n\nThat's a nifty trick; label something a mistake, and then it suddenly becomes\none.\n\nNo, it's not a mistake, first it has to be proven to be mistake and I haven't\nseen any arguments that try to do so.\n\nBesides it's a red herring, you said such a name would be original and I've\njust proved that it's not original, so the originality is not a concern.\n\n> > And it's not confusing,\n> \n> A simple fact that Ilya asked the question tells us otherwise ;-)\n\nIt's not any more confusing than these:\n\napplypatch-msg:\n\nWhen does this happen? Can I return an error?\n\npre-applypatch:\n\nAgain when does it happen? What does the input contains? The whole patch? Including the message?\n\npost-applypatch:\n\nTotally confused.\n\npre-commit:\nprepare-commit-msg:\ncommit-msg:\n\nWhat is the difference between these? Doesn't pre-commit contains the message already?\n\npre-receive:\n\nBefore receiving what?\n\nupdate:\n\nUpdating what? When is it called? Can I cancel something?\n\nThe fact that somebody asked a question doesn't make a name confusing.\n\n> I personally do not see an immediate need for post-update-branch,\n> but if the new hook is about intervening an operation,\n\nIt's not about that, I can remove that feature if it would make you happier.\n\n> Otherwise it would be impossible to later add \"post-update-branch\"\n\nWhich is never going to happen.\n\nI'm still waiting for anybody to imagine any reason why we might want\npost-udpate-branch.\n\n-- \nFelipe Contreras\n"},{"id":"239504","messageId":"xmqqvbtzwv4l.fsf@gitster.dls.corp.google.com","threadId":"36461","inReplyTo":"53583111dd8ad_24448772ec17@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-23T22:15:06Z","receivedAt":"2014-04-23T22:15:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> \n>> > ... there are _already_ hooks without pre/post.\n>> \n>> Like commit-msg? Yes, it would have been nicer if it were named\n>> verify-commit-message or something.\n>\n> No it wouldn't. I can use the commit-msg hook to change the commit message and\n> to absolutely no verification, so verify-commit-message would be misleading.\n\nYou are confused (and please do not spread the confusion). If you\nread the first paragraph of the documentation on the hook and think\nfor 5 seconds why \"--no-verify\" countermands it, you would realize\nthat the hook is primarily meant for verification. We also allow\nthe hook to edit the message, but that is not even \"a useful feature\nadded as an afterthought\"; the documentation mentions it because the\nimplementation did not bother to make sure the hook did not touch\nthe message file.\n\nIt was a mistake not to call it with a clear name that tells\nverification happens there.\n\n>> Old mistakes are harder to change because of inertia. It is not a\n>> good excuse to knowingly make a new mistake to add new exceptions\n>> that the users need to check documentations for, is it?\n\nI see no reason to waste more time on this point.\n"},{"id":"239506","messageId":"xmqqoazrwtsc.fsf@gitster.dls.corp.google.com","threadId":"36461","inReplyTo":"535782d95bbed_24448772ec7a@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-23T22:44:03Z","receivedAt":"2014-04-23T22:44:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> >> I have a branch which should always be recompiled on update;\n>> >> post-update-branch would be a good place for that.\n>> >\n>> > And why would pre-update-branch not serve that purpose?\n>> \n>> Because the code that needs to be compiled is not yet in the workspace\n>\n> And it won't be in 'post-update-branch' either.\n>\n> % git checkout master\n> % git branch feature-a stable\n> <- update-branch hook will be called here\n>\n> The hook will get 'feature-a' as the first argument, but the code in the\n> workspace would correspond to 'master'; the checked out branch (pre or post).\n\nThe whole point of a pre- hook is to run _before_ the externally\nobservable state changes due to the operation.\n\nIf Stephen has a separate build-tree that fetches from the branch\nevery time the tip of the branch changes in this repository to\nproduce build artifacts for the branch to be shared in his network,\nperhaps via NFS or something. \"git fetch\" that will be run from\nthat build-tree repository will *not* see the tip of the branch, and\nrunning such a hook will not be possible from a pre-update-branch\nhook.\n\nWe can certainly argue that such a hook could instead push to the\nbuild-tree repository using the commit object name, but I tend to\nthink such an argument is merely sidestepping the real issue. Some\nhooks do want to observe the state _after_ the operation [*1*],\nwhile some hooks can do without seeing exactly the state after the\noperation.\n\nSo while I am generally not very supportive towards post-anything\nhook, I would reject a claim that says \"pre-anything can be used\nwithout inventing post-anything---do the same thing and allow the\noperation and you are done\". That is not simply true.\n\n\n[Footnote]\n\n*1* A trivial example: send out an e-mail that contains the output\n from \"git branch -l -v\" or \"git log --oneline --decorate --all\"\n to a logger and expect to see the branch tip pointing at the\n commit _after_ the operation.\n"},{"id":"239510","messageId":"535862411c29d_3c7abff3103e@nysa.notmuch","threadId":"36461","inReplyTo":"xmqqvbtzwv4l.fsf@gitster.dls.corp.google.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T01:00:49Z","receivedAt":"2014-04-24T01:00:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >> \n> >> > ... there are _already_ hooks without pre/post.\n> >> \n> >> Like commit-msg? Yes, it would have been nicer if it were named\n> >> verify-commit-message or something.\n> >\n> > No it wouldn't. I can use the commit-msg hook to change the commit message and\n> > to absolutely no verification, so verify-commit-message would be misleading.\n> \n> You are confused (and please do not spread the confusion). If you\n> read the first paragraph of the documentation on the hook and think\n> for 5 seconds why \"--no-verify\" countermands it, you would realize\n> that the hook is primarily meant for verification.\n\nI do not care what the hook is \"primarily for\", it's for more than just\nverification.\n\n> We also allow the hook to edit the message, but that is not even \"a useful\n> feature added as an afterthought\"; the documentation mentions it because the\n> implementation did not bother to make sure the hook did not touch the message\n> file.\n\nIndeed it's too late now, and now the hook does more than just verification,\ntherefore verify-commit-message wouldn't be an appropriate name.\n\n> It was a mistake not to call it with a clear name that tells\n> verification happens there.\n\nNo, the name is fine for what the hook does, if you would want the script to do\nsomething different, *and* change the name of the script, that's a different\nissue.\n\n> >> Old mistakes are harder to change because of inertia. It is not a\n> >> good excuse to knowingly make a new mistake to add new exceptions\n> >> that the users need to check documentations for, is it?\n> \n> I see no reason to waste more time on this point.\n\nYou haven't proved it's a mistake.\n\nThe only thing you have showed is that letting the 'commit-msg' modify the\nmessage was a mistake, not that the name is wrong for what it currently does.\n\n-- \nFelipe Contreras\n"},{"id":"239511","messageId":"535864bbc3a84_3c7abff3107b@nysa.notmuch","threadId":"36461","inReplyTo":"xmqqoazrwtsc.fsf@gitster.dls.corp.google.com","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T01:11:23Z","receivedAt":"2014-04-24T01:11:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> >> I have a branch which should always be recompiled on update;\n> >> >> post-update-branch would be a good place for that.\n> >> >\n> >> > And why would pre-update-branch not serve that purpose?\n> >> \n> >> Because the code that needs to be compiled is not yet in the workspace\n> >\n> > And it won't be in 'post-update-branch' either.\n> >\n> > % git checkout master\n> > % git branch feature-a stable\n> > <- update-branch hook will be called here\n> >\n> > The hook will get 'feature-a' as the first argument, but the code in the\n> > workspace would correspond to 'master'; the checked out branch (pre or post).\n> \n> The whole point of a pre- hook is to run _before_ the externally\n> observable state changes due to the operation.\n> \n> If Stephen has a separate build-tree that fetches from the branch\n> every time the tip of the branch changes in this repository to\n> produce build artifacts for the branch to be shared in his network,\n> perhaps via NFS or something. \"git fetch\" that will be run from\n> that build-tree repository will *not* see the tip of the branch, and\n> running such a hook will not be possible from a pre-update-branch\n> hook.\n> \n> We can certainly argue that such a hook could instead push to the\n> build-tree repository using the commit object name,\n\nExactly, it could do that.\n\n> but I tend to think such an argument is merely sidestepping the real issue.\n\nSo you grant that there is no reason anybody can think of why we would ever\nwant a post-update-branch?\n\n> Some hooks do want to observe the state _after_ the operation [*1*], while\n> some hooks can do without seeing exactly the state after the operation.\n\nYes, and when the operation is updating a branch, nobody can think of why we\nwould want the former.\n\n> So while I am generally not very supportive towards post-anything\n> hook, I would reject a claim that says \"pre-anything can be used\n> without inventing post-anything---do the same thing and allow the\n> operation and you are done\". That is not simply true.\n\nLet's make a bet, we go for 'pre-update-branch' and five years from now, if\nthere's no 'post-update-branch', you will publicly accept thta I was right.\n\nDeal?\n\n-- \nFelipe Contreras\n"},{"id":"239567","messageId":"8538h24xdg.fsf@stephe-leake.org","threadId":"36461","inReplyTo":"535782d95bbed_24448772ec7a@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-04-24T14:26:19Z","receivedAt":"2014-04-24T14:26:19Z","isPatch":true,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Felipe Contreras writes:\n\n>> >> I have a branch which should always be recompiled on update;\n>> >> post-update-branch would be a good place for that.\n>> >\n>> > And why would pre-update-branch not serve that purpose?\n>> \n>> Because the code that needs to be compiled is not yet in the workspace\n>\n> And it won't be in 'post-update-branch' either.\n\nThen you are using a very odd definition of \"post update\"\n\n> % git checkout master\n> % git branch feature-a stable\n> <- update-branch hook will be called here\n>\n> The hook will get 'feature-a' as the first argument, but the code in the\n> workspace would correspond to 'master'; the checked out branch (pre or post).\n\nThen the hooks should be called 'pre-branch', 'post-branch'; there is no\n\"update\" involved.\n\nThe hook I need is actually \"post-merge\", since \"merge\" is the command that\nupdates the workspace.\n\nSorry for the noise.\n-- \n-- Stephe\n"},{"id":"239582","messageId":"53595317c11b4_1f7b143d31089@nysa.notmuch","threadId":"36461","inReplyTo":"8538h24xdg.fsf@stephe-leake.org","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:08:23Z","receivedAt":"2014-04-24T18:08:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Stephen Leake wrote:\n> Felipe Contreras writes:\n> \n> >> >> I have a branch which should always be recompiled on update;\n> >> >> post-update-branch would be a good place for that.\n> >> >\n> >> > And why would pre-update-branch not serve that purpose?\n> >> \n> >> Because the code that needs to be compiled is not yet in the workspace\n> >\n> > And it won't be in 'post-update-branch' either.\n> \n> Then you are using a very odd definition of \"post update\"\n\nIt's not. The branch was updated, not the workspace.\n\n> > % git checkout master\n> > % git branch feature-a stable\n> > <- update-branch hook will be called here\n> >\n> > The hook will get 'feature-a' as the first argument, but the code in the\n> > workspace would correspond to 'master'; the checked out branch (pre or post).\n> \n> Then the hooks should be called 'pre-branch', 'post-branch'; there is no\n> \"update\" involved.\n\nOf course there is. A 'branch' hook would be triggered when you create a new\nbranch (e.g. `git branch`), however, it should not be triggered when you update\na branch (e.g. `git rebase`).\n\n> The hook I need is actually \"post-merge\", since \"merge\" is the command that\n> updates the workspace.\n\nI'd say it's probably 'post-checkout'.\n\n-- \nFelipe Contreras\n"},{"id":"239765","messageId":"7vfvl0htys.fsf@alter.siamese.dyndns.org","threadId":"36461","inReplyTo":"535864bbc3a84_3c7abff3107b@nysa.notmuch","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-26T17:38:19Z","receivedAt":"2014-04-26T17:38:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> So you grant that there is no reason anybody can think of why we would ever\n> want a post-update-branch?\n\nNo, it only shows that you (and I) are not imaginative enough\n(and/or we didn't bother spending enough brain cycles) to come up\nwith an example. Your lack of imagination and foresight does not\ngive you any right to close the door to those who come after you who\nhave real needs, or make it awkward to add it later for them.\n\n> Let's make a bet, we go for 'pre-update-branch' and five years from now, if\n> there's no 'post-update-branch', you will publicly accept thta I was right.\n>\n> Deal?\n\nLet me get this straight. You spent a lot of effort to argue that\nnaming it update-branch is the right thing, but now you want me to\nname it pre-update-branch, only so that you can prove you are right?\n\nPlaying a silly bet among friends may be fun from time to time. But\nI do not like using Git as a plaything, I am not your friend, and I\nnever felt it fun having to interact with you. I am not interested\nin proving you right or wrong. You are not that interesting.\n\nWhat you said however shows clearly the reason why it is not fun to\nwork with you, and I think that is a lot more important point. Your\npriorities are screwed up. For the rest of us, making Git better is\nthe primary reason why we are here. You seem to be saying that it\nis more important to you, however, to \"win\" your little argument,\nand you are willing to even sacrifice a better Git (in your mind,\nwith the hook named as update-branch) in order to \"win\".\n\nWith a person with such screwed-up priorities, nobody whose first\nobjective is to make Git better can have a sane conversation. Ask\nthose who said they do not want to work with you. In the list\narchive, there are plenty of examples to choose from, and I think\nthey will agree with me.\n\nIt is a pity that in all of these long flamefest, you may have meant\nwell to improve Git when you brought up something that needs to be\nsolved in your first few messages. The rest of us may even have\nagreed that it is good to address that issue on many of them. But\nthe time \"something needs to be done\" and \"the way Felipe proposes\nto solve it is good\" turns out to be different, i.e. when those who\nagree with the former do not agree with the latter, the discussions\nwith you go downhill quick. Each and every time. See your \"index\nis hard to learn for people---can we do something?\" topic, if you\nwant another example, where you try to twist words by Peff and\nothers and caught in doing so.\n\nNow, I know you are going to say \"that is what *you* think, and even\nif they agree, that is only what *they* think. it is not true! my\npriorities are right and they are wrong!\".\n\nI'd freely give you that they are only *impressions* we have on you,\nthat we were forced to form by observing your past and present\nbehaviours. It may not be \"true you\". You may be a loving an\nwonderful person in reality, and you are not showing your true self\nwhen you are on this list. But you know something? The project\nadvances by humans working together, and without telepathy, these\nimpression are the only thing we humans can go by.\n\nI also know that you are going to say \"that is what *you* think\". I\nhave nothing more to say to you at that point.\n\nIt could be that your \"bet\" is a way for you to finally admitting\nthat naming the hook with \"pre-\" prefix will result in a better Git\nthan without, without you having to say \"Yes, you are right, let's\nchange it\" (which I rarely if ever saw you doing). But still that\nshows the same screwed-up priorities---winning your little argument\n(or not losing it) matters more to you than working well with\nothers. I do not think I want to work with such a person.\n"},{"id":"239775","messageId":"535c08eb8105d_5310a7730895@nysa.notmuch","threadId":"36461","inReplyTo":"7vfvl0htys.fsf@alter.siamese.dyndns.org","subject":"Re: [RTC/PATCH] Add 'update-branch' hook","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-26T19:28:43Z","receivedAt":"2014-04-26T19:28:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > So you grant that there is no reason anybody can think of why we would ever\n> > want a post-update-branch?\n> \n> No, it only shows that you (and I) are not imaginative enough\n> (and/or we didn't bother spending enough brain cycles) to come up\n> with an example.\n\nThat is the same thing; nobody can think of a reason.\n\n> Your lack of imagination and foresight does not give you any right to close\n> the door to those who come after you who have real needs, or make it awkward\n> to add it later for them.\n\nNo, but rationality and evidence are the only things we can use to make\ndecisions, and there is no reason to think something is going to happen, I\ndon't see why any rational person would think that it would.\n\n> > Let's make a bet, we go for 'pre-update-branch' and five years from now, if\n> > there's no 'post-update-branch', you will publicly accept thta I was right.\n> >\n> > Deal?\n> \n> Let me get this straight. You spent a lot of effort to argue that\n> naming it update-branch is the right thing, but now you want me to\n> name it pre-update-branch, only so that you can prove you are right?\n\nThat is right.\n\nIt's impossible to convince you with logic and evidence, and even when you are\nshown to be wrong, you don't accept it.\n\nThere is literally nothing anybody can do to convince you that imaginary fears\nare just imaginary. At the end of the day your conclusion will be that the\nimprobable is still possible, well anything is possible, so saying \"I don't see\nhow A could happen, but it's possible\" is really not saying anything at all.\n\nSo yes, the only thing I can do is give up, however if you have any stakes in\nprogress of Git you would put your money where your mouth is.\n\nIf you had already done your job you should have some certainty on whether a\n'post-update-branch' is going to happen or not. If you don't have such\ncertainty enough to make a bet, then why should anybody trust your conclusion?\n\n> For the rest of us, making Git better is the primary reason why we are here.\n> You seem to be saying that it is more important to you, however, to \"win\"\n> your little argument, and you are willing to even sacrifice a better Git (in\n> your mind, with the hook named as update-branch) in order to \"win\".\n\nI can't make Git better if you don't humble yourself. You need to accept when\nyou are wrong.\n\nIf I say \"A is not going to happen\" and I provide evidence, but you say it\nwould, and indeed it doesn't happen, maybe when I say \"B is not going to\nhappen\", maybe you would actually listen, and if not, maybe when I say\n\"C is not going to happen\" you would.\n\nBut if you are only willing to accept you were wrong when it's safe, then how\nis anything going to change for the future.\n\n> With a person with such screwed-up priorities, nobody whose first\n> objective is to make Git better can have a sane conversation.\n\nYou are the one with the screwed priorities.\n\nTime and time again the #1 issue people have raised about Git is the\nuser-interface. We even had Git user surveys to try to find out what people\nwanted.\n\nIn these surveys the last thing people wanted was better performance, yet most\nGit developers are still focusing on performance.\n\nWhat people said needed improvement was the user-interface and documentation,\nyet *nothing* has changed in these two areas. It's not a wonder no more surveys\nare launched; because the results of such surveys are ignored anyway.\n\nIf a project has screwed-up priorities, it's when the areas of improvements\nusers say are needed get ignored.\n\n> if you want another example, where you try to twist words by Peff and others\n> and caught in doing so.\n\nThis is plainly intellectually dishonest. One year ago I made a summary of what\nothers said[1], I tried to keep it verbatim, CC'ed them, and invited them to\nclarify if their position was misrepresented. Nobody, not even Jeff complained\nabout that.\n\nNow, my mistake was thinking that \"A is better\" meant \"we should go for A\",\nhowever, that wasn't the case for Jeff. I didn't twist any words, I made a\nwrong assumption.\n\nHowever, I bet most people in that list agree that \"we should go for A\", and if\nyou want, I can ask them all again (except Jeff, because we know his answer).\nBut I bet you are not interested in what they (or for that matter anyone) think\non the matter.\n\nAnd you know it was an easy mistake to make, to accuse me of twisting words is\njust dishonest.\n\n> It could be that your \"bet\" is a way for you to finally admitting\n> that naming the hook with \"pre-\" prefix will result in a better Git\n> than without, without you having to say \"Yes, you are right, let's\n> change it\" (which I rarely if ever saw you doing). But still that\n> shows the same screwed-up priorities---winning your little argument\n> (or not losing it) matters more to you than working well with\n> others. I do not think I want to work with such a person.\n\nThat is not it at all.\n\nHow am I going to convince you of anything controversial in the future, if you\nare never willing to admit that you were wrong, and pay a small public face\nprice?\n\nThe fact of the matter is that you don't want to be wrong, you don't want to be\nshown to be wrong, and you don't want to accept you were wrong. Therefore you\nreject any experiment in tha direction, and you ignore things like the user\nsurvey that shows your priorities are wrong.\n\n*This* is what hurts the project, not my \"bet\".\n\nNow, if you had any certainty on what you are saying, you would say \"Sure\", win\nthe bet, and nothing bad would happen, users would have \"pre-update-branch\" and\n\"post-update-branch\", and everybody would be happy (except me a little bit\nbecause I was wrong). But the fact of the matter is that at some level you\nalready know there won't be any \"post-update-branch\", I guess that's why you\ndecided to attack me personally instead of dealing with your cognitive\ndissonance and accept that fact.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/233469\n\n-- \nFelipe Contreras\n"}]}