[PATCH v2] add -p: fix counting empty context lines in edited patches

From: Phillip Wood recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: calculate offset delta for edited patches", 2018-03-05) required all context lines to start with a space, empty lines are not counted. This was intended to avoid any recounting problems if the user had

Re: [PATCH 2/2] git-rebase: error out when incompatible options passed

On 07/06/18 06:06, Elijah Newren wrote: git rebase has three different types: am, merge, and interactive, all of which are implemented in terms of separate scripts. am builds on git-am, merge builds on git-merge-recursive, and interactive builds on git-cherry-pick. We make use of features in

Re: [PATCH] git-rebase.sh: handle keep-empty like all other options

Hi Elijah On 07/06/18 06:07, Elijah Newren wrote: Signed-off-by: Elijah Newren --- git-rebase.sh | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 40be59ecc4..a56b286372 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -276,6 +276,7

Re: [PATCH] add -p: fix counting empty context lines in edited patches

On 01/06/18 21:03, Eric Sunshine wrote: > On Fri, Jun 1, 2018 at 1:46 PM, Phillip Wood > wrote: >> recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: >> calculate offset delta for edited patches", 2018-03-05) required all >> context lines

[PATCH] add -p: fix counting empty context lines in edited patches

From: Phillip Wood recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: calculate offset delta for edited patches", 2018-03-05) required all context lines to start with a space, empty lines are not counted. This was intended to avoid any recounting problems if the user had

Re: [GSoC][PATCH 0/2] rebase -i: rewrite append_todo_help() in C

On 31/05/18 19:44, Stefan Beller wrote: On Thu, May 31, 2018 at 10:48 AM, Phillip Wood wrote: Hi Alban, it's great to see you working on this On 31/05/18 12:01, Alban Gruin wrote: This series rewrites append_todo_help() from shell to C. This is part of the effort to rewrite interactive

Re: [GSoC][PATCH 0/2] rebase -i: rewrite append_todo_help() in C

On 31/05/18 20:25, Alban Gruin wrote: Hi Phillip, Le 31/05/2018 à 19:48, Phillip Wood a écrit : Hi Alban, it's great to see you working on this On 31/05/18 12:01, Alban Gruin wrote: This series rewrites append_todo_help() from shell to C. This is part of the effort to rewrite interactive

Re: [GSoC][PATCH 0/2] rebase -i: rewrite append_todo_help() in C

Hi Alban, it's great to see you working on this On 31/05/18 12:01, Alban Gruin wrote: > This series rewrites append_todo_help() from shell to C. This is part > of the effort to rewrite interactive rebase in C. > > The first commit rewrites append_todo_help() in C (the C version > covers a bit

Re: git rebase -i --exec and changing directory

Hi Ondrej On 27/05/18 13:53, Ondrej Mosnáček wrote: Hi Philip, 2018-05-27 14:28 GMT+02:00 Philip Oakley : You may need to give a bit more background of things that seem obvious to you. So where is the src directory you are cd'ing to relative to the directory/repository

Re: Regression in patch add?

On 11/05/18 03:47, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> Yes, I think it probably makes sense to do that. Originally I didn't >> count empty lines as context lines in case the user accidentally added >> some empty lines at t

Re: Regression in patch add?

On 10/05/18 15:11, Oliver Joseph Ash wrote: > You found the problem Phillip! My editor was trimming trailing white space, > which breaks the context line. I'm glad we found the source of the problem (and that it wasn't some obscure bug) > I had tried to use an alternative editor to account for

Re: Regression in patch add?

On 10/05/18 13:17, Martin Ågren wrote: > > On 10 May 2018 at 12:41, Oliver Joseph Ash wrote: >> I just ran into a similar problem: >> https://stackoverflow.com/questions/50258565/git-editing-hunks-fails-when-file-has-other-hunks >> >> I can reproduce on 2.17.0. The issue

