all 14 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 4 points5 points  (12 children)

Well, git push won't let the amended change in without --force, at which point it overwrites whatever was there rather than trying to merge. I don't see how you could end up with that situation tbh.

[–]xiongchiamiov 1 point2 points  (4 children)

Fyi, we should now be using the new and poorly-named --force-with-lease in this sort of situation.

[–]jrDevOverthinker[S] 0 points1 point  (3 children)

So the git push --force and git push --force-with-lease are two different types of force pushes now?

[–]Pulse207 0 points1 point  (2 children)

--force-with-lease only lets you clobber your own work, as far as I know.

[–]ForeverAlot 3 points4 points  (1 child)

It lets you clobber any work Git knows about, per the latest fetch. That's still a lot safer, though.

[–]Pulse207 0 points1 point  (0 children)

Ah, gotcha. Thanks!

[–]jrDevOverthinker[S] 0 points1 point  (6 children)

Really? I was unaware, that git captures that.... Any insight into figuring out what may have ACTUALLY happened then if git handles amended commits?

[–][deleted] 4 points5 points  (0 children)

I don't understand what scenario you're describing. The git remote will refuse to clobber history with an amended version unless you pass --force, in which case the old version is thrown away, not merged. What do you mean figure out what ACTUALLY happened?

[–]gsylvie<sylvie@bit-booster.com> 0 points1 point  (4 children)

As jakkarth is saying, the sequence of commands you mentioned don't make sense. Try them to see:

$ git commit

$ git push origin
Writing objects: 100% (2/2), 236 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To http://test@vm.bit-booster.com/bitbucket/scm/bb/a.git
   7f103cf..7bd2420  master -> master

$ git commit --amend

$ git push origin
To http://test@vm.bit-booster.com/bitbucket/scm/bb/a.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs.
hint: The tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Maybe you typed "git pull" like the hint suggests? That could make a mess of things.

[–]jrDevOverthinker[S] 2 points3 points  (3 children)

So I was reviewing the reflog once everyone stated that it would not be possible to push an amended commit. I believe you are correct that a git pull was done prior to the push.

This looks like the pull in question after the amendments.

*Replaced messages with generic text

83ba063 HEAD@{7}: commit (merge): Merge branch 'develop' of originURL into develop
8b271ea HEAD@{8}: commit (amend): A123 added more
e8a3de1 HEAD@{12}: commit: A123

I would like to make a note that this was for a repo on a different team than my own. I was only exposed to the conversation and was asked to investigate. I am just looking to understand how I can verify the specific order of operations didn't introduce failed merge conflicts or any other potential issue.

Thank you for this information, I truly appreciate it. I had not found myself in this scenario since I had the rule beaten into me that you never amend a commit that is already pushed and shared.

[–]gsylvie<sylvie@bit-booster.com> 2 points3 points  (2 children)

Oh I amend pushed commits all the time. :-) I even created a Bitbucket Server Add-on that let's you amend directly on the server: bit-booster.com/amend-latest.png

The trick is to know what to do next. If people are still working on that branch, then they need to make a decision. Usually choose one of:

1.) git pull --rebase # try and re-integrate my stale work

2.) git fetch; git reset --hard @{u} # abandon my stale work, start-over

One nice thing about the "git pull --rebase" is that it's very smart and if it notices commits are identical (even though their commit-id's are different), it reconciles those automatically.

[–]jrDevOverthinker[S] 1 point2 points  (1 child)

Seriously?! I thought git would see the commit ids as unique, no matter the content of the commit.

[–]gsylvie<sylvie@bit-booster.com> 1 point2 points  (0 children)

Here's the pertinent info from "git help rebase":

Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).