Hi,
On Sat, Jan 31, 2015 at 10:46 AM, Rémi Rampin wrote:
> Hi,
>
> This bug report concerns git-gui. Apologies if this is not the right
> mailing-list.
>
> By submodule I mean a repository for which .git is not a regular Git
> directory, but rather a "gitdir: ..." file.
> While running "git gui"
On Mon, Feb 2, 2015 at 9:41 PM, Chris Packham wrote:
> Hi,
>
> On Sat, Jan 31, 2015 at 10:46 AM, Rémi Rampin wrote:
>> Hi,
>>
>> This bug report concerns git-gui. Apologies if this is not the right
>> mailing-list.
>>
>> By submodule I mean a repository for which .git is not a regular Git
>> dire
On 01/02/15 23:48, Junio C Hamano wrote:
I was reviewing the recent bugs and fixes for the last time, and was
wondering if we want to do 2.3-rc3 with build fix for those with
ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
for those with Perl with older Getopt::Long (tc/t9001-n
Hi,
On 2015-02-01 23:34, Junio C Hamano wrote:
> Jeff King writes:
>
>> 1. I'm a user who has set my preferred core.whitespace in my
>> ~/.gitconfig. A particular project I am working on uses an
>> alternate tabwidth. How do I set that in the repo config without
>> repeating my
Hi all (in particular Junio),
On 2015-01-31 22:04, Johannes Schindelin wrote:
> [...] switch to fsck.severity to address Michael's
> concerns that letting fsck.(error|warn|ignore)'s comma-separated lists
> possibly overriding each other partially;
Having participated in the CodingStyle thread, I
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
>> letting fsck.(error|warn|ignore)'s comma-separated lists possibly
>> overriding each othe
2015-02-02 3:41 UTC-05:00, Chris Packham :
> [...]
> But it actually looks like git rev-parse --resolve-git-dir $path needs
> to be run inside a git repository _any_ git repository, which seems a
> bit backwards to me.
> [...]
Indeed, looking at git-rev-parse(1), the correct option might be
--show
On Feb 1, 2015, at 17:33, Junio C Hamano wrote:
"Kyle J. McKay" writes:
use 5.008;
So either that needs to change or the code should properly deal with
the version of Getopt::Long that comes with 5.8.0.
Since it's really not very difficult or invasive to add support for
the no- variants, h
Hi Michael,
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
>>> letting fsck.(error|warn|
When "git status" recurses a directory that isn't readable (but
executable), it should print out a warning/error. Currently, if there
are untracked files in these directories, git wouldn't be able to
discover them. Ideally, "git status" should return a non-zero exit
code as well.
The problem seems
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/choose_repository.tcl b/lib/choose_repository.tcl
index 49ff641..
Function _git_dir would previously fail to accept a "gitdir: ..." file
as a valid Git repository.
---
lib/choose_repository.tcl | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 92d6022..49ff641 100644
--- a/lib/choose_repos
On Sun, Feb 01, 2015 at 01:55:33PM -0800, Jonathon Mah wrote:
> The string in 'base' contains a path suffix to a specific object; when
> its value is used, the suffix must either be filled (as in
> stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
> (as in prepare_packed_git)
On Sun, Feb 01, 2015 at 01:55:00PM -0800, Jonathon Mah wrote:
> Signed-off-by: Jonathon Mah
> ---
> t/t5710-info-alternate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
> index 5a6e49d..d82844a 100755
> ---
Junio C Hamano writes:
> * Here is what I am at the moment; I cannot quite explain (hence I
>cannot convince myself) why this is the right solution, but it
>seems to make the above sample case work without breaking any
>existing tests. It is possible that the tests that would break
Signed-off-by: Jonathon Mah
---
Adjust prune test directly, much nicer.
t/t5304-prune.sh | 13 +
t/t5710-info-alternate.sh | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index e32e46d..e825be7 100755
--- a/t/t53
The string in 'base' contains a path suffix to a specific object; when
its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
(as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb
(introduced in 660c889e46
> On 2015-02-02, at 09:53, Jeff King wrote:
>
> I think this is probably the best fix, and is the pattern we use
> elsewhere when touching alt->base.
>
> We _could_ further change this to have for_each_loose_file_in_objdir
> actually use alt->base as its scratch buffer, writing the object
> file
The string in 'base' contains a path suffix to a specific object; when
its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
(as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb
(introduced in 660c889e46
Signed-off-by: Jonathon Mah
---
Messed up the v2 patch, sorry.
t/t5304-prune.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index e32e46d..e825be7 100755
--- a/t/t5304-prune.sh
+++ b/t/t5304-prune.sh
@@ -253,4 +253,17 @@ test_expect_succ
Jeff King writes:
I didn't reply to the latter part of this message yesterday, because
I wanted to think more on it.
> But is it such a bad thing to have them in conflict? Can't we define a
> set of rules that does what people expects? For example, by the "last
> one wins" principle, any time we
On Mon, Feb 02, 2015 at 10:33:02AM -0800, Jonathon Mah wrote:
> Signed-off-by: Jonathon Mah
> ---
> Adjust prune test directly, much nicer.
Agreed, this is much nicer. A few comments:
> +test_expect_success 'prune: handle alternate object database' '
This test fails, so we either need expect_f
The string in 'base' contains a path suffix to a specific object; when
its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
(as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb
(introduced in 660c889e46
On Mon, Feb 02, 2015 at 10:48:12AM -0800, Jonathon Mah wrote:
> The string in 'base' contains a path suffix to a specific object; when
> its value is used, the suffix must either be filled (as in
> stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
> (as in prepare_packed_git)
Michael Haggerty writes:
> You make an interesting point: values that start as a list of
> independent booleans can grow dependencies over time.
>
> In retrospect, ISTM that a better interface for the indentation-related
> "whitespace" settings would have been something like
>
> * "whitespace.ind
Stefan Beller writes:
> On 01.02.2015 14:51, /#!/JoePea wrote:
>> I have this in my .gitignore:
>>
>> ./*.js
>>
>> I would expect that to cause git to ignore .js files in the same
>> folder as .gitignore, but it doesn't do anything. However, this works:
>>
>> /*.js
>>
>> I'm not sure what
Jeff King writes:
> On Mon, Feb 02, 2015 at 10:48:12AM -0800, Jonathon Mah wrote:
>
>> The string in 'base' contains a path suffix to a specific object; when
>> its value is used, the suffix must either be filled (as in
>> stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
>>
Jonathon Mah writes:
> +test_expect_success 'prune: handle alternate object database' '
> + test_create_repo A &&
> + (cd A &&
> + echo "Hello World" >file1 &&
> + git add file1 &&
> + git commit -m "Initial commit" file1) &&
> + git clone -
Am 30.01.2015 um 16:14 schrieb Patrick Steinhardt:
When we add a new submodule the path of the submodule is being normalized. We
fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule'
will become 'path/to/./submodule' where it should be 'path/to/submodule'
instead.
Than
On Mon, Feb 02, 2015 at 12:00:17PM -0800, Junio C Hamano wrote:
> Jonathon Mah writes:
>
> > +test_expect_success 'prune: handle alternate object database' '
> > + test_create_repo A &&
> > + (cd A &&
> > + echo "Hello World" >file1 &&
> > + git add file1 &&
> > +
The string in 'base' contains a path suffix to a specific object; when
its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
(as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb
(introduced in 660c889e46
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
"Kyle J. McKay" writes:
> On Feb 1, 2015, at 17:33, Junio C Hamano wrote:
>
>> "Kyle J. McKay" writes:
>>
use 5.008;
>>>
>>> So either that needs to change or the code should properly deal with
>>> the version of Getopt::Long that comes with 5.8.0.
>>>
>>> Since it's really not very difficu
On Mon, Feb 02, 2015 at 12:05:54PM -0800, Jonathon Mah wrote:
> Simplified test per Junio (verified that it fails before and passes
> now). Punting on Jeff's "more elaborate example".
I think that's fine. I started to try to create such an example, but
it's actually rather tricky. If the alternat
On Sun, Feb 01, 2015 at 02:48:00PM -0800, Junio C Hamano wrote:
> I was reviewing the recent bugs and fixes for the last time, and was
> wondering if we want to do 2.3-rc3 with build fix for those with
> ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
> for those with Perl with
Jeff King writes:
> So I actually do not see how the situation would come up in practice,
> and possibly we could drop the iteration of the alternates' loose
> objects entirely from this code. But certainly that is orthogonal to
> Jonathon's fix (which is a true regression for the less-exotic cas
Jeff King writes:
> I thought at first that we also had a regression in pruning with
> alternates, but it looks like that bug actually went into v2.2. I still
> think we would want the fix fairly promptly, but it does not need to
> happen before v2.3 is released.
Yes, this was regression in v2.
On Mon, Feb 02, 2015 at 12:49:23PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I actually do not see how the situation would come up in practice,
> > and possibly we could drop the iteration of the alternates' loose
> > objects entirely from this code. But certainly that is orthogo
"git apply" have been fairly careless about letting the input follow
symbolic links, especially when used without the --index/--cached
options (which was more or less deliberate to mimic what "patch"
used to do). When the input tells it to modify a/b/c, and lstat(2)
said that there is "a/b/c" that
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
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.
By default, a patch that affects outside the working area is
rejected as a mistake (or a mischief); Git itself does not create
such a patch, unless the user bends backwards and specifies a
non-standard prefix to "git diff" and friends.
When `git apply` is used without either `--index` or `--cached
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
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
On Mon, Feb 02, 2015 at 03:27:27PM -0800, Junio C Hamano wrote:
> By default, a patch that affects outside the working area is
> rejected as a mistake (or a mischief); Git itself does not create
> such a patch, unless the user bends backwards and specifies a
> non-standard prefix to "git diff" and
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 &&
> + test_path_is_missing
On Mon, Feb 02, 2015 at 03:27:30PM -0800, Junio C Hamano wrote:
> +static struct string_list symlink_changes;
I notice we don't duplicate strings for this list. Are the paths we
register here always stable? I think they should be, as they are part of
the "struct patch".
> +#define SYMLINK_GOES_A
Jeff King writes:
> On Mon, Feb 02, 2015 at 03:27:30PM -0800, Junio C Hamano wrote:
>
>> +static struct string_list symlink_changes;
>
> I notice we don't duplicate strings for this list. Are the paths we
> register here always stable? I think they should be, as they are part of
> the "struct pat
git isn’t tracking folder renames when the case of the letters change, but it
will track it if the folder changes names. Is this intentional?
Here is an example:
08:51:26 ~/test $ git init
Initialized empty Git repository in /Users/kcoleman/test/.git/
08:51:29 ~/test (master #) $ mkdir main
08:
On Mon, Feb 02, 2015 at 05:56:55PM -0800, Junio C Hamano wrote:
> > I think this means we'll be
> > overly cautious with a patch that does:
> >
> > 1. add foo as a symlink
> >
> > 2. remove foo
> >
> > 3. add foo/bar
> >
> > which is perfectly OK
>
> No, such a patchset is broken.
>
> A va
2015-02-02 11:15 GMT-08:00 Junio C Hamano :
> Stefan Beller writes:
>
>> On 01.02.2015 14:51, /#!/JoePea wrote:
>>> I have this in my .gitignore:
>>>
>>> ./*.js
>>>
>>> I would expect that to cause git to ignore .js files in the same
>>> folder as .gitignore, but it doesn't do anything. However,
Are you, by any chance, on MacOS? HFS+ by default is
case-insensitive-but-case-preserving, and Git on MacOS by default runs
with core.ignorecase = true as a result.
If you set that to false does it change the behavior?
Hope this helps,
Bryan Turner
On Tue, Feb 3, 2015 at 12:56 PM, Kevin Coleman
Sorry for sending x2. I got a bounce notification the first time.
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
On Mon, Feb 02, 2015 at 11:52:21PM -0500, 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
On Mon, Feb 02, 2015 at 11:58:33AM -0500, Andrew Wong wrote:
> When "git status" recurses a directory that isn't readable (but
> executable), it should print out a warning/error. Currently, if there
> are untracked files in these directories, git wouldn't be able to
> discover them. Ideally, "git
If I am allowed to to some load thinking:
The commit msh header says:
reject input that touches outside $cwd
The commit message says:
By default, a patch that affects outside the working area
And the new command line option is this:
--unsafe-paths
(Which may be a good choice to pretend peo
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 was off.
-Kevin Coleman
> On Feb 3, 2015, at
57 matches
Mail list logo
