On 05/03/2017 09:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
I see the semantics as "don't write what you already have", where
"have" means what you have in local storage, but if you extend "have"
to what upstream has, then yes, you're right that this changes
(ignoring shallow clones).
Jonathan Tan writes:
> I see the semantics as "don't write what you already have", where
> "have" means what you have in local storage, but if you extend "have"
> to what upstream has, then yes, you're right that this changes
> (ignoring shallow clones).
>
> This does remove a resistance that we
On 05/02/2017 11:32 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote:
On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
Jonathan Tan writes:
On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
Thanks for your comments. If you're r
On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote:
> On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
>> Jonathan Tan writes:
>>
>>> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
> Thanks for your comments. If you're referring to the codepath
> invol
On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
> Jonathan Tan writes:
>
>> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
>>> Jonathan Tan writes:
>>>
Thanks for your comments. If you're referring to the codepath
involving write_sha1_file() (for example, builtin/hash-object ->
>>
Jonathan Tan writes:
> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
>> Jonathan Tan writes:
>>
>>> Thanks for your comments. If you're referring to the codepath
>>> involving write_sha1_file() (for example, builtin/hash-object ->
>>> index_fd or builtin/unpack-objects), that is fine because
>>>
On 05/01, Jonathan Tan wrote:
> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
> >Jonathan Tan writes:
> >
> >>Thanks for your comments. If you're referring to the codepath
> >>involving write_sha1_file() (for example, builtin/hash-object ->
> >>index_fd or builtin/unpack-objects), that is fine bec
On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
Thanks for your comments. If you're referring to the codepath
involving write_sha1_file() (for example, builtin/hash-object ->
index_fd or builtin/unpack-objects), that is fine because
write_sha1_file() invokes freshen_packed_o
Jonathan Tan writes:
> Thanks for your comments. If you're referring to the codepath
> involving write_sha1_file() (for example, builtin/hash-object ->
> index_fd or builtin/unpack-objects), that is fine because
> write_sha1_file() invokes freshen_packed_object() and
> freshen_loose_object() dire
On 04/30/2017 08:57 PM, Junio C Hamano wrote:
One thing I wonder is what the performance impact of a change like
this to the codepath that wants to see if an object does _not_ exist
in the repository. When creating a new object by hashing raw data,
we see if an object with the same name already
Jonathan Tan writes:
> In order to determine the code changes in sha1_file.c necessary, I
> investigated the following:
> (1) functions in sha1_file that take in a hash, without the user
> regarding how the object is stored (loose or packed)
> (2) functions in sha1_file that operate on pac
11 matches
Mail list logo
