rebase update-refs can delete ref branch

rebase update-refs can delete ref branch

[Eric Musser]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
$ git init
Initialized empty Git repository in /home/emusser/git/test/.git/
$ git checkout -b working-branch
Switched to a new branch 'working-branch'
$ git commit -m "commit 1" --allow-empty
[working-branch (root-commit) 1238cf8] commit 1
$ git commit -m "commit 2" --allow-empty
[working-branch 2dd4408] commit 2
$ git branch other-branch
$ git commit -m "commit 3" --allow-empty
[working-branch 39f626e] commit 3
$ git rebase -i --update-refs HEAD~2
[I am presented]:
pick 2dd4408 commit 2 # empty
update-ref other-branch

pick 39f626e commit 3 # empty

[I deleted first two lines and submitted]:
pick 39f626e commit 3 # empty

Successfully rebased and updated refs/heads/working-branch.
Updated the following refs with --update-refs:
refs/heads/other-branch
$ git rev-parse other-branch
other-branch
fatal: ambiguous argument 'other-branch': unknown revision or path not
in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

What did you expect to happen? (Expected behavior)
The branch I interactively removed from the rebase to not actually be
deleted. It is common
to remove unrelated changes (and refs) from your working branch before pushing.
I'd hope in this case I would not have to use `git rebase
--no-update-refs' (if I'm set
in my config UpdateRefs=true) to avoid branches from being deleted.

What happened instead? (Actual behavior)
The branch was deleted.

What's different between what you expected and what actually happened?
The branch was deleted when I would expect branches that are no longer listed
to not be updated or deleted.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.38.0
cpu: aarch64
built from commit: 3dcec76d9df911ed8321007b1d197c1a206dc164
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.16.13-generic #2 SMP Fri Mar 11 12:48:38 UTC 2022 aarch64
compiler info: gnuc: 10.2
libc info: glibc: 2.17
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]
pre-commit

Re: rebase update-refs can delete ref branch

[Victoria Dye]

Hi Eric!

> [I am presented]:
> pick 2dd4408 commit 2 # empty
> update-ref other-branch
> 
> pick 39f626e commit 3 # empty
> 
> [I deleted first two lines and submitted]:
> pick 39f626e commit 3 # empty
> 
> Successfully rebased and updated refs/heads/working-branch.
> Updated the following refs with --update-refs:
> refs/heads/other-branch
> $ git rev-parse other-branch
> other-branch
> fatal: ambiguous argument 'other-branch': unknown revision or path not
> in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'

I believe this is the same bug as one reported back in October [1], where
deleting all 'update-ref' lines from the 'rebase-todo' inadvertently causes
the rebase to delete those refs. The bug was fixed in 44da9e0841 (rebase
--update-refs: avoid unintended ref deletion, 2022-11-07), so you shouldn't
see the issue anymore in Git that's built from newer revisions (e.g., the
latest pre-release v2.39.0-rc2 or the upcoming final v2.39.0).

I hope that helps!
- Victoria

[1] https://lore.kernel.org/git/CAFzd1+5F4zqQ1CNeY2xaaf0r__JmE4ECiBt5h5OdiJHbaE78VA@mail.gmail.com/

> [System Info]
> git version:
> git version 2.38.0
> cpu: aarch64
> built from commit: 3dcec76d9df911ed8321007b1d197c1a206dc164
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 5.16.13-generic #2 SMP Fri Mar 11 12:48:38 UTC 2022 aarch64
> compiler info: gnuc: 10.2
> libc info: glibc: 2.17
> $SHELL (typically, interactive shell): /bin/bash
> 
> 
> [Enabled Hooks]
> pre-commit

Re: rebase update-refs can delete ref branch

[Junio C Hamano]

Victoria Dye <vdye@github.com> writes:

> I believe this is the same bug as one reported back in October [1], where
> deleting all 'update-ref' lines from the 'rebase-todo' inadvertently causes
> the rebase to delete those refs. The bug was fixed in 44da9e0841 (rebase
> --update-refs: avoid unintended ref deletion, 2022-11-07), so you shouldn't
> see the issue anymore in Git that's built from newer revisions (e.g., the
> latest pre-release v2.39.0-rc2 or the upcoming final v2.39.0).

Thanks for digging the history.  It is unfortunate that, even though
the fix exactly identifies b3b1a21d (sequencer: rewrite update-refs
as user edits todo list, 2022-07-19) as the culprit and it is trivial
to see that was shipped as part of Git 2.38, the fix was not queued
to allow merging 44da9e0841 into 2.38.x maintenance track, so it is
unlikely to appear in any 2.38.x maintenance releases we might issue
in the future.

But if the users can afford to update to 2.38.x or 2.39.0, picking
the latter is always better, as the newer feature release has longer
shelf life ;-)

Re: rebase update-refs can delete ref branch

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Thanks for digging the history.  It is unfortunate that, even though
> the fix exactly identifies b3b1a21d (sequencer: rewrite update-refs
> as user edits todo list, 2022-07-19) as the culprit and it is trivial
> to see that was shipped as part of Git 2.38, the fix was not queued
> to allow merging 44da9e0841 into 2.38.x maintenance track, so it is
> unlikely to appear in any 2.38.x maintenance releases we might issue
> in the future.

Well, I changed my mind.  Let's bite the bullet and cherry-pick the
single patch, just for this once (as a general principle, I hate
cherry-picking and try to avoid unless the fix is absolutely needed).

This is primarily because we have enough material to prepare for
Git 2.38.2 already accumulated on the 'maint' front, all from the
bugfixes merged to 'master' for the upcoming Git 2.39.

I'd plan to tag 2.38.2 and 2.39 at the same time on coming Monday,
but note that I am operating in Asia/Tokyo timezone, so it may be
Sunday for many folks in the western hemisphere.