Re: [PATCH v4 4/4] rebase --skip: clean up commit message after a failed fixup/squash

On 06/05/18 18:50, Phillip Wood wrote: Hi Johannes, sorry it's taken me a while to look at this. I think it mostly makes sense to me, the code is well documented. I've got one comment below On 27/04/18 21:48, Johannes Schindelin wrote: During a series of fixup/squash commands, the interactive

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Hi Taylor On 09/05/18 03:13, Taylor Blau wrote: Teach 'git-grep(1)' a new option, '--column', to show the column number of the first match on a non-context line. This makes it possible to teach 'contrib/git-jump/git-jump' how to seek to the first matching position of a grep match in your

Re: [PATCH v4 4/4] rebase --skip: clean up commit message after a failed fixup/squash

Hi Johannes, sorry it's taken me a while to look at this. I think it mostly makes sense to me, the code is well documented. I've got one comment below On 27/04/18 21:48, Johannes Schindelin wrote: > > During a series of fixup/squash commands, the interactive rebase builds > up a commit message

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Hi Taylor On 05/05/18 03:43, Taylor Blau wrote: > > Teach 'git-grep(1)' a new option, '--column', to show the column > number of the first match on a non-context line. > > For example: > > $ git grep -n --column foo | head -n3 > .clang-format:51:14:# myFunction(foo, bar, baz); >

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

On 26/04/18 10:51, Johannes Schindelin wrote: > Hi Phillip, > > On Wed, 25 Apr 2018, Phillip Wood wrote: > >> On 25/04/18 13:48, Johannes Schindelin wrote: >>> >>> On Mon, 23 Apr 2018, Phillip Wood wrote: >>> >>>> On 23/04/18 19:11, Stefa

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

On 25/04/18 13:48, Johannes Schindelin wrote: Hi Phillip, On Mon, 23 Apr 2018, Phillip Wood wrote: On 23/04/18 19:11, Stefan Beller wrote: On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: Eric Sunshine pointed out that I had such a commit m

Re: [PATCH] git: add -N as a short option for --no-pager

On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly in the environment? From the git config man page: When

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

On 23/04/18 19:11, Stefan Beller wrote: On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin wrote: Eric Sunshine pointed out that I had such a commit message in https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov630snqhpv5qgrqdd8mw-syzn...@mail.gmail.com/ and I

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

On 23/04/18 13:20, Johannes Schindelin wrote: Hi Phillip, On Sat, 21 Apr 2018, Phillip Wood wrote: On 21/04/18 11:33, 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

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

On 21/04/18 16:56, Phillip Wood wrote: > On 21/04/18 11:33, 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 t

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

On 21/04/18 11:33, 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 upstream Git.

Re: [PATCH 3/3] rebase --skip: clean up commit message after a failedfixup/squash

On 20/04/18 13:18, Johannes Schindelin wrote: During a series of fixup/squash commands, the interactive rebase builds up a commit message with comments. This will be presented to the user in the editor if at least one of those commands was a `squash`. However, if the last of these fixup/squash

Re: [RFC PATCH] ident: don't cache default date

On 20/04/18 09:11, Johannes Schindelin wrote: > Hi Phillip, > > On Thu, 19 Apr 2018, Phillip Wood wrote: > >> On 18/04/18 19:15, Johannes Sixt wrote: >>> Am 18.04.2018 um 19:47 schrieb Phillip Wood: >>>> On 18/04/18 12:27, Ævar Arnfjörð Bjarmason wrote:

Re: [PATCH v7 06/17] sequencer: introduce new commands to reset the revision

On 19/04/18 13:20, Johannes Schindelin wrote: > In the upcoming commits, we will teach the sequencer to rebase 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 branch

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 16/04/18 10:48, Phillip Wood wrote: > On 14/04/18 14:11, Johannes Schindelin wrote: >> Hi, >> >> On Sat, 14 Apr 2018, Phillip Wood wrote: >> >> FWIW I agree with Hannes' patch. >> >>> I think 'git am' probably gives all patches the same comm

