Hello All, Thank you for all your very considered replies. The solution I end ed up using (without the complex explanations) was
git push # fail git pull git merge origin/master # resolve conflicts git push This should go up the front of any manual of GIT, right after git clone. But I have not seen it explicitly that I can recall. (I threw the abtmp branch away) My interpretation is that that when you push to a remote it will will follow any direct set of arrows (only) to move origin/master along. I have not read that anywhere though. <rant> One problem with GIT is that every document author gets so carried away with advanced features for obscure branching and even partial staged commits(!) that they just lose track of the basics. For example the Git Basics chapter in the git-scm.com book talks about advanced things like staging in the intro (which I would never use, just always commit -a) but does not describe how to check in to a shared repository and resolve conflicts. Then the external repository chapter does not talk about merging! The simple model, which I use, is that there is one shared repository used by all developers. I have a local cache, much like Subversion but storing all the history for convenience. We all normally work on head, with branches for releases that are kept very short. Big merges are dangerous and avoided. I have seen teams get into big trouble just introducing branches to CVS. As code is merged backwards and forwards between the branches errors are introduced. Buggy code often reappears on different branches, only to be merged back onto good branches. But the good news is that once you fix the same bug multiple times you get really good at fixing that bug. Of course because of all this merging the code could never be restructured which would make the merges unmanageable. Note that the above is not because of CVS's many, many issues. It is instead the nature of branching and merging code. And in particular to rely on complex branching rather than having a good module structure that makes branching largely unnecessary. The idea that people are only staging some file in their working directory at particular times during the edit, and then putting different staged changes into different branches, and then pushing different branches to different shared repositories seems just crazy to me. Broken builds would be the least of the problems. Maybe a team of people as smart as Linus Torvald might be able to handle it, but not the people that I have worked with. So it is great to have fancy functionality. But getting the basics right is most important. Using git like Subversion doc should be chapter 1, not just left as a something implied. </rant> On Thursday, October 30, 2014 4:41:42 PM UTC+10, Anthony Berglas wrote: > > Hello All, > > I am trying to do something really simple. I want to commit local changes > to a remote repository. But along the way other developers modified the > remote. This appears to be very difficult to do in Git. > > When I finished my changes I did a commit -a. All good. > > But then the push failed. git fetch ok. So I tried to checkout the > origin/master. That gave me a "detached head", even though it looked like > I was on head. It said create a branch so I created abtmp (I do not > actually want any branches). Then merged origin/master back into abtmp > (which seems the wrong way). > > So now I have the following. What I want is to get rid of abtmp and > commit back to origin/master on the remote server. > > $ git log --oneline --decorate --graph --all > * 5e0fcfb (HEAD, abtmp) Merge remote branch 'origin/master' into abtmp > |\ > | * 944773a (origin/master, origin/HEAD) - shrm has to be optional > logically (if s > | * 4952f9c - correct to point by default > * | 75b9d6d (master) Performace tests > |/ > * c1106db - replace with st > * b046367 - set back further > * 5a3ce83 - fixup doc link reference > * 2ca8ecf (tag: 7.0e) - this > > Questions:- > > 1. How do I fix this up. > 2. What is the best way to deal with these simple conflicts in future. > > Is there any doc that goes over this clearly. (e.g. not > http://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes which goes > over setting up multiple remotes etc. and other cleverness but not the > basics.) > > What is wanted is "How to use Git like Svn". > > Thanks, > > Anthony > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
