On Wed, Nov 15, 2023 at 09:49:31AM -0800, Kees Cook wrote:
> On Wed, Nov 15, 2023 at 06:03:30PM +0100, Borislav Petkov wrote:
> > From: "Borislav Petkov (AMD)"
> >
> > After receiving a second patchset this week without knowing which tree
> > it applies on and trying to apply it on the obvious on
On 09/27, Beyondhorizon Zheng wrote:
> [git issue] git am failed for patches of converting the file format of
> source codes from dos to unix
>
> Git version: git version 2.23.0
> Host PC: ubuntu 16.04.10
> Reporter: Shuang Zheng
>
> I have submitted a patch which co
[git issue] git am failed for patches of converting the file format of
source codes from dos to unix
Git version: git version 2.23.0
Host PC: ubuntu 16.04.10
Reporter: Shuang Zheng
I have submitted a patch which convert the file format of source file
from dos to unix with command:
dos2unix misc
This is another set of patches from Git for Windows' fork that have been
sitting there since 2010, providing cross-platform GUI helpers to ask the
user a question or allow typing in a password.
This patch series was first submitted as
https://github.com/patthoyts/git-gui/pull/5 which was ig
On 19/09/19 12:11PM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> > On 19/09/19 11:47AM, Denton Liu wrote:
> > > For the record, you could do a
> > >
> > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6
> > >
> > > to bring them over instead of
On Thu, Sep 19, 2019 at 12:11:05PM -0700, Denton Liu wrote:
> > > For the record, you could do a
> > >
> > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6
I forgot one more thing, if you end up doing this, you should probably
sign-off on your cherry-picks by doing `-s`.
On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> On 19/09/19 11:47AM, Denton Liu wrote:
> > On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> > > Hi Junio,
> > >
> > > On 18/09/19 10:49AM, Junio C Hamano wrote:
> > > > Pratyush Yadav writes:
> > > > You should be
On 19/09/19 11:47AM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> > Hi Junio,
> >
> > On 18/09/19 10:49AM, Junio C Hamano wrote:
> > > Pratyush Yadav writes:
> > > You should be able to merge this (and all other git-gui topics
> > > already in my tree Dent
On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> Hi Junio,
>
> On 18/09/19 10:49AM, Junio C Hamano wrote:
> > Pratyush Yadav writes:
> > You should be able to merge this (and all other git-gui topics
> > already in my tree Denton pointed out) to your 'master'. If you
> > then ma
Hi Junio,
On 18/09/19 10:49AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
> You should be able to merge this (and all other git-gui topics
> already in my tree Denton pointed out) to your 'master'. If you
> then make a trial merge of the result back into my tree with "git
> merge -Xsubtree=g
On 18/09/19 10:49AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > Assuming I have git.git cloned in ../git (relative to git-gui.git), I
> > ran:
> >
> > git pull -Xsubtree=git-gui ../git $branches
> >
> > instead of:
> >
> > git merge $branches
> >
> > because git-gui's tree doesn't
Pratyush Yadav writes:
> Assuming I have git.git cloned in ../git (relative to git-gui.git), I
> ran:
>
> git pull -Xsubtree=git-gui ../git $branches
>
> instead of:
>
> git merge $branches
>
> because git-gui's tree doesn't have those commits and branches yet, so
> we can't merge straight
but directly to git.
Thanks for noticing.
I do recall forking Pat's tree, applying a few patches and pulling
the result to git itself while asking Pat to pull from me to get
these patches. Perhaps these were not merged back before Pratyush
inherited the tree.
On Wed, Sep 18, 2019 at 08:44:04PM +0530, Pratyush Yadav wrote:
> On 18/09/19 02:27AM, Denton Liu wrote:
> > On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
> > > Hi Pratyush,
> > >
> > >
> > > I was comparing your git-gui repo[1] with the source code of
> > > git/git-gui
On 18/09/19 02:27AM, Denton Liu wrote:
> On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
> > Hi Pratyush,
> >
> >
> > I was comparing your git-gui repo[1] with the source code of
> > git/git-gui[2]. There seems to be a couple of things missing.
> >
> > For example, I cre
On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
>
> I was comparing your git-gui repo[1] with the source code of
> git/git-gui[2]. There seems to be a couple of things missing.
>
> For example, I created a patch back in March 2018[3]. Junio pulled it
> s
Hi Pratyush,
I was comparing your git-gui repo[1] with the source code of
git/git-gui[2]. There seems to be a couple of things missing.
For example, I created a patch back in March 2018[3]. Junio pulled it
so the changes are really there in git/git-gui/git-gui.sh (see this[4]
line). This was whi
On Mon, 16 Sep 2019 at 22:46, Johannes Sixt wrote:
>
> Am 16.09.19 um 21:58 schrieb Junio C Hamano:
> > I wonder if the result becomes even clearer if we dropped "instead
> > of the usual output". It is a given that presence of an option
> > would change the behaviour, so "instead of the usual" d
tch introduces, but the objective of this patch is clarify about
> the generation of output in patch format, so...
You have a point here, too.
Below is v2 of just patch 1/2. 2/2 remains unchanged. I've added
git-show to the enumeration.
--- 8< ---
diff, log doc: say "patch text"
0.10 (on top of brian's
> recent patch so that it builds to begin with). They all render this
> nicely.
>
> Both of these patches seem like good changes to me.
Thanks, both. I am neutral between "patch" and "patch text", but if
the latter is more easi
hat it builds to begin with). They all render this
nicely.
Both of these patches seem like good changes to me.
Martin
A poster on Stackoverflow was confused that the documentation of git-log
promised to generate "patches" or "patch files" with -p, but there were
none to be found. Rewrite the corresponding paragraph to talk about
"patch text" to avoid the confusion.
Shorten the langu
find "The source of this book
is hosted on GitHub. Patches, suggestions and comments are
welcome." 'hosted on GitHub' has link. Click.
2. We are taken to github.com/progit/progit2; among the list of
files, I see CONTRIBUTING.md, which sounds promising. Click.
3.
At this page (in Russian)
https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%BE%D0%B4%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8
I see:
вы рассмотрим
I expected:
мы рассмотрим
And I fail to find the exact file to fix. I fail to find
On 25/07/19 5:04 PM, Christian Couder wrote:
Hi Pratyush,
On Wed, Jul 24, 2019 at 11:43 PM Pratyush Yadav wrote:
I have a quick little feature to add to git-gui, and I'm wondering where
should I discuss it and send patches. The git-gui repo [0] has no readme
I can see that would point
Hi,
On Wed, 24 Jul 2019, Pratyush Yadav wrote:
> I have a quick little feature to add to git-gui, and I'm wondering
> where should I discuss it and send patches. The git-gui repo [0] has
> no readme I can see that would point me in the right direction.
> Googling around didn&
Hi Pratyush,
On Wed, Jul 24, 2019 at 11:43 PM Pratyush Yadav wrote:
>
> I have a quick little feature to add to git-gui, and I'm wondering where
> should I discuss it and send patches. The git-gui repo [0] has no readme
> I can see that would point me in the right direction
Hi,
I have a quick little feature to add to git-gui, and I'm wondering where
should I discuss it and send patches. The git-gui repo [0] has no readme
I can see that would point me in the right direction. Googling around
didn't get me anything either.
Should I send it here on this
Am 12.06.19 um 17:03 schrieb Shawn Landden:
> If a patch has been applied upstream AND THEN reverted, rebase still
> drops the patch, requiring the use of relative rebase git rebase -i
> HEAD~5 et cetera.
>
> git rebase should detect reverts as well.
You have the same patch that upstream has. Per
If a patch has been applied upstream AND THEN reverted, rebase still
drops the patch, requiring the use of relative rebase git rebase -i
HEAD~5 et cetera.
git rebase should detect reverts as well.
-Shawn Landden
sense to encourage proper separation of
> >> concerns: to keep patches that introduce regression tests demonstrating a
> >> breakage separate from patches that fix the breakage. It would certainly
> >> help me (e.g. when staring at a range diff).
> >
> > Then per
ding to, Dscho made it sound as if I am
reviewing only from my MUA, but most of my reviews are done after
the patches are tentatively applied (it is a separate issue if the
result is found worth keeping and merged to 'pu'), so our workflows
are not so different. It is not like "must h
Duy Nguyen writes:
> On Thu, Mar 14, 2019 at 9:10 PM Johannes Schindelin
> wrote:
>> In any case, before we get better tooling to work around these issues, I
>> still think it makes a ton of sense to encourage proper separation of
>> concerns: to keep patches that in
On Thu, Mar 14, 2019 at 9:10 PM Johannes Schindelin
wrote:
> In any case, before we get better tooling to work around these issues, I
> still think it makes a ton of sense to encourage proper separation of
> concerns: to keep patches that introduce regression tests demonstrating a
&
ite space review", i.e. focusing on problems that can be
seen from the diff, but that are really of little consequence when it
comes to the health of our code base?
What it boils down to: it needs to be easier to pull down patches and to
recreate local branches for them.
It is in this
On Thu, Feb 07 2019, Jeff King wrote:
> On Wed, Feb 06, 2019 at 11:20:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> >> So far we've had the convention that these GIT_TEST_* variables,
>> >> e.g. the one for the commit graph, work the same way. Thus we guarantee
>> >> that we get (in theory) 10
On Wed, Feb 06, 2019 at 11:20:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> So far we've had the convention that these GIT_TEST_* variables,
> >> e.g. the one for the commit graph, work the same way. Thus we guarantee
> >> that we get (in theory) 100% coverage even when running the tests in
> >>
On Wed, Feb 06 2019, Jeff King wrote:
> On Wed, Feb 06, 2019 at 10:52:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > I wonder if it would be more obvious what's going on if we instead had a
>> > prereq like:
>> >
>> > test_expect_success !PROTO_V2 'ls-remote --symref' '
>> > ...
>> >
On Wed, Feb 06, 2019 at 10:52:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I wonder if it would be more obvious what's going on if we instead had a
> > prereq like:
> >
> > test_expect_success !PROTO_V2 'ls-remote --symref' '
> > ...
> > '
> >
> > and just skipped those tests entirely (
the final patch, this
> all seems pretty sane to me from a quick look.
>
> There is one thing that your test patches made me wonder. When we have
> to make an exception to a test (i.e., that doesn't work under v2), you
> do it by unsetting GIT_TEST_PROTOCOL_VERSION in the envi
that most of the branches have been merged to master, I
> have rebased it on master. The only branch that I needed to merge was
> js/protocol-advertise-multi.
Thanks for working on this. With the exception of the final patch, this
all seems pretty sane to me from a quick look.
There is one thing
the rebase, this is unchanged from [1]. There is some discussion
there between Ævar, Junio, and I, thinking that it is OK to merge this
even if we didn't eliminate all errors. Right now, only 3 test cases
fail with GIT_TEST_PROTOCOL_VERSION=2.
Patch 1 implements the test variable, patches 2-7
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 a/arch/x8
Æ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 ju
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/
>>
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 leadin
uot; 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.
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
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 n
&the_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 dif
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
read_index() with &the_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
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
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
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
nelle/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/)
> > se
efile: 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"?
>
> >
/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
ot;Makefile: 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
0644
--- 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
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.
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(&sb, "fixed string"), but
use oid_to_hex(&oid) or strbuf_addstr(
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
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&#
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 th
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
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
aking 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 _co
> related 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 "
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 bef
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
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 seems
t; chance 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 ser
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
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
&
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
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
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,
w
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 "git
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 rev
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
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 };
>
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 rev
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
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
> > >
> > > > 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
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", so i
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
> > > f
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.
>
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
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", so it
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
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
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 compone
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 nonsensica
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 rev
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 t
:
> 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
&g
LGTM, thanks for the v2.
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 complain
1 - 100 of 670 matches
Mail list logo
