David Lang <david@xxxxxxx> writes: > On Fri, 18 Jan 2013, Junio C Hamano wrote: > >> David Lang <david@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html