Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Thu, Feb 9, 2017 at 11:58 AM, Stephen Morton <stephen.c.mor...@gmail.com>
wrote:

>  Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton <stephen.c.mor...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <
>> igor.d.djordje...@gmail.com> wrote:
>>
>>> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>>>
>>>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.d...@gmail.com>
>>>> wrote:
>>>>
>>>>> For example, single (resolved) merge commit (M):
>>>>>
>>>>> 1) A---B---C---D branchA
>>>>> \   \
>>>>>  V---W---*M*---E branchB
>>>>>
>>>>> ... and conflicting merge commit (M) with multiple merge resolution
>>>>> commits (X, Y and Z):
>>>>>
>>>>> 2) A---B---C---D branchA
>>>>> \   \
>>>>>  V---W---*M*---*X*---*Y*---*Z*---E branchB
>>>>>
>>>>> Commits D and E are new commits on the two branches, representing the
>>>>> same code state/content in both cases. Commit Z in case (2) has the same
>>>>> code state/content as (squash) commit M in case (1).
>>>>>
>>>>>
>>>> I think that after the situation in 2), if you do a  `git checkout
>>>> branchA ; git merge branchB`, it will try to merge X,Y,Z,E when you only
>>>> want it to merge E. You might say "but they'll be no-ops because they're
>>>> already in A", but this is just not necessarily true.
>>>>
>>>
>>> I think you`re wrong here, here`s what the git-merge[1] documentation
>>> states (emphasis mine, pay attention to that part):
>>>
>>> "With the strategies that use 3-way merge (including the default,
>>> recursive), if a change is made on both branches, but later reverted on one
>>> of the branches, that change will be present in the merged result; some
>>> people find this behavior confusing. It occurs because **only the heads
>>> and the merge base are considered when performing a merge, not the
>>> individual commits**. The merge algorithm therefore considers the
>>> reverted change as no change at all, and substitutes the changed version
>>> instead."
>>>
>>> So in both case (1) and (2) above, all that subsequent merge with 'git
>>> checkout branchA; git merge branchB' considers/sees are branch head
>>> commits D and E, and common base commit C -- only these three, and they`re
>>> the same in both cases, thus the merge result is the same, no matter the
>>> different individual commits in between.
>>>
>>
>> *(Oops, hit [send] to early.)*
>
> *No.*
>
> Think about what the files in the repo looks like at state M and what
> commits X,Y,Z look like. M has lots of *committed conflict markers in it*.
> Commit X will 100% definitely involve removing committed conflict markers
> (and probably removing one of the "ours" or "theirs" sections). Commit X
> might also involve code refactoring.  So `git diff M E` that you are
> applying to A will also 100% definitely involve removing a bunch of
> conflict markers. This is independent of considering each of the individual
> commits, to specifically address the point above. What happens if you try
> to apply that diff to branchA? Chaos is what happens, on the scale of
> hundreds of files, and that's what I'm talking about.
>
> I had tried to avoid just this kind of wild goose chase with various
> disclaimers in my question. Apparently not. I appreciate that in you think
> you are trying to help. But you are not. Perhaps after this email you will
> finally get your "aha moment" and finally get to the point of understanding
> where I was when I first wrote my first post, I do not know. But I am not
> going to reply further.
>
> Steve
>

Igor is right and I am wrong.

I tried a Minimal, Complete, and Verifiable example and discovered that
indeed git "does the right thing" with respect to merge tracking.

That is interesting because it means the whole premise for my question and
concern was not correct. You can indeed just commit the merge conflicts and
resolve them later in separate commits and everything will be ok. It's not
pretty and there are probably many reasons not to do it, but if you have to
it won't further mess up your future.

I guess where I got confused was that, in my diagram above, I was not
taking into account the changes introduced by the merge commit. I was
imagining that a final 'git merge branchB' would merge 'git diff M E' into
branch A rather than actually it would merge 'git diff C E' which will
indeed produce the correct result. (This is probably an oversimplification,
but you get the general idea.)



Stephen

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Thursday, 9 February 2017 17:31:38 UTC-5, Philip Oakley wrote:
>
> Hi Stephen,
>  
> There is another approach to merging, that is the 'imerge' tool [1], which 
> does consider every commit on both sides of the merge. 
>  
> It was developed for the cases where the two branches have diverged in 
> many places. 
>  
> The 'i' in 'imerge' is a reference to it creating an incremental image of 
> the merge process, so you can see where the individual commits have 
> conflicts, so you can see where to investigate.
>  
> It allows you (as I understand it) to picks points on the developing merge 
> where there are no conflicts to use as the next commit point(s), so making 
> useful progress quickly.
>  
> Some of the discussion had somewhat diverged between the 'what has Git 
> coded (for merge) and why does it choose to do it that way' and 'how and 
> where should these (tricky) merges be approached from'. Neither is wrong 
> per se, rather they are each right in their own context, but given that the 
> contexts had divereged the approaches had likewise diverged..
>  
> I've not used imerge myself, but it has had some good responses.
>  
> Philip
>  
> [1] 
> https://github.com/mhagger/git-imerge#git-imergeincremental-merge-and-rebase-for-git
>  see 
> also the linked articles, video, presentation, etc.
>  
>


Thanks Philip.

Magnus already mentioned 'git imerge' on January 26th and I thanked him and 
wrote a reply about it on the 27th.

Stephen
 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

 Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton <stephen.c.mor...@gmail.com>
wrote:

>
>
> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <
> igor.d.djordje...@gmail.com> wrote:
>
>> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>>
>>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.d...@gmail.com>
>>> wrote:
>>>
>>>> For example, single (resolved) merge commit (M):
>>>>
>>>> 1) A---B---C---D branchA
>>>> \   \
>>>>  V---W---*M*---E branchB
>>>>
>>>> ... and conflicting merge commit (M) with multiple merge resolution
>>>> commits (X, Y and Z):
>>>>
>>>> 2) A---B---C---D branchA
>>>> \   \
>>>>  V---W---*M*---*X*---*Y*---*Z*---E branchB
>>>>
>>>> Commits D and E are new commits on the two branches, representing the
>>>> same code state/content in both cases. Commit Z in case (2) has the same
>>>> code state/content as (squash) commit M in case (1).
>>>>
>>>>
>>> I think that after the situation in 2), if you do a  `git checkout
>>> branchA ; git merge branchB`, it will try to merge X,Y,Z,E when you only
>>> want it to merge E. You might say "but they'll be no-ops because they're
>>> already in A", but this is just not necessarily true.
>>>
>>
>> I think you`re wrong here, here`s what the git-merge[1] documentation
>> states (emphasis mine, pay attention to that part):
>>
>> "With the strategies that use 3-way merge (including the default,
>> recursive), if a change is made on both branches, but later reverted on one
>> of the branches, that change will be present in the merged result; some
>> people find this behavior confusing. It occurs because **only the heads
>> and the merge base are considered when performing a merge, not the
>> individual commits**. The merge algorithm therefore considers the
>> reverted change as no change at all, and substitutes the changed version
>> instead."
>>
>> So in both case (1) and (2) above, all that subsequent merge with 'git
>> checkout branchA; git merge branchB' considers/sees are branch head
>> commits D and E, and common base commit C -- only these three, and they`re
>> the same in both cases, thus the merge result is the same, no matter the
>> different individual commits in between.
>>
>
> *(Oops, hit [send] to early.)*

