Using git pull to track a remote branch without merging

I am using git to track content which is changed by some people and shared "read-only" with others. The "readers" may from time to time need to make a change, but mostly they will not.

I want to allow for the git "writers" to rebase pushed branches** if need be, and ensure that the "readers" never accidentally get a merge. That's normally easy enough.

git pull origin +master

There's one case that seems to cause problems. If a reader makes a local change, the command above will merge. I want pull to be fully automatic if the reader has not made local changes, while if they have made local changes, it should stop and ask for i开发者_JAVA技巧nput. I want to track any upstream changes while being careful about merging downstream changes.

In a way, I don't really want to pull. I want to track the master branch exactly.

** (I know this is not a best practice, but it seems necessary in our case: we have one main branch that contains most of the work and some topic branches for specific customers with minor changes that need to be isolated. It seems easiest to frequently rebase to keep the topics up to date.)

Your are looking for the command git-fetch.

You might also find git pull --rebase useful.

Update: --rebase can be made the default pull behavior by setting branch.<name>.rebase = true on individual branches. Setting branch.autosetuprebase = true will set this on new branches by default, though existing branches would need to be updated manually. Or you can always default to --rebase by setting pull.rebase = true globally.

How about:

  git pull --ff-only origin master

I use that often. Unfortunately, as richard-hansen@ pointed out below, this does not work as an alias:

[alias]
pull = pull --ff-only

Git 2.0 (Q2 2014) will add in commit b814da8 a config push.ff:

pull.ff::

By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded.

• When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line).
• When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).

I think you want a workflow using two branches. A merged local branch (master), and a remote 'read-only' tracking branch (remote).

Using dual remotes on a master branch allows you to continue working, and keep up to date with the remote project. Your local changes, and merged remote changes can be pushed to your local git server.

 git push localserver master

Upstream patches can be created and refined on your remote tracking branches, and submitted to the project.

A separate tracking branch for the 'read-only' remote lets you prepare patches and commits for upstream to the remote project.

# Master branch is merge of local changes, and remote changes
git checkout master
git pull -m origin master
# Set up a local tracking branch for the 'read-only' remote.
git checkout -b remote remote master
# Start reviewing changes between the two branches.
git diff --name-status ..master

When you want to upstream a patch, a diff from master..remote can be used to define the patch your read-only remote branch.

git diff master..remote -- files >patch
git checkout remote
patch -p1 <patch
git commit -m "Your patch"
git format-patch -1

Send the formatted patch file to the remote project. If you need to amend and rebase for the remote project, you can do that work on your remote tracking branch until it's approved.

(Setting up a git dual remote involves editing .git/config, and is explained elsewhere)

Since you don't want the manual merging by the readers fetching, you could write a hook to examine what came down and prompt the user:

http://git-scm.com/docs/githooks

I would still just recommend fetching and having the readers manage their merges or rebases locally. That's a simpler solution to your problem.