Johannes Schindelin writes:
>> [fsck "level"]
>> missingAuthor = error
>>
>> , which looks funny. "level" is a constant, so it seems superfluous.
Yes, it is superfluous, but is one way to avoid the ambiguity with
"skiplist". Structuring it like this would not be so bad, either,
though.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We will see 2.3 final later this week, hopefully.
You can find the changes described here in the integration branches
of the repositories liste
We currently read the preimage to apply a patch from the index only
when the --cached option is given. Do so also when the command is
running under the --index option. With --index, the index entry and
the working tree file for a path that is involved in a patch must be
identical, so this should
The design and implementation haven't changed.
This round primarily is to update documentation and comments with
rephrases and grammofixes and tighten some tests.
The previous round begins here:
http://thread.gmane.org/gmane.comp.version-control.git/263291
Junio C Hamano (4):
apply: reject
By default, a patch that affects outside the working area
(either a Git controlled working tree, or the current working
directory when "git apply" is used as a replacement of GNU
patch) rejected as a mistake (or a mischief); Git itself does
not create such a patch, unless the user bends over backwa
We should reject a patch, whether it renames/copies dir/file to
elsewhere with or without modificiation, or updates dir/file in
place, if "dir/" part is actually a symbolic link to elsewhere,
by making sure that the code to read the preimage does not read
from a path that is beyond a symbolic link.
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch
On Tue, Feb 3, 2015 at 4:01 PM, Junio C Hamano wrote:
> Jeff King writes:
>> diff --git a/t/t4122-apply-symlink-inside.sh
>> b/t/t4122-apply-symlink-inside.sh
>> index 942c5cb..fbba8dd 100755
>> --- a/t/t4122-apply-symlink-inside.sh
>> +++ b/t/t4122-apply-symlink-inside.sh
>> @@ -112,6 +113,20 @
Jeff King writes:
> On Tue, Feb 03, 2015 at 01:40:12PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > But wouldn't we still fail writing "foo/bar" at that point if "foo" is a
>> > regular file (again, we should never do this, but that is the point of
>> > the test).
>>
>> The poin
On Tue, Feb 03, 2015 at 01:40:12PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But wouldn't we still fail writing "foo/bar" at that point if "foo" is a
> > regular file (again, we should never do this, but that is the point of
> > the test).
>
> The point of the test is not to create
Jeff King writes:
> On Tue, Feb 03, 2015 at 11:27:07AM +0100, Tom G. Christensen wrote:
>
>> The __builtin_ctzll function was added in gcc 3.4.0.
>> This extends the check for gcc so that use of __builtin_ctzll is only
>> enabled if gcc >= 3.4.0.
>> ---
>>
>> I noticed this on RHEL3 during 2.0.0
Jeff King writes:
> But wouldn't we still fail writing "foo/bar" at that point if "foo" is a
> regular file (again, we should never do this, but that is the point of
> the test).
The point of the test is not to create foo, whether it is a symlink
or an emulating regular file, in the first place.
On Tue, Feb 03, 2015 at 01:23:15PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, I do not think these tests will _fail_ when the filesystem does
> > not support symlinks. But nor are they actually testing anything
> > interesting. They would pass on such a system even without you
Jeff King writes:
> Right, I do not think these tests will _fail_ when the filesystem does
> not support symlinks. But nor are they actually testing anything
> interesting. They would pass on such a system even without your patch,
> as we would fail to apply even the symlink creation part of the
On Tue, Feb 03, 2015 at 12:23:28PM -0800, Junio C Hamano wrote:
> > By the way, does this patch (and the other symlink-escape ones) need to
> > be marked with the SYMLINKS prereq? For a pure-index application, it
> > should work anywhere, but I have a feeling that this "git apply patch"
> > may tr
Jeff King writes:
> Here's the test addition I came up with, because it didn't look like we
> were covering this case.
Thanks.
> diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
> index 942c5cb..fbba8dd 100755
> --- a/t/t4122-apply-symlink-inside.sh
> +++ b/t/t412
Stefan Beller writes:
> On Tue, Feb 3, 2015 at 11:37 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano wrote:
+ test_must_fail git apply --index patch
+
+'
>>>
>>> Is the empty line between the last test_must_fail and
Jeff King writes:
> On Mon, Feb 02, 2015 at 03:27:27PM -0800, Junio C Hamano wrote:
>
>> +test_expect_failure 'symlink escape via ..' '
>> +{
>> +mkpatch_symlink tmp .. &&
>> +mkpatch_add tmp/foo ../foo
>> +} >patch &&
>> +test_must_fail git apply patch &&
>> +
Stefan Beller writes:
> 2015-02-02 11:15 GMT-08:00 Junio C Hamano :
>
>> Isn't gitignore(5) documentation reasonably clear?
>> ...
>> - A leading slash matches the beginning of the pathname. For
>>example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".
>>
>>> That's true, though
On Tue, Feb 3, 2015 at 11:37 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano wrote:
>>> + test_must_fail git apply --index patch
>>> +
>>> +'
>>
>> Is the empty line between the last test_must_fail and the closing `'`
>> intentional?
>
Stefan Beller writes:
> On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano wrote:
>> + test_must_fail git apply --index patch
>> +
>> +'
>
> Is the empty line between the last test_must_fail and the closing `'`
> intentional?
I think I just mimicked the previous existing one, but I can go wit
Commit dd61399 introduced support for http proxies that require
authentication but it relies on the CURL_PROXYAUTH option which was
added in curl 7.10.7.
This makes sure proxy authentication is only enabled if libcurl can
support it.
Signed-off-by: Tom G. Christensen
---
RHEL3 ships with curl 7.
On Tue, Feb 03, 2015 at 11:27:07AM +0100, Tom G. Christensen wrote:
> The __builtin_ctzll function was added in gcc 3.4.0.
> This extends the check for gcc so that use of __builtin_ctzll is only
> enabled if gcc >= 3.4.0.
> ---
>
> I noticed this on RHEL3 during 2.0.0rc phase but I see that the s
Hi Michael,
On 2015-02-03 16:11, Michael Haggerty wrote:
> On 02/02/2015 05:48 PM, Johannes Schindelin wrote:
>> On 2015-02-02 13:43, Michael Haggerty wrote:
>>> On 02/02/2015 12:41 PM, Johannes Schindelin wrote:
Hi all (in particular Junio),
On 2015-01-31 22:04, Johannes Schindelin
On Tue, Feb 03, 2015 at 08:14:06AM -0500, Michaël Fortin wrote:
> Repo1 has the following pre-commit hook:
>
> #!/bin/bash
> git -C "../Repo2" status --porcelain
>
> I then commit in Repo1 using the following (this is actually ran by a
> GUI, I have no control over the commands themselves):
>
>
2015-02-02 12:24 UTC-05:00, Remi Rampin :
>> - return [_is_git [file join [file dirname $path]
>> $link_target]]
>> + set link_target_abs [file join [file dirname $path]
>> $link_target]
2015-02-03 3:51 UTC-05:00, Chris Packham :
> At this point link_t
2015-02-02 12:24 UTC-05:00, Remi Rampin :
>> proc _is_git {path} {
>> + if {[file isfile $path]} {
>> + set fp [open $path r]
>> + gets $fp line
>> + close $fp
>> + if {[regexp "^gitdir: (.+)$" $line line link_target]} {
2015-02-03 3:4
On 02/02/2015 05:48 PM, Johannes Schindelin wrote:
> On 2015-02-02 13:43, Michael Haggerty wrote:
>> On 02/02/2015 12:41 PM, Johannes Schindelin wrote:
>>> Hi all (in particular Junio),
>>>
>>> On 2015-01-31 22:04, Johannes Schindelin wrote:
>>>
[...] switch to fsck.severity to address Michael
Hi all,
I'm seeing behavior that I *think* might be a bug in git (I'm running 2.2.2).
At least I couldn't find anything about this anywhere, so here goes:
I'm trying to run git commands outside of the current working copy (e.g. inside
another repo) from a pre-commit hook. However I'm encounteri
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
---
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed on Debian Sarge:
http://article.gmane.org/gmane.comp.versio
On Tue, Feb 03, 2015 at 10:32:45AM +0100, Lukas Fleischer wrote:
> On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
> > Symptoms: $ git blame HEAD -- foo fatal: no such path foo in > garbage>
> >
> > Expected output: $ git blame HEAD -- foo fatal: no such path foo in
> > HEAD
> >
> > Bisect s
Hi
First of all thanks for a great piece of software!!
I have a tiny complaint though, about git not allowing symlinked files (in
an easy way).
I would use this to keep track of the contents of a file that is also being
developed and shared across other projects, but later changes to it could
br
On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
> Symptoms:
> $ git blame HEAD -- foo
> fatal: no such path foo in
>
> Expected output:
> $ git blame HEAD -- foo
> fatal: no such path foo in HEAD
>
> Bisect says this was introduced in 1da1e07c835e900337714cfad6c32a8dc0b36ac3
> [...]
Symptoms:
$ git blame HEAD -- foo
fatal: no such path foo in
Expected output:
$ git blame HEAD -- foo
fatal: no such path foo in HEAD
Bisect says this was introduced in 1da1e07c835e900337714cfad6c32a8dc0b36ac3
valgrind output looks like this:
==4738== Memcheck, a memory error detector
=
On Tue, Feb 3, 2015 at 6:24 AM, Remi Rampin wrote:
> If _is_git had to follow "gitdir: ..." files to reach the actual Git
> directory, we set _gitdir to that final path.
> ---
> lib/choose_repository.tcl | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/lib/
Hi Remi,
Added Pat Thoyts the git-gui maintainer.
(Disclaimer, it's been years since I did anything with Tcl).
On Tue, Feb 3, 2015 at 6:24 AM, Remi Rampin wrote:
> Function _git_dir would previously fail to accept a "gitdir: ..." file
> as a valid Git repository.
> ---
> lib/choose_repository.
On 02/03/2015 07:23 AM, Kevin Coleman wrote:
Awesome reply! That makes sense. So basically if I accidentally capitalize a
folder name and commit it, I need to be very careful when I correct it.
Definitely ran into this problem with my repo and ‘lost’ a few commits before I
noticed something
On 02/03/2015 05:52 AM, Kevin Coleman wrote:
Yes, I am on a Mac. I just tried that, but I don’t think that completely fixed
it. As you can see it tracks “foo/bar.md” and then it tracks “Foo/bar.md”. It
still tracks both “foo” and “Foo” even tho only “Foo” exists in my dir after
the re
38 matches
Mail list logo
