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.


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 

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 

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.  


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.

Reply via email to