On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong normalper...@yhbt.net wrote:
Torsten Bögershausen tbo...@web.de wrote:
(And why is it 0 and not 0777)
This is to preserve the uncommon sticky/sgid/suid bits. Probably not
needed, but better to keep as much intact as possible.
Can we avoid
On Mon, Jul 14, 2014 at 6:31 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong normalper...@yhbt.net wrote:
Torsten Bögershausen tbo...@web.de wrote:
You're saying this as if Windows is a single-user system. It's not,
but it uses ACLs rather than POSIX
Still, git might like to know what ACLs to apply to files at checkout
time. That would be a vast new feature, I think, and probably not
worth it, particularly since that would require dealing with the
different types of ACLs: NTFS/NFSv4/ZFS on the one hand, POSIX Draft
on the other, plus AFS
Am 14.07.2014 03:01, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Perhaps squashing this to 7e8e5af9 instead?
Yes please, this is much better than my first attempt.
One thing that I found troubling is the ../../../ three levels up
is hardcoded. Would it be always
Am 09.07.2014 22:00, schrieb Eric Wong:
Torsten Bögershausen tbo...@web.de wrote:
(And why is it 0 and not 0777)
This is to preserve the uncommon sticky/sgid/suid bits. Probably not
needed, but better to keep as much intact as possible.
Can we avoid the fchmod() all together ?
Karsten Blees karsten.bl...@gmail.com writes:
1.) Permissions of files in .git are controlled by the core.sharedRepository
setting, and your patch seems to break that (i.e. if someone accidentally
has made .git/config world readable, git-config no longer fixes that, even
if
Jens Lehmann jens.lehm...@web.de writes:
So what about adding Currently only submodules living in the
root directory of the superproject with the default name (same
as the path) are supported. to the comment above the function?
OK, done, and merged to 'next'.
Thanks.
--
To unsubscribe from
Jens Lehmann jens.lehm...@web.de writes:
Perhaps squashing this to 7e8e5af9 instead?
Yes please, this is much better than my first attempt.
One thing that I found troubling is the ../../../ three levels up
is hardcoded. Would it be always true for any value of $1? If
the submodule is bound
Am 10.07.2014 22:52, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
Jens Lehmann jens.lehm...@web.de writes:
I agree, but this case is special. The test asserts that nobody
added, modified or removed *anything* inside the .git directory.
The reason for problem we are
On 07/09/2014 11:57 PM, Junio C Hamano wrote:
Eric Wong normalper...@yhbt.net writes:
Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org writes:
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
Torsten Bögershausen tbo...@web.de writes:
Isn't the whole problem starting here:
in config.c:
fd = hold_lock_file_for_update(lock, config_filename, 0);
In lockfile.c:
/* This should return a meaningful errno on failure */
int hold_lock_file_for_update(struct lock_file *lk, const
Junio C Hamano gits...@pobox.com writes:
Jens Lehmann jens.lehm...@web.de writes:
I agree, but this case is special. The test asserts that nobody
added, modified or removed *anything* inside the .git directory.
The reason for problem we are seeing here is that I have to
remove the
On 2014-07-10 21.49, Junio C Hamano wrote:
[]
If we limit the case to Inherit permissions from the file we are
replacing by taking a lock on it, which is the topic of discussion
in this thread, we do not have to worry about how to configure the
value (we do not have to) and adding a new
Torsten Bögershausen tbo...@web.de writes:
On 2014-07-10 21.49, Junio C Hamano wrote:
[]
If we limit the case to Inherit permissions from the file we are
replacing by taking a lock on it, which is the topic of discussion
in this thread, we do not have to worry about how to configure the
There seems to be some other trouble under Mac OS, not yet fully tracked down,
(may be related to the diff -r)
Torsten sees failures of this kind under Mac OS:
diff -r .git/modules/sub1/config sub1/.git/config
6d5
worktree = ../../../sub1
8a8
worktree = ../../../sub1
So the config
On 07/08/2014 10:25 PM, Ramsay Jones wrote:
On 08/07/14 20:34, Jens Lehmann wrote:
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or
Torsten Bögershausen tbo...@web.de writes:
A brute force approach could be to simply run the config file(s)
through sort and compare them:
sort .git/modules/sub1/config expect
sort sub1/.git/config actual
test_cmp expect actual
Or git config --list from these files, perhaps?
--
To
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
failed: Function not implemented
I'm not sure what this is about, seems to happen during the cp -R of
the
Am 09.07.2014 08:14, schrieb Torsten Bögershausen:
There seems to be some other trouble under Mac OS, not yet fully tracked
down,
(may be related to the diff -r)
Torsten sees failures of this kind under Mac OS:
diff -r .git/modules/sub1/config sub1/.git/config
6d5
worktree =
Johannes Sixt j...@kdbg.org writes:
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
failed: Function not implemented
I'm not sure what this is about,
Jens Lehmann jens.lehm...@web.de writes:
I agree, but this case is special. The test asserts that nobody
added, modified or removed *anything* inside the .git directory.
The reason for problem we are seeing here is that I have to
remove the core.worktree setting when moving the git directory
Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org writes:
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
failed: Function not
Torsten Bögershausen tbo...@web.de wrote:
(And why is it 0 and not 0777)
This is to preserve the uncommon sticky/sgid/suid bits. Probably not
needed, but better to keep as much intact as possible.
Can we avoid the fchmod() all together ?
For single-user systems, sure.
For
Eric Wong normalper...@yhbt.net writes:
Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org writes:
Am 08.07.2014 21:34, schrieb Jens Lehmann:
And Msysgit complains
error: fchmod on c:/xxxt/trash
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
Amended locally here already; thanks,
On 08/07/14 20:34, Jens Lehmann wrote:
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
On 08/07/14 21:25, Ramsay Jones wrote:
On 08/07/14 20:34, Jens Lehmann wrote:
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
Amended locally here already; thanks, both.
-8
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index
On 2014-07-07 19.05, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
Amended locally here already; thanks, both.
There seems to be some other trouble under
Am 03.07.2014 07:56, schrieb Torsten Bögershausen:
On 07/02/2014 09:57 PM, Jens Lehmann wrote:
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700
Many submodule tests are broken.
One problem is here:
lib-submodule-update.sh:264: possible problem: echo -n is not
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't fixed yet.
On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700
Many
On 07/02/2014 09:57 PM, Jens Lehmann wrote:
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't fixed yet.
On what I have on pu
This is the series I sought feedback for some time ago in gmane/$245048. It
took longer than I expected to finish this series because I had to diagnose
the test failures I saw with some of the ten commands I added since then.
They boiled down to four different inconsistencies in Git's handling of
34 matches
Mail list logo
