What can cause erratic behavior with git?

While I’m currently struggling with these problems in a project that uses git, this is not really asking solutions to specific problems, but I’m more asking for what are the possible causes for these types of problems. (The problems have been fixed, but their reason is a mystery.)

What can cause erratic behavior with git, especially when rebasing? Erratic behavior that’s very hard to solve, tends to mess up the entire commit history, and often the easiest (although laborious) solution is to do a hard reset and then cherry-pick individual commits in order to fix and clean up the commit history. The kind of erratic behavior I’m referring to includes things like:

  • Duplicated commits appearing in the commit log, with different hashes. In other words, the exact same commit, with the exact same modifications and time/date, is randomly duplicated one or several times, with no rhyme or reason, each duplicate having its own different hash. Some commits may have been duplicated just once, others even four times, and there’s no logic to their order or placement in the commit log (they may appear one after another, or separated by a half dozen other commits, out-of-order in relation to the commit date of other commits, etc.)
  • Inside a branch (that has been created from the master branch), when trying to do a “git rebase master”, it causes a merge conflict with a file that exists only in this branch and nowhere else. In other words, the file in question does not exist in the master branch (and has never existed there), and it was created and has only ever existed in this branch. Essentially, git is trying to merge the file with an older version of the same file in the same branch (which makes absolutely no sense).
  • There’s the master branch and branches A and B made from it. There exist two files in the project, “x/name” and “y/name”. In branch A the former is renamed “z/name” (ie. the directory is renamed), and then this change is merged into the master branch. Then in branch B I do a “git rebase master” to get those changes, and git gives a rename conflict, as it tries to rename “x/name” as “y/name”, which once again makes absolutely no sense. (I don’t have the faintest idea what caused this, or how such a conflict is supposed to be resolved. Especially since it’s an incorrect attempt at renaming the file.)

I am becoming a master (hah!) at doing hard resets and cherry-picking commits to the current branch to try to fix its commit history and resolve rebasing conflicts. I just wish I didn’t have to constantly do that. I would really love to get some ideas of what could cause this completely erratic and asinine behavior.

Hi @warprules! :wave:

Duplicated commits with different hashes sounds like the result of rewriting history, and then doing a regular push rather than a force push.

Commit SHAs are based on quite a few things, including the content of the commit, the timestamp in the commit metadata of when the commit was written, and the timestamp of when it’s actually committed. That means the exact same commit can have different SHAs if you commit it at different times.

Also, the SHA of the parent commit is taken into account, so changing anything about one commit will change the SHAs of all of its descendant commits too! There’s a pretty thorough blog post about what makes up a SHA here:

All of this means that if you do anything to affect a commit in the history of your repo, all of the SHAs from that point on are likely to change. This includes rebasing. That’s why it’s important to force push and overwrite all of the current commits. A regular push will just add the rewritten commits alongside the old ones.

I’m less sure what’s going on with your rebasing problems from the information you’ve provided, sorry! Could it be that sometimes you’re rebasing on master, and sometimes on origin/master? Do you have collaborators that might be working on the repository at the same time?

There’s a very detailed post on rebasing here that might help you understand what’s going on!