On 23/09/2019 09:37, SZEDER Gábor wrote:
On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
Am 22.09.19 um 21:53 schrieb SZEDER Gábor:
On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
On 22/09/2019 19:01, SZEDER Gábor wrote:
+/*
+ * One day. See the 'name
Hi
On 09/09/2019 15:13, Johannes Schindelin wrote:
Hi,
On Mon, 9 Sep 2019, Phillip Wood wrote:
On 08/09/2019 00:44, Warren He wrote:
Everyone in this thread, thanks for your support and encouragement.
[...]
It should not really imply `--interactive`, but `--rebase-merges
Hi Taylor and ZJ
On 22/09/2019 04:11, Taylor Blau wrote:
Hi ZJ,
On Tue, Sep 17, 2019 at 03:31:34PM +0200, Zeger-Jan van de Weg wrote:
When adding or updating configuration values using git-config, the
values could all be observed by different processes as these are passed
as arguments. In some
Hi Peff
On 24/09/2019 07:44, Jeff King wrote:
We've never had a formally written Code of Conduct document. Though it
has been discussed off and on over the years, for the most part the
behavior on the mailing list has been good enough that nobody felt the
need to push one forward.
However, even
Hi Gábor
On 24/09/2019 10:01, SZEDER Gábor wrote:
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
[...]
After some poking around at various CoC options, this one seemed like
the best fit to me. But I'm open to suggestions or more discussion. It
seems to me that the important piece i
Hi Eric
On 24/09/2019 02:03, Eric Wong wrote:
Patches 1-11 are largely unchanged from the original series with the
exception of 2, which is new and posted at:
https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
12-17 take further steps to get us away from hashmap_entry b
Hi Rohit
This is an improvement but there are a couple of outstanding issues from
the previous round with regard to handing --ignore-date when
GIT_COMMITTER_DATE is set. I'll try and look at the rest of the series soon.
On 07/09/2019 12:50, Rohit Ashiwal wrote:
rebase am already has this fla
Hi Alban
Thanks for removing some more unnecessary work reloading the the todo list.
On 25/09/2019 21:13, Alban Gruin wrote:
Currently, complete_action() calls sequencer_continue() to do the
rebase. Even though the former already has the todo list, the latter
loads it from the disk and parses
Hi Alban
On 25/09/2019 21:13, Alban Gruin wrote:
get_replay_opts() did not fill `squash_onto' if possible, meaning that
I'm not sure what you mean by 'if possible' here, I think the sentance
makes sense without that.
this field should be read from the disk by the sequencer through
read_pop
Hi Alban
On 25/09/2019 21:13, Alban Gruin wrote:
This can be seen as a continuation of ag/reduce-rewriting-todo.
Currently, complete_action() releases its todo list before calling
sequencer_continue(), which reloads the todo list from the disk. This
series removes this useless round trip.
Pat
Hi Dscho
On 02/10/2019 09:16, Johannes Schindelin wrote:
Hi,
On Fri, 27 Sep 2019, Phillip Wood wrote:
Hi Alban
On 25/09/2019 21:13, Alban Gruin wrote:
>>> [...]
builtin/rebase.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/rebase.c b/builtin/rebas
Hi Rohit
On 07/09/2019 12:50, Rohit Ashiwal wrote:
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to tre
Hi Rohit
The handling of ident_split is looking better now but I've got a
question below about returning vs going to a cleanup section when
there's an error.
On 07/09/2019 12:50, Rohit Ashiwal wrote:
rebase am already has this flag to "lie" about the committer date
by changing it to the auth
Hi Junio
On 03/10/2019 06:04, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still
Hi Elijah
On 05/10/2019 01:40, Elijah Newren wrote:
On Fri, Oct 4, 2019 at 4:49 AM Phillip Wood wrote:
Hi Junio
On 03/10/2019 06:04, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while c
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
---
Documentation/git-add.txt | 3 ++-
git-add--interactive.perl | 17 -
t/t3701-add-interactive.sh | 2 +-
3 files c
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
---
Documentation/git-add.txt | 3 ++-
git
From: Phillip Wood
I've added some documentation to git-add.txt for the new selection
mode and cleaned up some style issues, otherwise these are unchanged
since v1. These patches build on top of the recount fixes in [1]. The
commit message for the first patch describes the motivation:
&q
On 03/03/18 09:23, Nguyễn Thái Ngọc Duy wrote:
>
> There is not a strong reason to hide this option, and git-merge already
> completes this one. Let's allow to complete this for all commands (and
> let git-completion.bash do the suppressing if neede).
>
> This makes --rerere-autoupdate completabl
On 05/03/18 18:50, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> I've updated these to clean up the perl style in response to Junio's
>> comments on v4.
>
> I've considered the use of "apply --recount"
On 02/03/18 23:33, Igor Djordjevic wrote:
> Hi Phillip,
>
>> On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote:
>>>
>>>> It is interesting to think what it means to faithfully rebase a '-s
>>>> ours' merge.
>>>
>>> I shoul
On 03/03/18 00:29, Igor Djordjevic wrote:
> Hi Phillip,
>
> On 02/03/2018 12:31, Phillip Wood wrote:
>>
>>> Thinking about it overnight, I now suspect that original proposal had a
>>> mistake in the final merge step. I think that what you did is a way to
>&g
On 05/03/18 05:00, Sergey Organov wrote:
> Hi Plillip and Igor,
>
> Igor Djordjevic writes:
>> Hi Phillip,
>>
>> On 02/03/2018 12:31, Phillip Wood wrote:
>>>
>>>> Thinking about it overnight, I now suspect that original proposal had a
>>>
On 06/03/18 19:57, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> If the list of lines to be selected begins with '^' select all the
>> lines except the ones listed.
>
> There is "# Input that begins with '
On 06/03/18 18:12, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Tue, 6 Mar 2018, Phillip Wood wrote:
>
>> On 03/03/18 00:29, Igor Djordjevic wrote:
>>>
>>> On 02/03/2018 12:31, Phillip Wood wrote:
>>>>
>>>>> Thinking about it over
On 07/03/18 07:26, Johannes Schindelin wrote:
> Hi Buga,
>
> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>
>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>>>
> And I guess being consistent is pretty important, too - if you add new
> content during merge rebase, it should always show up
On 08/03/18 11:20, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>>>>
>>>>>> And
On 08/03/18 17:53, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> and use a leading '-' for inversion. I'm tempted to keep supporting 'n-'
>> to mean everything from 'n' to the last line though.
>
> Thanks for double checking. It
On 13/03/18 16:32, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> On 08/03/18 17:53, Junio C Hamano wrote:
>>> Phillip Wood writes:
>>>
>>>> and use a leading '-' for inversion. I'm tempted to keep supporting 'n-'
>>&
From: Phillip Wood
This allows one to run 'git rebase --exec "make check" --signoff'
which is useful when preparing a patch series for publication and is
more convenient than doing the signoff with another --exec command.
This change also allows --root without --onto to wo
From: Phillip Wood
When the root commit was empty it was being pruned by the
--cherry-pick option passed to rev-parse. This is because when --onto
is omitted rebase creates an empty commit (which it later amends) for
the new root commit.
Signed-off-by: Phillip Wood
---
git-rebase
On 15/03/18 10:18, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Wed, 14 Mar 2018, Phillip Wood wrote:
>
>> diff --git a/git-rebase.sh b/git-rebase.sh
>> index b353c33d41..40301756be 100755
>> --- a/git-rebase.sh
>> +++ b/git-rebase.sh
>> @@ -459,6 +4
On 14/03/18 11:11, Phillip Wood wrote:
> From: Phillip Wood
>
> When the root commit was empty it was being pruned by the
> --cherry-pick option passed to rev-parse. This is because when --onto
> is omitted rebase creates an empty commit (which it later amends) for
> t
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 1-357 to stage lines 1, 2, 3, 5 & 7.
Signed-off-by: Phillip Wood
---
Notes:
changes since v2:
- removed
From: Phillip Wood
Since v2 I've updated the patches to use '-' instead of '^' to invert
the selection to match the rest of add -i and clean -i.
These patches build on top of the recount fixes in [1]. The commit
message for the first patch describes the motivation:
&qu
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
---
Notes:
changes since v2:
- use '-' to invert the selection instead of '^' to be consistent
with t
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
I've just been reviewing some patches with 'git log --graph --patch' and
came across what looked like a bug:
| @@ -272,6 +272,9 @@ do
| --keep-empty)
| keep_empty=yes
| ;;
| --allow-empty-message)
| + --no-keep-empty)
| + keep_empty=
| +
On 20/03/18 06:09, Jeff King wrote:
> On Mon, Mar 19, 2018 at 10:21:56AM +0000, Phillip Wood wrote:
>
>> I've just been reviewing some patches with 'git log --graph --patch' and
>> came across what looked like a bug:
>>
>> | @
From: Phillip Wood
If the user set the environment variable 'squash_onto', the 'rebase'
command would erroneously assume that the user passed the option
'--root'.
Signed-off-by: Phillip Wood
---
git-rebase.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a
From: Phillip Wood
$OPT_SPEC has always allowed --no-keep-empty so lets start handling
it.
Signed-off-by: Phillip Wood
---
git-rebase.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git-rebase.sh b/git-rebase.sh
index 8b1b892d72..37b8f13971 100755
--- a/git-rebase.sh
+++ b/git
From: Phillip Wood
If there are empty commits on the left hand side of $upstream...HEAD
then the empty commits on the right hand side that we want to keep are
pruned by --cherry-pick. Fix this by using --cherry-mark instead of
--cherry-pick and keeping the commits that are empty or are not
From: Phillip Wood
These patches are based on top of maint. The first two are a reworking
of "[PATCH 2/2] rebase --root -k: fix when root commit is empty" [1]
[1]
https://public-inbox.org/git/2018031427.14217-2-phillip.w...@talktalk.net/
Phillip Wood (3):
rebase --root: sto
From: Phillip Wood
If there are empty commits on the left hand side of $upstream...HEAD
then the empty commits on the right hand side that we want to keep are
pruned because they are marked as cherry-picks. Fix this by keeping
the commits that are empty or are not marked as cherry-picks.
Signed
From: Phillip Wood
If there are empty commits on the left hand side of $upstream...HEAD
then the empty commits on the right hand side that we want to keep are
being pruned. This will be fixed in the next commit.
Signed-off-by: Phillip Wood
---
t/t3421-rebase-topology-linear.sh | 1 +
1 file
From: Phillip Wood
These patches apply on top of js/rebase-recreate-merge. They extend
the --keep-empty fix from maint [1] to work with --recreate-merges.
[1]
https://public-inbox.org/git/20180320100315.15261-3-phillip.w...@talktalk.net/T/#u
Phillip Wood (2):
add failing test for rebase
From: Phillip Wood
Thanks for the feedback on v1, based on that I've added support for
--interacive --signoff and --merge --signoff. I've split this series
so the fixes from patch two in the last verion are now in a separate
series [1]. The tests in this version depends on those fixes.
From: Phillip Wood
rebase --preserve-merges does not support --signoff so error out
rather than just silently ignoring it so that the user knows the
commits will not be signed off.
Signed-off-by: Phillip Wood
---
git-rebase.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git
From: Phillip Wood
rebase --merge accepts --keep-empty but just ignores it, by using an
implicit interactive rebase the user still gets the rename detection
of a merge based rebase but with with --keep-empty support.
If rebase --keep-empty without --interactive or --merge stops for the
user to
From: Phillip Wood
Allow --signoff to be used with --interactive and --merge. In
interactive mode only commits marked to be picked, edited or reworded
will be signed off.
The main motivation for this patch was to allow one to run 'git rebase
--exec "make check" --signoff'
On 20/03/18 17:34, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> + if (!keep_empty && is_empty)
>>> strbuf_addf(&buf, "%c ", comment_line_char);
>
> We are not trying to preserve an empty one, and have found an empty
> one, so we comment it out, and then
On 20/03/18 15:42, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Tue, 20 Mar 2018, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> These patches apply on top of js/rebase-recreate-merge. They extend
>> the --keep-empty fix from maint [1] to work with --r
On 20/03/18 16:08, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Tue, 20 Mar 2018, Phillip Wood wrote:
>
>> git-rebase--am.sh | 79
>> ---
>
> Those are a lot of changes, but pretty much all of it is a change
it's a context line that
> happens to look like a diff header. We can only be sure of
> the indent on the "*" lines, since we know those don't
> contain arbitrary data (technically the user could include a
> bunch of extra indentation via --format, but that's r
On 20/03/18 19:32, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> On 20/03/18 15:42, Johannes Schindelin wrote:
>> ...
>>> As indicated in another reply, I'd rather rebase the --recreate-merges
>>> patches on top of your --keep-empty patch series. T
On 29/03/18 19:32, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> Since v2 I've updated the patches to use '-' instead of '^' to invert
>> the selection to match the rest of add -i and clean -i.
>>
>>
On 31/03/18 13:50, Ævar Arnfjörð Bjarmason wrote:
Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if
there's more than one hunk", 2018-02-13) which is present in
2.17.0-rc*, but not 2.16.0.
In Perl, regex variables like $1 always refer to the last regex
match. When the aforemention
On 31/03/18 20:20, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Mar 30 2018, Phillip Wood wrote:
>
>> On 29/03/18 19:32, Junio C Hamano wrote:
>>> Phillip Wood writes:
>>>
>>>> From: Phillip Wood
>>>>
>>>> Since v2 I've
On 09/04/18 11:21, Junio C Hamano wrote:
* pw/add-p-select (2018-03-16) 3 commits
(merged to 'next' on 2018-03-30 at eae69f5ded)
+ add -p: optimize line selection for short hunks
+ add -p: allow line selection to be inverted
+ add -p: select individual hunk lines
"git add -p" interact
On 10/04/18 13:30, Johannes Schindelin wrote:
Firstly let me say that I think expanding the documentation and having
an example is an excellent idea.
+
+
+label onto
+
+# Branch: refactor-button
+reset onto
+pick 123456 Extract a generic Button class from the DownloadButton one
+p
inked to the same repository.
>
> Signed-off-by: Johannes Schindelin
If a label or reset command fails it is likely to be due to a
typo. Rescheduling the command would make it easier for the user to fix
the problem as they can just run 'git rebase --edit-todo'. It also
ensures
cts then ret == 0 rather than -1
> +
> + if (active_cache_changed &&
> + write_locked_index(&the_index, &lock, COMMIT_LOCK)) {
> + strbuf_release(&ref_name);
> + return error(_("merge: Unable to write new index file&
On 11/04/18 20:10, Eric Sunshine wrote:
On Wed, Apr 11, 2018 at 11:35 AM, Phillip Wood
wrote:
On 10/04/18 13:30, Johannes Schindelin wrote:
+The `reset` command is essentially a `git reset --hard` to the specified
+revision (typically a previously-labeled one).
s/labeled/labelled
On 12/04/18 10:30, Johannes Schindelin wrote:
Hi Phillip,
On Wed, 11 Apr 2018, Phillip Wood wrote:
On 10/04/18 13:30, Johannes Schindelin wrote:
Firstly let me say that I think expanding the documentation and having an
example is an excellent idea.
Thanks! At first, I meant to leave this
On 12/04/18 23:02, Johannes Schindelin wrote:
Hi Jake,
On Thu, 12 Apr 2018, Jacob Keller wrote:
On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov wrote:
Jacob Keller writes:
On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote:
It was rather --recreate-merges just a few weeks ago, and I
On 13/04/18 11:12, Phillip Wood wrote:
> On 10/04/18 13:29, Johannes Schindelin wrote:
>> +static int do_merge(struct commit *commit, const char *arg, int arg_len,
>> +int flags, struct replay_opts *opts)
>> +{
>> +int run_commit_flags = (
On 13/04/18 17:52, Johannes Sixt wrote:
>
> I just noticed that all commits in a 70-commit branch have the same
> committer timestamp. This is very unusual on Windows, where rebase -i of
> such a long branch takes more than one second (but not more than 3 or
> so thanks to the builtin nature of t
On 14/04/18 14:11, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 14 Apr 2018, Phillip Wood wrote:
>
>> On 13/04/18 17:52, Johannes Sixt wrote:
>>>
>>> I just noticed that all commits in a 70-commit branch have the same
>>> committer timestamp. This i
On 15/04/18 13:21, mqudsi wrote:
>
> Hello all,
>
> I'm currently running the latest version of git built from `master`, and
> I'm running into what appears to be a regression in the behavior of the
> piecewise `git add -p` when applying a manually edited chunk.
>
> I first run `git add -p`, the
On 15/04/18 14:59, Martin Ågren wrote:
> Hi Mahmoud
>
> On 15 April 2018 at 14:21, wrote:
>> I first run `git add -p`, then manually edit a chunk (after hitting `s`
>> once, if it matters). The chunk originally contains the following:
>
> [...]
>
>> Under git 2.7.4, I can edit it to the follow
'git mtimes
restore'). The sentinels can be specified on the commandline when
running 'git mtimes save' or stored in multiple mtimes.sentinal config
keys.
Best Wishes
Phillip
--->8---
#!/usr/bin/perl
# Copyright (C) 2018 Phillip Wood
#
# git-mtimes.perl
#
# This program
On 21/11/17 10:44, Adam Dinwoodie wrote:
> On Monday 20 November 2017 at 08:16 pm +, Ramsay Jones wrote:
>> For several days, I have been staring at some 'unexpected passes' in
>> the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test
>> files (tests #11-13 in both cases).
Thank
From: Phillip Wood
When there is more than one squash/fixup command in a row check the
intermediate messages are correct.
Signed-off-by: Phillip Wood
---
t/t3404-rebase-interactive.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase
From: Phillip Wood
I've updated the patches to fix the embarassing build failure in
v3. I've also added a patch to remove the known breakage from some of
the tests in t3512/t3513 that now pass - someone who knows about
submodules should check this. The only other change is to
From: Phillip Wood
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 other than 'rec
From: Phillip Wood
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-rewrite hook. Once
the sequencer
From: Phillip Wood
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.
Signed-off-by: Phillip Wood
---
Notes
From: Phillip Wood
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 &
From: Phillip Wood
Load default values for message cleanup and gpg signing of commits in
preparation for committing without forking 'git commit'. Note that we
interpret commit.cleanup=scissors to mean COMMIT_MSG_CLEANUP_SPACE to
be consistent with 'git commit'
Signed-
From: Phillip Wood
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 from
lib-submodule-update.s
From: Phillip Wood
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
---
Notes:
changes since v2:
- updated commit message to reflect the
From: Phillip Wood
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 addition to specifying if this is
an
On 24/11/17 13:48, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> Load default values for message cleanup and gpg signing of commits in
>> preparation for committing without forking 'git commit'. Note that we
>
On 04/12/17 18:30, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> --- a/builtin/rebase--helper.c
>> +++ b/builtin/rebase--helper.c
>> @@ -9,6 +9,17 @@ static const char * const builtin_rebase_helper_usage[] = {
>> NULL
>> };
>>
>> +s
On 05/12/17 11:21, Phillip Wood wrote:
> On 04/12/17 18:30, Junio C Hamano wrote:
>> Phillip Wood writes:
>>
>>> --- a/builtin/rebase--helper.c
>>> +++ b/builtin/rebase--helper.c
>>> @@ -9,6 +9,17 @@ static const char * const buil
On 04/12/17 19:24, Stefan Beller wrote:
> On Fri, Nov 24, 2017 at 3:07 AM, Phillip Wood
> wrote:
>> From: Phillip Wood
>>
>> Now that the sequencer creates commits without forking 'git commit' it
>> does not see an empty commit in these tests which fixe
Hi Igor
On 09/12/17 03:03, Igor Djordjevic wrote:
>
> Hi Alexei,
>
> On 09/12/2017 03:18, Alexei Lozovsky wrote:
>>
>>> Chris reported in this very topic[1] that sometimes, due to
>>> conflicts with later commits, "checkout > commit > [checkout >]
>>> rebase --onto" is "much easier to do", where
On 05/12/17 11:21, Phillip Wood wrote:
> On 04/12/17 18:30, Junio C Hamano wrote:
>> Phillip Wood writes:
>>
>>> --- a/builtin/rebase--helper.c
>>> +++ b/builtin/rebase--helper.c
>>> @@ -9,6 +9,17 @@ static const char * const buil
Hi Igor
On 09/12/17 03:03, Igor Djordjevic wrote:
>
> Hi Alexei,
>
> On 09/12/2017 03:18, Alexei Lozovsky wrote:
>>
>>> Chris reported in this very topic[1] that sometimes, due to
>>> conflicts with later commits, "checkout > commit > [checkout >]
>>> rebase --onto" is "much easier to do", wher
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
>>>
From: Phillip Wood
When there is more than one squash/fixup command in a row check the
intermediate messages are correct.
Signed-off-by: Phillip Wood
---
t/t3404-rebase-interactive.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase
From: Phillip Wood
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 indicate if it successfully handled
From: Phillip Wood
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-rewrite hook. Once
the sequencer
From: Phillip Wood
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.
Signed-off-by: Phillip Wood
---
Notes
From: Phillip Wood
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
---
Notes:
changes since v2:
- updated commit message to reflect the
From: Phillip Wood
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 addition to specifying if this is
an
From: Phillip Wood
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 other than 'rec
From: Phillip Wood
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 from
lib-submodule-update.s
From: Phillip Wood
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 &
501 - 600 of 906 matches
Mail list logo
