git-branchless moves main branch whenever I run git reset on another branch

[nyanpasu64]

I installed git branchless and ran git branchless init because I wanted to try out git move and perhaps restack, not because I'm interested in a branchless workflow (I like my named branches very much thanks).

I originally installed 0.3.6 and ran init on that version, but tried upgrading to 0.3.7 and reran init to check if the bug is fixed (it's not). branchless is configured with dev as my main branch.

When I checkout any other branch or detached HEAD (both behind or ahead of dev), then run a command like git reset, git-branchless somehow moves dev to the current commit (which shouldn't happen in unmodified Git), printing branchless: processing 1 update: branch dev. I'm not sure if any other commands cause this issue; checkout and commit don't.

Running git branch -f dev origin/dev fixes it... but the next time I checkout a branch or detached HEAD, then run any mutating command, branchless moves dev to the current commit again. This happens on every mutating command, regardless if I git branch -f dev origin/dev or not.

[arxanas]

Hi @nyanpasu64, thanks for reporting, and sorry that this is happening to you.

I'm not at a computer right now, so I'll investigate further when I get a chance later.

In principle, none of the hooks should actually be moving branches or touching Git objects. However, it might be that git-branchless is adding bad events to its internal event log, and this is corrupting the smartlog output. Can you confirm: is the branch really pointing to the wrong location in Git, or does it just appear to be pointing to the wrong location in the smartlog, etc.?

You can also try running with the environment variable RUST_LOG=info git checkout ... or RUST_LOG=debug git checkout ... and upload the logs here so I can examine them (see also https://github.com/arxanas/git-branchless/wiki/Coding#logging). It might give a clue as to what's happening.

Are you using a non-standard setup in any way? In particular, is dev a symbolic reference? You can check with git symbolic-ref dev.

[arxanas]

Also, can you clarify what you use git reset for in your workflow, in particular vs git checkout?

[nyanpasu64]

Sorry I ran into a Firefox rendering bug, then a performance bug, so I got distracted debugging that.

is the branch really pointing to the wrong location in Git

Yes, git show and tig show the branch pointing to the current commit.

is dev a symbolic reference? You can check with git symbolic-ref dev.

fatal: ref dev is not a symbolic ref

You can also try running with the environment variable RUST_LOG=info git checkout ... or RUST_LOG=debug git checkout ... and upload the logs here so I can examine them (see also arxanas/git-branchless/wiki/Coding#logging). It might give a clue as to what's happening.

Output of git checkout HEAD and git reset: gist

Is it worth uploading the SQLite file here?

Note that I often use git revise, which apparently doesn't run Git hooks, and perhaps leads to branchless's state desynchronizing from Git's? I'm not sure if that's the cause of this issue, but if so, can you handle it more cleanly?

Also, can you clarify what you use git reset for in your workflow, in particular vs git checkout?

I use git reset --hard to discard uncommitted changes, git reset --keep for moving a checked-out branch while ignoring uncommitted changes and aborting on conflicts, and git reset for clearing staged changes (and occasionally to move the branch of HEAD while keeping the filesystem untouched), and git reset --soft occasionally to move the branch of HEAD while keeping the old state in the index.

I use git checkout for switching branches, git checkout -b to create and checkout a branch, and git checkout -f to move and checkout a branch. I use git branch -f to move a branch only. (Honestly I think git branch --checkout is nicer than git checkout -b, but it's likely too late to propose that as a new command.)

[nyanpasu64]

The bug persists after git branchless init --uninstall. I'm not sure if it's branchless causing it...

[arxanas]

Just to make sure, can you check the contents of the hooks in .git/hooks and make sure that they don't invoke git-branchless anymore? If they appear to be no-ops, also try deleting them, just in case it somehow changed the behavior of some operation.

I thought I had seen something like this before a long time ago in development, but I never got a repro case for it.

[arxanas]

Maybe the problem is that the reference-transaction hook is exiting with error. Under some circumstances, this will cause the transaction to be rejected (https://git-scm.com/docs/githooks#_reference_transaction), which could give the appearance that the branch is moving back to its old location. Could you try deleting the reference-transaction hook and see if the behavior persists?

[nyanpasu64]

The bug persists after cargo uninstall git-branchless, git branchless init --uninstall and removing the fish alias, and clearing all non-sample hooks, or even renaming hooks to hooks~. The issue occurs when running git reset with fish, bash, and sh. Copying the repository to a new folder preserves the bug. Cloning my local folder to a new folder doesn't preserve the bug. Creating a worktree pointing to the same .git folder, then git reset, doesn't trigger the bug.

There's something in .git causing this behavior, I don't know what yet.

[nyanpasu64]

In my buggy repo, .git/ORIG_HEAD contains ref: refs/heads/dev. In a good repo, .git/ORIG_HEAD contains a SHA1 hash. Copying this file from my bad repo to a new clone's .git causes this behavior.

I'm not sure if git branchless caused ORIG_HEAD to point to a branch rather than a commit ID, but it seems that your repo mentions ORIG_HEAD, so it's at least plausible. I haven't figured out what command would cause this behavior though (I reinstalled branchless but not the fish alias, and tried poking around but didn't trigger the issue).

[arxanas]

Thanks for looking into it. That must be the issue. git-branchless does modify ORIG_HEAD during git move/git restack for on-disk rebases (which presumably you ran at some point?), in an attempt to set it correctly so that git rebase --abort works. Either it's not supposed to be a symbolic reference, or it should have been cleaned up at some point. I'm guessing the former.

I'm not exactly sure what ORIG_HEAD has to do with git reset, but I'm sure it'll become clear once I look into it more.

[arxanas]

I opened #151 to track this issue. If you happen to find specific repro steps, let me know.

[arxanas]

I suppose this is what happens:

• You check out a branch. This sets HEAD to be a symbolic reference.
• You use git move or git restack, which currently copies HEAD to ORIG_HEAD. (This behavior is evidently wrong.)
• You later use a non-branchless command which writes to ORIG_HEAD, like git reset. For whatever reason, the responsible code writes to the reference, but it unpeels the symbolic reference first. This means that its target branch is overwritten with its original value, which would ordinarily be saved in ORIG_HEAD as a backup.

This is a rare occurrence for me because 1) usually my HEAD is detached, so it's a direct rather than symbolic reference, and 2) I don't tend to use Git commands which write to ORIG_HEAD.

[arxanas]

Furthermore, ORIG_HEAD is only written if the git move/git restack command happens to be an on-disk invocation (such as if there were merge conflicts, or if you specifically requested --on-disk).

It looks like this reproduces the issue, and causes foo to move even though it's not checked out:

$ git checkout -b foo
$ git move --on-disk -d HEAD^
$ git checkout --detach
$ git reset --hard HEAD^
$ git reset --hard HEAD^

[arxanas]

Thanks again for reporting this bug and for investigating it. This should be fixed in #173. You can try installing from source to pick up the latest changes (cargo install --locked --git https://github.com/arxanas/git-branchless).

[nyanpasu64]

I installed branchless into a test repo, and the bug seems fixed.

Note that I've stopped using branchless for the time being. My goal was to adopt branchless incrementally, picking and choosing the pieces useful for my branch-based workflow. I hoped that git move could replace "rebase many branches at once", but I have to spell it git branchless move (which is annoying to type) unless I run git branchless init. And doing so breaks my prior workflow, since git operations now start creating refs which clog up git log and tig output (jonas/tig#1160, #171). A hack is to run git branchless init then deleting the hooks. However, git move still creates branchless refs.

Additionally, git move doesn't match rebase since if I run it with a branch checked out, it leaves me on a detached HEAD rather than the starting branch (which points to a new commit). Before I keep working, I have to look in my terminal prompt to see which branch I had checked out before git move (I think fish's git prompt also shows that the current detached HEAD matches a branch) and check it out again.

I think I still don't understand git move. And it just deleted one of my branches. Is this supposed to happen?

nyanpasu64@ryzen ~/code/exotracker-redux (dev)> git move -s dev -d save-as-folder
Attempting rebase in-memory...
[1/4] Skipped commit (was already applied upstream): c0b22ea2 Add "New" action for reopening default document
[2/4] Skipped commit (was already applied upstream): 1e504dc8 On "save as" failure, prompt for a different path
[3/4] Committed as: 0c007e2a ???
[4/4] Committed as: 4bbbf352 deduplicate?
branchless: running command: git checkout b10ccdc4ba41a96024c476bff782f816e006937b
Previous HEAD position was c0b22ea2 Add "New" action for reopening default document
HEAD is now at b10ccdc4 If file open, use current file's folder for "save as"
In-memory rebase succeeded.
nyanpasu64@ryzen ~/code/exotracker-redux ((save-as-folder)) [1]> git show dev
fatal: ambiguous argument 'dev': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

[arxanas]

Thanks for the feedback. You should be able to alias git move normally, i.e. with git config --global alias.move "branchless move" to make it accessible in repositories. I've opened #183 to support the idea of not generating branchless references when using git move standalone.

I think I still don't understand git move. And it just deleted one of my branches. Is this supposed to happen?

Yes, this is the intended behavior, intended to fix a deficiency in git rebase. There's a note in the last bullet point in the documentation:

When you move the current commit and it exists upstream, and there is a branch pointing to that commit, the commit and branch are deleted. git rebase deletes the commit, but preserves the branch (which now points to the wrong commit).

Presumably dev pointed to the first commit in your list c0b22ea2 Add "New" action for reopening default document, which existed already in the destination save-as-folder, so the dev branch was deleted. It seems like you were relying on the behavior of the branch being preserved but pointing to the destination commit?

It appears that your workflow is the opposite of what I had in mind for git move. Normally, it expects that you're moving a feature branch on top of a main development branch, i.e. git move -s save-as-folder -d dev, so that if the feature branch was merged upstream, it would disappear. What does the branch dev represent here?

[nyanpasu64]

It appears that your workflow is the opposite of what I had in mind for git move.

Oops I got it backwards I guess. I didn't actually have a workflow in mind, I was experimenting in a copy of my repo so I wouldn't damage my main repo, and I didn't have any feature branches left to move, so it wasn't the best situation to do testing. So I ended up moving my main branch (dev) on top of a random older tag.

[arxanas]

As of #183, it should be possible to use git branchless move on repositories without running git branchless init. If you want to make it easier to invoke, then set a global alias with git config --global alias.move "branchless move".

[KevinWuWon]

I'm seeing a similar issue. I installed from source 2 days ago.

I started on a branch called kww-line-bootstrap. My main branch is called green and there's another branch called kww-line:

│◇ 4d2f69b4 1d (green)
│┣━┓
│⋮ ◯ 43fba8b9 18h stuff
│⋮ ┣━┓
│⋮ ┃ ◯ a4a467e3 17h stuff
│⋮ ┃ ┣━┓
│⋮ ┃ ┃ ◯ 4446b3cc 17h stuff
│⋮ ┃ ┃ ┃
│⋮ ┃ ┃ ◯ 913f780e 17h stuff
│⋮ ┃ ┃ ┃
│⋮ ┃ ┃ ◯ f0fb5fdf 17h stuff
│⋮ ┃ ┃ ┃
│⋮ ┃ ┃ ◯ 1d62e6fa 17h stuff
│⋮ ┃ ┃ ┃
│⋮ ┃ ┃ ◯ 3e0918f8 17h stuff
│⋮ ┃ ┃
│⋮ ┃ ◯ b905bd20 17h stuff
│⋮ ┃ ┃
│⋮ ┃ ◯ 9c833b9b 13h stuff
│⋮ ┃ ┃
│⋮ ┃ ◯ 9a667526 13h stuff
│⋮ ┃ ┃
│⋮ ┃ ◯ 2270a783 13h (kww-line) stuff
│⋮ ┃
│⋮ ● b466e31b 2h (kww-line-bootstrap) stuff

I typed:

$ git checkout green

results in this event:

Transaction 835, event 1138:
1. Check out from b466e31b to 4d2f69b4

I typed:

$ git pull --ff-only

results in these events:

Transaction 836, event 1139:
1. Create branch kww-line at 4d2f69b4
2. Check out from 4d2f69b4 to 80211be0
3. Move branch green from 4d2f69b4 to 80211be0
4. Commit 80211be0

Step 1 in the above is the WTF. Step 4 also seems unnecessary?

As a result, here is the tree:

◇ 4d2f69b4 1d (kww-line) stuff
┣━┓
⋮ ◯ 43fba8b9 18h stuff
⋮ ┣━┓
⋮ ┃ ◯ a4a467e3 18h stuff
⋮ ┃ ┣━┓
⋮ ┃ ┃ ◯ 4446b3cc 18h stuff
⋮ ┃ ┃ ┃
⋮ ┃ ┃ ◯ 913f780e 18h stuff
⋮ ┃ ┃ ┃
⋮ ┃ ┃ ◯ f0fb5fdf 18h stuff
⋮ ┃ ┃ ┃
⋮ ┃ ┃ ◯ 1d62e6fa 18h stuff
⋮ ┃ ┃ ┃
⋮ ┃ ┃ ◯ 3e0918f8 18h stuff
⋮ ┃ ┃
⋮ ┃ ◯ b905bd20 18h stuff
⋮ ┃ ┃
⋮ ┃ ◯ 9c833b9b 13h stuff
⋮ ┃ ┃
⋮ ┃ ◯ 9a667526 13h stuff
⋮ ┃ ┃
⋮ ┃ ◯ 2270a783 13h stuff
⋮ ┃
⋮ ◯ b466e31b 3h (kww-line-bootstrap) stuff
⋮
◆ 80211be0 4h (green) stuff

Observe that kww-line now points at 4d2f69b4. Expect it to still be at 2270a783

I have the following hooks:

• post-checkout
• post-commit
• post-merge
• post-rewrite
• pre-auto-gc
• reference-transaction

[KevinWuWon]

My .git/ORIG_HEAD currently says:

ref: refs/heads/kww-line

[arxanas]

@KevinWuWon if you delete .git/ORIG_HEAD, it should resolve the issue. Does it get recreated by some command?

[KevinWuWon]

OK I deleted it and did another git pull and didn't see the problem this time. Hopefully that was the last of it.

Thanks!