Re: Question re. git remote repository

David Lang [off-list ref] writes:

On Fri, 18 Jan 2013, Junio C Hamano wrote:

quoted

David Lang [off-list ref] writes:
...

quoted

developers then do their work locally, and after a change has been
reviewed, pull it into the master repository.

s/pull it into/push it into/; I think.

fair enough, I always think in terms of pulling from feature branches
into the main repository so that any merge conflicts get resolved. I
didn't describe this clearly enough.

If you are assuming that the "main repository" has a working tree
and somebody goes there, runs "git pull" and manually resolves
conflicts, that may be asking for trouble down the road. It may be
sufficient for two-person group as long as they coordinate among
themselves so that only one of them uses that working tree at the
"main repository" at a time.

But in general, it is more common to have a bare repository without
any working tree as the "main repository", let a push that conflicts
fail, and have the pusher fetch from the "main repository" and fix
up the conflicts in his working repository before he tries to push
the cleaned-up result.  That gives the pusher a chance to re-test
the result of integration with what he did not see while he was
developing what he attempted to push.

"pull" and "pull -rebase" are two ways to do that "fetch from the
'main' and fix up" step.