Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > Quoting Junio C Hamano <gitster@xxxxxxxxx> > >> Out of curiosity, how did you find this? > > Soon after you posted your original in > http://thread.gmane.org/gmane.comp.version-control.git/121881, I applied > it to my tree, and I have been running 'git pull --rebase' for ever. I > noticed that rebase didn't remove the commit, even after your 54bc13c. > > Today I found that the rebased patch only removed that file. The real > question is how you lost the deletion of the file when you applied. What > happened? My stupidity, and a little bit of danger in trusting "am -3" blindly. The patch sent to the list was against the master, but the actual commit created, 54bc13c, was on maint. Back then, there was a commit in master but not in maint that stopped using cp1251.txt and started using iso8859-5.txt instead. Because maint did not have iso8859-5.txt (which the patch wanted to remove), when "am -3" did its fake 3-way merge, the removal of the path did not even conflict. It was the case of "neither side wants to have this file". As the result, cp1251.txt was left in the tree (which is half-Ok, even though the updated test never looked at it anymore), and merging the result back to master did not touch iso8859-5.txt. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html