|
|
| Page 1 of 1 |
|
|
 Posted: Sun, 5th Feb 2023 21:37 Post subject: Git help required, again! |
|
 |
| Code: | # What happened?
# do some coding, test it, everything is O.K.!
$ git add .
$ git commit -m 'major LP re-write, improved logging'
$ git tag v1.1
$ git push
# shortly after, ... notice a minor typo, correcting it...
$ git add .
$ git commit --amend
# in vi, just type ":wq", accepting previously typed commit messages...
$ git push
To ltkrmt01:/data/repos/meta
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to 'ltkrmt01:/data/repos/meta'
hint: Updates were rejected because 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.
# WHAT??? WHY??? why can't I push anymore???
$ git log
06914d4 (HEAD -> main) major LP re-write, improved logging
2f203b0 (tag: v1.1, ltkrmt01/main) major LP re-write, improved logging
5202805 (tag: v1.0) added minor verbose outputs and documentation.
90356f1 added AIO-workflow
5366207 added zypper-repos module
86d6308 included support for Tumbleweed
640124c moved AIO deploymnet heading further up to functions
6a811a8 minor re-phrasing
81e281a big re-work
010324a removed duplicate shebang
ed3c284 snapshot
9ce6696 added netbackup firewall module for later implemantation
8df2135 fixing typo only...
887134a fixed double shebang bug and sssd.conf set to chmod 600
a45689c bugfixes from test runs...
5bbd6a6 snapshot modules
975d1f5 updated .gitignore
b400deb added update of workdir repo on ltkrmt01 function
28e719b updated org functions
0ddab89 added sub-headings
# I am at commit 06914d4 now, but I cannot push anymore.
# I think the previous "git commit --amend" did not work as I am used to it, because there was the "v1.1" tag previously?? is that the reason why it behaves like this?
# anyhow I don't know what to do now, as I really expected it to *stay* at commit 2f203b0 after the amend *without* creating a new commit (and *without* detaching it's head, obviously) and that pushing would still work.
# so how do I fix this? I assume this must be trivial, no?
# please help sad little pax!!
|
"There will be no end to the troubles of humanity, until philosophers become kings, or kings become philosophers.", Plato.
"Hyperbole will destroy us all.", Matt Dillahunty.
"The hyperbole, the demonization of the other opinion and the unwillingness to even read the opposing opinion destroys the so important political discussions necessary for the well functioning of society.", Couleur
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2023 23:54 Post subject: |
|
|
tldr; --amend requires a force push to overwrite remote. In general, avoid force pushing where possible because it can cause problems for collaborators working on the code.
https://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repository
| Quote: |
By amending commits, you are changing their SHA1, which means the local and remote history are no longer the same.
If you want to replace the remote history by your (amended) local one, you will need to force push.
If you don't, Git will refuse the push, and ask you to pull (which in this case is not helpful, as you would merge with identical content but different commit messages)
Force pushing can be dangerous as it forces other collaborators to reset their own local history to the new (forced pushed) one.
As commented, --force-with-lease is safer (if the remote branch you are changing was itself changed since your last pull, meaning other were actively using it and pushing it back, then the forced push is denied).
Combine that with a sensible pull policy (where you always rebase what you have not yet pushed), and force pushing becomes less needed.
|
|
|
| Back to top |
|
|
|
|
| Posted: Mon, 6th Feb 2023 00:42 Post subject: |
|
|
Last edited by paxsali on Thu, 4th Jul 2024 22:59; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Mon, 6th Feb 2023 19:09 Post subject: |
|
|
Last edited by paxsali on Thu, 4th Jul 2024 22:59; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Mon, 6th Feb 2023 19:40 Post subject: |
|
|
Well you can always do the peasant method I do because I never trusted the amend command
1) locally, git reset HEAD~ (files from previously last commit will get marked as modified), change whatever, commit locally
2) on remote, git update-ref HEAD HEAD~ (if it's bare repo) or git reset HEAD~ (if not)
3) locally, git push origin master
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 7th Feb 2023 00:44 Post subject: |
|
|
It's in the description, every commit has a hash, --amend is changing that local commits hash. So now your local and remote are out of sync / different hashes for the "same" commit. By design it's not going to let you push that amended / changed hash.
Force push is going to overwrite / blow away whatever is in remote thus fixing your problem.
*Note*:
If there were 10 of you working frequently on that repo though you can see the potential problems. Now all their local copies are going to have the old commit hash vs. the new commit hash you --amended and force pushed. They would need to fix their local copies, I would do something like this:
`git stash` whatever they are working on
`git reset --hard HEAD^` get rid of the latest commit that was amended.
`git pull` get the new amended commit
`git stash pop` get back whatever you were working on.
However this will become a dogs breakfast if the other devs have made commits after the one you amend and force push to remote. Ofc fixable, but I'd need google and its a PITA.
|
|
| Back to top |
|
|
| Page 1 of 1 |
All times are GMT + 1 Hour |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group
|
|
 |
|
