Re: RFE: git-patch-id should handle patches without leading "diff"

Jonathan Nieder writes: >> So it seems most sensible to me if this is going to be supported that we >> go a bit beyond the call of duty and fake up the start of it, namely: >> >> --- a/arch/x86/kernel/process.c >> +++ b/arch/x86/kernel/process.c >> >> To be: >> >> diff --git

Re: RFE: git-patch-id should handle patches without leading "diff"

Ævar Arnfjörð Bjarmason wrote: > On Fri, Dec 07 2018, Jonathan Nieder wrote: >> The patch-id appears to only care about the diff text, so it should be >> able to handle this. So if we have a better heuristic for where the >> diff starts, it would be good to use it. > > No, the patch-id doesn't

Re: RFE: git-patch-id should handle patches without leading "diff"

On Fri, Dec 07 2018, Jonathan Nieder wrote: > Hi, > > Konstantin Ryabitsev wrote: > >> Every now and again I come across a patch sent to LKML without a leading >> "diff a/foo b/foo" -- usually produced by quilt. E.g.: >> >> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/ >>

Re: RFE: git-patch-id should handle patches without leading "diff"

Hi, Konstantin Ryabitsev wrote: > Every now and again I come across a patch sent to LKML without a leading > "diff a/foo b/foo" -- usually produced by quilt. E.g.: > > https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/ > > I am guessing quilt does not bother including the

Re: RFE: git-patch-id should handle patches without leading "diff"

" there, with just "--- " (which is legit) we'd get confused and start earlier before the diffstat. So if you're interested in having this I leave it to you to run with this & write tests for it, but more convincingly run it on the git & LKML archives and see that the output is the same (or just extra in case where we now find patches) with --stable etc.

RFE: git-patch-id should handle patches without leading "diff"

Hi, all: Every now and again I come across a patch sent to LKML without a leading "diff a/foo b/foo" -- usually produced by quilt. E.g.: https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/ I am guessing quilt does not bother including the leading "diff a/foo b/foo" because it's

How to add edges to visualize cherry-picks and ported patches

Hi, I hope this is the right place for this answer. If not, plaese point me to a more appropriate place. A project  "P2" [2] forked from another project "P1" [1]  quite some time ago, both repos share a common history up to some point. After this point, P2 cherry-picked commits from P1, but did

Re: [PATCH] Makefile: add pending semantic patches

with _index may be correct but not immediately >> > necessary)? >> >> the latter. I assume correctness (of the semantic patch) to be a given, > > I'm afraid we can't assume that. As far as correctness is concerned, > I think semantic patches are not different from any o

Re: [PATCH] coccicheck: introduce 'pending' semantic patches

On Fri, Nov 09, 2018 at 04:10:52PM -0800, Stefan Beller wrote: > From: SZEDER Gábor > > Teach `make coccicheck` to avoid patches named "*.pending.cocci" and > handle them separately in a new `make coccicheck-pending` instead. > This means that we can separate &qu

Re: [PATCH] Makefile: add pending semantic patches

_index() with _index may be correct but not immediately > > necessary)? > > the latter. I assume correctness (of the semantic patch) to be a given, I'm afraid we can't assume that. As far as correctness is concerned, I think semantic patches are not different from any other code we write, i.e

Re: [PATCH] coccicheck: introduce 'pending' semantic patches

On 2018.11.09 16:10, Stefan Beller wrote: > From: SZEDER Gábor > > Teach `make coccicheck` to avoid patches named "*.pending.cocci" and > handle them separately in a new `make coccicheck-pending` instead. > This means that we can separate "critical" patch

Re: [PATCH] coccicheck: introduce 'pending' semantic patches

On Sat, 10 Nov 2018 at 01:10, Stefan Beller wrote: > I dialed back on the workflow, as we may want to explore it first > before writing it down. Makes sense. FWIW, this iteration looks good to me. Martin

[PATCH] coccicheck: introduce 'pending' semantic patches

From: SZEDER Gábor Teach `make coccicheck` to avoid patches named "*.pending.cocci" and handle them separately in a new `make coccicheck-pending` instead. This means that we can separate "critical" patches from "FYI" patches. The former target can continue cau

