From: Junio C Hamano gits...@pobox.com
Jeff King p...@peff.net 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
From: Jeff King p...@peff.net
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
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
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 means
Jeff King p...@peff.net 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
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
6 matches
Mail list logo