Re: [PATCH v4 4/6] rev-list: handle missing tree objects properly

> > So we don't want to die in list-objects.c. If we > > fail to fetch, then we will die on line 213 in rev-list.c. > > Why don't we want to die in list-objects.c? When --missing=error is > passed, fetch_if_missing retains its default value of 1, so > parse_tree_gently() will attempt to fetch it

Re: [PATCH v4 4/6] rev-list: handle missing tree objects properly

> > > @@ -373,6 +375,7 @@ int cmd_rev_list(int argc, const char **argv, const > > > char *prefix) > > > init_revisions(, prefix); > > > revs.abbrev = DEFAULT_ABBREV; > > > revs.commit_format = CMIT_FMT_UNSPECIFIED; > > > + revs.do_not_die_on_missing_tree = 1; > > > > Is this

Re: [PATCH v4 4/6] rev-list: handle missing tree objects properly

On Tue, Aug 14, 2018 at 11:06 AM Jonathan Tan wrote: > > > Previously, we assumed only blob objects could be missing. This patch > > makes rev-list handle missing trees like missing blobs. A missing tree > > will cause an error if --missing indicates an error should be caused, > > and the hash is

Re: [PATCH v4 4/6] rev-list: handle missing tree objects properly

> Previously, we assumed only blob objects could be missing. This patch > makes rev-list handle missing trees like missing blobs. A missing tree > will cause an error if --missing indicates an error should be caused, > and the hash is printed even if the tree is missing. The last sentence is

[PATCH v4 4/6] rev-list: handle missing tree objects properly

Previously, we assumed only blob objects could be missing. This patch makes rev-list handle missing trees like missing blobs. A missing tree will cause an error if --missing indicates an error should be caused, and the hash is printed even if the tree is missing. In list-objects.c we no longer