Re: [RFC PATCH] ident: don't cache default date

On 18/04/18 19:15, Johannes Sixt wrote: > Am 18.04.2018 um 19:47 schrieb Phillip Wood: >> On 18/04/18 12:27, Ævar Arnfjörð Bjarmason wrote: >>> On Wed, Apr 18 2018, Phillip Wood wrote: >>>> From: Phillip Wood <phillip.w...@dunelm.org.uk> >>>>

Re: [PATCH v6 05/15] sequencer: introduce the `merge` command

On 14/04/18 01:51, Johannes Schindelin wrote: > Hi Phillip, > > On Fri, 13 Apr 2018, Phillip Wood wrote: > >> On 13/04/18 11:12, Phillip Wood wrote: >>> @@ -3030,7 +3029,8 @@ static int pick_commits(struct todo_list *todo_list, >>> struct replay_opts *opts)

Re: [PATCH v6 04/15] sequencer: introduce new commands to reset the revision

On 15/04/18 18:17, Philip Oakley wrote: > From: "Phillip Wood" <phillip.w...@talktalk.net> > : Friday, April 13, 2018 11:03 AM >> 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 f

Re: [RFC PATCH] ident: don't cache default date

Hi Ævar, thanks for your comments On 18/04/18 12:27, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Apr 18 2018, Phillip Wood wrote: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> Now that the sequencer commits without forking when the commit messag

[RFC PATCH] ident: don't cache default date

From: Phillip Wood <phillip.w...@dunelm.org.uk> Now that the sequencer commits without forking when the commit message isn't edited all the commits that are picked have the same committer date. If a commit is reworded it's committer date will be a later time as it is created by r

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 16/04/18 06:56, Johannes Sixt wrote: > > Am 15.04.2018 um 23:35 schrieb Junio C Hamano: >> Ah, do you mean we have an internal sequence like this, when "rebase >> --continue" wants to conclude an edit/reword? > > Yes, it's only 'reword' that is affected, because then subsequent picks > are

Re: Optimizing writes to unchanged files during merges?

es 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 <phillip.w...@dunelm.org.uk> # # git-mtimes.perl # #

Re: Regression in patch add?

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

