On Thu, Feb 8, 2024 at 12:00 PM Phillip Wood via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
> Rebase records the oid of HEAD before rebasing and the commit created by
> "--autostash" in files in the rebase state directory. This means that
> the autostash commit is never reachable from any ref or reflog and when
> rebasing a detached HEAD the original HEAD can become unreachable if the
> user expires HEAD's the reflog while the rebase is running. Fix this by
> reading the relevant files when marking reachable commits.
>
> Note that it is possible for the commit recorded in
> .git/rebase-merge/amend to be unreachable but pruning that object does
> not affect the operation of "git rebase --continue" as we're only
> interested in the object id, not in the object itself.
>
> Reported-by: Orgad Shaneh <orgads@xxxxxxxxx>
> Signed-off-by: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
> ---
> diff --git a/reachable.c b/reachable.c
> @@ -30,6 +31,53 @@ static void update_progress(struct connectivity_progress *cp)
> +static int add_one_file(const char *path, struct rev_info *revs)
> +{
> + struct strbuf buf = STRBUF_INIT;
> +
> + if (!read_oneliner(&buf, path, READ_ONELINER_SKIP_IF_EMPTY)) {
> + strbuf_release(&buf);
> + return 0;
> + }
> + strbuf_trim(&buf);
> + if (!get_oid_hex(buf.buf, &oid)) {
> + object = parse_object_or_die(&oid, buf.buf);
> + add_pending_object(revs, object, "");
> + }
> + return 0;
> +}
Is this leaking the strbuf? Should the function instead end with:
strbuf_release(&buf);
return 0;
Also, what is the significance of the return value of this function?
All code paths seem to be returning 0 unconditionally, and the caller
ignores the return value.
> +/* Mark objects recored in rebase state files as reachable. */
s/recored/recorded/
