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
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 conflicts.
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.
>
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 "$FAKE_EDITOR" <<-\EOF &&
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
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 b
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 requi
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 w
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 t
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'
| \ |
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 | A1'--A2'--A3'--U1'
>>>
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
On 02/03/18 16:09, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> +diff_cmp () {
>>> + for x
>>> + do
>>> + sed -e '/^index/s/[0-9a-f]*[1-9a-f][0-9a-f]*\.\./1234567../' \
>>> +-e '/^index/s/\.\.[0-9a-f]*[1-9a-f][0-9a-f]*/..9abcdef/' \
>>> +-e '/^
On 16/07/17 12:39, Philip Oakley wrote:
>
> From: "Junio C Hamano"
> Sent: Wednesday, July 12, 2017 10:29 PM
>> William Duclot writes:
>>
- The original said "When you have resolved this problem", without
giving a guidance how to resolve, and without saying what the
problem
From: Phillip Wood
After resolving conflicts during a rebase it is a pain to have to run
'git add' before 'git rebase --continue'. Passing --autostage to 'git
rebase --continue' will stage them automatically so long as 'git diff
--check' says they a
From: Phillip Wood
If rebase --interactive is unable to commit staged changes because
HEAD has changed since rebase stopped the user gets different messages
depending on whether they specified --autostage or not. Update the
messages in the other code paths to match the --autostage one.
Signed
From: Phillip Wood
These patches add an '--autostage' option (and corresponding config
variable) to 'rebase --continue' that will stage any unstaged changes
before continuing. This saves the user having to type 'git add' before
running 'git rebase --con
From: Phillip Wood
This enables the user to always specify --autostage with --continue
The tests check that setting rebase.continue.autostage=true results in
'git rebase --continue' autostaging unstaged changes and that
'--no-autostage' overrides it.
Signed-off-by: Ph
From: Phillip Wood
Make sure that --autostage stages any changes and fails if there are
merge markers in the file to be staged.
Signed-off-by: Phillip Wood
---
t/t3418-rebase-continue.sh | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/t
From: Phillip Wood
If HEAD has changed since the rebase stopped or rebase stopped due to
a failed exec then 'git rebase --continue --autostage' will autostage
changes that cannot be commited. Fix this by reordering some of the
checks so that 'git rebase --continue --autostag
On 24/07/17 21:53, Junio C Hamano wrote:
Phillip Wood writes:
git rebase --continue requiring one to git add first confuses/annoys me
too. I started a patch to autostage unstaged changes if they don't
contain conflict markers a couple of weeks ago, I'll clean it up and
post it later
On 26/07/17 23:12, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Hmph, this is interesting.
>>
>> "git rebase" does take "--rerere-autoupdate" option from the command
>> line, and propagates it to a later invocation of "rebase --continue"
>> by storing the value to $state_dir/allow_rerere_a
On 27/07/17 11:36, Phillip Wood wrote:
On 26/07/17 23:12, Junio C Hamano wrote:
Junio C Hamano writes:
Hmph, this is interesting.
"git rebase" does take "--rerere-autoupdate" option from the command
line, and propagates it to a later invocation of "rebase --continue
From: Phillip Wood
With the exception of 'rebase -m' when continuing after stopping for
the user to resolve conflicts, they all forget the setting of
--rerere-autoupdate.
Phillip Wood (6):
am: remember --rerere-autoupdate setting
rebase: honor --rerere-autoupdate
rebase -i: hono
From: Phillip Wood
Rebase accepts '--rerere-autoupdate' as an option but only honors it
if '-m' is also given. Fix it for a non-interactive rebase by passing
on the option to 'git am' and 'git cherry-pick'. Rework the tests so
that they can be use
From: Phillip Wood
Using test_commit is simpler than chaining echo && git add &&
test_tick && commit. Also having tags makes it clearer which commit
is being selecting by reset.
Signed-off-by: Phillip Wood
---
t/t3504-cherry-pick-rerere.sh | 19 --
From: Phillip Wood
When continuing after conflicts, cherry-pick forgot if the user had specified
'--rerere-autoupdate'.
Redo the cherry-pick rerere tests to check --rerere-autoupdate works
as expected.
Signed-off-by: Phillip Wood
---
sequencer.c | 10 +++
From: Phillip Wood
Interactive rebase was ignoring '--rerere-autoupdate'. Fix this by
reading it appropriate file when restoring the sequencer state for an
interactive rebase and passing '--rerere-autoupdate' to merge and
cherry-pick when rebasing with '--preserve-merge
From: Phillip Wood
cherry-pick and revert should not accept --[no-]rerere-autoupdate once
they have started.
Signed-off-by: Phillip Wood
---
This will break scripts that pass --[no-]rerere-autoupdate to 'git
cherry-pick --continue'. I don't think that this will be an iss
From: Phillip Wood
Save the rerere-autoupdate setting so that it is remembered after
stopping for the user to resolve conflicts.
Signed-off-by: Phillip Wood
---
There are no new tests, but this code is exercised by the new rebase
tests in the next patch.
builtin/am.c | 12
1
Hi Junio
Thanks for your comments.
On 02/08/17 23:29, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Phillip Wood writes:
>>
>>> From: Phillip Wood
>>>
>>> cherry-pick and revert should not accept --[no-]rerere-autoupdate once
>>>
On 03/08/17 18:19, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> On 02/08/17 23:29, Junio C Hamano wrote:
>> ...
>>> The
>>> latter makes it more in line with how "am -3" followed by "am --no-3
>>> --continue" behaves.
>&g
From: Phillip Wood
If there was no 'Signed-off-by:' trailer but another trailer such as
'Reported-by:' then 'git am --signoff' would add a blank line between
the existing trailers and the added 'Signed-off-by:' line. e.g.
Rebase accepts '--re
On 07/08/17 19:08, Jonathan Tan wrote:
> On Mon, 07 Aug 2017 10:49:28 -0700
> Junio C Hamano wrote:
>
>> Phillip Wood writes:
>>
>>> From: Phillip Wood
>>>
>>> If there was no 'Signed-off-by:' trailer but another trailer such as
>>
On 07/08/17 18:49, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> If there was no 'Signed-off-by:' trailer but another trailer such as
>> 'Reported-by:' then 'git am --signoff' would add a blank line b
From: Phillip Wood
If there was no 'Signed-off-by:' trailer but another trailer such as
'Reported-by:' then 'git am --signoff' would add a blank line between
the existing trailers and the added 'Signed-off-by:' line. e.g.
Rebase accepts '--re
From: Phillip Wood
If there was no 'Signed-off-by:' trailer but another trailer such as
'Reported-by:' then 'git am --signoff' would add a blank line between
the existing trailers and the added 'Signed-off-by:' line. e.g.
Rebase accepts '--re
On 27/07/17 16:24, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> On 26/07/17 23:12, Junio C Hamano wrote:
>>>> I think
>>>> you are already 80% there without adding a yet another option,...
>>> ...
>>> I'm interested in the 2
On 21/08/17 23:41, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> ... I prefer
>> having to pass --autostage with --continue so that it is a concious
>> decision by the user to stage unstaged changes when they continue rather
>> than rebase just doing it each ti
On 22/08/17 16:54, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> In other words, instead of
>>>
>>> git add -u && git rebase --continue
>>>
>>> you would want a quicker way to say
>>>
>>> git re
701 - 800 of 906 matches
Mail list logo