Re: Regression in patch add?

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`,

Re: Bug: rebase -i creates committer time inversions on 'reword'

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. Thi

Re: Bug: rebase -i creates committer time inversions on 'reword'

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

Re: [PATCH v6 05/15] sequencer: introduce the `merge` command

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 = (

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

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

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

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

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

On 11/04/18 20:10, Eric Sunshine wrote: On Wed, Apr 11, 2018 at 11:35 AM, Phillip Wood <phillip.w...@talktalk.net> 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

Re: [PATCH v6 05/15] sequencer: introduce the `merge` command

t; + } > + rollback_lock_file(); > + > + ret = run_git_commit(git_path_merge_msg(), opts, run_commit_flags); If there were conflicts this will try and run git commit with unmerged cache entries > + strbuf_release(_name); > + > + return ret; &

Re: [PATCH v6 04/15] sequencer: introduce new commands to reset the revision

me repository. > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> 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

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

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

Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)

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"

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

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 <phillip.w...@talktalk.net> writes: >>> >>>> From: Phillip Wood <phillip.w...@dune

Re: [PATCH v2] add -p: fix 2.17.0-rc* regression due to moved code

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

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

On 29/03/18 19:32, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> Since v2 I've updated the patches to use '-' instead of '^' to invert >> the selectio

Re: [PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

On 20/03/18 19:32, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> 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

Re: [PATCH 7/7] diff-highlight: detect --graph by indent

> 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 rare > enough to disregard). > &g

Re: [PATCH v2 3/3] rebase --keep-empty: always use interactive rebase

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 chan

Re: [PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

On 20/03/18 15:42, Johannes Schindelin wrote: > Hi Phillip, > > On Tue, 20 Mar 2018, Phillip Wood wrote: > >> From: Phillip Wood <phillip.w...@dunelm.org.uk> >> >> These patches apply on top of js/rebase-recreate-merge. They extend >> the --keep-empty

Re: [PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

On 20/03/18 17:34, Junio C Hamano wrote: > Johannes Schindelin writes: > >>> + if (!keep_empty && is_empty) >>> strbuf_addf(, "%c ", comment_line_char); > > We are not trying to preserve an empty one, and have found an empty > one, so we

[PATCH v2 3/3] rebase --keep-empty: always use interactive rebase

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

[PATCH v2 1/3] rebase: extend --signoff support

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

[PATCH v2 2/3] rebase -p: error out if --signoff is given

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

[PATCH v2 0/3] rebase: extend --signoff support

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

[PATCH 2/2] rebase --recreate-merges --keep-empty: don't prune empty commits

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

[PATCH 1/2] add failing test for rebase --recreate-merges --keep-empty

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

[PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

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

[PATCH 0/3] rebase --keep-empty/--root fixes

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

[PATCH 3/3] rebase: respect --no-keep-empty

From: Phillip Wood <phillip.w...@dunelm.org.uk> $OPT_SPEC has always allowed --no-keep-empty so lets start handling it. Signed-off-by: Phillip Wood <phillip.w...@dunelm.org.uk> --- git-rebase.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git-rebase.sh b/git-reb

[PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

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

[PATCH 1/3] rebase --root: stop assuming squash_onto is unset

From: Phillip Wood <phillip.w...@dunelm.org.uk> 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 <phillip.w...@dunelm.org.uk> --- git-rebase.sh | 1 + 1 fil

Re: [BUG] log --graph corrupts patch

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: >> >> | @@ -272,6 +272,9

[BUG] log --graph corrupts patch

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= | +

[PATCH v3 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 v3 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 1-357 to stage lines 1, 2, 3, 5 & 7. Signed-off-by: Phillip Wood <phillip.w...@

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

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

[PATCH v3 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> --- Notes: changes since v2: - use '-' to invert the selec

Re: [PATCH 2/2] rebase --root -k: fix when root commit is empty

On 14/03/18 11:11, Phillip Wood wrote: > From: Phillip Wood <phillip.w...@dunelm.org.uk> > > 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 (

Re: [PATCH 1/2] rebase: support --signoff with implicit 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

[PATCH 2/2] rebase --root -k: fix when root commit is empty

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

[PATCH 1/2] rebase: support --signoff with implicit rebase

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

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

On 13/03/18 16:32, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> On 08/03/18 17:53, Junio C Hamano wrote: >>> Phillip Wood <phillip.w...@talktalk.net> writes: >>> >>>> and use a leading '-' for inversion. I'm t

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

On 08/03/18 17:53, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> 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.

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

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

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

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

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

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

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

On 06/03/18 19:57, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> 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

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

On 05/03/18 05:00, Sergey Organov wrote: > Hi Plillip and Igor, > > Igor Djordjevic <igor.d.djordje...@gmail.com> writes: >> Hi Phillip, >> >> On 02/03/2018 12:31, Phillip Wood wrote: >>> >>>> Thinking about it overnight, I now suspect that o

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

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

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

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 should have

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

On 05/03/18 18:50, Junio C Hamano wrote: > Phillip Wood <phillip.w...@talktalk.net> writes: > >> 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. >

Re: [PATCH 1/2] completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate

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

[PATCH v2 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 v2 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 v2 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> --- Documentation/git-add.txt | 3 ++- git-add--interactive.perl | 17

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

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

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

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/' \ >>>

[PATCH v5 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 v5 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 v5 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 v5 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 v5 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 v5 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 v5 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 v5 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 v5 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

<    1   2   3   4   5   6   >