1

Ok, this one is a little complicated and most probably is very specific. Let me try to explain.

Lets say I pull this git repo into my local drive. Then make a number of changes. As these changes are in many different files and are aimed for different goals, the commits are more then one. Lets say the commit from these changes are with hash value ab001 to ab005 (five commits). And then I create the series of patches and send to the community for review.

Meanwhile, lets suppose I realize that the master repo has been changed quit a bit, so I need to rebase. I do that, solving all the conflicts. Now this would result in another commit, lets say ab006.

All is good.

But next day I get comments and advices on the previous patch (one with those 5 commits). So, I now have to make some changes according to those comments, and send a v2 (version 2) of the older patch (i.e. 5 commits). So I have to uncommit those 5 commits, make changes and commit again and create another patch (with those 5 commits).

How will I go about doing this, I cannot uncommit, since there is a rebase commit in the HEAD. I am really confused about this.

Haris
  • 12,120
  • 6
  • 43
  • 70
  • The git documentation suggests you should make your changes in new commits, instead of amending the ones you have. See the section "Recovering From Upstream Rebase", https://git-scm.com/docs/git-rebase – declan Jun 16 '16 at 17:24
  • @declan, True. But for every small change and suggestion, I cannot send incremental commits. It looks sloppy and the reviewer looses grasp of the previous changes (as it has not been merged). – Haris Jun 16 '16 at 17:26
  • Sure, fair enough. – declan Jun 16 '16 at 17:26
  • If I were in this situation I would "undo" the rebase that pulled in the latest master changes, then make my changes to ab001-ab005, the redo the rebase on master. Would that approach work for you? If so I can give more details. – declan Jun 16 '16 at 17:28
  • @declan, Yes that would work, but everytime I would have to resolve the conflicts. Its tiring. – Haris Jun 16 '16 at 17:29
  • Agreed, that's not a good long-term workflow. If you want to continue rewriting your commit history in this branch, it's definitely easiest if you don't have to rebase onto master until the new features are done. – declan Jun 16 '16 at 17:31
  • @declan Yes. true that. The rebasing is creating the main problem. I wonder if there is a solution to this. – Haris Jun 16 '16 at 17:34

1 Answers1

3

You could "undo" the rebase from master, then amend commits ab001 to ab005.

git log

# commit ab005
# Fifth commit on the topic branch
# ...
#
# commit ab001
# First commit on the topic branch
#
# commit xy999
# Last commit on master before I started this new branch

git reset --hard xy999
git cherry-pick ab001
...
git cherry-pick ab005

Now your history is clean and you can amend the topic branch commits. If necessary you can redo the rebase onto master, although if at all possible I'd recommend waiting until the work in this branch is done.

declan
  • 5,605
  • 3
  • 39
  • 43