From: Phillip Wood
Add unquote_path() from git-add--interactive so it can be used by
other scripts. Note this is a straight copy, it does not handle
'\a'. That will be fixed in the next commit
Signed-off-by: Phillip Wood
---
perl/G
From: Phillip Wood
I'm using this in some scripts and it would be more convenient to have
it available from Git.pm rather than copying and pasting it each time
I need it. I think it should be useful to other people using Git.pm as
well. It is not uncommon to get a quoted path back from a co
have 1 known breakage(s)
# passed all remaining 95 test(s)
1..96
Also as far as I can see it passes on travis -
https://travis-ci.org/git/git/jobs/245990993#L910 have I missed
something? Do you want me to submit a fixup patch for t3420 or have you
got one already?
Thanks
Phillip
> Thanks.
Oh, that explains it, I was pretty sure the reflog messages were not
translated so couldn't understand why it would fail under
GETTEXT_POISON=YesPlease
> So we can safely merge this topic down.
That's great, thanks for taking the time to track down the reason for
the test failure
Best Wishes
Phillip
On 23/06/17 20:01, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> For 3420, I can wrap the two-liner patch I showed here earlier into
>> a commit on top of the series.
>
> So, here is what I'll queue on top before merging the topic down to
> 'master'.
Thanks for creating this fixup, I'll
From: Phillip Wood
This is what the other routines in Git.pm do if there's an error.
Signed-off-by: Phillip Wood
---
perl/Git.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index
f075b500c510d183074c0358fb24fefc722
From: Phillip Wood
Move unquote_path() from git-add--interactive to Git.pm so it can be
used by other scripts. Note this is a straight copy, it does not
handle '\a'. That will be fixed in the next commit.
Signed-off-by: Phillip Wood
---
git-add--interactive
From: Phillip Wood
The version copied from git-add--interactive did not handle quoted
paths containing '\a'.
Signed-off-by: Phillip Wood
---
perl/Git.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Gi
From: Phillip Wood
Check that unquote_path() handles spaces and escape sequences properly
Signed-off-by: Phillip Wood
---
t/t9700/test.pl | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index
1b75c919651a8126e2a327f3d9645d4377823726
From: Phillip Wood
Thanks for the review Junio, I've amended the patches as you suggested.
The first patch now removes unquote_path() from add -i as well as
adding it to Git.pm. I've fixed the naming issues (the version I sent
previously was copied from another script rather than dir
On 23/06/17 00:18, Jeff King wrote:
> On Thu, Jun 22, 2017 at 11:26:17AM +0100, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> I'm using this in some scripts and it would be more convenient to have
>> it available from Git.pm rather than copying and pasting
From: Phillip Wood
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 a bit more sense - fo
From: Phillip Wood
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 the hook. Using
From: Phillip Wood
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 to run the
'prepare-commit
On 23/01/18 19:12, Junio C Hamano wrote:
Phillip Wood 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 match HEAD
and the commits to be merged, and fast
From: Phillip Wood
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:
These two patches add some test
From: Phillip Wood
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 the hook. Using
From: Phillip Wood
Fix the indentation and style of the hook script in preparation for
further changes.
Signed-off-by: Phillip Wood
---
t/t7505-prepare-commit-msg-hook.sh | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/t/t7505-prepare-commit-msg-hook.sh
b/t
From: Phillip Wood
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 a bit more sense - fo
On 24/01/18 18:59, Junio C Hamano wrote:
Ramsay Jones writes:
On 24/01/18 12:34, Phillip Wood wrote:
From: Phillip Wood
Commit 356ee4659b ("sequencer: try to commit without forking 'git
commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when
cr
t
> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
> index 06a4723d4d..5c513a9736 100644
> --- a/git-rebase--merge.sh
> +++ b/git-rebase--merge.sh
> @@ -137,6 +137,10 @@ skip)
> finish_rb_merge
> return
> ;;
> +show-patch)
> + cmt="$(cat "$state_dir/current")"
> + exec git format-patch --subject-prefix= --stdout "${cmt}^!"
> + ;;
> esac
Here and in the git-rebase--interactive you have access to the SHA of
the failed pick so you could run git log --patch and git colored output
and it would use the pager in the same way as 'git am --show-patch' does
Best Wishes
Phillip
On 26/01/18 11:22, Duy Nguyen wrote:
> On Fri, Jan 26, 2018 at 6:12 PM, Phillip Wood
> wrote:
>>> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
>>> index 06a4723d4d..5c513a9736 100644
>>> --- a/git-rebase--merge.sh
>>> +++ b/git-reba
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
>>> wrote:
>
getting too long, or label re-use, because the directory containing all
>> these helper files will be deleted upon successful rebase in
>> `sequencer_remove_state()`.
>
> Yes.
>
It might be a good idea to have 'git rebase --abort' delete the refs as
well as the file though
Best Wishes
Phillip
uot;$state_dir"
> echo "$onto_name" > "$state_dir/onto_name"
> write_basic_state
> +rm -f "$(git rev-parse --git-path ORIG_COMMIT)"
>
> msgnum=0
> for cmt in $(git rev-list --reverse --no-merges "$revisions")
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 41c915d18c..1db4301b90 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -182,6 +182,7 @@ You can run "git stash pop" or "git stash drop" at any
> time.
> }
>
> finish_rebase () {
> + rm -f "$(git rev-parse --git-path ORIG_COMMIT)"
> apply_autostash &&
> { git gc --auto || true; } &&
> rm -rf "$state_dir"
> diff --git a/sequencer.c b/sequencer.c
> index 4d3f60594c..fe907a0701 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1792,6 +1792,8 @@ static int make_patch(struct commit *commit, struct
> replay_opts *opts)
> p = short_commit_name(commit);
> if (write_message(p, strlen(p), rebase_path_stopped_sha(), 1) < 0)
> return -1;
> + update_ref("rebase", "ORIG_COMMIT", &commit->object.oid,
> +NULL, 0, UPDATE_REFS_DIE_ON_ERR);
The sequencer tries to return errors rather than dying so the caller can
handle them. The other callers of update_ref pass UPDATE_REFS_MSG_ON_ERR
Best Wishes
Phillip
From: Phillip Wood
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.
Signed-off-by: Phillip Woo
From: Phillip Wood
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 active keys
add -p: Only bind s
From: Phillip Wood
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 filter the help. Note that the li
From: Phillip Wood
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.
Signed-off-by: Phillip
From: Phillip Wood
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 those that are skipped or edited
From: Phillip Wood
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 most of the time it is possible for hunks
From: Phillip Wood
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 split then the offset correction will be lost
From: Phillip Wood
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 hunks in the correct place, however in
From: Phillip Wood
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
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --
From: Phillip Wood
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 split then the offset correction will be lost
From: Phillip Wood
Indent here documents in line with the current style for tests.
Signed-off-by: Phillip Wood
---
t/t3701-add-interactive.sh | 174 ++---
1 file changed, 87 insertions(+), 87 deletions(-)
diff --git a/t/t3701-add-interactive.sh b/t
From: Phillip Wood
Purge the index lines from diffs so we're not hard coding sha1 hash
values in the expected output.
Signed-off-by: Phillip Wood
---
t/t3701-add-interactive.sh | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/t/t370
From: Phillip Wood
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
---
Notes:
I can't think of a reason why this shouldn't be OK but I can't help
From: Phillip Wood
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'. There are min
From: Phillip Wood
Simplify things slightly by using the above helpers.
Signed-off-by: Phillip Wood
---
t/t3701-add-interactive.sh | 36 +++-
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
From: Phillip Wood
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 code to count files without a trailin
From: Phillip Wood
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 hunks in the correct place, however in
From: Phillip Wood
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
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --
From: Phillip Wood
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 most of the time it is possible for hunks
From: Phillip Wood
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:
"When I end up editing h
From: Phillip Wood
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 applied). Instead offer an option
for add
From: Phillip Wood
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
---
git-add--interactive.perl
From: Phillip Wood
If the list of lines to be selected begins with '^' select all the
lines except the ones listed.
Signed-off-by: Phillip Wood
---
git-add--interactive.perl | 15 ++-
t/t3701-add-interactive.sh | 2 +-
2 files changed, 15 insertions(+), 2 deletion
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
>>
>> While working on a patch series to stage selected lines from a hunk
>> without having to edit it I got worried that subsequent patches
Is there
> a way at this point in the rebase to "go back" to commit C (so without
> "git rebase --abort")?
>
> (Surely, it's not as simple as doing a "git reset --hard
> sha-of-commit-C" is it?)
Hi Hilco
In the past when I've wanted to edi
void these problems in the future. I'm worried though that
someone out there is scripting with a non-interactive editor which may
break if we start verifying the message so maybe the default should be
changed and a --no-verify option added to cherry-pick and revert
instead. They'd have to change their script but at least it would work
and everyone else would get the behaviour they probably expect.
Best Wishes
Phillip
r) for this to be a faithful
rewrite but it is distracting having to write it anywhere else.
Other than that, this looks like a quite straight-forward cleanup.
Thanks, both. Here is what I'd be queuing tentatively.
That looks good, thanks for fixing it up
Phillip
t/t3701-add-i
On 19/02/18 11:29, Phillip Wood wrote:
From: Phillip Wood
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
On 20/02/18 17:39, Junio C Hamano wrote:
Phillip Wood writes:
From: Phillip Wood
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, but all-zero object name for
missing side of deletion or cre
d in
git-mergetool.sh, so I suppose it's okay to use in git-stash.sh etc,
too.
In recent versions of git there's unquote_path() in Git.pm, you could
possibly use that with perl -e from your script
Best Wishes
Phillip
Best wishes
Peter
ref paths without the leaning ref/.
Under than directory there would be a subtree with the metadata - files
called description, frozen, a directory of notes etc. So for
refs/heads/master you'd have refs/metadata/heads/description containing
the description refs/metadata/heads/master/notes/... containing the
notes I want to share and refs/heads/metadata/master/frozen to indicate
if the branch was frozen.
Best Wishes
Phillip
Will merge to 'next'.
>
Could you hold off on this one please, I do a reroll next week with a
couple of clean-ups for the tests.
Thanks
Phillip
manually.
>
> (This all would of course only work properly without --preserve-merges and
> without the upcoming --recreate-merges.)
It shouldn't be too hard to support --recreate-merges in the case where
you don't go past a merge commit, one would just have to check
refs/rewritten to see if any label commands need to be inserted.
Best Wishes
Phillip
> Ciao,
> Johannes
>
From: Phillip Wood
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
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --
From: Phillip Wood
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 most of the time it is possible for hunks
From: Phillip Wood
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 hunks in the correct place, however in
From: Phillip Wood
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 split then the offset correction will be lost
From: Phillip Wood
Indent here documents in line with the current style for tests.
Signed-off-by: Phillip Wood
---
t/t3701-add-interactive.sh | 174 ++---
1 file changed, 87 insertions(+), 87 deletions(-)
diff --git a/t/t3701-add-interactive.sh b/t
From: Phillip Wood
Simplify things slightly by using the above helpers.
Signed-off-by: Phillip Wood
---
Notes:
changes since v2
- fixed use of test_set_editor to match what was in pu
t/t3701-add-interactive.sh | 33 +
1 file changed, 5 insertions
From: Phillip Wood
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't need to worry about the
From: Phillip Wood
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 stage selected lines from a
From: Phillip Wood
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
---
Notes:
I can't think of a reason why this shouldn't be OK but I can't help
From: Phillip Wood
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 code to count files without a trailin
On 27/02/18 22:35, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> Indent here documents in line with the current style for tests.
>>
>> Signed-off-by: Phillip Wood
>> ---
>
> This loses the hand-edit-while-queuing
On 27/02/18 22:42, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> t/t3701-add-interactive.sh | 30 --
>> 1 file changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
&
On 28/02/18 11:03, Phillip Wood wrote:
> On 27/02/18 22:42, Junio C Hamano wrote:
>> Phillip Wood writes:
>>
>>> t/t3701-add-interactive.sh | 30 --
>>> 1 file changed, 20 insertions(+), 10 deletions(-)
>>>
>>> di
From: Phillip Wood
Simplify things slightly by using the above helpers.
Signed-off-by: Phillip Wood
---
Notes:
changes since v2
- fixed use of test_set_editor to match what was in pu
t/t3701-add-interactive.sh | 33 +
1 file changed, 5 insertions
From: Phillip Wood
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 having to edit it I got worried
From: Phillip Wood
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
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --
From: Phillip Wood
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 split then the offset correction will be lost
From: Phillip Wood
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
---
Notes:
I can't think of a reason why this shouldn't be OK but I can't help
From: Phillip Wood
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 code to count files without a trailin
From: Phillip Wood
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't need to worry about the
From: Phillip Wood
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
Signed-off-by: Junio C Hamano
---
Notes:
changes since v3:
- updated to match what
From: Phillip Wood
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 hunks in the correct place, however in
From: Phillip Wood
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 most of the time it is possible for hunks
Hi Junio
On 28/02/18 15:37, Junio C Hamano wrote:
> Phillip Wood 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 done the
> same way as one would
On 01/03/18 20:14, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> 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 ad
On 01/03/18 20:30, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> Now that add -p counts patches properly it should be possible to turn
>> off the '--recount' option when invoking 'git apply'
>
> Sounds good ;
On 01/03/18 20:29, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> @@ -887,8 +892,8 @@ sub merge_hunk {
>> $o_cnt = $n_cnt = 0;
>> for ($i = 1; $i < @{$prev->{TEXT}}; $i++) {
>> my $line = $prev-&g
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'
| \ |
h M
git merge-recursive A -- M A'
tree=$(git write-tree)
git merge-recursive B -- $tree B'
tree=$(git write-tree)
git merge-recursive C -- $tree C'
tree=$(git write-tree)
M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB' -pC')
This should pull in all the changes from the parents while preserving
any evil conflict resolution in the original merge. It superficially
reminds me of incremental merging [1] but it's so long since I looked at
that I'm not sure if there are any significant similarities.
Best Wishes
Phillip
[1] https://github.com/mhagger/git-imerge
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
>>>>>|\
From: Phillip Wood
Simplify things slightly by using the above helpers.
Signed-off-by: Phillip Wood
---
Notes:
changes since v2
- fixed use of test_set_editor to match what was in pu
t/t3701-add-interactive.sh | 33 +
1 file changed, 5 insertions
From: Phillip Wood
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
Signed-off-by: Junio C Hamano
---
Notes:
changes since v3:
- updated to match what
From: Phillip Wood
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 would
be applied in the w
From: Phillip Wood
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
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --
From: Phillip Wood
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 most of the time it is possible for hunks
From: Phillip Wood
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 hunks in the correct place, however in
From: Phillip Wood
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't need to worry about the
From: Phillip Wood
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 code to count files without a trailin
From: Phillip Wood
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 split then the offset correction will be lost
From: Phillip Wood
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
---
Notes:
I can't think of a reason why this shouldn't be OK but I can't help
ctions, I would think.
>
> So, I certainly do not mind a reroll to move it to a more generic
> place, but I do not think I would terribly mind if we leave it in
> its current place, later to be moved by the first new caller that
> wants to use it from outside this script.
>
I did wonder about putting this function in a library when I first wrote
it but decided to wait and see if it is useful instead. As Junio points
out it would need to be improved to act as a generic filter, so I'll
take the easy option and leave it where it is at the moment.
Best Wishes
Phillip
eeks ago, I'll clean it up and
post it later this week.
I also find it confusing that it asks me to edit the commit message for
picks, fixups and non-final squashes after conflicts. I can see that
perhaps one might want to amend the message to reflect any changes that
were made while resolving the conflicts but I've never had too. I'd
rather be able to pass --edit to rebase --continue if I needed to edit
the message in those cases. Looking through the code I think it would
require saving some extra state when rebase bails out on conflicts so
rebase --continue could tell if it should be asking the user to amend
the message.
Best Wishes
Phillip
701 - 800 of 976 matches
Mail list logo
