{"thread":{"id":"13760","subject":"Pushing an --amend-ed commit","startedAt":"2008-06-02T09:51:47Z","lastAt":"2008-06-03T17:49:56Z","messageCount":5,"participants":["Robert Haines","Paolo Bonzini","Matt Pearson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78347","messageId":"6B355924-0EA9-4AF8-B051-F17FC4530495@manchester.ac.uk","threadId":"13760","inReplyTo":null,"subject":"Pushing an --amend-ed commit","fromName":"Robert Haines","fromEmail":"rhaines@manchester.ac.uk","sentAt":"2008-06-02T09:51:47Z","receivedAt":"2008-06-02T09:51:47Z","isPatch":false,"sender":{"key":"rhaines@manchester.ac.uk","avatar":null},"body":"Hi list,\n\nThe other day I did the classic:\n\n1) Right, changes all done and committed. Push to public repo.\n2) Bugger, missed out an obvious one-liner in a Makefile. Make change  \nand --amend that last commit.\n3) Push to public repo again... Ah, \"Not a strict subset\" error, can't  \npush...\n\nIt's obvious (I think) to me why I get this error - the commit now has  \na different hash so it looks like it would be the wrong thing to do to  \nallow the push as far as git is concerned. Right?\n\nSo, is it safe to \"use the --force\" in this instance when pushing?  \nThis should just replace the old commit with the --amended commit with  \nno side-effects, shouldn't it?\n\nThanks,\nRob\n\n-- \nRobert Haines\n\nResearch Associate, RealityGrid          Tel. : +44 (0)161 275 6067\nResearch Computing Services              Fax. : +44 (0)161 275 0637\nUniversity of Manchester                 Email: rhaines@manchester.ac.uk\nOxford Road                              Web  : www.realitygrid.org\nManchester, M13 9PL, UK                       : www.rcs.manchester.ac.uk\n"},{"id":"78369","messageId":"484409F9.5020807@gnu.org","threadId":"13760","inReplyTo":"6B355924-0EA9-4AF8-B051-F17FC4530495@manchester.ac.uk","subject":"Re: Pushing an --amend-ed commit [and a git-merge-theirs strategy]","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-02T14:55:53Z","receivedAt":"2008-06-02T14:55:53Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> 1) Right, changes all done and committed. Push to public repo.\n> 2) Bugger, missed out an obvious one-liner in a Makefile. Make change \n> and --amend that last commit.\n> 3) Push to public repo again... Ah, \"Not a strict subset\" error, can't \n> push...\n> \n> It's obvious (I think) to me why I get this error - the commit now has a \n> different hash so it looks like it would be the wrong thing to do to \n> allow the push as far as git is concerned. Right?\n> \n> So, is it safe to \"use the --force\" in this instance when pushing? This \n> should just replace the old commit with the --amended commit with no \n> side-effects, shouldn't it?\n\nYes, but it would screw up other people that pulled from you.\n\nIf that's an issue (it most likely is, unless you're just pushing just \nto your own mirror repository), it is better if you do it the other way \nround: adding your commits on top of origin^, starting from the one that \nfixed a typo.  In other words, make the history look like you hadn't \nused --amend.\n\nDo like this: first create git-merge-theirs somewhere in your path; it's \nthis three-line script, and it has to have that name.\n\n#! /bin/sh\neval git reset \\$$# -- .\ngit-checkout-index -q -f -a\n\nDon't forget to make it executable. :-)\n\nAnd here's the magic incantation to be executed on branch master:\n\ngit rebase -s theirs --onto origin/master origin/master^ HEAD\n\nBasically, it uses the script created above to place the commits _after_ \norigin/master^ _above_ origin/master.  What the script does is resolve \nconflicts by taking the version in your \"master\" branch.\n\nTo do so, git-merge-theirs uses \"git reset\" to check out into the index \nthe last head passed to it (which we know is the next commit being added \nto the rebase).  Then it extracts the index into the working tree to \navoid complaints from \"git commit\" about files not being up-to-date.\n\nThere is no builtin git-merge-theirs strategy; if there was one, it \nshould make sure that it was only called with two heads, for example.\n\nAnyway, now you can push again.  I suggest however reviewing your commit \nmessages and, if necessary, using \"git rebase -i origin/master\" to edit \nsome of them.\n\nPaolo\n"},{"id":"78440","messageId":"706b4240806021708u4ade0f9ake53e26f53e34d97d@mail.gmail.com","threadId":"13760","inReplyTo":"6B355924-0EA9-4AF8-B051-F17FC4530495@manchester.ac.uk","subject":"Re: Pushing an --amend-ed commit","fromName":"Matt Pearson","fromEmail":"404emailnotfound@gmail.com","sentAt":"2008-06-03T00:08:48Z","receivedAt":"2008-06-03T00:08:48Z","isPatch":false,"sender":{"key":"404emailnotfound@gmail.com","avatar":null},"body":"On Mon, Jun 2, 2008 at 5:51 AM, Robert Haines <rhaines@manchester.ac.uk> wrote:\n> So, is it safe to \"use the --force\" in this instance when pushing? This\n> should just replace the old commit with the --amended commit with no\n> side-effects, shouldn't it?\n\nSafe from what perspective?  If you're sure nobody has pulled from\nyou, then yes, it's fine.  If you know exactly who pulled and can\ncontact them to do a reset and re-pull, then it should be fine. If you\ndon't care about screwing up people who pulled from you, then I\nsuppose that's still fine.  However, screwing with history is\ngenerally a bad idea, since now people who pull from you don't have\nyour current HEAD as a parent commit in their tree.  Finding common\nancestors is going to be messed up (and future merges with them,\npossibly).\n\n(also, first git mailing list post.  I hope none of the experienced\npeople have to correct me)\n"},{"id":"78442","messageId":"706b4240806021722k2d15a4e9offa4d513a4ba6106@mail.gmail.com","threadId":"13760","inReplyTo":"706b4240806021708u4ade0f9ake53e26f53e34d97d@mail.gmail.com","subject":"Re: Pushing an --amend-ed commit","fromName":"Matt Pearson","fromEmail":"404emailnotfound@gmail.com","sentAt":"2008-06-03T00:22:44Z","receivedAt":"2008-06-03T00:22:44Z","isPatch":false,"sender":{"key":"404emailnotfound@gmail.com","avatar":null},"body":"On Mon, Jun 2, 2008 at 8:08 PM, Matt Pearson <404emailnotfound@gmail.com> wrote:\n> (also, first git mailing list post.  I hope none of the experienced\n> people have to correct me)\n\nHeh, guess I have to correct myself -- someone already replied a long\ntime ago.  That's what I get for replying right when I start reading\nbacklog and depending on gmail to group threads for me :)\n"},{"id":"78522","messageId":"A36634E4-D440-4E85-9567-7331FC201BFB@manchester.ac.uk","threadId":"13760","inReplyTo":"484409F9.5020807@gnu.org","subject":"Re: Pushing an --amend-ed commit [and a git-merge-theirs strategy]","fromName":"Robert Haines","fromEmail":"rhaines@manchester.ac.uk","sentAt":"2008-06-03T17:49:56Z","receivedAt":"2008-06-03T17:49:56Z","isPatch":false,"sender":{"key":"rhaines@manchester.ac.uk","avatar":null},"body":"On 2 Jun 2008, at 15:55, Paolo Bonzini wrote:\n>> 1) Right, changes all done and committed. Push to public repo.\n>> 2) Bugger, missed out an obvious one-liner in a Makefile. Make  \n>> change and --amend that last commit.\n>> 3) Push to public repo again... Ah, \"Not a strict subset\" error,  \n>> can't push...\n>> It's obvious (I think) to me why I get this error - the commit now  \n>> has a different hash so it looks like it would be the wrong thing  \n>> to do to allow the push as far as git is concerned. Right?\n>> So, is it safe to \"use the --force\" in this instance when pushing?  \n>> This should just replace the old commit with the --amended commit  \n>> with no side-effects, shouldn't it?\n>\n> Yes, but it would screw up other people that pulled from you.\n\nAh yes, forgot about that...\n\n> If that's an issue (it most likely is, unless you're just pushing  \n> just to your own mirror repository)\n\nIt's not an issue right now as I'm still experimenting, but it  \ncertainly will be when I let others lose on this stuff. It's really  \nnot something I see myself doing a lot - I usually test a lot more  \nthoroughly before publishing to a public repo...\n\n> it is better if you do it the other way round: adding your commits  \n> on top of origin^, starting from the one that fixed a typo.  In  \n> other words, make the history look like you hadn't used --amend.\n\n<snip big explanation and code>\n\nThanks very much for the code and method. It goes over my head a bit  \nright now, but I'll think on it and try it and see how I get on! A lot  \nof what git can do scares me a bit still - mainly because it's me  \ndriving it...\n\nThanks also to the other people who answered me!\n\nCheers,\nRob\n"}]}