On 2020-05-21 at 17:35:22, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > ... The only case in which we do not have a commit object is when > > invoking git switch with --orphan. Moreover, we can only hit this code > > path without a commit object additionally with either --force or > > --discard-changes. > > It was easy for me to trace the codepath to see when these options > are used we end up with no commit object, but I ran out of time > trying to see if the "forced orphan" is the only way to end up with > a NULL in new_branch_info->commit. Assuming that is true, of course > the following perfectly makes sense. I believe it is. The only case in which we have a NULL commit as far as I can tell is with switch and an orphan, and in merge_working_tree we call reset_tree either if the changes are discarded or unpack_trees couldn't do a trivial merge. Since I'm pretty sure unpack_trees can indeed merge with the empty tree, we would only call reset_trees with --discard-changes or --force. And reset_tree is only called from merge_working_tree. In addition, I did try other situations plus the entire testsuite with my erroneous first patch and was unable to cause a segfault anywhere (which would have been a trivial NULL dereference) in case I missed something, which leads me to believe that this is in fact the only situation in which this occurs. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
