Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 20
1 file changed, 20 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index fda78bc..4579215 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1720,6 +1720,26 @@ static int ce_write_entry(git_SHA_CTX *c, int fd,
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> read-cache.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/read-cache.c b/read-cache.c
> index fda78bc..4579215 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1720,6 +1720,26 @@
On Fri, Jan 25, 2013 at 2:15 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> read-cache.c | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/read-cache.c b/read-cache.c
>> index fda78bc..4579215 100644
>
Duy Nguyen writes:
> Even
> when cache-tree is not involved, I do not want the index to point to
> an non-existing SHA-1 ("git diff --cached" may fail next time, for
> example).
I think we have tests that explicitly add SHA-1 that names an object
that does not exist to the index and check f
On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
> This is not a tangent, but if you want to go this "forbid making our
> repository depend on objects we do not have but we know about after
> we peek submodule odb" route [*1*], write_sha1_file() needs to be
> told about has_sha1_file_proper(
Duy Nguyen writes:
> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
>> This is not a tangent, but if you want to go this "forbid making our
>> repository depend on objects we do not have but we know about after
>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>> told
On Mon, Jan 28, 2013 at 12:54 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
>>> This is not a tangent, but if you want to go this "forbid making our
>>> repository depend on objects we do not have but we know about after
>>> we peek su
Duy Nguyen writes:
>>> Another thing needs to be done for this to work. The current reading
>>
>> For *what* to work???
>
> The "forbid making our repository depend on objects we do not have but
> we know about afterwe peek submodule odb"
With your "when our object database is contaminated, chec
On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
> Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
I think I went from one problem to another and did not make it clear.
The reason behind this preference is security. With "a
Duy Nguyen writes:
> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
>> Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
>
> I think I went from one problem to another and did not make it clear.
> The reason behind this p
On Mon, Jan 28, 2013 at 1:36 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
>>
>> I think I went from one problem
11 matches
Mail list logo
