Fast-Forward rebase does not preserve SHA-1 of commits
By lloyd.r... on July 12, 2013 15:02 (imported from Google Code)
What steps will reproduce the problem?
- Make some commits to the local repo
- Push to Gerrit (e.g. refs/for/trunk)
- A commit in the middle of all your patches fails in gerrit so you want to fix and interactively rebase. Click 'Git Rebase...' and check 'Force Rebase' (otherwise you can't see your commits) then reorder/edit/squash/skip your commits (one workflow is to fix locally, commit the fix to the local repo, move the commit object to just above the bad commit and squash it into it)
- Push to Gerrit (e.g. refs/for/trunk)
What is the expected output? What do you see instead?
I expect Gerrit to cope with the commit and notice changes where there are changes. However, because --force is used, the commit has a different 'committer' date and therefore a different SHA. Gerrit sees a different SHA, expects a change but then fails to find one in the commit message or the files. It therefore refuses the patches.
Perhaps Gerrit should cope better (I will also make a Gerrit issue report), but the command line 'git rebase --interactive' does not require use of --force, so nor should TortoiseGit.
TortoiseGit should allow you see the commits to rebase without requiring a 'Force Rebase'.
What version of TortoiseGit and msysgit are you using? On
what operating system?
TortoiseGit 1.8.4.0 (C:\Program Files\TortoiseGit\bin)
git version 1.7.11.msysgit.0 (C:\Program Files (x86)\Git\bin)