Johannes Schindelin johannes.schinde...@gmx.de 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,
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
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's concerns that
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 remiram...@gmail.com wrote:
Function _git_dir would previously fail to accept a gitdir: ... file
as a valid Git repository.
---
On Tue, Feb 3, 2015 at 6:24 AM, Remi Rampin remiram...@gmail.com 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
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
Jeff King p...@peff.net writes:
On Tue, Feb 03, 2015 at 01:40:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
2015-02-02 12:24 UTC-05:00, Remi Rampin remiram...@gmail.com:
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-02 12:24 UTC-05:00, Remi Rampin remiram...@gmail.com:
- 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
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 same
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 wrote:
[...]
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):
git add
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
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 t...@statsbiblioteket.dk
---
Stefan Beller sbel...@google.com writes:
On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano gits...@pobox.com 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
On Tue, Feb 3, 2015 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano gits...@pobox.com wrote:
+ test_must_fail git apply --index patch
+
+'
Is the empty line between the last test_must_fail
On Tue, Feb 3, 2015 at 4:01 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
+
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 try to
Jeff King p...@peff.net 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
+++
Stefan Beller sbel...@google.com writes:
On Tue, Feb 3, 2015 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano gits...@pobox.com wrote:
+ test_must_fail git apply --index patch
+
+'
Is the
Stefan Beller stefanbel...@gmail.com writes:
2015-02-02 11:15 GMT-08:00 Junio C Hamano gits...@pobox.com:
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.
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 random
garbage
Expected output: $ git blame HEAD -- foo fatal: no such path foo in
HEAD
Bisect says
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:
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
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
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
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
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
Symptoms:
$ git blame HEAD -- foo
fatal: no such path foo in random garbage
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
On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
Symptoms:
$ git blame HEAD -- foo
fatal: no such path foo in random garbage
Expected output:
$ git blame HEAD -- foo
fatal: no such path foo in HEAD
Bisect says this was introduced in 1da1e07c835e900337714cfad6c32a8dc0b36ac3
Jeff King p...@peff.net 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
On Tue, Feb 03, 2015 at 01:23:15PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Tue, Feb 03, 2015 at 01:40:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
38 matches
Mail list logo
