Re: [PATCH v2 1/2] builtin/checkout: simplify metadata initialization
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- May 23, 2020, 12:22 UTC
- Message-ID
- <20200523122205.GA1915090@camp.crustytoothpaste.net>
- In-Reply-To
- <xmqq1rndtcmd.fsf@gitster.c.googlers.com>
On 2020-05-21 at 17:35:22, Junio C Hamano wrote:
Show 12 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> 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