Jens Lehmann 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 this list: send
Karsten Blees 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 core.sharedRepository=0600).
For any
Am 09.07.2014 22:00, schrieb Eric Wong:
> Torsten Bögershausen 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 ?
Am 14.07.2014 03:01, schrieb Junio C Hamano:
> Jens Lehmann 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
> 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
On Mon, Jul 14, 2014 at 6:31 AM, Erik Faye-Lund wrote:
> On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong wrote:
>> Torsten Bögershausen wrote:
>>
>
> You're saying this as if Windows is a single-user system. It's not,
> but it uses ACLs rather than POSIX permissions to manage file-system
> permission
On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong wrote:
> Torsten Bögershausen 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 to
Jens Lehmann 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 to the super
Am 10.07.2014 22:52, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> Jens Lehmann 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
Torsten Bögershausen 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
>> value
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 p
Junio C Hamano writes:
> Jens Lehmann 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 th
Torsten Bögershausen 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 char
> *
On 07/09/2014 11:57 PM, Junio C Hamano wrote:
Eric Wong writes:
Junio C Hamano wrote:
Johannes Sixt 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
Eric Wong writes:
> Junio C Hamano wrote:
>> Johannes Sixt 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: Func
Torsten Bögershausen 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 multi-user syst
Junio C Hamano wrote:
> Johannes Sixt 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
> >>
>
Jens Lehmann 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
> from .git/modu
Johannes Sixt 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, s
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
>> <
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
Torsten Bögershausen 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 actual &&
> test_cmp expect actual &&
Or "git config --list" from these files, perhaps?
--
To unsubscribe from t
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 writes:
Junio, do you want me to resend 02/14 without the non-portable "echo -n"
or could you just sq
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 conf
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 writes:
> Junio, do you want me to resend 02/14 without the non-portable "echo -n"
> o
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 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?
Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
> On 2014-07-07 19.05, Junio C Hamano wrote:
>> Jens Lehmann 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, bo
On 2014-07-07 19.05, Junio C Hamano wrote:
> Jens Lehmann 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 Mac OS, n
Jens Lehmann 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 24c9fd7..358
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,
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 7a0da7902cbbc9a876b9
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
>
> Ma
(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 porta
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 n
34 matches
Mail list logo
