tags:

views:

52

answers:

3

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 input. 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.)

+4  A: 

Your are looking for the command git-fetch.

Seamus
I'm afraid not. git-fetch updates the local copy of the branch remotes/origin/master, but it does not update the master branch itself. I want the "readers" to be able to get a copy of the changes made upstream.
J Barlow
A: 

You might also find git pull --rebase useful.

dahlbyk
A: 

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

http://www.kernel.org/pub/software/scm/git/docs/githooks.html

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

HTH,

Adam

adymitruk