Re: Question re. git remote repository

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2013, 21:38 UTC
Message-ID: <7v1udiqiic.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz>

David Lang <david@lang.hm> writes:

Show 12 quoted lines

> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> writes:
>> ...
>>> 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.