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
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
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
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
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
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
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,
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
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:
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
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
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: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 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..
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
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
"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
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
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.
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
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
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
"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
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
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 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 &&
> > +
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
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 -
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
>>
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
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
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)
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: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
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
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
> 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
---
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
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
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
> ---
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)
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
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..
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
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|
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
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 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
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
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
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
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
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"
57 matches
Mail list logo
