From: Matthew Wilcox
If you have a base-64 encoded patch with CRLF endings (as produced
by forwarding a patch from Outlook to a Linux machine, for example),
the keep_cr setting is not honoured because keep_cr is only passed
to mailsplit, which does not look through the encoding. The keep_cr
logi
From: Matthew Wilcox
Extend the --scissors mechanism to strip off the preamble created by
forwarding a patch. There are a couple of extra headers ("Sent" and
"To") added by forwarding, but other than that, the --scissors option
will now remove patches forwarded from Microsoft Outlook to a Linux
I'm not at all attached to changing all of them, just figured it made
sense while I was here.
Would a patch that changes only:
git-add--interactive.perl | 2 +-
git-archimport.perl | 2 +-
git-cvsexportcommit.perl | 2 +-
git-cvs
[plain text re-send, sorry]
Interesting, I'm guessing this came from when git was installed (
https://github.com/Homebrew/homebrew-core/blob/master/Formula/git.rb#L50
), when the perl path was likely still /usr/bin/perl
It feels weird to me that the perl path is fixed at
compile/install-time as o
On Wed, Jan 11, 2017 at 02:11:42PM -0800, Junio C Hamano wrote:
> > It's actually kind of ugly. For instance, a failing test in
> > t3600 now produces:
> >
> >error: the following files have staged content different from both the
> >error: file and the HEAD:
> >error: bar.txt
> >
Am 12.01.2017 um 06:51 schrieb Pat Pannuto:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index cf6fc926a..6d7b6c35d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/env perl
This change, and all others that
Pat Pannuto writes:
> I spent a little while debugging why git-format-patch refused to believe
> that SSL support was installed (Can't locate Net/SMTP/SSL.pm in @INC...)
> Turns out that it was installed for my system's preferred /usr/local/bin/perl,
> but not for git-format-patch's hard-coded /u
Depending on system configuration, /usr/bin/perl may not be the
preferred perl interpreter, use /usr/bin/env perl to invoke perl
instead to repsect user preferences.
In most cases this will not matter as any perl install will work,
but for applications such as git-format-patch, which may require
p
I spent a little while debugging why git-format-patch refused to believe
that SSL support was installed (Can't locate Net/SMTP/SSL.pm in @INC...)
Turns out that it was installed for my system's preferred /usr/local/bin/perl,
but not for git-format-patch's hard-coded /usr/bin/perl; changing the sheb
This commit is in preparation for converting all shebangs to use 'env'
instead of a fixed perl path, which will not allow for arguments to 'perl'.
Signed-off-by: Pat Pannuto
---
Documentation/cat-texi.perl | 4 +++-
Documentation/cmd-list.perl | 4 +++-
Documentation/fix-texi.perl
On 01/10/2017 10:35 AM, Jeff King wrote:
> On Sun, Jan 08, 2017 at 10:52:25AM +0100, Michael Haggerty wrote:
>> [...]
Since my last email, I have implemented a bunch of what we discussed
[1]. Because of the new semantics, I also *renamed the main command* from
git test range [...]
to
gi
From: Jacob Keller
Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated
list of strings. However, this was not documented in the
api-parse-options documentation. Add documentation now so that future
developers ma
From: Jacob Keller
Teach `--match` to be accepted multiple times, accumulating a list of
patterns to match into a string list. Each pattern is inclusive, such
that a tag need only match one of the provided patterns to be
considered for matching.
This extension is useful as it enables more flexib
From: Jacob Keller
Extend name-rev further to support matching refs by adding `--discard`
patterns. These patterns will limit the scope of refs by discarding any
ref that matches at least one discard pattern. Checking the discard refs
shall happen first, before checking the include --refs pattern
From: Jacob Keller
Teach git-describe the `--discard` option which will allow specifying
a glob pattern of tags to ignore. This can be combined with the
`--match` patterns to enable more flexibility in determining which tags
to consider.
For example, suppose you wish to find the first official r
From: Jacob Keller
Teach git describe and git name-rev the ability to match multiple
patterns inclusively. Additionally, teach these commands to also accept
negative patterns to discard any refs which match.
The pattern lists for positive and negative patterns are inclusive. This
means that for
From: Jacob Keller
Teach git name-rev to take a string list of patterns from --refs instead
of only a single pattern. The list of patterns will be matched
inclusively, such that a ref only needs to match one pattern to be
included. If a ref will only be excluded if it does not match any of the
pa
In the future we want to support working tree operations within submodules,
e.g. "git checkout --recurse-submodules", which will update the submodule
to the commit as recorded in its superproject. In the submodule the
unpack-tree operation is carried out as usual, but the reporting to the
user need
On Wed, Jan 11, 2017 at 3:28 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Preparing the expected output "expect" outside test_expect_success
>>> block is also old-school. Move it inside the new test?
>>
>> I looked into that. What is our current stance on using single/double quotes?
>
On Tue, Jan 10, 2017 at 12:49 AM, Karthik Nayak wrote:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 34cd61cd9..f293ee5b0 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -37,11 +37,11 @@ static unsigned char head_sha1[20];
> static int branch_use_color = -1;
> static c
Stefan Beller writes:
>> Preparing the expected output "expect" outside test_expect_success
>> block is also old-school. Move it inside the new test?
>
> I looked into that. What is our current stance on using single/double quotes?
Using dq around executable part, i.e.
test_expect_succ
On Wed, Jan 11, 2017 at 1:32 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Add support for the super-prefix option for commands that unpack trees.
>> For testing purposes enable it in read-tree, which has no other path
>> related output.
>
> "path related output"? I am not sure I unders
Jeff King writes:
> On Wed, Jan 11, 2017 at 09:01:38AM -0500, Jeff King wrote:
>
>> [1/2]: Revert "vreportf: avoid intermediate buffer"
>> [2/2]: vreport: sanitize ASCII control chars
>
> We've talked before about repeating the "error:" header for multi-line
> messages. The reversion in patch
Elia Pinto writes:
> In general snprintf is bad because it may silently truncate results if we're
> wrong. In this patch where we use PATH_MAX, we'd want to handle larger
> paths anyway, so we switch to dynamic allocation.
>
> Helped-by: Jeff King
> Signed-off-by: Elia Pinto
> ---
> This is the
Brandon Williams writes:
> Improve constness of the index_state parameter to the
> 'read_blob_data_from_index' function.
>
> Signed-off-by: Brandon Williams
> ---
Thanks.
Stefan Beller writes:
> Add support for the super-prefix option for commands that unpack trees.
> For testing purposes enable it in read-tree, which has no other path
> related output.
"path related output"? I am not sure I understand this.
When read-tree reads N trees, or unpack_trees() is as
Richard Hansen writes:
>> Back then we didn't even have wildmatch(), and used fnmatch()
>> instead, so forcing FNM_PATHNAME would have meant that people
>> wouldn't be able to say "foo*bar" to match "foo/other/bar"; with
>> wildmatch, "foo**bar" lets you defeat WM_PATHNAME so having
>> WM_PATHNAM
This part was missing in f6f85861 (submodule: add absorb-git-dir function,
2016-12-12).
Noticed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
git-submodule.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 554bd1c494..b43af
Jeff King writes:
> On Tue, Jan 10, 2017 at 02:15:11PM -0800, Junio C Hamano wrote:
>
>> Richard Hansen writes:
>> ...
>> > I think so. (For bare repositories anyway; non-bare should be
>> > relative to GIT_WORK_TREE.) Perhaps git_config_pathname() itself
>> > should convert relative paths to
Jeff King writes:
> Another difference I found is that "[\d]" matches a literal "\" or "d"
> in ERE, but behaves like "[0-9]" in PCRE. I'll work up a patch based on
> that.
Wow, clever.
Thanks.
Lars Schneider writes:
>> Hmm, I would have expected that the basic flow would become
>>
>> for each paths to be processed:
>> convert-to-worktree to buf
>> if not delayed:
>> do the caller's thing to use buf
>> else:
>>
Jakub Narębski writes:
>> Yes, this problem happens every day with filters that perform network
>> requests (e.g. GitLFS).
>
> Do I understand it correctly that the expected performance improvement
> thanks to this feature is possible only if there is some amount of
> parallelism and concurrency
Jeff King writes:
> On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:
>
>> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?
> ...
> I'm not sure if I'm complaining or not. I can't immediately think of
> something that would be horribly broken. But it really feels
In modern Git we prefer "git -C )"
as it doesn't need an extra shell.
Signed-off-by: Stefan Beller
---
And because it is in a setup function, we actually save the invocation
of 22 shells for a single run of the whole test suite.
Noticed while adding a lot more in near vincinity, though not as n
On 2017-01-11 13:15, Junio C Hamano wrote:
Richard Hansen writes:
On 2017-01-10 21:46, Junio C Hamano wrote:
Richard Hansen writes:
I was looking at the code to see how the two file formats differed and
noticed that match_order() doesn't set the WM_PATHNAME flag when it
calls wildmatch().
On Wed, 2017-01-11 at 07:53 -0500, Jeff King wrote:
> On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:
>
> > Why does git cat-file -t $sha:foo, where foo is a submodule, not work?
>
> Because "cat-file" is about inspecting items in the object database, and
> typically the submodule c
Richard Hansen writes:
> On 2017-01-10 21:46, Junio C Hamano wrote:
>> Richard Hansen writes:
>>
>>> I was looking at the code to see how the two file formats differed and
>>> noticed that match_order() doesn't set the WM_PATHNAME flag when it
>>> calls wildmatch(). That's unintentional (a bug)
Jeff King writes:
> Yes, I would think die_errno() is a no-brainer for translation, since
> the strerror() will be translated.
>
>> apply.c:die(_("internal error"));
>>
>> That is funny, too. I think we should substitute that with
>>
>> die("BUG: untranslated, but what w
On Wed, Jan 11, 2017 at 11:13:00AM +0100, Lars Schneider wrote:
>
> In v1 I implemented a) with the busy-loop problem in mind.
>
> My thinking was this:
>
> If the filter sees at least one filter request twice then the filter knows
> that
> Git has already requested all files that require filterin
On 2017-01-10 21:46, Junio C Hamano wrote:
Richard Hansen writes:
I was looking at the code to see how the two file formats differed and
noticed that match_order() doesn't set the WM_PATHNAME flag when it
calls wildmatch(). That's unintentional (a bug), right?
It has been that way from day
On Wed, Jan 11, 2017 at 3:37 AM, Jeff King wrote:
> On Tue, Jan 10, 2017 at 10:28:42AM -0800, Stefan Beller wrote:
>
>> > And then presumably that mix would gradually move to 100% consistency as
>> > more messages are translated. But the implicit question is: are there
>> > die() messages that sho
W dniu 11.01.2017 o 11:20, Lars Schneider pisze:
> On 10 Jan 2017, at 23:11, Jakub Narębski wrote:
>> W dniu 09.01.2017 o 00:42, Junio C Hamano pisze:
>>> larsxschnei...@gmail.com writes:
From: Lars Schneider
Some `clean` / `smudge` filters might require a significant amount of
>>
On Tue, Jan 10, 2017 at 02:15:11PM -0800, Junio C Hamano wrote:
> Richard Hansen writes:
>
> >> A related tangent.
> >>
> >> I wonder if anything that uses git_config_pathname() should be
> >> relative to GIT_DIR when it is not absolute.
> >
> > I think so. (For bare repositories anyway; non-ba
On Wed, Jan 11, 2017 at 09:01:38AM -0500, Jeff King wrote:
> [1/2]: Revert "vreportf: avoid intermediate buffer"
> [2/2]: vreport: sanitize ASCII control chars
We've talked before about repeating the "error:" header for multi-line
messages. The reversion in patch 1 makes this easy to play wit
This reverts commit f4c3edc0b156362a92bf9de4f0ec794e90a757fc.
The purpose of that commit was to let us write errors of
arbitrary length to stderr by skipping the intermediate
buffer and sending our varargs straight to fprintf. That
works, but it comes with a downside: we do not get access to
the v
Our error() and die() calls may report messages with
arbitrary data (e.g., filenames or even data from a remote
server). Let's make it harder to cause confusion with
mischievous filenames. E.g., try:
git rev-parse "$(printf "\rfatal: this argument is too sneaky")" --
or
git rev-parse "$(prin
When adding a warning() call in 50d341374 (http: make redirects more
obvious, 2016-12-06), somebody brought up that evil servers can redirect
you to something like:
https://evil.example.com/some/repo?unused=\rwarning:+rainbows+and_unicorns_ahead
(where "\r" is a literal CR), and instead of see
> On 09 Jan 2017, at 21:44, Stefan Beller wrote:
>
> On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider
> wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amount of time.
>> This blocks the entire Git
On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:
> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?
Because "cat-file" is about inspecting items in the object database, and
typically the submodule commit is not present in the superproject's
database. So we canno
On Tue, Jan 10, 2017 at 10:28:42AM -0800, Stefan Beller wrote:
> > And then presumably that mix would gradually move to 100% consistency as
> > more messages are translated. But the implicit question is: are there
> > die() messages that should never be translated? I'm not sure.
>
> I would assum
A few of the tests want to check that "git grep -P -E" will
override -P with -E, and vice versa. To do so, we use a
regex with "\x{..}", which is valid in PCRE but not defined
by POSIX (for basic or extended regular expressions).
However, POSIX declares quite a lot of syntax, including
"\x", as "u
> On 10 Jan 2017, at 23:11, Jakub Narębski wrote:
>
> W dniu 09.01.2017 o 00:42, Junio C Hamano pisze:
>> larsxschnei...@gmail.com writes:
>>> From: Lars Schneider
>>>
>>> Some `clean` / `smudge` filters might require a significant amount of
>>> time to process a single blob. During this proce
> On 10 Jan 2017, at 00:38, Taylor Blau wrote:
>
> I've been considering some alternative approaches in order to make the
> communication between Git and any extension that implements this protocol more
> intuitive.
>
> In particular, I'm considering alternatives to:
>
>> for each delayed
On Tue, Jan 10, 2017 at 12:40:00PM +0100, Szabolcs Nagy wrote:
> > > I'm not sure if musl is wrong for failing to complain about a
> > > bogus regex. Generally making something that would break into
> > > something that works is an OK way to extend the standard. So our
> > > test is at fault for a
Hello my name is Ms. Thandi Robert, from Ivory Coast. My parents were brutally
mulled by the former president Laurent Gbagbo because of political crisis as
the only survival of my family. I got your email while searching for a reliable
personality in my private study on the internet. I am in
> On 08 Jan 2017, at 21:45, Eric Wong wrote:
>
> larsxschnei...@gmail.com wrote:
>> +++ b/t/t0021/rot13-filter.pl
>
>> +$DELAY{'test-delay1.r'} = 1;
>> +$DELAY{'test-delay3.r'} = 3;
>>
>> open my $debug, ">>", "rot13-filter.log" or die "cannot open log file: $!";
>>
>> @@ -166,6 +176,15 @@ wh
> On 08 Jan 2017, at 21:14, Torsten Bögershausen wrote:
>
> On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Some `clean` / `smudge` filters might require a significant amount of
>> time to process a single blob. During this process the Gi
> On 09 Jan 2017, at 00:42, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Some `clean` / `smudge` filters might require a significant amount of
>> time to process a single blob. During this process the Git checkout
>> operation is blocked and Git n
58 matches
Mail list logo
