Re: [PATCH 2/3] submodule-config: rename commit_sha1 to commit_or_tree

On Wed, Nov 2, 2016 at 4:17 PM, Stefan Beller wrote: > -`const struct submodule *submodule_from_path(const unsigned char > *commit_sha1, const char *path)`:: > +`const struct submodule *submodule_from_path(const unsigned char > *commit_or_tree, const char *path)`:: > >

Re: [PATCH] transport: add core.allowProtocol config option

Jonathan Nieder writes: > That is, would it be possible to use something like > > [protocol "sso"] > allow = always > > instead of > > [core] > allowProtocol = file:git:http:https::sso > > ? That sounds like quite a large usability

[PATCH v2] transport: add core.allowProtocol config option

Add configuration option 'core.allowProtocol' to allow users to create a whitelist of allowed protocols for fetch/push/clone in their gitconfig. For git-submodule.sh, fallback to default whitelist only if the user hasn't explicitly set `GIT_ALLOW_PROTOCOL` or doesn't have a whitelist in their

Re: [PATCH] transport: add core.allowProtocol config option

Thanks for CCing me. I haven't looked at this implementation in detail, but it would be good to move this configuration into the config system because I think we can more easily provide a default safe configuration. It would be nice to use this to introduce a default list of whitelisted

Re: [PATCH v11 13/14] convert: add filter..process option

> On 2 Nov 2016, at 18:03, Johannes Sixt wrote: > >> Am 17.10.2016 um 01:20 schrieb larsxschnei...@gmail.com: >> +# Compare two files and ensure that `clean` and `smudge` respectively are >> +# called at least once if specified in the `expect` file. The actual >> +# invocation

Re: [PATCH] transport: add core.allowProtocol config option

(+peff and bburky, who introduced GIT_ALLOW_PROTOCOL) Brandon Williams wrote: > Add configuration option 'core.allowProtocol' to allow users to create a > whitelist of allowed protocols for fetch/push/clone in their gitconfig. Ooh. This would be especially useful at $DAYJOB, where there is a

Re: [PATCH] transport: add core.allowProtocol config option

On Wed, Nov 02, 2016 at 04:46:13PM -0700, Brandon Williams wrote: > > > I thought at first we'd have to deal with leaking "v", but "get_value" > > > is the "raw" version that gives you the uninterpreted value. I think > > > that means it may give you NULL, though if we see an implicit bool like:

Re: [PATCH] transport: add core.allowProtocol config option

