a comment is in-between the
two parts but I wasn't happy so I just dropped it.
Cc: Rob Herring
Cc: Frank Rowand
Signed-off-by: Stephen Boyd
---
Changes from v2:
* Updated test to be really multiline.
Changes from v1:
* Added a new boolean property unit test
* Updated the regex to
Quoting Johannes Sixt (2019-10-16 14:10:09)
> [Removed bouncing addresses of Matthieu Moy and William Duclot from Cc]
>
> Am 16.10.19 um 22:32 schrieb Stephen Boyd:
> > diff --git a/t/t4018/dts-nodes-multiline-prop
> > b/t/t4018/dts-nodes-multiline-prop
> > new
a comment is in-between the
two parts but I wasn't happy so I just dropped it.
Cc: Rob Herring
Cc: Frank Rowand
Signed-off-by: Stephen Boyd
---
Changes from v1:
* Added a new boolean property unit test
* Updated the regex to simplify multi-line property skipping
* Added some space to
Quoting Johannes Sixt (2019-10-12 05:54:00)
> Am 08.10.19 um 16:43 schrieb Stephen Boyd:
> > Quoting Johannes Sixt (2019-10-05 07:09:11)
> >> Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> >>> --- /dev/null
> >>> +++ b/t/t4018/dt
Quoting Johannes Sixt (2019-10-05 07:09:11)
> Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> > While reviewing some dts diffs recently I noticed that the hunk header
> > logic was failing to find the containing node. This is because the regex
> > doesn't consider propert
a comment is in-between the
two parts but I wasn't happy so I just dropped it.
Cc: Rob Herring
Cc: Frank Rowand
Signed-off-by: Stephen Boyd
---
t/t4018/dts-nodes-multiline-prop | 12
t/t4018/dts-root | 2 +-
t/t4018/dts-root-comment | 8
ases/latest
Cc: Rob Herring
Cc: Frank Rowand
Signed-off-by: Stephen Boyd
---
Changes from v2:
* Added a few more tests for comments after and before {
* Added a root node test
* Support for root node (/) in the regex
* Simplified regex per Johannes' feedback
* Sprinkled some newline
Quoting Johannes Sixt (2019-08-19 11:40:47)
> Am 17.08.19 um 00:56 schrieb Stephen Boyd:
> > The Linux kernel receives many patches to the devicetree files each
> > release. The hunk header for those patches typically show nothing,
> > making it difficult to figure out what n
'dts' pattern to git so that users can get better diff
output on dts files when they use the diff=dts driver.
The regex has been constructed based on the spec at devicetree.org[1]
[1] https://github.com/devicetree-org/devicetree-specification/releases/latest
Cc: Rob Herring
Signed-off-b
(Sorry for weird reply, I'm not subscribed and my MUA is not prepared
for this)
> Change the git-send-email command-line argument parsing and config
> reading code to parse those two in the right order. I.e. first we set
> our hardcoded defaults, then we read our config, and finally we read
> the
Quoting Junio C Hamano (2019-05-06 21:38:24)
> Stephen Boyd writes:
>
> > I wonder if we need to make some other sort of form of
> > "prerequisite-patch-id:" here and let that be a legacy form of the
> > patch-id so that users know that they have a fix
n get the same
hash when we're generating patch-ids for 'format-patch --base=' types of
command invocations.
Cc: Xiaolong Ye
Signed-off-by: Stephen Boyd
---
I wonder if we need to make some other sort of form of
"prerequisite-patch-id:" here and let that be a legacy form of
stable. Update the documentation as well.
Cc: Xiaolong Ye
Signed-off-by: Stephen Boyd
---
Documentation/git-format-patch.txt | 2 +-
t/t4014-format-patch.sh| 36 +-
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-format-pa
Quoting Alban Gruin (2019-01-13 13:26:21)
> Hi Stephen,
>
> thank you for your patch. I left a few comments below.
>
> Le 11/01/2019 à 22:51, Stephen Boyd a écrit :
> > diff --git a/userdiff.c b/userdiff.c
> > index 97007abe5b16..2bc964e11089 100644
> > ---
'dts' pattern to git so that users can get better diff
output on dts files when they use the diff=dts driver.
The regex has been constructed based on the spec at devicetree.org[1]
[1] https://github.com/devicetree-org/devicetree-specification/releases/latest
Cc: Rob Herring
Signed-off-b
(replying from webmail interface)
On Fri, Sep 5, 2014 at 3:25 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Redoing what e3f67d30 (am: fix patch format detection for
>> Thunderbird "Save As" emails, 2010-01-25) tried to do without
>> wasting a fork and a pipe may be a workable improvem
On 05/09/13 08:10, René Scharfe wrote:
> Am 06.05.2013 22:16, schrieb Stephen Boyd:
>> Ok. I tested it and it definitely helps.
>>
>> ==10728== LEAK SUMMARY:
>> ==10728==definitely lost: 316,355,458 bytes in 8,652 blocks
>> ==10728==indirectly lost: 1,327,2
On 04/30/13 15:47, René Scharfe wrote:
> Am 30.04.2013 02:11, schrieb Stephen Boyd:
>> (resending since the attachment seems to make vger sad)
>>
>> Hi,
>>
>> I'm running git rev-list | git cherry-pick --stdin on a range of about
>> 300
On 04/30/13 15:47, René Scharfe wrote:
> Am 30.04.2013 02:11, schrieb Stephen Boyd:
>> (resending since the attachment seems to make vger sad)
>>
>> Hi,
>>
>> I'm running git rev-list | git cherry-pick --stdin on a range of about
>> 300
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork() for commit: Cannot allocate memory
Running valgrind shows me that the tree traversal code
On 02/11/13 20:27, Stephen Boyd wrote:
> I ran into these bugs the other day and didn't have time to
> investigate further. So I wrote test cases for them instead.
>
> Stephen Boyd (2):
> t3501: Expose bug with cherry-pick into dirty trees w/ renames
> t3501: Exp
Hi,
I was trying git am -3 with a patch that touched files that didn't exist
in the branch I was on. Obviously it failed badly, so I wanted to abort
out of the git am state with git am --abort. Unfortunately, it seems
that git am --abort in this scenario fails with this error:
error: cache entry
: Stephen Boyd
---
t/t3501-revert-cherry-pick.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 6f489e2..eef4d8c 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -109,4
I ran into these bugs the other day and didn't have time to
investigate further. So I wrote test cases for them instead.
Stephen Boyd (2):
t3501: Expose bug with cherry-pick into dirty trees w/ renames
t3501: Expose addinfo_cache error message in cherry-pick
t/t3501-revert-cherry-pi
ile
that was still dirty after the cherry-pick.
error: addinfo_cache failed for path 'otherfile'
I suspect this error message shouldn't be printed, so recreate
the problem in t3501 so that it can be fixed.
Signed-off-by: Stephen Boyd
---
t/t3501-revert-cherry-pick.sh
fail with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Suggested-by: Jeff King
Signed-off-by: Stephen Boyd
---
gpg-interface.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gp
On 01/30/13 21:50, Jeff King wrote:
>
> The strbuf_read above will read to EOF, so it should be equivalent (and
> IMHO slightly more readable) to do:
>
> diff --git a/gpg-interface.c b/gpg-interface.c
> index 0863c61..5f142f6 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -130,8 +130,1
On 01/31/13 08:24, Junio C Hamano wrote:
> Stephen Boyd writes:
>
>> While debugging an error with verify_signed_buffer() the error
>> messages from run-command weren't very useful:
>>
>> error: cannot create pipe for gpg: Too many open files
>> err
d to be created in the error message so we
can more easily debug similar problems in the future.
For example, the above error now prints:
error: cannot create stderr pipe for gpg: Too many open files
error: could not run gpg.
Signed-off-by: Stephen Boyd
---
run-command.c | 8 ++--
1
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Signed-off-by: Stephen Boyd
---
gpg-interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 2c0bed3..474c037 100644
While running --show-signatures on the linux kernel I noticed that after
a while git failed with an error message indicating it had run out of
file descriptors. The first patch fixes this problem, and the next
two are randmom bits since I was in the area.
Stephen Boyd (3):
gpg: Close stderr
fail with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Signed-off-by: Stephen Boyd
---
gpg-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gpg-interface.c b/gpg-interface.c
index 0
The pretty formats for GPG signatures were introduced but never
documented. Use the documentation from the commit that introduced them.
Do the same for the --show-signature option added to git log and
friends.
Signed-off-by: Stephen Boyd
---
I had to google for --show-signature one too many
read without replying to anything, and it is
> valid to leave $initial_reply_to empty.
>
> An earlier update to avoid y...@example.com stuffed in address fields
> did not take these two cases into account.
>
> Noticed and fix suggested by Stephen Boyd.
>
> Signed-off-by: Junio C
On Thu, Sep 6, 2012 at 1:03 PM, Junio C Hamano wrote:
>
> If you let $to to go empty with the first hunk of your patch, where
> does the mail eventually go? Does anybody later in the code decide
> to add some recipient? If there is a reason why an empty input is a
> valid here, I think there is
(Sorry sending this from web interface)
On Wed, Sep 5, 2012 at 8:29 PM, Junio C Hamano wrote:
> Stephen Boyd writes:
>> This is now bugging me if I just hit enter and don't want to specify
>> anything for
>> these headers (I want the defaults or what's in the
On Tue, Aug 14, 2012 at 3:25 PM, Junio C Hamano wrote:
> @@ -745,13 +752,15 @@ sub file_declares_8bit_cte {
> if (!defined $sender) {
> $sender = $repoauthor || $repocommitter || '';
> $sender = ask("Who should the emails appear to be from? [$sender] ",
> - def
Can we throw up a big warning or just outright fail if someone types
'n' or 'y' and hits enter for the in-reply-to question in
git-send-email? I saw a git-send-email sent patch with an In-Reply-To
header containing n on lkml today and it makes threading in my mail
client get confused.
https://lkml
38 matches
Mail list logo
