Re: prepare-commit-msg hook no longer run for cherry-pick?
Dmitry Torokhov writes: > Right, so it looks like the master works well, it is next(?) branch > that is troublesome (apparently we pack experimental internally?). > > I bisected it down to: > > commit 356ee4659bb551cd9464b317d691827276752c2d (refs/bisect/bad) > Author: Phillip Wood > Date: Fri Nov 24 11:07:57 2017 + > >sequencer: try to commit without forking 'git commit' > ... > > With this commit the hook is not being run unless I specify '-e' flag > to cherry-pick. Thanks.
Re: prepare-commit-msg hook no longer run for cherry-pick?
On Tue, Jan 9, 2018 at 6:24 PM, Junio C Hamano wrote: > > Dmitry Torokhov writes: > > >> I had prepare-commit-msg hook that would scrub "Patchwork-ID: " tags > >> form commit messages and would update input mailing list patchwork to > >> mark corresponding patches as "accepted" when I cherry pick form > >> WIP/review queue into branches that I publish, but that recently stopped > >> working if I do a simple cherry-pick. > > > > This seems like a regression, at least for my use case. Unfortunately > > my mail seems to get lost in the mailing list noise... > > Possibly. Can you bisect to see which commit broke things for you? > That would allow people who know what they themselves broke better > than I do to take a look ;-) Right, so it looks like the master works well, it is next(?) branch that is troublesome (apparently we pack experimental internally?). I bisected it down to: commit 356ee4659bb551cd9464b317d691827276752c2d (refs/bisect/bad) Author: Phillip Wood Date: Fri Nov 24 11:07:57 2017 + sequencer: try to commit without forking 'git commit' If the commit message does not need to be edited then create the commit without forking 'git commit'. Taking the best time of ten runs with a warm cache this reduces the time taken to cherry-pick 10 commits by 27% (from 282ms to 204ms), and the time taken by 'git rebase --continue' to pick 10 commits by 45% (from 386ms to 212ms) on my computer running linux. Some of greater saving for rebase is because it no longer wastes time creating the commit summary just to throw it away. The code to create the commit is based on builtin/commit.c. It is simplified as it doesn't have to deal with merges and modified so that it does not die but returns an error to make sure the sequencer exits cleanly, as it would when forking 'git commit' Even when not forking 'git commit' the commit message is written to a file and CHERRY_PICK_HEAD is created unnecessarily. This could be eliminated in future. I hacked up a version that does not write these files and just passed an strbuf (with the wrong message for fixup and squash commands) to do_commit() but I couldn't measure any significant time difference when running cherry-pick or rebase. I think eliminating the writes properly for rebase would require a bit of effort as the code would need to be restructured. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano With this commit the hook is not being run unless I specify '-e' flag to cherry-pick. Thanks. -- Dmitry
Re: prepare-commit-msg hook no longer run for cherry-pick?
Dmitry Torokhov writes: >> I had prepare-commit-msg hook that would scrub "Patchwork-ID: " tags >> form commit messages and would update input mailing list patchwork to >> mark corresponding patches as "accepted" when I cherry pick form >> WIP/review queue into branches that I publish, but that recently stopped >> working if I do a simple cherry-pick. > > This seems like a regression, at least for my use case. Unfortunately > my mail seems to get lost in the mailing list noise... Possibly. Can you bisect to see which commit broke things for you? That would allow people who know what they themselves broke better than I do to take a look ;-) Thanks.
Re: prepare-commit-msg hook no longer run for cherry-pick?
Hi Junio, On Fri, Jan 5, 2018 at 10:48 AM, Dmitry Torokhov wrote: > Hi, > > I had prepare-commit-msg hook that would scrub "Patchwork-ID: " tags > form commit messages and would update input mailing list patchwork to > mark corresponding patches as "accepted" when I cherry pick form > WIP/review queue into branches that I publish, but that recently stopped > working if I do a simple cherry-pick. This seems like a regression, at least for my use case. Unfortunately my mail seems to get lost in the mailing list noise... Please let me know if this is indeed broken or I need to adjust my workflow. Thanks! > If I specify that I want to edit > the message, then the hook is executed: > > dtor@dtor-ws:~/kernel/master (for-linus)$ GIT_TRACE=2 git cherry-pick > ff162c1554efe951ba6c7a19a228fc76a91fe1ed > 10:43:12.832426 git.c:344 trace: built-in: git 'cherry-pick' > 'ff162c1554efe951ba6c7a19a228fc76a91fe1ed' > [for-linus 48bc600a3659] Input: raydium_i2c_ts - include hardware version in > firmware name > Author: Jeffrey Lin > Date: Thu Jan 4 21:35:23 2018 -0800 > 1 file changed, 12 insertions(+), 2 deletions(-) > dtor@dtor-ws:~/kernel/master (for-linus)$ gti reset --hard HEAD^ > HEAD is now at 02a0d9216d4d Input: xen-kbdfront - do not advertise > multi-touch pressure support > dtor@dtor-ws:~/kernel/master (for-linus)$ GIT_TRACE=2 git cherry-pick -e > ff162c1554efe951ba6c7a19a228fc76a91fe1ed > 10:43:24.433162 git.c:344 trace: built-in: git 'cherry-pick' > '-e' 'ff162c1554efe951ba6c7a19a228fc76a91fe1ed' > 10:43:24.782355 run-command.c:627 trace: run_command: 'commit' '-n' '-e' > 10:43:24.786460 git.c:344 trace: built-in: git 'commit' '-n' > '-e' > 10:43:25.082164 run-command.c:627 trace: run_command: > '.git/hooks/prepare-commit-msg' '.git/COMMIT_EDITMSG' 'merge' > hint: Waiting for your editor to close the file... > 10:43:31.491551 run-command.c:627 trace: run_command: 'vim' > '/usr/local/goo gle/home/dtor/kernel/master/.git/COMMIT_EDITMSG' > [for-linus 039c57df0ec8] Input: raydium_i2c_ts - include hardware version in > firmware name > Author: Jeffrey Lin > Date: Thu Jan 4 21:35:23 2018 -0800 > 1 file changed, 12 insertions(+), 2 deletions(-) > dtor@dtor-ws:~/kernel/master (for-linus)$ > > Also note that the argument to the hook is "merge" whereas I think it > used to be "cherry-pick" earlier. > > Is this behavior intentional? dpkg reports version as 2.16.0~rc0+next. > > Thanks! > > -- > Dmitry -- Dmitry
prepare-commit-msg hook no longer run for cherry-pick?
Hi, I had prepare-commit-msg hook that would scrub "Patchwork-ID: " tags form commit messages and would update input mailing list patchwork to mark corresponding patches as "accepted" when I cherry pick form WIP/review queue into branches that I publish, but that recently stopped working if I do a simple cherry-pick. If I specify that I want to edit the message, then the hook is executed: dtor@dtor-ws:~/kernel/master (for-linus)$ GIT_TRACE=2 git cherry-pick ff162c1554efe951ba6c7a19a228fc76a91fe1ed 10:43:12.832426 git.c:344 trace: built-in: git 'cherry-pick' 'ff162c1554efe951ba6c7a19a228fc76a91fe1ed' [for-linus 48bc600a3659] Input: raydium_i2c_ts - include hardware version in firmware name Author: Jeffrey Lin Date: Thu Jan 4 21:35:23 2018 -0800 1 file changed, 12 insertions(+), 2 deletions(-) dtor@dtor-ws:~/kernel/master (for-linus)$ gti reset --hard HEAD^ HEAD is now at 02a0d9216d4d Input: xen-kbdfront - do not advertise multi-touch pressure support dtor@dtor-ws:~/kernel/master (for-linus)$ GIT_TRACE=2 git cherry-pick -e ff162c1554efe951ba6c7a19a228fc76a91fe1ed 10:43:24.433162 git.c:344 trace: built-in: git 'cherry-pick' '-e' 'ff162c1554efe951ba6c7a19a228fc76a91fe1ed' 10:43:24.782355 run-command.c:627 trace: run_command: 'commit' '-n' '-e' 10:43:24.786460 git.c:344 trace: built-in: git 'commit' '-n' '-e' 10:43:25.082164 run-command.c:627 trace: run_command: '.git/hooks/prepare-commit-msg' '.git/COMMIT_EDITMSG' 'merge' hint: Waiting for your editor to close the file... 10:43:31.491551 run-command.c:627 trace: run_command: 'vim' '/usr/local/goo gle/home/dtor/kernel/master/.git/COMMIT_EDITMSG' [for-linus 039c57df0ec8] Input: raydium_i2c_ts - include hardware version in firmware name Author: Jeffrey Lin Date: Thu Jan 4 21:35:23 2018 -0800 1 file changed, 12 insertions(+), 2 deletions(-) dtor@dtor-ws:~/kernel/master (for-linus)$ Also note that the argument to the hook is "merge" whereas I think it used to be "cherry-pick" earlier. Is this behavior intentional? dpkg reports version as 2.16.0~rc0+next. Thanks! -- Dmitry
