[PATCH v5 0/9] Correct offsets of hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> I've updated these to clean up the perl style in response to Junio's comments on v4. Cover letter to v1: While working on a patch series to stage selected lines from a hunk without having to edit it I got worried that subsequent patches

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

On 02/03/18 11:17, Phillip Wood wrote: > > On 02/03/18 01:16, Igor Djordjevic wrote: >> >> Hi Sergey, >> >> On 01/03/2018 06:39, Sergey Organov wrote: >>> >>>>> (3) ---X1---o---o---o---o---o---X2 >>>>>|\

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On 01/03/18 05:39, Sergey Organov wrote: > > Hi Igor, > > Igor Djordjevic writes: > >> Hi Sergey, >> >> On 28/02/2018 06:19, Sergey Organov wrote: >>> > (3) ---X1---o---o---o---o---o---X2 >|\ |\ >| A1---A2---A3---U1

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

On 02/03/18 01:16, Igor Djordjevic wrote: > > Hi Sergey, > > On 01/03/2018 06:39, Sergey Organov wrote: >> (3) ---X1---o---o---o---o---o---X2 |\ |\ | A1---A2---A3---U1 | A1'--A2'--A3'--U1' | \ |

Re: [PATCH v4 8/9] add -p: fix counting when splitting and coalescing

