From: Jeff King
>
> On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote:
>
>> Here is a patch series to improve the way sha1_object_info_extended()
>> behaves when it is passed a replaced object.
>
> Overall looks OK to me.
Thanks for reviewing it.
[...]
> I checked the resultin
From: Junio C Hamano
>
> Jeff King writes:
>
>> On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
>>
>>> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
>>> directly in lookup_replace_object. That means that it is now a
>>> meaningful flag for sha1_object_info_ext
Jeff King writes:
> On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
>
>> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
>> directly in lookup_replace_object. That means that it is now a
>> meaningful flag for sha1_object_info_extended, even though the name does
On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
> directly in lookup_replace_object. That means that it is now a
> meaningful flag for sha1_object_info_extended, even though the name does
> not say so. It also mean
On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote:
> Here is a patch series to improve the way sha1_object_info_extended()
> behaves when it is passed a replaced object.
> [...]
> Christian Couder (5):
> replace_object: don't check read_replace_refs twice
> introduce lookup_repl
Here is a patch series to improve the way sha1_object_info_extended()
behaves when it is passed a replaced object.
This patch series was inspired by a sub thread in this discussion:
http://thread.gmane.org/gmane.comp.version-control.git/238118
Patches 1/5 and 2/5 are cleanups.
Patch 4/5 adds a t
6 matches
Mail list logo