Re: git pull fails with merge conflicts. How can this possibly happen?

[Yuri Khan]

On Sat, Nov 15, 2014 at 3:54 AM, Alan Mackenzie <address@hidden> wrote:

> gitk doesn't work on my system, of course.  (Nothing ever does without a
> lot of effort).

I want to propose a couple of rules of thumb for beginner Git users.


Rule First:

* Drop everything else you’re trying to do with Git and get
comfortable with at least one Git repository browser. One that
displays pretty graphs.

Starting with Git without a graph browser is like learning chess by
playing blind.

At a minimum, this command is always available:

$ git log --graph --decorate --oneline --color <branch>…


Rule Second:

* Do not ever use “git pull”.

“git pull” does two things. First, it will bring into your local
repository new commits[1] from the remote, and rearrange the remote
tracking branch heads[2] to match their current positions in the
remote. Second, it will try to match[3] your local branch head with a
remote tracking branch head, and merge that into your local branch.

[1] This set of commits is unpredictable and depends on the past
actions of many other people.
[2] The motion of remote tracking branches is unpredictable and
depends on the past actions of many other people.
[3] The matching of the local branch to the corresponding remote
tracking branch is predictable and depends only on your own actions.
But still it is often surprising.

Instead:

1. Cautiously “git fetch” new remote state into your local repo.
2. Explore the changes with a graph browser, at least for the few
branches you are directly interested in (emacs-24 and master). See if
any of the remote branches diverged with your local branches.
3. Decide if you want a merge, a rebase, a cherry-pick, or something
else entirely. (I have seen cases when the remote had changed so much
that it was easier to reimplement a feature on top of the new remote
state than try to merge or rebase.)


Also, required reading/watching:

* Git Pro, book by Scott Chacon
* Git For Ages 4 and Up, talk by Michael Schwern


> Funny thing: looking at the gitk man page, there doesn't
> appear to be a way of specifying the repository.  Hmm.

By convention, all git commands assume they are run within the
repository. So just cd into the repo first.

Some features in gitk also assume it has been run in the repository
root. (Arguably this is a bug but apparently no one has yet gotten
around to fix it.)