Re: rebase -i --update-refs can lead to deletion of branches

From: Victoria Dye <vdye@github.com>
Date: Nov 4, 2022, 00:31 UTC
Message-ID: <123628cc-1410-aaa0-0151-2dff35bd1855@github.com>
In-Reply-To: <CAFzd1+5F4zqQ1CNeY2xaaf0r__JmE4ECiBt5h5OdiJHbaE78VA@mail.gmail.com>

herr.kaste wrote:

> Now, I should just have not used `--update-refs` in the first place but anyway
> I decide late that I rather don't want to update "master" etc. and it should
> probably not delete the local refs.
>

Agreed, this doesn't seem like desired behavior - the opposite of "update the ref" isn't "delete the ref". ;)

The reason it's happening is because, when '--update-refs' is used, the rebase starts by constructing a list of 'update_ref_record's for each of the refs that *could* be updated. Each item in that list contains the corresponding ref's "before" commit OID (i.e., what it currently points to) and initializes the "after" OID to null. When an 'update-ref' line is encountered in the 'rebase-todo', the "after" OID is updated with the newly-rebased value. However, if an 'update-ref' line is removed from the 'rebase-todo', the "after" value is never updated. Then, when the rebase finishes and the ref state data is applied, all of the entries with null "after" OIDs are deleted.

The three options for a fix I can think of are:

  1. initialize the "after" OID to the value of "before".
  2. don't update refs with a null "after" OID.
  3. initialize the "after" OID to the value of "before", don't update the
     ref if "before" == "after".

I think #3 is the best option, since it avoids the unnecessary updates of #1 and leaves a cleaner path to a 'delete-ref' option (like the one proposed elsewhere in the thread [1]) than #2. I'll send a patch shortly.

[1] https://lore.kernel.org/git/CA+JQ7M-GbBTHZZ9xOLR=FitWFpUnkfuep9kSfNPxuSbJbKteGw@mail.gmail.com/

Thanks for reporting!
- Victoria