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 
wrote:

>  Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton 
> 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 
 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

[Philip Oakley]

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.

-- 
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

[Igor Djordjevic]

On Thursday, February 9, 2017 at 5:58:56 PM UTC+1, Stephen Morton wrote:
>
>  Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton  > wrote:
>>
>> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic > > 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  
 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.*
>

Hmm... *Yes*? :D
 

> 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.
>

All this has nothing to do with 'git checkout branchA; git merge branchB' you 
were concerned with and what we were discussing so far. For that merge to 
happen, only D and E (branch heads) and C (common base) are relevant, that 
is diffs C..D and C..E, and these are _the same_ in both cases you 
mentioned. Commits M, X, Y and Z are all irrelevant here (and their diffs 
as well).

If you`re complaining that once you resolve all the merge conflicts in Z 
and try to merge branchB back to branchA all the hell breaks loose (again), 
that is very true -- but that is something you`re imposing with your 
current flow, having branchA and branchB so much different (like totally 
different projects), and both long living and alive, and still merging 
between them back and forth.

And that is something you still have with your preferred case (1) as well 
(without commits X, Y and Z), as as soon you try to merge E back to D it`s 
still the same, _every_ resolution/refactoring contained in merge commit M 
will get inside your branchA (through that commit E).

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. 
>

Hmm, that`s pretty ignorant for someone asking for help in a public space, 
but oh well, you have every right to do so :) *Perhaps after this e-mail 
you will finally get your "aha moment" and finally get to the point of* 
_actually 
showing_ what you want to accomplish in the first place (and what I asked 
for in my very first e-mail here, still in 

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 
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 
>>> 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 
>> 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.

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

[Magnus Therning]

Stephen Morton  writes:

> - So, the question is: what is the best git-like way to a) record the
> merge in a proper way that will allow any subsequent merges to occur
> properly (most important) and additionally b) record the intermediate
> conflict fixing if possible.

You are aware of `rerere` I guess, right?

I don't know if you can share the recorded resolutions though.

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

Any sufficiently advanced technology is indistinguishable from a rigged
demo.
 — Andy Finkel

-- 
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.


signature.asc
Description: PGP signature

[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 the 
conflicts slowly over time? I propose a method of accomplishing the 
conflict resolution (that I take as a premise to my question), but it 
involves an initial merge commit and then several subsequent commits which 
cannot be left as the final state because subsequent merges would not 
happen properly. I am not sure about the best way to take that final 
repository state and represent in a final series of git merge 

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

[Igor Djordjevic]

>
> ... and (2) either way, you end up with with branchA state being the same 
> (whichever of the two paths you take).
>

 p.s. Just to clarify "branchA state being the same" - once you eventually 
do that 'git merge branchB' in the future, that is, no matter if you`re 
merging from z directly, or from redone/resolved merge commit (being the 
same as z).

-- 
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

[Igor Djordjevic]

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

-- 
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

[Hugh Gleaves]

I read that too, but if you're unwilling to answer any of my questions 
below then there's nothing more for me to say.

On Monday, February 6, 2017 at 1:41:07 PM UTC-7, Stephen Morton wrote:
>
> 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  > 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  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 

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  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  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

[Hugh Gleaves]

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  > 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 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  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.

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

[Hugh Gleaves]

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 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.