[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] git pull origin branch
Thank you everyone. I will keep doing the same. I tried rebasing and had a few issues (merge conflicts!). Mark -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/8TuQNsE-ve8J. 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.
Re: [git-users] git pull origin branch
I would stick to having merge commits, because they more fully capture the work that took place. On Sun, Aug 21, 2011 at 10:41 PM, PJ Weisberg wrote: > There's nothing necessarily wrong with merge commits, but if you want to > straighten out your history before you push: > > $ git fetch origin > $ git rebase origin/branch > This approach, while it will work the vast majority of the time, will potentially break things without you knowing about it, and it's not obvious how. There's a brief write-up explaining it at http://aprescott.com/posts/git-rebase-landmines -- 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.
Re: [git-users] workflow question for central git repo
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.
[git-users] workflow question for central git repo
Hi, 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? Rgds, Sandeep -- 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] git pull origin branch
On Sun, 21 Aug 2011 13:39:35 -0700 (PDT) Mark Liversedge wrote: > Dumb question. I'm working on a branch locally that is also over at > github. I fetch the latest from github with: [...] > But when I pull other folks commits I get a merge commit and that > gets pushed up to github. > > I've come to the conclusion that my pull/push commands are flawed and > I should do this differently. > > How *should* I be doing this? Note that while PJ Weisberg offered you a working and popular solution, there's nothing inherently bad about merge commits, and this is more a policy problem rather than technical one. Many (most?) DVCSes do not support a concept of rebasing at all, so bringing others' changes always results in a merge commit in those systems. A classical case for rebasing is when you do not have commit access to the repository and are working on a feature which you then plan to submit as a series of patches (via e-mail for instance), otherwise merging may not be as bad as it may seem. -- 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.