*No.*

Think about what the files in the repo looks like at state M and what
commits X,Y,Z look like. M has lots of *committed conflict markers in it*.
Commit X will 100% definitely involve removing committed conflict markers
(and probably removing one of the "ours" or "theirs" sections). Commit X
might also involve code refactoring.  So `git diff M E` that you are
applying to A will also 100% definitely involve removing a bunch of
conflict markers. This is independent of considering each of the individual
commits, to specifically address the point above. What happens if you try
to apply that diff to branchA? Chaos is what happens, on the scale of
hundreds of files, and that's what I'm talking about.

I had tried to avoid just this kind of wild goose chase with various
disclaimers in my question. Apparently not. I appreciate that in you think
you are trying to help. But you are not. Perhaps after this email you will
finally get your "aha moment" and finally get to the point of understanding
where I was when I first wrote my first post, I do not know. But I am not
going to reply further.

Steve

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <
igor.d.djordje...@gmail.com> wrote:

> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>
>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.d...@gmail.com>
>> wrote:
>>
>>> For example, single (resolved) merge commit (M):
>>>
>>> 1) A---B---C---D branchA
>>> \   \
>>>  V---W---*M*---E branchB
>>>
>>> ... and conflicting merge commit (M) with multiple merge resolution
>>> commits (X, Y and Z):
>>>
>>> 2) A---B---C---D branchA
>>> \   \
>>>  V---W---*M*---*X*---*Y*---*Z*---E branchB
>>>
>>> Commits D and E are new commits on the two branches, representing the
>>> same code state/content in both cases. Commit Z in case (2) has the same
>>> code state/content as (squash) commit M in case (1).
>>>
>>>
>> I think that after the situation in 2), if you do a  `git checkout
>> branchA ; git merge branchB`, it will try to merge X,Y,Z,E when you only
>> want it to merge E. You might say "but they'll be no-ops because they're
>> already in A", but this is just not necessarily true.
>>
>
> I think you`re wrong here, here`s what the git-merge[1] documentation
> states (emphasis mine, pay attention to that part):
>
> "With the strategies that use 3-way merge (including the default,
> recursive), if a change is made on both branches, but later reverted on one
> of the branches, that change will be present in the merged result; some
> people find this behavior confusing. It occurs because **only the heads
> and the merge base are considered when performing a merge, not the
> individual commits**. The merge algorithm therefore considers the
> reverted change as no change at all, and substitutes the changed version
> instead."
>
> So in both case (1) and (2) above, all that subsequent merge with 'git
> checkout branchA; git merge branchB' considers/sees are branch head
> commits D and E, and common base commit C -- only these three, and they`re
> the same in both cases, thus the merge result is the same, no matter the
> different individual commits in between.
>

*No.*

Think about what the files in the repo looks like at state M and what
commits X,Y,Z look like. M has lots of *committed conflict markers in it*.
Commit X will 100% definitely involve removing committed conflict markers
(and probably removing one of the "ours" or "theirs"). Commit X might also
involve code refactoring.  So `git diff M E` that you are applying to A
will also 100% definitely involve removing a bunch of conflict markers

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Tuesday, 7 February 2017 18:25:32 UTC-5, Igor Djordjevic wrote:
>
> On Wednesday, January 25, 2017 at 11:17:11 PM UTC+1, Stephen Morton wrote:
>>
>> I'm looking for a git branching and merge strategy for merge with lots of 
>> conflicts requiring multiple people. I can make it work, and I understand 
>> git, but it all seems kind of awkward and it feels like there must be a 
>> better way.
>>
>> I've got a big git merge to do. There are lots of conflicts and it 
>> requires many people to resolve them all.
>>
>> The only way to handle this in git, AFAIK, is to start the merge and then 
>> just commit all files with conflicts in them and then let different people 
>> work on the different conflicts, committing them as they go. That is great 
>> for resolving the conflicts. In the diagram below, branchA is merged into 
>> branchB with merge commit M. The code in the repo at M is full of 
>> conflicts. Many of the conflicts in the merge are actually resolved in 
>> commits x, y, z.
>>
>> o---o---o---o branchA
>>  \   \
>>   \-o---o-M---x---y---z branchB
>>
>>
>> But I worry that the above strategy is not good for git's merge tracking 
>> and future merges. Because if we do a 'git checkout branchA; git merge 
>> branchB`, git will erroneously try to merge x,y,z into branchA.
>>
>> I *could *create branchB2 where I re-do the original merge but then just 
>> `git checkout z -- . ` and commit that as the merge commit. That would 
>> work well for the git merge tracking. Then I would keep branchB just as 
>> historical reference for "who fixed what conflict and why" during the merge.
>>
>>
>> The above would all work, but it seems so un-git-like. It feels like 
>> there must be a much better and established practice, yet I have not found 
>> anything online. Is there a better way to do this?
>>
>> Thanks,
>> Steve
>>
>> p.s. I'm aware of answers like "Your workflow is broken, with git you 
>> merge often and therefore never have lots of conflicts." It's just too long 
>> a discussion to argue that point, so let's just avoid it, ok.
>>
>
> I`m sorry, but what I`m missing here is what you are actually trying to 
> accomplish...?
>
> I mean, you provided the graph, and you say you`re worried that if you do 
> 'git 
> checkout branchA; git merge branchB', commits x, y and z would 
> "erroneously" end up in branchA, which should mean it is something you 
> don`t want to happen.
>
> BUT, then you say that you _could_ redo the merge, do 'git checkout z -- 
> .' and commit that as resolved merge commit, and you would be happy with 
> it (once you later merge branchB into branchA to introduce some new changes 
> from branchB into branch A), keeping old (and unmerged) branchB for 
> reference (commits x, y, z).
>
> Now, I`m still pretty new to git, so please excuse me if I`m missing 
> something, but how would that be different than just simply doing 'git 
> checkout branchA; git merge branchB' in the first place (with the graph 
> you`ve shown) - which you said you want to avoid...?
>
> It seems the only difference would be keeping all x, y, z commits still in 
> there (branchA history), which you first said you don`t want, but then 
> later showed that you do actually seem to care about (in terms of changes 
> they introduce), as you would be fine with committing them all at once as 
> part of the (resolved) merge commit...?
>
> I`m sorry if I`m failing to grasp something obvious here, I`m just a bit 
> confused - you don`t want the commits (initial 'git merge branchB' concern), 
> but you do want the changes (redo merge, checkout z, resolve commit)... but 
> you also would like to have the history. But, (1) commits x, y and z _are_ 
> history, and (2) either way, you end up with with branchA state being the 
> same (whichever of the two paths you take).
>
> So, what is that you would actually like to do (and I`m missing to get 
> here)...? :)
>
> Regards,
> BugA
>


Since you freely admit "I'm still pretty new to git", I'll try to explain 
once. But if I don't quite get it so that you understand, I'm afraid that's 
all I can do. (My time is better spent perhaps helping answer other 
people's questions on stackoverflow than helping somebody who, in a 
somewhat snarky tone, asks me to explain my own question back to them.)

 - Git is great at merge tracking. Because its DAG implicitly tracks 
merges. But merge commits are just one single commit. 
 - What if you have a merge whose conflicts are so complex that you cannot 
resolve them all at once, you have to get a bunch of people to resolve

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

Thank you for taking the time to think about my issues. However, I will
direct you then to the end of my original question. " p.s. I'm aware of
answers like "Your workflow is broken, with git you merge often and
therefore never have lots of conflicts." It's just too long a discussion to
argue that point, so let's just avoid it, ok. "

Stephen

On Mon, 6 Feb 2017 at 15:00 Hugh Gleaves <hugh.glea...@gmail.com> wrote:

> Yes I did read that already, what I don't know is the actual scale:
>
>
>- How many developers on this project branch?
>- How long does the project take?
>- How many changes (commits) do developers make per week?
>- How often do you merge ongoing changes from master into the project
>branch?
>- How many changes do developers make to master per week?
>
>
>
>
>
> On Monday, February 6, 2017 at 12:36:57 PM UTC-7, Stephen Morton wrote:
>
> Thanks for your reply Hugh. Have a look at my follow up reply earlier in
> the thread where I use Microsoft and the XBOX as an analogy. You should get
> the idea.
>
> Stephen
>
>
> On Mon, 6 Feb 2017 at 14:33 Hugh Gleaves <hugh.g...@gmail.com> wrote:
>
> First here's a summary of what I setup for a small team:
>
>
> http://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task/41753291#41753291
>
> You say "big merge" and "lots of conflicts" I wonder why this is happening?
>
> Tell me what do you mean by a "big merge" and what do you consider "lots
> of conflicts"?
>
> Ideally the more frequently you merge the smaller will be the scale of any
> conflicts.
>
> What do branches represent in your situation? are they representing
> projects or bug fixes etc? do multiple developers work on a branch or just
> single developers?
>
>
>
> On Wednesday, January 25, 2017 at 3:17:11 PM UTC-7, Stephen Morton wrote:
>
> I'm looking for a git branching and merge strategy for merge with lots of
> conflicts requiring multiple people. I can make it work, and I understand
> git, but it all seems kind of awkward and it feels like there must be a
> better way.
>
> I've got a big git merge to do. There are lots of conflicts and it
> requires many people to resolve them all.
>
> The only way to handle this in git, AFAIK, is to start the merge and then
> just commit all files with conflicts in them and then let different people
> work on the different conflicts, committing them as they go. That is great
> for resolving the conflicts. In the diagram below, branchA is merged into
> branchB with merge commit M. The code in the repo at M is full of
> conflicts. Many of the conflicts in the merge are actually resolved in
> commits x, y, z.
>
> o---o---o---o branchA
>  \   \
>   \-o---o-M---x---y---z branchB
>
>
> But I worry that the above strategy is not good for git's merge tracking
> and future merges. Because if we do a 'git checkout branchA; git merge
> branchB`, git will erroneously try to merge x,y,z into branchA.
>
> I *could *create branchB2 where I re-do the original merge but then just `git
> checkout z -- . ` and commit that as the merge commit. That would work
> well for the git merge tracking. Then I would keep branchB just as
> historical reference for "who fixed what conflict and why" during the merge.
>
>
> The above would all work, but it seems so un-git-like. It feels like there
> must be a much better and established practice, yet I have not found
> anything online. Is there a better way to do this?
>
> Thanks,
> Steve
>
> p.s. I'm aware of answers like "Your workflow is broken, with git you
> merge often and therefore never have lots of conflicts." It's just too long
> a discussion to argue that point, so let's just avoid it, ok.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/0DObGNobp1w/unsubscribe.
>
> To unsubscribe from this group and all its topics, send an email to
> git-users+...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/0DObGNobp1w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

Thanks for your reply Hugh. Have a look at my follow up reply earlier in
the thread where I use Microsoft and the XBOX as an analogy. You should get
the idea.

Stephen


On Mon, 6 Feb 2017 at 14:33 Hugh Gleaves <hugh.glea...@gmail.com> wrote:

> First here's a summary of what I setup for a small team:
>
>
> http://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task/41753291#41753291
>
> You say "big merge" and "lots of conflicts" I wonder why this is happening?
>
> Tell me what do you mean by a "big merge" and what do you consider "lots
> of conflicts"?
>
> Ideally the more frequently you merge the smaller will be the scale of any
> conflicts.
>
> What do branches represent in your situation? are they representing
> projects or bug fixes etc? do multiple developers work on a branch or just
> single developers?
>
>
>
> On Wednesday, January 25, 2017 at 3:17:11 PM UTC-7, Stephen Morton wrote:
>
> I'm looking for a git branching and merge strategy for merge with lots of
> conflicts requiring multiple people. I can make it work, and I understand
> git, but it all seems kind of awkward and it feels like there must be a
> better way.
>
> I've got a big git merge to do. There are lots of conflicts and it
> requires many people to resolve them all.
>
> The only way to handle this in git, AFAIK, is to start the merge and then
> just commit all files with conflicts in them and then let different people
> work on the different conflicts, committing them as they go. That is great
> for resolving the conflicts. In the diagram below, branchA is merged into
> branchB with merge commit M. The code in the repo at M is full of
> conflicts. Many of the conflicts in the merge are actually resolved in
> commits x, y, z.
>
> o---o---o---o branchA
>  \   \
>   \-o---o-M---x---y---z branchB
>
>
> But I worry that the above strategy is not good for git's merge tracking
> and future merges. Because if we do a 'git checkout branchA; git merge
> branchB`, git will erroneously try to merge x,y,z into branchA.
>
> I *could *create branchB2 where I re-do the original merge but then just `git
> checkout z -- . ` and commit that as the merge commit. That would work
> well for the git merge tracking. Then I would keep branchB just as
> historical reference for "who fixed what conflict and why" during the merge.
>
>
> The above would all work, but it seems so un-git-like. It feels like there
> must be a much better and established practice, yet I have not found
> anything online. Is there a better way to do this?
>
> Thanks,
> Steve
>
> p.s. I'm aware of answers like "Your workflow is broken, with git you
> merge often and therefore never have lots of conflicts." It's just too long
> a discussion to argue that point, so let's just avoid it, ok.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/0DObGNobp1w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote:
>
>
> Stephen Morton <stephen@gmail.com > writes: 
>
> > I'm looking for a git branching and merge strategy for merge with lots 
> > of conflicts requiring multiple people. I can make it work, and I 
> > understand git, but it all seems kind of awkward and it feels like 
> > there must be a better way. 
> > 
> > I've got a big git merge to do. There are lots of conflicts and it 
> > requires many people to resolve them all. 
>
> Have you looked at git-imerge? 
>

No, I had not looked at git imerge. It looks interesting for some of the 
merges we do. Thanks.

git imerge is of course a tool to help you to resolve the conflicts in a 
big merge. My question really was much more along the lines of once the 
conflicts are resolved, what is the best way to arrange the commits/merges 
(the DAG) to represent a complex multi-step conflict resolution in git. So 
although very useful-looking, 'git imerge' isn't really an answer to my 
question. However, I see from the docs/video that 'git imerge' has a number 
of optional solutions to my question when running its finish/simplify 
command: [merge, rebase, rebase-with-history,  full]. I imagine most people 
eventually just take 'merge' or 'rebase'. The 'rebase-with-history' and 
'full' options are interesting and do present a novel 'more git-y' solution 
to my problem, although you can really only achieve them using something 
like 'git imerge'.
 So it looks to me like really if not using something like 'git imerge' 
from the beginning, if just resolving all the conflicts as a series of 
commits after the fact, there is not more 'git-y' way to do what I want to 
do. We will resolve all the conflicts as described originally works and 
then just use that final state to make one single merge commit to represent 
the whole merge, perhaps saving all the conflict resolutions in a branch 
for posterity.

Steve

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

On Thursday, 26 January 2017 16:12:43 UTC-5, Philip Oakley wrote:
>
> - Original Message - 
>
> I'm looking for a git branching and merge strategy for merge with lots of 
> conflicts requiring multiple people. I can make it work, and I understand 
> git, but it all seems kind of awkward and it feels like there must be a 
> better way.
>
> I've got a big git merge to do. There are lots of conflicts and it 
> requires many people to resolve them all.
>
> The only way to handle this in git, AFAIK, is to start the merge and then 
> just commit all files with conflicts in them and then let different people 
> work on the different conflicts, committing them as they go. That is great 
> for resolving the conflicts. In the diagram below, branchA is merged into 
> branchB with merge commit M. The code in the repo at M is full of 
> conflicts. Many of the conflicts in the merge are actually resolved in 
> commits x, y, z.
>
> o---o---o---o branchA
>  \   \
>   \-o---o-M---x---y---z branchB
>
>
> But I worry that the above strategy is not good for git's merge tracking 
> and future merges. Because if we do a 'git checkout branchA; git merge 
> branchB`, git will erroneously try to merge x,y,z into branchA.
>
> I *could *create branchB2 where I re-do the original merge but then just `git 
> checkout z -- . ` and commit that as the merge commit. That would work 
> well for the git merge tracking. Then I would keep branchB just as 
> historical reference for "who fixed what conflict and why" during the merge.
>
>
> The above would all work, but it seems so un-git-like. It feels like there 
> must be a much better and established practice, yet I have not found 
> anything online. Is there a better way to do this?
>
> Thanks,
> Steve
>
> p.s. I'm aware of answers like "Your workflow is broken, with git you 
> merge often and therefore never have lots of conflicts." It's just too long 
> a discussion to argue that point, so let's just avoid it, ok.
>  
>
> OK, so what is your workflow, and work products, in a little more detail - 
> how is it made to 'work' at the moment?
>  
> Is the project well modularised with no file >100 lines (excepting, maybe, 
> well developed libraries that never change), or are they mega-beast files 
> with a mix of long and short functions/objects/procedures ?
>  
> How are the review / merges done? do you have a small core team that hangs 
> together that can work on each issue, or is it multiple functions having a 
> review by committee that then depatches instructions to a poor coder to try 
> and implement before the cycle continues..
>  
> Do you have any intermediate work products (in the current process) where 
> some parts are fully merged, and then you can move on to the other parts; 
> or it's all partly merged as an intermediate work product for another round?
>  
> What is the smallest work element you could extract and get merged (done, 
> done style) from beneath the management's radar, as that you can do (with 
> proper commit message) in Git.
>  
> Have you seen the Mikado method (aka pick up sticks) as applied to 
> correctling faulty software.  https://vimeo.com/54450491 is a nice 
> presentation from Lean Agile Scotland 
>  a few years ago.
>  
> --
> Philip
> [If I were you I wouldn't start from here, he said]
>

Thanks for your reply Philip.

I'm really not looking for "SW development workflow" advice. I'm looking 
for the best way to handle in git the situation I describe above.

This is a huge corporate product. (If you're asking about files with 100 
lines of code, you cannot begin to believe how far off you are.) Imagine, 
if you will, that the XBOX is based on Windows XP, and now it wants to 
merge all of its XBOX-specific changes (which permeate much of its version 
of the Windows XP code) with Windows 10. All the while, nothing is static: 
the XBOX coding continues, as do the Windows 10 patches. Once this is done, 
in several months, the XBOX code will remain based on Windows 10 for 
several years. In a few years, this will all be one again when the XBOX 
merges with Windows 2020. (This product is neither a gaming nor a Microsoft 
product, but the analogy is pretty good.)

Steve


-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Stephen Morton]

