Pushing an --amend-ed commit

Hi list,

The other day I did the classic:

1) Right, changes all done and committed. Push to public repo.
2) Bugger, missed out an obvious one-liner in a Makefile. Make change  
and --amend that last commit.
3) Push to public repo again... Ah, "Not a strict subset" error, can't  
push...

It's obvious (I think) to me why I get this error - the commit now has a different hash so it looks like it would be the wrong thing to do to allow the push as far as git is concerned. Right?

So, is it safe to "use the --force" in this instance when pushing? This should just replace the old commit with the --amended commit with no side-effects, shouldn't it?

Thanks, Rob

Yes, but it would screw up other people that pulled from you.

If that's an issue (it most likely is, unless you're just pushing just to your own mirror repository), it is better if you do it the other way round: adding your commits on top of origin^, starting from the one that fixed a typo. In other words, make the history look like you hadn't used --amend.

Do like this: first create git-merge-theirs somewhere in your path; it's this three-line script, and it has to have that name.

#! /bin/sh eval git reset \$$# -- . git-checkout-index -q -f -a

Don't forget to make it executable. :-)

And here's the magic incantation to be executed on branch master:

git rebase -s theirs --onto origin/master origin/master^ HEAD

Basically, it uses the script created above to place the commits _after_ origin/master^ _above_ origin/master. What the script does is resolve conflicts by taking the version in your "master" branch.

To do so, git-merge-theirs uses "git reset" to check out into the index the last head passed to it (which we know is the next commit being added to the rebase). Then it extracts the index into the working tree to avoid complaints from "git commit" about files not being up-to-date.

There is no builtin git-merge-theirs strategy; if there was one, it should make sure that it was only called with two heads, for example.

Anyway, now you can push again. I suggest however reviewing your commit messages and, if necessary, using "git rebase -i origin/master" to edit some of them.

Paolo

On 2 Jun 2008, at 15:55, Paolo Bonzini wrote:

Ah yes, forgot about that...

It's not an issue right now as I'm still experimenting, but it certainly will be when I let others lose on this stuff. It's really not something I see myself doing a lot - I usually test a lot more thoroughly before publishing to a public repo...

<snip big explanation and code>

Thanks very much for the code and method. It goes over my head a bit right now, but I'll think on it and try it and see how I get on! A lot of what git can do scares me a bit still - mainly because it's me driving it...

Thanks also to the other people who answered me!

Cheers, Rob

On Mon, Jun 2, 2008 at 5:51 AM, Robert Haines <rhaines@manchester.ac.uk> wrote:

Safe from what perspective? If you're sure nobody has pulled from you, then yes, it's fine. If you know exactly who pulled and can contact them to do a reset and re-pull, then it should be fine. If you don't care about screwing up people who pulled from you, then I suppose that's still fine. However, screwing with history is generally a bad idea, since now people who pull from you don't have your current HEAD as a parent commit in their tree. Finding common ancestors is going to be messed up (and future merges with them, possibly).

(also, first git mailing list post. I hope none of the experienced people have to correct me)

On Mon, Jun 2, 2008 at 8:08 PM, Matt Pearson <404emailnotfound@gmail.com> wrote:

Heh, guess I have to correct myself -- someone already replied a long time ago. That's what I get for replying right when I start reading backlog and depending on gmail to group threads for me :)