Read on Twitter
Git trivia of the day, courtesy of the .NET blog, which is stored in Git.
@runfaster2000 was rebasing a topic branch with his post on top of main. That resulted in an empty set (i.e. no commits over what was in main). Strange. So he asked me if know what went wrong.
@runfaster2000 was rebasing a topic branch with his post on top of main. That resulted in an empty set (i.e. no commits over what was in main). Strange. So he asked me if know what went wrong.
My first inclination was: someone must have merged the branch already. However, his file wasn't there. OK, maybe someone merged & then deleted the file, so I ran
git log --diff-filter=D --summary
This will show all commits & msg that deleted a file and also show their names.
git log --diff-filter=D --summary
This will show all commits & msg that deleted a file and also show their names.
His file didn't show up but I found a commit of mine with a similar file name.
Turns out, I copy and pasted the contents of his file and committed that at some point for test purposes (which I then subsequently also deleted).
Turns out, I copy and pasted the contents of his file and committed that at some point for test purposes (which I then subsequently also deleted).
Since GitHub tracks the contents of files, rather than their names, it (correctly) concluded that the commits from Rich's topic branch aren't necessary anymore.
However, in this case we want to take the changes regardless. Simple fix. Rich just added --reapply-cherry-picks to his rebase command. That will take all commits, even if the content is already in main.
git rebase main --reapply-cherry-picks
git rebase main --reapply-cherry-picks
Git might have issues with the naming of the CLI. But to this day it's only version control where I can truly understand WHY things are happening and HOW I can fix that.