I'm looking for a git branching and merge strategy for merge with lots of 
conflicts requiring multiple people. I can make it work, and I understand 
git, but it all seems kind of awkward and it feels like there must be a 
better way.

I've got a big git merge to do. There are lots of conflicts and it requires 
many people to resolve them all.

The only way to handle this in git, AFAIK, is to start the merge and then 
just commit all files with conflicts in them and then let different people 
work on the different conflicts, committing them as they go. That is great 
for resolving the conflicts. In the diagram below, branchA is merged into 
branchB with merge commit M. The code in the repo at M is full of 
conflicts. Many of the conflicts in the merge are actually resolved in 
commits x, y, z.

o---o---o---o branchA
 \   \
  \-o---o-M---x---y---z branchB


But I worry that the above strategy is not good for git's merge tracking 
and future merges. Because if we do a 'git checkout branchA; git merge 
branchB`, git will erroneously try to merge x,y,z into branchA.

I *could *create branchB2 where I re-do the original merge but then just `git 
checkout z -- . ` and commit that as the merge commit. That would work well 
for the git merge tracking. Then I would keep branchB just as historical 
reference for "who fixed what conflict and why" during the merge.


The above would all work, but it seems so un-git-like. It feels like there 
must be a much better and established practice, yet I have not found 
anything online. Is there a better way to do this?

Thanks,
Steve

p.s. I'm aware of answers like "Your workflow is broken, with git you merge 
often and therefore never have lots of conflicts." It's just too long a 
discussion to argue that point, so let's just avoid it, ok.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Slow git pushes, 1 min in pack-objects

[Stephen Morton]

On Thursday, 5 March 2015 11:08:33 UTC-5, Thomas Ferris Nicolaisen wrote:

 On Wednesday, March 4, 2015 at 9:11:45 PM UTC+1, Stephen Morton wrote:

 I'm experiencing very slow git pushes. On the order of 1 minute to push a 
 trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be 
 taking a lot of time in the pack-objects phase. 

 Others are not seeing this with the same repo, but I'm the only one 
 working in a VM.
 ...

 Any ideas?


 Could have something to do with the filesystem. Is your Git repository 
 located in a folder shared from the host system, using some kind of virtual 
 fs? This could be a performance bottleneck:

 http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines

 If you can't figure out the filesystem type, please paste us the output of 
 `pwd` while the repo is current directory, along with the output of `mount`.



It is an ext4 filesystem on the guest linux drive.
On the host side, it is a .vmdk file and the virtualization software used 
is virtualbox. While the drive is dynamically allocated, after I ran into 
this issue, I used fallocate to create a 50GB dummy file and then delete it 
to ensure that there was headroom in the drive and that dynamic allocation 
slowness was not the issue, and subsequent pushes were still slow.
I have not experienced any filesystem slowness issues in the months I've 
been using this vm.

I'm very linux knowledgeable, and becoming more git knowledgeable, so feel 
free to ask me questions as technical as you want.

Steve


 

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Slow git pushes, 1 min in pack-objects

[Stephen Morton]

I'm experiencing very slow git pushes. On the order of 1 minute to push a 
trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be 
taking a lot of time in the pack-objects phase. 

Others are not seeing this with the same repo, but I'm the only one working 
in a VM.

~/ws/git/repo.1/repo  date; git push smorton; date
Wed Mar  4 15:03:11 EST 2015
15:03:11.086758 git.c:349   trace: built-in: git 'push' 
'smorton'
15:03:11.126665 run-command.c:341   trace: run_command: 'ssh' '-p' 
'7999' 'git@privacy.privacy' 'git-receive-pack '\''~smorton/repo.git'\'''
15:03:20.383341 run-command.c:341   trace: run_command: 'pack-objects' '
--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '
--progress'
15:03:20.383945 exec_cmd.c:134  trace: exec: 'git' 'pack-objects' '
--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '
--progress'
15:03:20.385168 git.c:349   trace: built-in: git 'pack-objects' 
'--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' 
'--progress'
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 20.86 KiB | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To ssh://git@privacy.privacy:7999/~smorton/repo.git
   5fe662f..a137bda  my_branch - my_branch
Wed Mar  4 15:04:22 EST 2015

After it was slow at first, I tried setting these which did not help

repack.writebitmaps=true
pack.windowmemory=100m



Details:
git version 2.1.4
OS: CentOS 6.6 64-bit *in a VM*. 
repo size: huge. 6 GB .git directory, around 800 MB working tree.
VM has 8 MB RAM and 8 cores.
CPU: i7, 8 core (4 cores hyperthreaded)



Any ideas?
Thanks.

Steve

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Cherry-pick workflow advice

[Stephen Morton]

On Wednesday, 7 January 2015 20:22:46 UTC-5, Stephen Morton wrote:

 On Wednesday, 7 January 2015 17:20:08 UTC-5, Magnus Therning wrote:

 On Wed, Jan 07, 2015 at 12:40:35PM -0800, Stephen Morton wrote: 
  My team is planning a transition to git. We're a big division in a 
  corporate environment. I'm the tools guy; I guess the latest 
  trendy term is DevOps. 
  
  Our current workflow involves the equivalent of using cherry-pick to 
  move approved bugfixes into the customer release branches. (1) We 
  intend to maintain this workflow with git for the conceivable 
  future. 
  
  I can rewrite our existing cherry-picking scripts for use with git 
  and that is *mostly *no problem, I think, except for one thing: 
  merges. If a dev doesn't use fetch --rebase, there could at some 
  point be a non-trivial merge as part of their series of commits. 
  Merges, from what I understand, present a problem for cherry-pick. I 
  can see two solutions at the moment. 
  
 1. Don't allow any merges in the branch to be cherry-picked from. 
(This is a bugfixes-only branch, no massive feature work.) 
We'll likely use some wrappers around git commands, to make 
'fetch --rebase' happen automagically for devs. If a dev tries 
to push a merge, block it and get them to do an interactive 
rebase until the merge is removed. This might sound crazy, but 
coming from a non-DVCS background it would not be a very 
different from our old workflow. 
 2. Cherry-pick the merge by introducing what seems to me to be 
likely hellishly complicated and error-prone code into the 
cherry-picking script to try to determine the correct merge 
parent to use when cherry-picking the merge. 
  
  Obviously, I prefer #1 and include #2 only for completeness. But I 
  don't really like #1 either. 
  
  Does anybody have any thoughts on this? Preferences to these 
  solutions, better versions of these solutions, additional different 
  solutions, other ways of thinking about the problem? 
  
  (While I'm mostly looking for this is how you do it comments, I 
  welcome *constructive* you should do it a different way comments. 
  But ones where you just say I'm crazy and doing it all wrong without 
  knowing anything about the size of my team, our corporate culture, 
  the number of customer release branches we have to support, the 
  penalties we are liable for if bugs are introduced in the field, 
  etc, are frankly not helpful at all.  Honestly, save your breath. 
  :-) 

 I know you write you intend to maintain the current workflow for the 
 foreseeable future, but have you considered turning around the 
 direction of merges?  That is, make the change on the customer 
 release branch and then merge into the development branch?  (A better 
 description can be found in the first half of 
 http://stackoverflow.com/a/2558501/34996.) 

 /M 


 That is a good point, and is actually what we do. I was trying to provide 
 a simplified description of what we do. We have a sort of continuous 
 integration ++ system. So devs commit to the pre-customer branch and it 
 undergoes normal continuous automated integration testing on the way there. 
 But before it is ready to be shipped in a customer load it must undergo 
 some degree of targeted testing that only a human can define or gate. and 
 that will take an unknown amount of time for all sorts of reasons -- from 
 hours to months. It is only after this point that it is cherry-picked into 
 the final customer branch.

 Steve


Actually, would option #2 be that hard? Presumably, if I have a bugfix to 
cherrypick which consists of a bunch of regular commits and one or more 
merge commits, I *can *figure out which parent in the merge I want to diff 
against. I just need to figure out which merge parent contains the other 
commits of interest. Or at least, which one has the shortest path to a 
commit of interest. (Or something like that.)

I'm sure there are some pathological cases one could concoct to prove this 
is impossible. But but given a normal dev working on one computer with 
their work in one clone and only pulling off the central master server, or 
even perhaps two different devs working on different aspects of the same 
bugfix, I'm beginning to think that it wouldn't be too bad at all.

Comments?

Steve

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Behavior of 'git clone --depth d --no-single-branch' ? It's not doing at all what I expect.

[Stephen Morton]

On Saturday, 6 December 2014 05:50:37 UTC-5, Philip Oakley wrote:

  
  Original Message - 

 *From: Stephen Morton*
 *To:* git-...@googlegroups.com javascript: 
 *Sent:* Friday, December 05, 2014 7:11 PM
 *Subject:* [git-users] Behavior of 'git clone --depth d 
 --no-single-branch' ? It's not doing at all what I expect.

 I'm trying to make a slice of a very large repo, discarding old history.

 I'm doing this which I figure should take me back enough time.
  git clone --depth 9320 --no-single-branch ssh://URL


 But then the resulting repo has the entire history. Neither the whole 
 history, nor the master branch history have been truncated to 9,320 
 changesets. It's as if the --depth parameter is being ignored.

   $  git log --oneline --all | wc -l
 61380
  $ git log master --oneline | wc -l
 262792

  $  git --version
 git version 2.1.3


 Am I doing something wrong, or misunderstanding something?

 Most likely misunderstanding something ;-)
 That something is probably that the depth is around each leg of the DAG, 
 so merges can create shortcuts which suck in a lot of other commits you 
 hadn't expected (at least that's my understanding). This includes old 
 redundant branches which are way back in history!
 The other option, which is a bit of a guess, is that you are getting the 
 depth from the various tags as well.
 

 As a follow-up question, what I *really* want to do is to split a repo 
 up, with the newer history in one part and the older history in the other. 
 Ideally, I would pick a changeset and it and all its descendants would be 
 in the newer part and its ancestors (and their descendants) would be in the 
 other part. This strikes me as a better, more branch-aware way of splitting 
 up a repo. 
 
 Try using 'git filter-branch' for creating new repos. Filter the branches 
 based on say commit date, or some measure of depth (to cover clock errors 
 between committer machines). Obviously, you'l need to run it twice, once to 
 create the older segment, and once for the new segment.
  
 Don't forget that all the 'new repo' commits will get new sha1 values 
 because their history 'changed' (amputation below date X), so you will need 
 a change over date when your developers check everything in, you do the 
 remaining split, and then they checkout against the new repo sha1s.
  
  
 Alternatively, just clone the repo and hard delete the old unwanted 
 branches followed by a garbage collect. This leaves you with just your 
 master (trunk) branch and a few current ones, hopefully spliced high up the 
 commit tree. (assumes a DAG shape that is ammenable to such pruning ;-) 
 [because you have a clone of your old you will have sha1 continuity across 
 and between the many distributed partial copies]
  
 As yet there is no way of doing a --timedepth=time_t val fetch, which 
 would be ideal. (As they say, contributions welcome!)
 --
 Philip


Thanks Pilip, that's useful.

Your answers gave me enough information to do further web searches to 
discover that I can use a graft to split up my repo. (Sort of backwards 
sounding at first, but it works.) Then I can use filter-branch to remove 
the old code isolated by the graft, and a whole series of garbage 
collection after that to actually get the repo size down.

Steve
 

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Behavior of 'git clone --depth d --no-single-branch' ? It's not doing at all what I expect.

[Stephen Morton]

I'm trying to make a slice of a very large repo, discarding old history.

I'm doing this which I figure should take me back enough time.
git clone --depth 9320 --no-single-branch ssh://URL


But then the resulting repo has the entire history. Neither the whole 
history, nor the master branch history have been truncated to 9,320 
changesets. It's as if the --depth parameter is being ignored.

 $  git log --oneline --all | wc -l
61380
 $ git log master --oneline | wc -l
262792

 $  git --version
git version 2.1.3


Am I doing something wrong, or misunderstanding something?



As a follow-up question, what I *really* want to do is to split a repo up, 
with the newer history in one part and the older history in the other. 
Ideally, I would pick a changeset and it and all its descendants would be 
in the newer part and its ancestors (and their descendants) would be in the 
other part. This strikes me as a better, more branch-aware way of splitting 
up a repo. 


Thanks,
Steve

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.