Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

2017-03-02 Thread Junio C Hamano
Jeff King writes: > On Tue, Feb 28, 2017 at 01:42:44PM -0800, Junio C Hamano wrote: > >> Jonathan Tan writes: >> >> > It could be argued that in the future, Git might need to distinguish >> > tree_objects from blob_objects - in particular, a user might

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

2017-02-28 Thread Jeff King
On Fri, Feb 24, 2017 at 05:18:36PM -0800, Jonathan Tan wrote: > Whenever tree_objects is set to 1 in revision.h's struct rev_info, > blob_objects is likewise set, and vice versa. Combine those two fields > into one. > > Some of the existing code does not handle tree_objects being different >

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

2017-02-28 Thread Jeff King
On Tue, Feb 28, 2017 at 01:42:44PM -0800, Junio C Hamano wrote: > Jonathan Tan writes: > > > It could be argued that in the future, Git might need to distinguish > > tree_objects from blob_objects - in particular, a user might want > > rev-list to print the trees but

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

2017-02-28 Thread Junio C Hamano
Jonathan Tan writes: > It could be argued that in the future, Git might need to distinguish > tree_objects from blob_objects - in particular, a user might want > rev-list to print the trees but not the blobs. That was exactly why these bits were originally made to

[PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

2017-02-24 Thread Jonathan Tan
Whenever tree_objects is set to 1 in revision.h's struct rev_info, blob_objects is likewise set, and vice versa. Combine those two fields into one. Some of the existing code does not handle tree_objects being different from blob_objects properly. For example, "handle_commit" in revision.c