> > > diff --git a/transport.c b/transport.c > > > index d57e8de..b1098cd 100644 > > > --- a/transport.c > > > +++ b/transport.c > > > @@ -652,7 +652,7 @@ static const struct string_list > > > *protocol_whitelist(void) > > > > > > if (enabled < 0) { > > > const char *v =

Re: [PATCH] transport: add core.allowProtocol config option

On 11/02, Jeff King wrote: > On Wed, Nov 02, 2016 at 07:05:39PM -0400, Jeff King wrote: > > > > +core.allowProtocol:: > > > + Provide a colon-separated list of protocols which are allowed to be > > > + used with fetch/push/clone. This is useful to restrict recursive > > > + submodule

Re: [PATCH] transport: add core.allowProtocol config option

On 11/02, Jeff King wrote: > On Wed, Nov 02, 2016 at 03:20:47PM -0700, Brandon Williams wrote: > > > Add configuration option 'core.allowProtocol' to allow users to create a > > whitelist of allowed protocols for fetch/push/clone in their gitconfig. > > > > For git-submodule.sh, fallback to

[PATCH 2/3] submodule-config: rename commit_sha1 to commit_or_tree

It is also possible to pass in a tree hash to lookup a submodule config. Make it clear by naming the variables accrodingly. Looking up a submodule config by tree hash will come in handy in a later patch. Signed-off-by: Stefan Beller ---

[PATCH 3/3] submodule-config: clarify parsing of null_sha1 element

Signed-off-by: Stefan Beller --- Documentation/technical/api-submodule-config.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/api-submodule-config.txt b/Documentation/technical/api-submodule-config.txt index

[PATCH 0/3] submodule-config: clarify/cleanup docs and header

A small series that would have helped me understand the submodule config once again. Thanks, Stefan Stefan Beller (3): submodule config: inline config_from_{name, path} submodule-config: rename commit_sha1 to commit_or_tree submodule-config: clarify parsing of null_sha1 element

[PATCH 1/3] submodule config: inline config_from_{name, path}

There is no other user of config_from_{name, path}, such that there is no reason for the existence of these one liner functions. Just inline these to increase readability. Signed-off-by: Stefan Beller --- submodule-config.c | 16 ++-- 1 file changed, 2

Re: [PATCH] transport: add core.allowProtocol config option

On Wed, Nov 02, 2016 at 07:05:39PM -0400, Jeff King wrote: > > +core.allowProtocol:: > > + Provide a colon-separated list of protocols which are allowed to be > > + used with fetch/push/clone. This is useful to restrict recursive > > + submodule initialization from an untrusted repository.

Re: [PATCH] transport: add core.allowProtocol config option

On Wed, Nov 02, 2016 at 03:20:47PM -0700, Brandon Williams wrote: > Add configuration option 'core.allowProtocol' to allow users to create a > whitelist of allowed protocols for fetch/push/clone in their gitconfig. > > For git-submodule.sh, fallback to default whitelist only if the user > hasn't

Re: [PATCH] transport: add core.allowProtocol config option

On 11/02, Stefan Beller wrote: > > This is useful to restrict recursive > > + submodule initialization from an untrusted repository. > > ok. Though as a user submodules may not spring to mind immediately here. > I think this is generally useful, too. e.g. an admin could put this in > the

Re: [PATCH] transport: add core.allowProtocol config option

On Wed, Nov 2, 2016 at 3:20 PM, Brandon Williams wrote: > Add configuration option 'core.allowProtocol' to allow users to create a > whitelist of allowed protocols for fetch/push/clone in their gitconfig. > > For git-submodule.sh, fallback to default whitelist only if the user

Re: RFE: Discard hunks during `git add -p`

On Wed, Nov 02, 2016 at 06:11:14PM -0400, Jeff King wrote: > > Being able to discard hunks (reset working copy to index contents) > > during add-p would alleviate the (quite broad) hard reset. > > As Konstantin pointed out, you can already discard interactively with > "git checkout -p". It

Re: send-email garbled header with trailing doublequote in email

On Wed, Nov 02, 2016 at 06:04:37PM -0400, Jeff King wrote: > Nope, it looks exactly as --dry-run reports it. My sendmail is postfix 3.1.0. > To see exactly what is being sent out, try: > > -- >8 -- > > cat >/tmp/foo <<\EOF > #!/bin/sh > echo "args: $*" > sed 's/^/stdin: /' > EOF > > chmod +x

[PATCH] transport: add core.allowProtocol config option

Add configuration option 'core.allowProtocol' to allow users to create a whitelist of allowed protocols for fetch/push/clone in their gitconfig. For git-submodule.sh, fallback to default whitelist only if the user hasn't explicitly set `GIT_ALLOW_PROTOCOL` or doesn't have a whitelist in their

Re: RFE: Discard hunks during `git add -p`

On Wed, Nov 02, 2016 at 02:46:04PM +0100, Jan Engelhardt wrote: > Current version: 2.10.2 > Example workflow: > > * I would do a global substitution across a source tree, e.g. `perl -i > -pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c` > * Using `git add -p`, I would verify each of the substitutions

Re: send-email garbled header with trailing doublequote in email

On Wed, Nov 02, 2016 at 10:38:05PM +0100, Andrea Arcangeli wrote: > > But in either case, in my test, the actual email address is still > > extracted correctly and fed to the MTA, so the mail is delivered. > > The email is delivered to the right email for me too, but to see the > problem you

Re: [ANNOUNCE] Git v2.11.0-rc0

On 11/01/2016 10:38 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> If it involves renaming and swapping, however, we may be talking >> about a change that we cannot deliver with confidence in less than a >> week before -rc1, which sounds, eh, suboptimal. >> >> FWIW,

Re: send-email garbled header with trailing doublequote in email

Hello, On Wed, Nov 02, 2016 at 05:11:18PM -0400, Jeff King wrote: > In fact, it is not even git that does this, but rather what > Mail::Address happens to output (though git has fallback routines if > that module isn't available that do the same thing). If it's something in perl it should be

Re: send-email garbled header with trailing doublequote in email

On Wed, Nov 02, 2016 at 09:27:09PM +0100, Andrea Arcangeli wrote: > send-email gets confused with one trailing " at the end of the > email. Details and how to reproduce below, it breaks also with > upstream git version 2.10.2.dirty. I'm not quite sure what happened, and what you wanted to

[ANNOUNCE] Git for Windows 2.10.2

Dear Git users, It is my pleasure to announce that Git for Windows 2.10.2 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.10.1(2) (October 13th 2016) Git for windows v2.10.1(2) was a MinGit-only release (i.e. there was no Git for windows installer

Re: [PATCH 4/4] t0021: fix filehandle usage on older perl

> +use IO::File; That did the trick (the J6T version work as well) Thanks for the fast responses.

send-email garbled header with trailing doublequote in email

Hello, send-email gets confused with one trailing " at the end of the email. Details and how to reproduce below, it breaks also with upstream git version 2.10.2.dirty. Feel free to CC me if you need any further info. Thanks, Andrea - Forwarded message from Andrea Arcangeli

Re: [PATCH 0/5] disallow symlinks for .gitignore and .gitattributes

On Wed, Nov 02, 2016 at 12:46:28PM -0700, Stefan Beller wrote: > On Wed, Nov 2, 2016 at 6:04 AM, Jeff King wrote: > > > > > attr.c| 58 > > --- > > $ git diff --stat origin/master..origin/sb/attr |grep attr.c >

Re: [PATCH 0/5] disallow symlinks for .gitignore and .gitattributes

On Wed, Nov 2, 2016 at 6:04 AM, Jeff King wrote: > > attr.c| 58 > --- $ git diff --stat origin/master..origin/sb/attr |grep attr.c attr.c | 531 +- >From a cursory

[PATCH 4/4] t0021: fix filehandle usage on older perl

The rot13-filter.pl script calls methods on implicitly defined filehandles (STDOUT, and the result of an open() call). Prior to perl 5.13, these methods are not automatically loaded, and perl will complain with: Can't locate object method "flush" via package "IO::Handle" Let's explicitly load

[PATCH 3/4] t0021: use $PERL_PATH for rot13-filter.pl

The rot13-filter.pl script hardcodes "#!/usr/bin/perl", and does not respect $PERL_PATH at all. That is a problem if the system does not have perl at that path, or if it has a perl that is too old to run a complicated script like the rot13-filter (but PERL_PATH points to a more modern one). We

[PATCH 2/4] t0021: put $TEST_ROOT in $PATH

We create a rot13.sh script in the trash directory, but need to call it by its full path when we have moved our cwd to another directory. Let's just put $TEST_ROOT in our $PATH so that the script is always found. This is a minor convenience for rot13.sh, but will be a major one when we switch

[PATCH 1/4] t0021: use write_script to create rot13 shell script

This avoids us fooling around with $SHELL_PATH and the executable bit ourselves. Signed-off-by: Jeff King --- t/t0021-conversion.sh | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh index a20b9f58e..dfde22549

[PATCH 0/4] t0021 perl portability fixups

This series should fix the portability problem you saw (in the final patch), and fixes the failure to use PERL_PATH along the way. [1/4]: t0021: use write_script to create rot13 shell script [2/4]: t0021: put $TEST_ROOT in $PATH [3/4]: t0021: use $PERL_PATH for rot13-filter.pl [4/4]:

Re: [PATCH v11 13/14] convert: add filter..process option

Am 17.10.2016 um 01:20 schrieb larsxschnei...@gmail.com: > +# Compare two files and ensure that `clean` and `smudge` respectively are > +# called at least once if specified in the `expect` file. The actual > +# invocation count is not relevant because their number can vary. > +# c.f. >

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

On 2 Nov 2016, at 17:04, Torsten Bögershausen wrote: >> * ls/filter-process (2016-10-17) 14 commits >> (merged to 'next' on 2016-10-19 at ffd0de042c) > > Some (late, as I recently got a new battery for the Mac OS 10.6 test system) > comments: > t0021 failes here: > > > Can't

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

Am 02.11.2016 um 18:04 schrieb Torsten Bögershausen: >> * ls/filter-process (2016-10-17) 14 commits >> (merged to 'next' on 2016-10-19 at ffd0de042c) > > Some (late, as I recently got a new battery for the Mac OS 10.6 test system) > comments: > t0021 failes here: > > > Can't locate object

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

On Wed, Nov 02, 2016 at 05:04:15PM +, Torsten Bögershausen wrote: > > * ls/filter-process (2016-10-17) 14 commits > > (merged to 'next' on 2016-10-19 at ffd0de042c) > > Some (late, as I recently got a new battery for the Mac OS 10.6 test system) > comments: > t0021 failes here: > > >

[PATCH v3 2/5] commit: make ignore_non_trailer take buf/len

Make ignore_non_trailer take a buf/len pair instead of struct strbuf. Signed-off-by: Jonathan Tan --- builtin/commit.c | 2 +- commit.c | 22 +++--- commit.h | 2 +- trailer.c| 2 +- 4 files changed, 14 insertions(+), 14

[PATCH v3 3/5] trailer: avoid unnecessary splitting on lines

trailer.c currently splits lines while processing a buffer (and also rejoins lines when needing to invoke ignore_non_trailer). Avoid such line splitting, except when generating the strings corresponding to trailers (for ease of use by clients - a subsequent patch will allow other components to

[PATCH v3 5/5] sequencer: use trailer's trailer layout

Make sequencer use trailer.c's trailer layout definition, as opposed to parsing the footer by itself. This makes "commit -s", "cherry-pick -x", and "format-patch --signoff" consistent with trailer, allowing non-trailer lines and multiple-line trailers in trailer blocks under certain conditions,

[PATCH v3 4/5] trailer: have function to describe trailer layout

Create a function that, taking a string, describes the position of its trailer block (if available) and the contents thereof, and make trailer use it. This makes it easier for other Git components, in the future, to interpret trailer blocks in the same way as trailer. In a subsequent patch,

[PATCH v3 0/5] Make other git commands use trailer layout

This is the same as v2 except that in 1/5, the comment about find_separators has been moved from the commit message to the code itself. Also, a trailing whitespace and unused variable fix. Jonathan Tan (5): trailer: be stricter in parsing separators commit: make ignore_non_trailer take

[PATCH v3 1/5] trailer: be stricter in parsing separators

Currently, a line is interpreted to be a trailer line if it contains a separator. Make parsing stricter by requiring the text on the left of the separator, if not the empty string, to be of the "" form. Signed-off-by: Jonathan Tan --- trailer.c | 27

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

> * ls/filter-process (2016-10-17) 14 commits > (merged to 'next' on 2016-10-19 at ffd0de042c) Some (late, as I recently got a new battery for the Mac OS 10.6 test system) comments: t0021 failes here: Can't locate object method "flush" via package "IO::Handle" at

Re: How can I tell, from a script, if “git cherry-pick” fails?

Hey Kevin, On Wed, Nov 2, 2016 at 8:44 PM, Kevin Layer wrote: > If the cherry-pick fails due to a merge conflict, it just returns an > exit status of 0. I have a script that does a series of cherry-picks > and I need to know if they succeed. Well, I haven't checked what it

Re: How can I tell, from a script, if “git cherry-pick” fails?

Nevermind. It's working as it should. The script that was doing the cherry-pick was doing it in an if and I neglected to exit with a non-zero status. Sorry for the noise. On Wed, Nov 2, 2016 at 8:14 AM, Kevin Layer wrote: > If the cherry-pick fails due to a merge conflict, it

How can I tell, from a script, if “git cherry-pick” fails?

If the cherry-pick fails due to a merge conflict, it just returns an exit status of 0. I have a script that does a series of cherry-picks and I need to know if they succeed. I'm sure this has been covered before. Using git version 1.8.3.1. Thank you. Kevin

Re: RFE: Discard hunks during `git add -p`

On Wed, 2 Nov 2016 14:46:04 +0100 (CET) Jan Engelhardt wrote: > Current version: 2.10.2 > Example workflow: > > * I would do a global substitution across a source tree, e.g. `perl > -i -pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c` > * Using `git add -p`, I would verify each of the

RFE: Discard hunks during `git add -p`

Current version: 2.10.2 Example workflow: * I would do a global substitution across a source tree, e.g. `perl -i -pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c` * Using `git add -p`, I would verify each of the substitutions that they make sense in their respective locations, and, based on that,

[PATCH 5/5] exclude: do not respect symlinks for in-tree .gitignore

Like .gitattributes, we would like to make sure that .gitignore files are handled consistently whether read from the index or from the filesystem. We can do so by using O_NOFOLLOW when opening the files. Signed-off-by: Jeff King --- dir.c | 9 +++--

[PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

The attributes system may sometimes read in-tree files from the filesystem, and sometimes from the index. In the latter case, we do not resolve symbolic links (and are not likely to ever start doing so). Let's open filesystem links with O_NOFOLLOW so that the two cases behave consistently. As a

[PATCH 3/5] exclude: convert "check_index" into a flags field

We pass the "check_index" flag through the variants of add_excludes(). Let's turn this into a full flags bit-field, so that we can add more flags to it without affecting the function signature. Note that only one caller actually needs to use the new flag name, as the rest all were passing "0"

[PATCH 2/5] attr: convert "macro_ok" into a flags field

The attribute code can have a rather deep callstack, through which we have to pass the "macro_ok" flag. In anticipation of adding other flags, let's convert this to a generic bit-field. Signed-off-by: Jeff King --- attr.c | 43 --- 1 file

[PATCH 1/5] add open_nofollow() helper

Some callers of open() would like to optionally use O_NOFOLLOW, but it is not available on all platforms. We could abstract this by publicly defining O_NOFOLLOW to 0 on those platforms, but that leaves us no room for any workarounds (e.g., by checking the file type via lstat()). Instead, let's

[PATCH 0/5] disallow symlinks for .gitignore and .gitattributes

I noticed in a nearby discussion that we will follow in-filesystem symlinks for in-tree .gitignore and .gitattributes files, but not when those files are read out of the index (e.g., when switching branches). This series teaches git to open those files with O_NOFOLLOW (when it is available) to

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

Johannes Schindelin writes: > On Mon, 31 Oct 2016, Junio C Hamano wrote: > >> * jc/git-open-cloexec (2016-10-31) 3 commits >> - sha1_file: stop opening files with O_NOATIME >> - git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback >> - git_open(): untangle

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

Torsten Bögershausen writes: >> * tb/convert-stream-check (2016-10-27) 2 commits >> - convert.c: stream and fast search for binary >> - read-cache: factor out get_sha1_from_index() helper >> > > It looks to be a good "proof of concept". > > The current series is far away from

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

Hi Junio, On Mon, 31 Oct 2016, Junio C Hamano wrote: > * jc/git-open-cloexec (2016-10-31) 3 commits > - sha1_file: stop opening files with O_NOATIME > - git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback > - git_open(): untangle possible NOATIME and CLOEXEC interactions > > The

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

> > * tb/convert-stream-check (2016-10-27) 2 commits > - convert.c: stream and fast search for binary > - read-cache: factor out get_sha1_from_index() helper > > End-of-line conversion sometimes needs to see if the current blob > in the index has NULs and CRs to base its decision. We used