Re: [PATCH] Makefile: add pending semantic patches

trib/coccinelle/README b/contrib/coccinelle/README > > index 9c2f8879c2..fa09d1abcc 100644 > > --- a/contrib/coccinelle/README > > +++ b/contrib/coccinelle/README > > @@ -1,2 +1,62 @@ > > This directory provides examples of Coccinelle (http://coccinelle.lip6.fr/) > >

Re: [PATCH] Makefile: add pending semantic patches

pending semantic patches", but this patch doesn't add > any. It adds Makefile-support for such patches though, and it defines > the entire concept of pending semantic patches. How about "coccicheck: > introduce 'pending' semantic patches"? > > > Add a description and pla

Re: [PATCH] Makefile: add pending semantic patches

+ b/contrib/coccinelle/README > @@ -1,2 +1,62 @@ > This directory provides examples of Coccinelle (http://coccinelle.lip6.fr/) > semantic patches that might be useful to developers. > + > +There are two types of semantic patches: > + > + * Using the semantic transformation to check for bad

Re: [PATCH] Makefile: add pending semantic patches

e: add pending semantic patches", but this patch doesn't add any. It adds Makefile-support for such patches though, and it defines the entire concept of pending semantic patches. How about "coccicheck: introduce 'pending' semantic patches"? > Add a description and place on how to use c

[PATCH] Makefile: add pending semantic patches

--- a/contrib/coccinelle/README +++ b/contrib/coccinelle/README @@ -1,2 +1,62 @@ This directory provides examples of Coccinelle (http://coccinelle.lip6.fr/) semantic patches that might be useful to developers. + +There are two types of semantic patches: + + * Using the semantic transformation to check

Re: [PATCH 01/24] Makefile: add pending semantic patches

Stefan Beller writes: > [Missing: SZEDERs sign off, so I also do not sign off] At least to me, based on my reading of DCO in Documentation/SubmittingPatches, this reasoning does not make much sense.

[PATCH 01/24] Makefile: add pending semantic patches

From: SZEDER Gábor There are basically two main use cases for semantic patches: - To avoid undesirable code patterns, e.g. we should not use sha1_to_hex(oid.hash) or strbuf_addf(, "fixed string"), but use oid_to_hex() or strbuf_addstr(, "fixed string&qu

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Wed, Oct 24, 2018 at 6:59 PM SZEDER Gábor wrote: > > On Mon, Oct 22, 2018 at 11:54:06AM -0700, Stefan Beller wrote: > > > For the sake of a good history, I would think running 'make coccicheck' > > and applying the resulting patches would be best as part of the (dirty) &

[PATCH v2 0/3] Allow choosing the SSL backend cURL uses (plus related patches)

This topic branch brings support for choosing cURL's SSL backend (a feature developed in Git for Windows' context) at runtime via http.sslBackend, and two more patches that are related (and only of interest for Windows users). Changes since v1: * Reworded the commit message of v1's patch 2/3

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Mon, Oct 22, 2018 at 07:39:35PM +0200, SZEDER Gábor wrote: > I don't really like how this or the previous RFC patch series deal > with semantic patches (or how some past patch series dealt with them, > for that matter), for various reasons: > [..] I am a little late to

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Mon, Oct 22, 2018 at 11:54:06AM -0700, Stefan Beller wrote: > For the sake of a good history, I would think running 'make coccicheck' > and applying the resulting patches would be best as part of the (dirty) > merge of any topic that proposes new semantic patches, but that would &

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

Stefan Beller writes: >> Anyway, even though "make coccicheck" does not run in subsecond, >> I've updated my machinery to rebuild the integration branches so >> that I can optionally queue generated coccicheck patches, and what I >> pushed out tonight has one a

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

my not making the best use of these > > patches. > > > > Steppng back a bit, I'd imagine in an ideal world where "make > > coccicheck" can be done instantaneously _and_ the spatch machinery > > is just as reliable as C compilers > > > > What I _could

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

ed to the semantic changes or Apple (AKA macOS) Oh, don't get me wrong. By Apple, I meant "the versions of compiler used on the Apple build at TravisCI site". I could have sent the above two lines in a separate topic, as the issue does not have anything to do with "new semantic

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Tue, Oct 23, 2018 at 2:40 AM Junio C Hamano wrote: > > The tip of 'pu' has trouble with -Wunused on Apple around the > delta-islands series. FWIW the "problem" is actually with -Wunused-function and is AFAIK not related to the semantic changes or Apple (AKA macOS) Indeed, I saw this issue

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

Junio C Hamano writes: > I actually think this round does a far nicer job playing well with > other topics than any earlier series. The pain you are observing I > think come primarily from my not making the best use of these > patches. > > Steppng back a bit, I'd imagine in an

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

Stefan Beller writes: > Am I overestimating or misunderstanding rerere here? Yes. > Would it be realistic for next and master branch instead of pu? > > I'd be wary for the master branch, as we may not want to rely on > spatch without review. (It can produce funny white space issues, > but

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

ance of landing in 'pu', unless we freeze the world. I wonder if we could approximate the ideal world with rerere+spatch a bit more: 1) I resend the series that includes "apply cocci patches" as the last patch and you queue it as usual 2) The first time such a series is merg

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

SZEDER Gábor writes: > I don't really like how this or the previous RFC patch series deal > with semantic patches (or how some past patch series dealt with them, > for that matter), for various reasons: > ... > How about introducing the concept of "pending" semantic patc

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Mon, Oct 22, 2018 at 10:39 AM SZEDER Gábor wrote: > > On Tue, Oct 16, 2018 at 04:35:31PM -0700, Stefan Beller wrote: > > the last patch (applying the semantic patches) has been omitted as that > > would produce a lot of merge conflicts. Without that patch, this merges &

New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

On Tue, Oct 16, 2018 at 04:35:31PM -0700, Stefan Beller wrote: > the last patch (applying the semantic patches) has been omitted as that > would produce a lot of merge conflicts. Without that patch, this merges > cleanly to next. > > As for when to apply the semantic patches, I

[PATCH 0/3] Allow choosing the SSL backend cURL uses (plus related patches)

This topic branch brings support for choosing cURL's SSL backend (a feature developed in Git for Windows' context) at runtime via http.sslBackend, and two more patches that are related (and only of interest for Windows users). Brendan Forster (1): http: add support for disabling SSL revocation

