I've got an unexpected behaviour while using `rebase -i`

[XDcedar]

Hello, I am currently learning Git using your excellent website. But I encountered an unexpected behavior while using the rebase -i command on level mixed2. It appears to be different from the actual Git command behavior.

Here is how to reproduce this issue:

1. Create a new repo
   Commands I use

git init
echo "commit" >> test.txt
git add .
git commit -m "C0"
echo "commit" >> test.txt
git add .
git commit -m "C1"
git switch -c newImage
echo "commit" >> test.txt
git add .
git commit -m "C2"
git switch -c caption
echo "commit" >> test.txt
git add .
git commit -m "C3"

And here is the result:

# show graph
git log --oneline --graph --all

* 62e95dd (HEAD -> caption) C3
* 1f4ae67 (newImage) C2
* f6b7a2c (main) C1
* 16aef50 C0

2. Execute the command git rebase -i HEAD~2, as per the solution provided on your website.

   
   git switch caption
   git rebase -i HEAD~2

exchange these two commits. same as the solution on website shows

pick 62e95dd # C3 pick 1f4ae67 # C2

resolve the conflicts and then...

git add . git rebase --continue

After executing these commands, I noticed that the rebase procedure ended with the missing commit `C3`. And the log would be like

• 1f4ae67 (HEAD -> caption, newImage) C2
• f6b7a2c (main) C1
• 16aef50 C0

  
  This behavior is totally different from what was expected based on what I learned from your website. I'm not sure whether this is a bug or not. Could you please let me know if I have missed anything or done something wrong?

[Netz00]

I was unable to reproduce your output.

1. Initial

   * da41c58 (HEAD -> caption) C3
   * 8012985 (newImage) C2
   * 72bcc6e (main) C1
   * 8d10241 C0

2. git rebase -i HEAD~2

   • Result after git add . && git rebase --continue 1st time

   • 4cd2938 (HEAD) C3 | da41c58 (caption) C3 | 8012985 (newImage) C2 |/
   • 72bcc6e (main) C1
   • 8d10241 C0

• Result after git add . && git rebase --continue 2nd time

• d664655 (HEAD -> caption) C2
• 4cd2938 C3 | * 8012985 (newImage) C2 |/
• 72bcc6e (main) C1
• 8d10241 C0

[XDcedar]

Thank you for your reply! I noticed that you've run rebase --continue twice, while I only ran it once. (Git didn't ask me to run it again.) This behaviour led me to try some further testing, and I found something new that may help:

1. I'm using Windows 11. It appears that when using the echo command in Windows 11, a UTF16-LE file is created, which Git treats as a binary file. As a result, the conflict hints fail to show up, and if I run git add . followed by git rebase --continue without making any modifications, the rebase procedure ends prematurely with only three remaining commits, which is what I showcased.
2. However, if I open the UTF16-LE file and make some modifications each time before continue rebase procedure, it triggers twice as expected.
3. If I create UTF8 file and edit it mannually instead of running echo command, Git behaves normally, requiring --continue twice and ending up with the correct answer.

Therefore, it seems that it's a Git issue? But I am still unclear about the root cause of the issue. Do you have any ideas why this is happening or where I should looking for the answer? Thanks for your help so far!

[Netz00]

I repeated everything with Windows 10 and I am still getting the correct answer (Windows 10 created UTF-8 file). Earlier I was using Linux (OpenSUSE Tumbleweed).

As I am unable to reproduce issue due to technical limitations required by Windows 11 I cannot investigate further in this anomaly.

There are lots of search results for UTF-16 git issues so I guess it is some popular problem with git and there could potentially be some solution. Maybe here you can find some answers. I wish you best luck with this.

This issue should be marked as closed.

[XDcedar]

It's OK! At least now I know it's a problem related to UTF-16 encoding and how to avoid it. I will look for answers elsewhere. Thanks for your help!