On 01/03/18 20:29, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> @@ -887,8 +892,8 @@ sub merge_hunk { >> $o_cnt = $n_cnt = 0; >> for ($i = 1; $i < @{$prev->{TEXT}}; $i++) { >> my $line = $p

Re: [PATCH v4 9/9] add -p: don't rely on apply's '--recount' option

On 01/03/18 20:30, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> Now that add -p counts patches properly it should be possible to turn >> off the '--recount' option

Re: [PATCH v4 7/9] add -p: calculate offset delta for edited patches

On 01/03/18 20:14, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> Recount the number of preimage and postimage lines in a hunk after it >> has been edited so any chang

Re: [PATCH v3 2/9] t3701: indent here documents

Hi Junio On 28/02/18 15:37, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> Is there an easy way for contributors to compare the branch they post to >> what ends up it pu? > > Distributed work is pretty much symmetric, so it can be do

[PATCH v4 6/9] add -p: adjust offsets of subsequent hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> Since commit 8cbd431082 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works

[PATCH v4 5/9] t3701: add failing test for pathological context lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the context lines to apply the subsequent

[PATCH v4 2/9] t3701: indent here documents

From: Phillip Wood <phillip.w...@dunelm.org.uk> Indent here documents in line with the current style for tests. While at it, quote the end marker of here-docs that do not use variable interpolation. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> Signed-off-by: Junio C

[PATCH v4 8/9] add -p: fix counting when splitting and coalescing

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a file has no trailing new line at the end diff records this by appending "\ No newline at end of file" below the last line of the file. This line should not be counted in the hunk header. Fix the splitting and coalescing cod

[PATCH v4 4/9] t3701: don't hard code sha1 hash values

From: Phillip Wood <phillip.w...@dunelm.org.uk> Use a filter when comparing diffs to fix the value of non-zero hashes in diff index lines so we're not hard coding sha1 hash values in the expected output. This makes it easier to change the expected output if a test is edited as we don'

[PATCH v4 0/9] Correct offsets of hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> I've fixed the second patch to match what was in pu and added some extra code to patch 4 to handle zero sha1 hashes where the length varies. Cover letter to v1: While working on a patch series to stage selected lines from a hunk without

[PATCH v4 1/9] add -i: add function to format hunk header

From: Phillip Wood <phillip.w...@dunelm.org.uk> This code is duplicated in a couple of places so make it into a function as we're going to add some more callers shortly. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-add--interactive.perl | 21 +++--

[PATCH v4 7/9] add -p: calculate offset delta for edited patches

From: Phillip Wood <phillip.w...@dunelm.org.uk> Recount the number of preimage and postimage lines in a hunk after it has been edited so any change in the number of insertions or deletions can be used to adjust the offsets of subsequent hunks. If an edited hunk is subsequently

[PATCH v4 9/9] add -p: don't rely on apply's '--recount' option

From: Phillip Wood <phillip.w...@dunelm.org.uk> Now that add -p counts patches properly it should be possible to turn off the '--recount' option when invoking 'git apply' Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: I can't think of a reason why this sho

[PATCH v4 3/9] t3701: use test_write_lines and write_script

From: Phillip Wood <phillip.w...@dunelm.org.uk> Simplify things slightly by using the above helpers. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: changes since v2 - fixed use of test_set_editor to match what was in pu t/t3701-add-interac

Re: [PATCH v3 4/9] t3701: don't hard code sha1 hash values

On 28/02/18 11:03, Phillip Wood wrote: > On 27/02/18 22:42, Junio C Hamano wrote: >> Phillip Wood <phillip.w...@talktalk.net> writes: >> >>> t/t3701-add-interactive.sh | 30 -- >>> 1 file changed, 20 insertions(+), 10 deleti

Re: [PATCH v3 4/9] t3701: don't hard code sha1 hash values

On 27/02/18 22:42, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> t/t3701-add-interactive.sh | 30 -- >> 1 file changed, 20 insertions(+), 10 deletions(-) >> >> diff --git a/t/t3701-add-interac

Re: [PATCH v3 2/9] t3701: indent here documents

On 27/02/18 22:35, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> Indent here documents in line with the current style for tests. >> >> Signed-

[PATCH v3 8/9] add -p: fix counting when splitting and coalescing

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a file has no trailing new line at the end diff records this by appending "\ No newline at end of file" below the last line of the file. This line should not be counted in the hunk header. Fix the splitting and coalescing cod

[PATCH v3 3/9] t3701: use test_write_lines and write_script

From: Phillip Wood <phillip.w...@dunelm.org.uk> Simplify things slightly by using the above helpers. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: changes since v2 - fixed use of test_set_editor to match what was in pu t/t3701-add-interac

[PATCH v3 4/9] t3701: don't hard code sha1 hash values

From: Phillip Wood <phillip.w...@dunelm.org.uk> Use a filter when comparing diffs to fix the value of non-zero hashes in diff index lines so we're not hard coding sha1 hash values in the expected output. This makes it easier to change the expected output if a test is edited as we don'

[PATCH v3 2/9] t3701: indent here documents

From: Phillip Wood <phillip.w...@dunelm.org.uk> Indent here documents in line with the current style for tests. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t3701-add-interactive.sh | 174 ++--- 1 file changed, 87 inser

[PATCH v3 0/9] Correct offsets of hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> I've fixed the use of test_set_editor most of which was already in pu and reworked the sha1 comparisons to rewrite the hashes in the index lines rather than deleting the index lines. Cover letter to v1: While working on a patch series to

[PATCH v3 9/9] add -p: don't rely on apply's '--recount' option

From: Phillip Wood <phillip.w...@dunelm.org.uk> Now that add -p counts patches properly it should be possible to turn off the '--recount' option when invoking 'git apply' Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: I can't think of a reason why this sho

[PATCH v3 5/9] t3701: add failing test for pathological context lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the context lines to apply the subsequent

[PATCH v3 7/9] add -p: calculate offset delta for edited patches

From: Phillip Wood <phillip.w...@dunelm.org.uk> Recount the number of preimage and postimage lines in a hunk after it has been edited so any change in the number of insertions or deletions can be used to adjust the offsets of subsequent hunks. If an edited hunk is subsequently

[PATCH v3 6/9] add -p: Adjust offsets of subsequent hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> Since commit 8cbd431082 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works

[PATCH v3 1/9] add -i: add function to format hunk header

From: Phillip Wood <phillip.w...@dunelm.org.uk> This code is duplicated in a couple of places so make it into a function as we're going to add some more callers shortly. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-add--interactive.perl | 21 +++--

Re: Is there any way to "interrupt" a rebase?

On 20/02/18 11:44, Johannes Schindelin wrote: > > Hi Hilco, > > On Tue, 20 Feb 2018, Johannes Schindelin wrote: > >> When I am particularly tired and overworked (and therefore know that my >> working memory is less useful than usual), I therefore resort to my >> second-favorite strategy: U use

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

On 22/02/18 00:31, Junio C Hamano wrote: > * pw/add-p-recount (2018-02-20) 9 commits > - add -p: don't rely on apply's '--recount' option > - add -p: fix counting when splitting and coalescing > - add -p: calculate offset delta for edited patches > - add -p: adjust offsets of subsequent hunks

Re: Git "branch properties"-- thoughts?

On 22/02/18 18:29, Paul Smith wrote: > > Hi all. I'm wondering if anyone has any thoughts about the best, or > even any, way to have "branch properties": some extra information which > is attached to a branch (that is, the actual branch name not the commit > it currently points to). > > My

Re: Git should preserve modification times at least on request

On 20/02/18 22:48, Peter Backes wrote: On Tue, Feb 20, 2018 at 11:32:23PM +0100, Johannes Schindelin wrote: Hi Peter, On Tue, 20 Feb 2018, Peter Backes wrote: On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote: I would probably invent a file format (``) I'm stuck there

Re: [PATCH v2 4/9] t3701: don't hard code sha1 hash values

On 20/02/18 17:39, Junio C Hamano wrote: Phillip Wood <phillip.w...@talktalk.net> writes: From: Phillip Wood <phillip.w...@dunelm.org.uk> Purge the index lines from diffs so we're not hard coding sha1 hash values in the expected output. The motivation of this patch is clear,

Re: [PATCH v2 5/9] t3701: add failing test for pathological context lines

On 19/02/18 11:29, Phillip Wood wrote: From: Phillip Wood <phillip.w...@dunelm.org.uk> When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the c

Re: [PATCH v2 3/9] t3701: use test_write_lines and write_script

On 20/02/18 17:19, Junio C Hamano wrote: Eric Sunshine writes: test_expect_success 'setup fake editor' ' - echo "#!$SHELL_PATH" >fake_editor.sh && - cat >>fake_editor.sh <<-\EOF && + FAKE_EDITOR="$(pwd)/fake-editor.sh" && + write_script

Re: Why git-revert doesn't invoke the pre-commit and the commit-msg hooks?

Hi Gustavo On 19/02/18 14:50, Gustavo Chaves wrote: > > I asked this question on StackOverflow and got an answer: > https://stackoverflow.com/q/48852925/114983 > > The problem is that git-revert invokes git-commit with the -n flag, > explicitly avoiding the pre-commit and the commit-msg hooks.

Re: Is there any way to "interrupt" a rebase?

On 19/02/18 19:35, Hilco Wijbenga wrote: > > Hi all, > > When maintaining a long running branch, I regularly rebase onto our > active development branch so that my branch stays up-to-date. What > happens fairly often is that during such a rebase, Git will exit > because of rebase/merge

Re: [PATCH 0/4] Correct offsets of hunks when one is skipped

On 13/02/18 23:56, brian m. carlson wrote: > On Tue, Feb 13, 2018 at 10:44:04AM +0000, Phillip Wood wrote: >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> While working on a patch series to stage selected lines from a hunk >> without having to edit it I go

[PATCH v1 2/3] add -p: allow line selection to be inverted

From: Phillip Wood <phillip.w...@dunelm.org.uk> If the list of lines to be selected begins with '^' select all the lines except the ones listed. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-add--interactive.perl | 15 ++- t/t3701-add-interactive.s

[PATCH v1 3/3] add -p: optimize line selection for short hunks

From: Phillip Wood <phillip.w...@dunelm.org.uk> If there are fewer than ten changes in a hunk then make spaces optional when selecting individual lines. This means that for short hunks one can just type -357 to stage lines 1, 2, 3, 5 & 7. Signed-off-by: Phillip Wood <phillip.w...@

[PATCH v1 1/3] add -p: select individual hunk lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> When I end up editing hunks it is almost always because I want to stage a subset of the lines in the hunk. Doing this by editing the hunk is inconvenient and error prone (especially so if the patch is going to be reversed before being a

[PATCH v1 0/3] add -p: select individual hunk lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> I need to update the add -i documentation but otherwise I think these patches are OK so I thought I'd try and get some feedback. They build on top of the recount fixes in [1]. The commit message for the first patch describes the motivation: &

[PATCH v2 8/9] add -p: fix counting when splitting and coalescing

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a file has no trailing new line at the end diff records this by appending "\ No newline at end of file" below the last line of the file. This line should not be counted in the hunk header. Fix the splitting and coalescing cod

[PATCH v2 5/9] t3701: add failing test for pathological context lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the context lines to apply the subsequent

[PATCH v2 1/9] add -i: add function to format hunk header

From: Phillip Wood <phillip.w...@dunelm.org.uk> This code is duplicated in a couple of places so make it into a function as we're going to add some more callers shortly. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-add--interactive.perl | 21 +++--

[PATCH v2 6/9] add -p: Adjust offsets of subsequent hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> Since commit 8cbd431082 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works

[PATCH v2 4/9] t3701: don't hard code sha1 hash values

From: Phillip Wood <phillip.w...@dunelm.org.uk> Purge the index lines from diffs so we're not hard coding sha1 hash values in the expected output. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t3701-add-interactive.sh | 32 1 file

[PATCH v2 9/9] add -p: don't rely on apply's '--recount' option

From: Phillip Wood <phillip.w...@dunelm.org.uk> Now that add -p counts patches properly it should be possible to turn off the '--recount' option when invoking 'git apply' Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: I can't think of a reason why this sho

[PATCH v2 0/9] Correct offsets of hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> Since v1 I've added some test cleanups for t3701, fixed the counting when splitting and coalescing hunks containing "\ No newline at end of file" lines and added a patch to remove '--recount' from the invocation of 'git apply'.

[PATCH v2 3/9] t3701: use test_write_lines and write_script

From: Phillip Wood <phillip.w...@dunelm.org.uk> Simplify things slightly by using the above helpers. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t3701-add-interactive.sh | 36 +++- 1 file changed, 7 insertions(+), 29 deletions(-)

[PATCH v2 2/9] t3701: indent here documents

From: Phillip Wood <phillip.w...@dunelm.org.uk> Indent here documents in line with the current style for tests. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t3701-add-interactive.sh | 174 ++--- 1 file changed, 87 inser

[PATCH v2 7/9] add -p: calculate offset delta for edited patches

From: Phillip Wood <phillip.w...@dunelm.org.uk> Recount the number of preimage and postimage lines in a hunk after it has been edited so any change in the number of insertions or deletions can be used to adjust the offsets of subsequent hunks. If an edited hunk is subsequently

[PATCH 4/4] add -p: calculate offset delta for edited patches

From: Phillip Wood <phillip.w...@dunelm.org.uk> Recount the number of preimage and postimage lines in a hunk after it has been edited so any change in the number of insertions or deletions can be used to adjust the offsets of subsequent hunks. If an edited hunk is subsequently

[PATCH 2/4] t3701: add failing test for pathological context lines

From: Phillip Wood <phillip.w...@dunelm.org.uk> When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the context lines to apply the subsequent

[PATCH 1/4] add -i: add function to format hunk header

From: Phillip Wood <phillip.w...@dunelm.org.uk> This code is duplicated in a couple of places so make it into a function as we're going to add some more callers shortly. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-add--interactive.perl | 21 +++--

[PATCH 0/4] Correct offsets of hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> While working on a patch series to stage selected lines from a hunk without having to edit it I got worried that subsequent patches would be applied in the wrong place which lead to this series to correct the offsets of hunks following

[PATCH 3/4] add -p: Adjust offsets of subsequent hunks when one is skipped

From: Phillip Wood <phillip.w...@dunelm.org.uk> Since commit 8cbd431082 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works

[PATCH 0/3] add -p: improve help messages

From: Phillip Wood <phillip.w...@dunelm.org.uk> Improve the help displayed if the user presses an inactive key by only listing active keys and printing specific messages for some keys. Also disable search if there's only a single hunk. Phillip Wood (3): add -p: only display help for

[PATCH 2/3] add -p: Only bind search key if there's more than one hunk

From: Phillip Wood <phillip.w...@dunelm.org.uk> If there is only a single hunk then disable searching as there is nothing to search for. Also print a specific error message if the user tries to search with '/' when there's only a single hunk rather than just listing the key bindings. Sign

[PATCH 1/3] add -p: only display help for active keys

From: Phillip Wood <phillip.w...@dunelm.org.uk> If the user presses a key that add -p wasn't expecting then it prints a list of key bindings. Although the prompt only lists the active bindings the help was printed for all bindings. Fix this by using the list of keys in the prompt to

[PATCH 3/3] add -p: improve error messages

From: Phillip Wood <phillip.w...@dunelm.org.uk> If the user presses a key that isn't currently active then explain why it isn't active rather than just listing all the keys. It already did this for some keys, this patch does the same for the those that weren't already handled. Sign

Re: [PATCH v2 3/3] rebase: introduce and use pseudo-ref ORIG_COMMIT

On 31/01/18 09:30, Nguyễn Thái Ngọc Duy wrote: > > The new command `git rebase --show-current-patch` is useful for seeing > the commit related to the current rebase state. Some however may find > the "git show" command behind it too limiting. You may want to > increase context lines, do a diff

Re: [PATCH v2 02/10] sequencer: introduce new commands to reset therevision

On 31/01/18 13:21, Johannes Schindelin wrote: > > Hi Stefan, > > On Tue, 30 Jan 2018, Stefan Beller wrote: > >> On Mon, Jan 29, 2018 at 2:54 PM, Johannes Schindelin >> wrote: >>> @@ -116,6 +118,13 @@ static GIT_PATH_FUNC(rebase_path_stopped_sha, >>>

Re: [PATCH 2/8] sequencer: introduce the `merge` command

On 31/01/18 13:48, Johannes Schindelin wrote: > Hi Jake & Phillip, > > On Mon, 29 Jan 2018, Johannes Schindelin wrote: > >> On Sat, 20 Jan 2018, Jacob Keller wrote: >> >>> On Fri, Jan 19, 2018 at 6:45 AM, Phillip Wood <phillip.w...@talktalk.net>

Re: [PATCH 2/2] rebase: add --show-patch

On 26/01/18 11:22, Duy Nguyen wrote: > On Fri, Jan 26, 2018 at 6:12 PM, Phillip Wood <phillip.w...@talktalk.net> > wrote: >>> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh >>> index 06a4723d4d..5c513a9736 100644 >>> --- a/git-rebase--

Re: [PATCH 2/2] rebase: add --show-patch

On 26/01/18 09:55, Nguyễn Thái Ngọc Duy wrote: > > It is useful to see the full patch while resolving conflicts in a > rebase. The only way to do it now is > > less .git/rebase-*/patch > > which could turn out to be a lot longer to type [1] if you are in a > linked worktree, or not at

Re: [PATCH v3 3/3] sequencer: run 'prepare-commit-msg' hook

On 24/01/18 18:59, Junio C Hamano wrote: Ramsay Jones <ram...@ramsayjones.plus.com> writes: On 24/01/18 12:34, Phillip Wood wrote: From: Phillip Wood <phillip.w...@dunelm.org.uk> Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 201

[PATCH v3 2/3] t7505: Add tests for cherry-pick and rebase -i/-p

From: Phillip Wood <phillip.w...@dunelm.org.uk> Check that cherry-pick and rebase call the 'prepare-commit-msg' hook correctly. The expected values for the hook arguments are taken to match the current master branch. I think there is scope for improving the arguments passed so they make

[PATCH v3 1/3] t7505: style fixes

From: Phillip Wood <phillip.w...@dunelm.org.uk> Fix the indentation and style of the hook script in preparation for further changes. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t7505-prepare-commit-msg-hook.sh | 14 -- 1 file changed, 8 insertions(+),

[PATCH v3 3/3] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood <phillip.w...@dunelm.org.uk> Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when creating the commit. Fix this by writing the commit message to a different file and running

[PATCH v3 0/3] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood <phillip.w...@dunelm.org.uk> The new test and the test hook scripts has been updated with some style fixes spotted by Junio. I've added an extra commit at the beginning to update the style of the original hook, so my later changes are clearer. Original cover letter: The

Re: [PATCH 3/8] sequencer: fast-forward merge commits, if possible

On 23/01/18 19:12, Junio C Hamano wrote: Phillip Wood <phillip.w...@talktalk.net> writes: On 18/01/18 15:35, Johannes Schindelin wrote: Just like with regular `pick` commands, if we are trying to recreate a merge commit, we now test whether the parents of said commit matc

[PATCH v2 2/2] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood <phillip.w...@dunelm.org.uk> Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when creating the commit. Fix this by writing the commit message to a different file and running

[PATCH v2 0/2] sequencer: run 'prepare-commit-msg' hook​

From: Phillip Wood <phillip.w...@dunelm.org.uk> I've updated the patches in response to comments, there are just a couple of small changes. Thanks to Ramsay and Eric for their reviews. Best Wishes Phillip Original cover letter: These two patches add some tests and fix the sequencer

[PATCH v2 1/2] t7505: Add tests for cherry-pick and rebase -i/-p

From: Phillip Wood <phillip.w...@dunelm.org.uk> Check that cherry-pick and rebase call the 'prepare-commit-msg' hook correctly. The expected values for the hook arguments are taken to match the current master branch. I think there is scope for improving the arguments passed so they make

Re: [PATCH 1/8] sequencer: introduce new commands to resettherevision

On 19/01/18 12:24, Phillip Wood wrote: > > On 18/01/18 15:35, Johannes Schindelin wrote: >> >> Internally, the `label ` command creates the ref >> `refs/rewritten/`. This makes it possible to work with the labeled >> revisions interactively, or in a scripted fash

Re: [PATCH 3/8] sequencer: fast-forward merge commits, if possible

On 18/01/18 15:35, Johannes Schindelin wrote: > > Just like with regular `pick` commands, if we are trying to recreate a > merge commit, we now test whether the parents of said commit match HEAD > and the commits to be merged, and fast-forward if possible. > > This is not only faster, but also

Re: [PATCH 2/8] sequencer: introduce the `merge` command

On 18/01/18 15:35, Johannes Schindelin wrote: > > This patch is part of the effort to reimplement `--preserve-merges` with > a substantially improved design, a design that has been developed in the > Git for Windows project to maintain the dozens of Windows-specific patch > series on top of

[PATCH 0/2] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood <phillip.w...@dunelm.org.uk> These two patches add some tests and fix the sequencer to run the 'prepare-commit-msg' hook when committing without forking 'git commit' Phillip Wood (2): t7505: Add tests for cherry-pick and rebase -i/-p sequencer: run 'prepare-comm

[PATCH 1/2] t7505: Add tests for cherry-pick and rebase -i/-p

From: Phillip Wood <phillip.w...@dunelm.org.uk> Check that cherry-pick and rebase call the 'prepare-commit-msg' hook correctly. The expected values for the hook arguments are taken to match the current master branch. I think there is scope for improving the arguments passed so they make

[PATCH 2/2] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood <phillip.w...@dunelm.org.uk> Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when creating the commit. Fix this by writing the commit message to a different file and running

Re: [PATCH 1/8] sequencer: introduce new commands to resettherevision

On 18/01/18 15:35, Johannes Schindelin wrote: > > In the upcoming commits, we will teach the sequencer to recreate merges. > This will be done in a very different way from the unfortunate design of > `git rebase --preserve-merges` (which does not allow for reordering > commits, or changing the

Re: [PATCH v5 8/9] sequencer: try to commit without forking 'git commit'

On 10/01/18 22:40, Johannes Schindelin wrote: > Hi, > > On Wed, 10 Jan 2018, Jonathan Nieder wrote: > >> Phillip Wood wrote: >> >>> From: Phillip Wood <phillip.w...@dunelm.org.uk> >>> >>> If the commit message does not need to be edit

[PATCH] sequencer: improve config handling

From: Phillip Wood <phillip.w...@dunelm.org.uk> The previous config handling relied on global variables, called git_default_config() even when the key had already been handled by git_sequencer_config() and did not initialize the diff configuration variables. Improve this by: i) l

Re: [PATCH v5 0/9] sequencer: don't fork git commit

On 11/12/17 23:44, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> I've reworked the config handling since v4. It now stores the default >> values in struct rep

Re: [PATCH v5 7/9] sequencer: load commit related config

On 11/12/17 14:13, Phillip Wood wrote: > From: Phillip Wood <phillip.w...@dunelm.org.uk> > > Load default values for message cleanup, gpg signing of commits and > basic diff configuration in preparation for committing without forking > 'git commit'. Note that we interpret co

[PATCH v5 7/9] sequencer: load commit related config

From: Phillip Wood <phillip.w...@dunelm.org.uk> Load default values for message cleanup, gpg signing of commits and basic diff configuration in preparation for committing without forking 'git commit'. Note that we interpret commit.cleanup=scissors to mean COMMIT_MSG_CLEANUP_SPACE to be cons

[PATCH v5 8/9] sequencer: try to commit without forking 'git commit'

From: Phillip Wood <phillip.w...@dunelm.org.uk> 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 th

[PATCH v5 9/9] t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1

From: Phillip Wood <phillip.w...@dunelm.org.uk> Now that the sequencer creates commits without forking 'git commit' it does not see an empty commit in these tests which fixes the known breakage. Note that logic for handling KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 is not removed fr

[PATCH v5 6/9] sequencer: simplify adding Signed-off-by: trailer

From: Phillip Wood <phillip.w...@dunelm.org.uk> Add the Signed-off-by: trailer in one place rather than adding it to the message when doing a recursive merge and specifying '--signoff' when running 'git commit'. This means that if there are conflicts when merging with a strategy othe

[PATCH v5 5/9] commit: move print_commit_summary() to libgit

From: Phillip Wood <phillip.w...@dunelm.org.uk> Move print_commit_summary() from builtin/commit.c to sequencer.c so it can be shared with other commands. The function is modified by changing the last argument to a flag so callers can specify whether they want to show the author date in ad

[PATCH v5 4/9] commit: move post-rewrite code to libgit

From: Phillip Wood <phillip.w...@dunelm.org.uk> Move run_rewrite_hook() from bulitin/commit.c to sequencer.c so it can be shared with other commands and add a new function commit_post_rewrite() based on the code in builtin/commit.c that encapsulates rewriting notes and running the post-r

[PATCH v5 2/9] commit: move empty message checks to libgit

From: Phillip Wood <phillip.w...@dunelm.org.uk> Move the functions that check for empty messages from bulitin/commit.c to sequencer.c so they can be shared with other commands. The functions are refactored to take an explicit cleanup mode and template filename passed by the caller. Sign

[PATCH v5 3/9] Add a function to update HEAD after creating a commit

From: Phillip Wood <phillip.w...@dunelm.org.uk> Add update_head_with_reflog() based on the code that updates HEAD after committing in builtin/commit.c that can be called by 'git commit' and other commands. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- Notes: chan

[PATCH v5 1/9] t3404: check intermediate squash messages

From: Phillip Wood <phillip.w...@dunelm.org.uk> When there is more than one squash/fixup command in a row check the intermediate messages are correct. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- t/t3404-rebase-interactive.sh | 4 1 file changed, 4 insertions(+)

[PATCH v5 0/9] sequencer: don't fork git commit

From: Phillip Wood <phillip.w...@dunelm.org.uk> I've reworked the config handling since v4. It now stores the default values in struct replay_opt rather than using global variables and calls git_diff_basic_config(). Unfortunately I've not had time to modify git_gpg_config() to in

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)

On 10/12/17 01:20, Igor Djordjevic wrote: > > Hi Philip, > > On 09/12/2017 20:01, Phillip Wood wrote: >> >>> But thanks for clarifying, anyway, it does feel like `git rebase >>> -i --autosquash` could be smarter in this regards, if `git rebase >>&

<    1   2   3   4   5   6   >