[PATCH 19/19] Apply semantic patches from previous patches

Previous commits added some cocci rules, but did not patch the whole tree, as to not dilute the focus for reviewing the previous patches. This patch is generated by 'make coccicheck' and applying the resulting diff, which was white space damaged (>8 spaces after a tab) in blame.c, which has b

Re: [PATCH v5 05/21] range-diff: also show the diff between patches

On 08/13, Johannes Schindelin wrote: > Hi Thomas, > > On Sun, 12 Aug 2018, Thomas Gummerer wrote: > > > On 08/10, Johannes Schindelin via GitGitGadget wrote: > > > From: Johannes Schindelin > > > > [...] > > > > I don't think this handles "--" quite as would be expected. Trying to > > use

[PATCH v6 05/21] range-diff: also show the diff between patches

From: Johannes Schindelin Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner. An alternative would be to display an interdiff, i.e. the hypothetical diff which is the result of first

Re: [PATCH v5 05/21] range-diff: also show the diff between patches

Hi Thomas, On Sun, 12 Aug 2018, Thomas Gummerer wrote: > On 08/10, Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin > > > > [..] > > > > @@ -13,15 +14,38 @@ NULL > > int cmd_range_diff(int argc, const char **argv, const char *prefix) > > { > > int creation_factor

Re: [PATCH v5 05/21] range-diff: also show the diff between patches

Hi Dscho, On 08/10, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > [..] > > @@ -13,15 +14,38 @@ NULL > int cmd_range_diff(int argc, const char **argv, const char *prefix) > { > int creation_factor = 60; > + struct diff_options diffopt = { NULL }; >

[PATCH v5 05/21] range-diff: also show the diff between patches

From: Johannes Schindelin Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner. An alternative would be to display an interdiff, i.e. the hypothetical diff which is the result of first

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

Hi Eric, On Fri, 10 Aug 2018, Eric Sunshine wrote: > On Fri, Aug 10, 2018 at 5:12 PM Johannes Schindelin > wrote: > > On Mon, 30 Jul 2018, Eric Sunshine wrote: > > > I think you can attain the desired behavior by making a final > > > parse_options() call with empty 'options' list after the call

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On Fri, Aug 10, 2018 at 5:12 PM Johannes Schindelin wrote: > On Mon, 30 Jul 2018, Eric Sunshine wrote: > > I think you can attain the desired behavior by making a final > > parse_options() call with empty 'options' list after the call to > > diff_setup_done(). It's pretty much a one-line fix, but

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

> > > > > > > git range-diff --no-patches > > > > fatal: single arg format requires a symmetric range > > > > > > > I immediately thought of testing for a leading `-` of the remaining > > > argument, but I could imagine that some

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

gt; > > > wrote: > > > > > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > > > > > Just like tbdiff, we now show the diff between matching patches. > > > > > > This is > > > > > > a "diff of two diffs&q

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On Mon, Jul 30, 2018 at 5:26 PM Thomas Gummerer wrote: > On 07/30, Johannes Schindelin wrote: > > On Sun, 29 Jul 2018, Thomas Gummerer wrote: > > > There's one more thing that I noticed here: > > > > > > git range-diff --no-patches > > > fatal:

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

hindelin via GitGitGadget wrote: > > > > > Just like tbdiff, we now show the diff between matching patches. This > > > > > is > > > > > a "diff of two diffs", so it can be a bit daunting to read for the > > > > > beginner. >

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

Hi Thomas & Eric, On Sun, 29 Jul 2018, Thomas Gummerer wrote: > On 07/29, Eric Sunshine wrote: > > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer > > wrote: > > > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > > > Just like tbdiff, we no

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On 07/29, Eric Sunshine wrote: > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer wrote: > > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > > Just like tbdiff, we now show the diff between matching patches. This is > > > a "diff of two diffs"

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer wrote: > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > Just like tbdiff, we now show the diff between matching patches. This is > > a "diff of two diffs", so it can be a bit daunting to read for the > > be

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginner. > > An alternative w

Re: [PATCH 4/5] coccinelle: put sane filenames into output patches

On 7/23/2018 9:50 AM, SZEDER Gábor wrote: Coccinelle outputs its suggested transformations as patches, whose header looks something like this: --- commit.c +++ /tmp/cocci-output-19250-7ae78a-commit.c Note the lack of 'diff --opts ' line, the differing number of path components

[PATCH 4/5] coccinelle: put sane filenames into output patches

Coccinelle outputs its suggested transformations as patches, whose header looks something like this: --- commit.c +++ /tmp/cocci-output-19250-7ae78a-commit.c Note the lack of 'diff --opts ' line, the differing number of path components on the --- and +++ lines, and the nonsensical filename

[PATCH v4 05/21] range-diff: also show the diff between patches

From: Johannes Schindelin Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner. An alternative would be to display an interdiff, i.e. the hypothetical diff which is the result of first

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

Jeff Felchner writes: > Hey all, I assumed this was going to be in 2.18, but I'm still having the > same issue. What's the plan for release of this? You assumed wrong ;-) A patch written on June 11th that is already deep into pre-release freeze, unless it is about fixing a regression during

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

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 > introduced empty lines at the end when editing the patch. However this >

Re: [PATCH v2 0/4] Automatic transfer encoding for patches

LGTM, thanks for the v2.

[PATCH v2 0/4] Automatic transfer encoding for patches

This series introduces an "auto" value for git send-email --transfer-encoding that uses 8bit when possible (i.e. when lines are 998 octets or shorter) and quoted-printable otherwise; it then makes this the default behavior. It also makes --validate aware of transfer encoding so it doesn't

Re: [PATCH 0/3] Automatic transfer encoding for patches

Overall this series looks good. Thanks for putting the patches together!

[PATCH 0/3] Automatic transfer encoding for patches

r encoding so it doesn't complain when using quoted-printable or base64. git am already understands how to handle patches in any valid transfer encoding. As a result of this series, we always produce MIME messages with a Content-Transfer-Encoding header. I don't think this will cause an

Two small l10n/i18n patches (resend)

(I'm not subscribed, please keep me in CC. Resending as suggested by Duy Nguyen in the hope that my patches get picked this time) Hello, I was reviewing the output of "git bisect" with my French locale and I saw a clear mistake in the French translation (fixed in the first commit)

[PATCH v3 05/20] range-diff: also show the diff between patches

From: Johannes Schindelin Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner. An alternative would be to display an interdiff, i.e. the hypothetical diff which is the result of first

Two small l10n/i18n patches

the locale is properly hardcoded in the test suite. In any case, "make test" is still working after those two commits. Thank you for considering my patches. I leave it tho the regular translators to add translations for the newly added strings.

[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] add -p: fix counting empty context lines in edited patches

On Mon, Jun 4, 2018 at 6:08 AM, Phillip Wood wrote: > On 01/06/18 21:03, Eric Sunshine wrote: >> On Fri, Jun 1, 2018 at 1:46 PM, Phillip Wood >> wrote: >>> + } elsif ($mode eq ' ' or $_ eq "\n") { >> >> Based upon a very cursory read of parts of git-add-interactive.perl, >> do I

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

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

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 to start with a space, empty lines are not counted. This > was

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

On Fri, Jun 1, 2018 at 10:46 AM, Phillip Wood wrote: > 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, em

[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: 2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Todd, it looks like that may very well be the same issue. And it looks like it's planning on being fixed in the next release? Would that be 2.17.1 since it's a regression? > On 2018 May 26, at 16:07, Todd Zullinger wrote: > > Hi Jeff, > > Jeff Felchner wrote: >> Ever since

Re: 2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Hi Jeff, Jeff Felchner wrote: > Ever since 2.17.0, when saving a patch (using add --patch > but probably other ways as well), if the whitespace is > removed from the initial column, the patch doesn't apply. This sounds a bit like the issue discussed in this thread a few weeks ago:

2.17.0 Regression When Adding Patches Without Whitespace In Initial Column

Ever since 2.17.0, when saving a patch (using add --patch but probably other ways as well), if the whitespace is removed from the initial column, the patch doesn't apply. Full walkthrough (including comparison with 2.16.3) in the video attached to this link:

Re: [PATCH v2 05/18] branch-diff: also show the diff between patches

Hi Buga, On Sun, 6 May 2018, Igor Djordjevic wrote: > On 04/05/2018 17:34, Johannes Schindelin wrote: > > Just like tbdiff, we now show the diff between matching patches. This is > > a "diff of two diffs", so it can be a bit daunting to read for the > > beginner

Re: [PATCH v2 05/18] branch-diff: also show the diff between patches

Hi Johannes, On 04/05/2018 17:34, Johannes Schindelin wrote: > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginner. > > And just like tbdiff, we now also accept the `--no

[PATCH v2 05/18] branch-diff: also show the diff between patches

Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner. And just like tbdiff, we now also accept the `--no-patches` option (which is actually equivalent to the diff option `-s`). This brings b

Re: [PATCH 05/18] branch-diff: also show the diff between patches

Hi Eric, On Thu, 3 May 2018, Eric Sunshine wrote: > On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > Just like tbdiff, we now show the diff between matching patches. This is > > a "diff of two diffs", s

Re: [PATCH 05/18] branch-diff: also show the diff between patches

On Thu, May 3, 2018 at 10:51 PM, Eric Sunshine wrote: > On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin > wrote: >> Note: while we now parse diff options such as --color, the effect is not >> yet the same as in tbdiff, where also the

Re: [PATCH 05/18] branch-diff: also show the diff between patches

On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginnger. s/beginnger/beginner/

[PATCH 05/18] branch-diff: also show the diff between patches

Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginnger. This brings branch-diff closer to be feature-complete with regard to tbdiff. An alternative would be to display an inte

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

Hi Junio, On Wed, 25 Apr 2018, Junio C Hamano wrote: > I really want to see that the runtime prefix stuff mature enough during > this cycle, so these follow-up patches are all very much appreciated. FWIW I merged these patches (including my touch-ups) into Git for Windows' `master` branch

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

est base branch for > patches that do not apply cleanly on `master` but require more stuff from > `next`/`pu`. The easiest is to leave that to the maintainer most of the time, as that is what maintainers do. Thanks. I really want to see that the runtime prefix stuff mature enough during this c

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

Basing your work on the tip of 'next' is good for discussion, but > >> not readily usable for final application. Let me see if I can > >> untangle the dependents to come up with a reasonable base. > > > > I'll queue this on top of a merge of 'dj/runtime-prefix' into 'master'.

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

application. Let me see if I can >> untangle the dependents to come up with a reasonable base. > > I'll queue this on top of a merge of 'dj/runtime-prefix' into 'master'. > Merging the resulting topic into 'next' and applying these patches > directly on top of 'next' result in i

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

p with a reasonable base. I'll queue this on top of a merge of 'dj/runtime-prefix' into 'master'. Merging the resulting topic into 'next' and applying these patches directly on top of 'next' result in identical trees, of course ;-)

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > We carried a slightly different version of the git_setup_gettext() patch > (which took care of releasing the buffer allocated by system_path()), > and we carry two more patches that touch the same area, so now that > dj/

Some mutt(1) patches and scripts

Hi, I have spent more time contributing to the Git list lately, and as such have grown a number of patches and scripts that have been useful for my workflow. I am interested in sharing them here in the hopes that they will be useful for others as well :-). My workflow is as follows: 1. Write

[PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

We carried a slightly different version of the git_setup_gettext() patch (which took care of releasing the buffer allocated by system_path()), and we carry two more patches that touch the same area, so now that dj/runtime-prefix hit `next`, it seems a good time to contribute those, too. Changes

[PATCH 0/3] Some add-on patches on top of dj/runtime-prefix

We carried a slightly different version of the git_setup_gettext() patch (which took care of releasing the buffer allocated by system_path()), and we carry two more patches that touch the same area, so now that dj/runtime-prefix hit `next`, it seems a good time to contribute those, too. Johannes

Re: Git send-email not sending email patches as subsequent replies

David Davis wrote: > I'm seeing 6 individual emails, how do I just see one email followed by 5 > email replies to the one? I don't want six individual emails. The five email replies you want are still individual emails. Emails are ALWAYS "individual", and reply

Re: Git send-email not sending email patches as subsequent replies

[PATCH 2/5] [PATCH 3/5] [PATCH 4/5] [PATCH 5/5] Is that not what you're seeing? You're quoting the manpage for --in-reply-to option below, but you're not using that option. > So for example when --thread and --no-chain-reply-to are specified, > the second and subsequent patches wil

Git send-email not sending email patches as subsequent replies

replies as suggested on https://git-scm.com/docs/git-send-email below: So for example when --thread and --no-chain-reply-to are specified, the second and subsequent patches will be replies to the first one like in the illustration below where [PATCH v2 0/3] is in reply to [PATCH 0/2]: [PATCH 0/2] Here

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

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

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

On 01/03/18 20:14, Junio C Hamano wrote: > Phillip Wood 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 >>

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

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 adjust the offsets of subsequent

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

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

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

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

Re: [PATCH v2 0/2] two small grep patches

On Fri, Feb 23, 2018 at 03:47:55PM +0100, Rasmus Villemoes wrote: > Changes in v2: > > - Drop patch 3 with dubious gain/complexity ratio > - Add comments regarding ownership of grep_source > > I was a little torn between copy-pasting the comment or just saying > "see above" in the second case.

[PATCH v2 0/2] two small grep patches

Changes in v2: - Drop patch 3 with dubious gain/complexity ratio - Add comments regarding ownership of grep_source I was a little torn between copy-pasting the comment or just saying "see above" in the second case. I think a memset would be confusing, at least unless one extends the comment to

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

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

Re: [PATCH 0/3] a few grep patches

On 02/15, Rasmus Villemoes wrote: > I believe the first two should be ok, but I'm not sure what I myself > think of the third one. Perhaps the saving is not worth the > complexity, but it does annoy my optimization nerve to see all the > unnecessary duplicated work being done. I agree, the first

  1   2   3   4   5   6   7   >