>
> * 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 to
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 codeflow
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 being ready, so p
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 possible NOATIME and CLOEXEC inter
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 get
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 changed, 24 inser
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 abs
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" alre
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 bo
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 +++--
t/t0008-ignores.sh | 29
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,
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 substitutions that
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
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 just returns an
>
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 returns in git 2.10,
> * 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
/Users/tb/projects/git/git.n
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 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 deletions(-)
diff --git a/built
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 +--
1 file changed, 2
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 obt
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, and
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, anothe
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:
>
>
> Can
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 met
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 locate object m
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.
> http://publ
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]: t0021
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 100755
--- a/t/t0021
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 rot1
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 can
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
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 read of your series
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
> attr.c
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 -
Date: Wed
> +use IO::File;
That did the trick (the J6T version work as well)
Thanks for the fast responses.
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
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 happen.
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 fixe
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, here is how the remov
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 need
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
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 gitc
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 /
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 might
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
> hasn't explicitly
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 sy
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
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. A
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
Documentat
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 insertions(+), 14 deletions(-)
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
---
Documentation/technical/api-submodule-config.txt | 4 +-
s
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 81921e477b..1df7a827ff 100644
---
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 defau
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 initializatio
> > > 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 = getenv("GIT_
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:
>
(+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 cus
> 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 count is not relev
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 protocols
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 gitc
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 improvement to me.
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)`::
>
> Lookup values for
62 matches
Mail list logo
