Thank you for all your very considered replies. The solution I end ed up
using (without the complex explanations) was
git merge origin/master
# resolve conflicts
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
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
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
> 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
> What is wanted is "How to use Git like Svn".
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
For more options, visit https://groups.google.com/d/optout.