On Mon, 22 Aug 2011 05:14:29 -0700 (PDT)
Sandeep Mahajan <sandeep.d.maha...@gmail.com> wrote:
> > > 1. Assume I have a central repo containing branches branchA.
> > > 2. This repo is cloned by user A and userB.
> > > 3. userA creates a new branchB where he merges in branchA.
> > > 4. There is a conflict reported, and only userB has the skills to
> > > resolve the conflict.
> > > Question: How can userB view the same conflicts, and get them
> > > resolved in branchA?
> > UserA pushes its BranchB to the server, UserB fetches it and then
> > attempts to merge whatever UserA tried to merge into BranchB.
> > After that, BranchB can be deleted from the server.
> Lets extrapolate on this and make it a bit more complicated.
> 1. I have a central repo containing branch1 and branch2
> 2. branch1 and 2 have 3 files - file1, file2 and file3
> 3. This repo is cloned by userA, userB, userC- each user owning file1,
> file2 and file3 respectively
> 4. Assume the three files have conflicting changes in branch1 and
> branch2 in central repo
> 5. Now an integration build engineer BuildUser clones the central
> 6. He creates a new branch branchBuild where he merges the branch1 -
> no conflicts.
> 7. Then he merges in branch2 - gets conflicts in file1, file2 and
> file3. This branch is pushed across to remote central repo.
> 8. Now these conflicts need to be resolved by userA, userB and userC.
> 9. Should users - userA, userB and userC, all clone from the repo,
> check out branchBuild and merge in the same branch1 followed by
> branch2 to see the same conflicts?
> Is there any alternative to step9?
> It seems a bit of overkill to get three users (userA, userB and userC)
> to replicate the same set of steps taken by an integration build
> engineer only to solve conflicts.
> Is there any other alternative way without requiring these users to
> merge the branches just to see the conflicts?
Well, I'm not sure about how exactly to approach this question...
One thing to start with, which is worth keeping in mind, is that a
merge conflict is by definition a case which has to be resolved by a
human. That's why merging is always performed in the work tree.
Now you have an integration engineer which does not possess the
necessary knowledge to resolve a merge conflict and a natural
requirement for the merge to happen in someone's work tree. This
suggests that to make the "owning" user to resolve the conflict is the
only sensible solution in your case with anything else being wishful
thinking. And this act requires the user to do merging against her
work tree which requires her to fetch the necessary head(s) first.
Hence I cannot imagine how the situation like yours could be solved
without your users performing their respective merges themselves.
If this still appears to be clumsy, you could probably look at this
problem from an opposite point of view: let each of your users perform
the first part of the job envisioned for the integration engineer. I
mean, each user first creates her own "integration branch" into which
she merges her changes (or rebases them) and then pushes that branch to
the central repo. Provided each user only touched her "owned file" on
her respective branch, she would only get merge conflicts for that
file and she knows how to resolve those conflicts. Then the task
for the integration engineer whould be to merge the resulting three
branches coming from the users. If the patchsets in the users' branches
were really isolated from each other such merging should occur without
Also you seem to consistently use the "clone" word while one of the
key ideas behind a DVCS is its ability to do minimal data transfers.
The users from your scenario do not need to (re-)clone the repo,
instead, they just have to *fetch* one intergation branch (pushed by
the integration engineer) and this act is not really a big deal in terms
of network traffic and disk space. So if you're mostly concerned with
these traffic/space issues you should rather not be.
Please don't top-post, this breaks discussion flow and hence sucks.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at