Roughly speaking, this is a "feature". Could you do a diagram of the merge - amend - merge process. Its not obvious which parts merged which at the second pass.
In the first merge you had the code growing so it accepted the left over code as part of the mainline. Then when you tried the second time (IIUC) the new merge looked back to the old bases and decided that it should stick with what it had (reverting a fix). The problem is asked fairly often (couple times a year?) on the main list and depends on the careful sequencing of the fix reversion, and which line of code gets priority. On Wednesday, December 2, 2020 at 3:38:35 AM UTC SJW wrote: > I had a bug in my code so I branched master to `bugfix-333` and I added a > `var_dump();` in the code to debug. > I then found the problem, fixed it, committed and merged `bugfix-333` into > `staging` branch. > I then realised that I'd left the `var_dump();` in the code so i checked > out the `bugfix-333` again and deleted the `var_dump()` > I again committed the code this time using `git commit --amend` > Then I checked out `staging` and merged `bugfix-333` again > > BUT ... the var_dump() is still there in staging? I checked out > `bugfix-333` and the code is gone. I tried again, checked out `staging` and > ran `git merge bugfix-333` but now I get: > > Already up to date. > > But it's not??? Is this a bug or a "feature"? > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/78093a75-5677-4ef6-b4bc-d308891ca092n%40googlegroups.com.
