[git-users] Re: workflow question for central git repo
On Aug 23, 2:09 am, Konstantin Khomoutov wrote: > On Mon, 22 Aug 2011 05:14:29 -0700 (PDT) > > Sandeep Mahajan 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 > > repo. > > 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 > conflicts. > > 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. > > P.S. > Please don't top-post, this breaks discussion flow and hence sucks. Thanks again. I take your point that I'll have to get my users to perform part of the integration engineer work i.e. do part of the merges themselves. I'll try out the scenario. My mistake I referred to 'clone'ing repeatedly. A fetch would suffice. -- 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 git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: workflow question for central git repo
On Mon, 22 Aug 2011 05:14:29 -0700 (PDT) Sandeep Mahajan 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 > repo. > 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 conflicts. 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. P.S. 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 git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: workflow question for central git repo
Thanks. 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 repo. 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? Rgds Sandeep On Aug 22, 9:37 pm, Konstantin Khomoutov wrote: > On Mon, 22 Aug 2011 04:18:58 -0700 (PDT) > > Sandeep Mahajan 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. -- 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 git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
