Re: [git-users] Git Branching and Merging Strategy for a Shared Team Resource

[Mikko Rantalainen]

On Fri, 26 Apr 2019, 04:22 ckdev101,  wrote:

>
> Here is the team make-up:
>
>- Sprint Team #1
>- Sprint Team #2
>- *Shared* DBA across teams
>- Dev. Lead (Myself)
>
> ...
>
> The problem is that the shared DBA needs to constantly and consistently
> make changes *across* teams for SQL-related items. In addition, for just
> SQL related items his changes need to be considered authoritative. His
> changes are localized to a specific folder, if that helps.
>

In my experience, you'll have much better experience with shared-nothing
setup. We have one database per developer, but during development the
database doesn't need to contain production data as-is but something with
the same schema and minimum data to test (all?) features.

If you have a solid set of database migration scripts, each developer
should be able to start with empty database and the migration takes care of
the rest.

Note that none of the above had nothing to do with git except that git is
already distributed and already fits the shared nothing style.

-- 
Mikko

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

[Hugh Gleaves]

I'm actually very interested in your problem because I would like to know 
if Git and this or that workflow are genuinely not up to scratch for your 
needs. 

In other words I'm interested to see what it is about your situation that 
differs from some more pedestrian one.

You say "merging Word onto Xbox" and I'm wondering what this entails. I 
would perceive this (at first pass anyway) as best represented as distinct 
product branches in some repo.

Ordinarily the model is "we have a production branch for our code" and all 
other branches are temporary and represent the work on some change or 
other, destined to become part of the production branch, the temp branch 
then being deleted.

In your situation it seems - to me - that this calls for several 
"production" branches (which as you know are ordinarily named "master").

So having multiple masters might be a way to represent this:

master_xbox
master_android
master_os360

then some generic change to Word would appear on some branch:

word_fix_2045 (e.g. some bug fix to grammar processor)

Delivering this (to production) would entail a pull-request from 
word_fix_2045 to master_xbox, word_fix_2045 to master_android etc etc.

I think the important thing for me would be being clear about code that's 
platform agnostic and code that isn't - platform agnostic code (by 
definition) can be freely merged into master_xbox, master_android etc 
whereas platform specific code would need to be merged to this or that 
platform branch.

You do seem to be saying - effectively - that you have distinct products 
(word xbox, word android) and perhaps representing this explicitly in the 
repo may help...


On Tuesday, February 7, 2017 at 1:33:41 AM UTC-7, Philip Oakley wrote:
>
> Hi Hugh,
>  
> It's all good if the projects (plural) already know where the features are 
> destined for. However, in many scenarios, that is just not the case. 
>  
> Consider merging Word onto Xbox and Android, and OS360 (a bit old that). 
> In my work envirnment we make bespoke hardware, so every unit gets bespoke 
> software each with bespoke features, and some features that worked on one 
> system then want porting to a new system (maybe 3-4 years later!). This 
> creates lots of misalignments and incompatibilities. 
>  
> At this point it all gets messy, with often only the top level concept 
> being properly carried over (like taking a computer science concept/lecture 
> from one machine to another) so in may way's it is just 're-implemented'. 
> Plus the hardware incompatibilities and non availability don't help (same 
> long timescales).
>  
> Git is probably the best that is available because it provides control to 
> the user to have small incremental commits with auto 
> validation/verification via the object ID (sha1), without recourse to all 
> the old style VCS hassle. But it (any vcs) still doesn't have a nice way of 
> incrementally merging and recording the progress (see the Mikado method 
> regarding note taking etc.)
>  
> I did see that on the SO answer you do provide individual forks which I 
> think is the right approach (rather that each user having special branches 
> on the master).
>  
> Have you had a case of having to incoprporate incompatible code that you 
> could share?
> Philip
>
> - Original Message - 
>
> *Subject:* Re: [git-users] Git branching and merge strategy for merge 
> with lots of conflicts requiring multiple people
>
> I suspect that you are perceiving "merging" as a late, final step in the 
> process. This is where you are erring I think. Merging should be done 
> frequently, this was conflicts will not accumulate over time and grow in 
> scale. 
>
> Generally "merging" means incorporating changes made outside of some 
> branch while work has been progressing on that branch, from the way you 
> word things it seems like you mean something a bit different?
>
> As soon as you create some branch (from some other, e.g. create project_x 
> from master) the project_x branch never gets/see ongoing updates made to 
> master. The project_x branch grows as people work and change code on that 
> branch but other changes being made to master are never seen.
>
> Over time project_x contains numerous changes. fixes etc that were not 
> there when the branch was created but it has also fallen behind other 
> ongoing updates made to master.
>
> However - eventually - project_x is destined to "go into" master (if 
> master equates to production say) so will need to be merged.
>
> If you do this merge late, say many months after numerous developers have 
> made hundreds of commits to both branches, then yes you'll get a 
> potentially large list of conflicts (lets say 300).
>
> But if you merge m

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

[Philip Oakley]

Hi Hugh,

It's all good if the projects (plural) already know where the features are 
destined for. However, in many scenarios, that is just not the case. 

Consider merging Word onto Xbox and Android, and OS360 (a bit old that). In my 
work envirnment we make bespoke hardware, so every unit gets bespoke software 
each with bespoke features, and some features that worked on one system then 
want porting to a new system (maybe 3-4 years later!). This creates lots of 
misalignments and incompatibilities. 

At this point it all gets messy, with often only the top level concept being 
properly carried over (like taking a computer science concept/lecture from one 
machine to another) so in may way's it is just 're-implemented'. Plus the 
hardware incompatibilities and non availability don't help (same long 
timescales).

Git is probably the best that is available because it provides control to the 
user to have small incremental commits with auto validation/verification via 
the object ID (sha1), without recourse to all the old style VCS hassle. But it 
(any vcs) still doesn't have a nice way of incrementally merging and recording 
the progress (see the Mikado method regarding note taking etc.)

I did see that on the SO answer you do provide individual forks which I think 
is the right approach (rather that each user having special branches on the 
master).

Have you had a case of having to incoprporate incompatible code that you could 
share?
Philip
  - Original Message - 
  From: Hugh Gleaves 
  To: Git for human beings 
  Cc: philipoak...@iee.org 
  Sent: Monday, February 06, 2017 7:46 PM
  Subject: Re: [git-users] Git branching and merge strategy for merge with lots 
of conflicts requiring multiple people


  I suspect that you are perceiving "merging" as a late, final step in the 
process. This is where you are erring I think. Merging should be done 
frequently, this was conflicts will not accumulate over time and grow in scale.


  Generally "merging" means incorporating changes made outside of some branch 
while work has been progressing on that branch, from the way you word things it 
seems like you mean something a bit different?


  As soon as you create some branch (from some other, e.g. create project_x 
from master) the project_x branch never gets/see ongoing updates made to 
master. The project_x branch grows as people work and change code on that 
branch but other changes being made to master are never seen.


  Over time project_x contains numerous changes. fixes etc that were not there 
when the branch was created but it has also fallen behind other ongoing updates 
made to master.


  However - eventually - project_x is destined to "go into" master (if master 
equates to production say) so will need to be merged.


  If you do this merge late, say many months after numerous developers have 
made hundreds of commits to both branches, then yes you'll get a potentially 
large list of conflicts (lets say 300).


  But if you merge master INTO project_x every few days you'll be forcing the 
developers to resolve fewer conflicts more often and the changes behind the 
conflicts will be much fresher in their minds.


  If you do this, then after a long project your project_x branch is more or 
less right up to date and has all of the project work PLUS all of the other 
unrelated changes that have been getting made to master.


  The last merge from master into project_x will get done, conflicts resolved 
etc and then creating a PR from project_x TO master will have zero conflicts.




  On Thursday, January 26, 2017 at 2:37:47 PM UTC-7, Stephen Morton wrote:
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 

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

[Magnus Therning]

Michael  writes:

>> Have you looked at git-imerge?
>
> Imerge looks like a really nice tool. How stable/sufficient is it? Why
> is it not part of the normal git distribution?

I've not had any problems with stability, but then I generally try to
avoid ending up in situations where it's needed ;)

I think python was mentioned as a reason for it not making it into the
normal git distribution. Listen to [1], I think that's where I heard it.

> I noticed that it was still getting dev work this month, and in the
> last two years a bunch of people forked copies of it, and made their
> own little tweaks, that were not brought back to the master.
>
> Is it ready for prime time yet? It really looks like a nice tool.

Take it for a spin! What's the worst that can happen? ;)

/M

[1]: 
http://episodes.gitminutes.com/2013/06/gitminutes-12-git-merge-2013-part-4.html

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

Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.

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

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

[Michael]

On 2017-01-27, at 12:57 AM, Philip Oakley  wrote:
> 
> It doesn't happen at my work, but one has to ask how / why have we dug the 
> hole so deep and wide that this gross merge conflict continues to repeat it 
> self as a regular corporate activity, and then how to get out of here/there 
> (and somehow hoping that Git is a silver bullet / holy grail to solve those 
> human falibilities).

When you need to fix a mess, how you got into the mess isn't important.

When a fire is burning, you want to put the fire out. That's urgent.

Once you no longer have urgent issues, you can then ask "How do we prevent this 
again?". That's important.

Being able to tell "Urgent", "Important", and "Both urgent AND important" apart 
is critical.

Being able to ignore "Urgent but unimportant" is the hard skill. 

===

Solving a bad merge can be either important or not. If you want to take two 
different codebases, and combine them into one (say, combining a Windows and a 
Mac codebase), it can be very painful. How you got there can be as simple as 
"The people who did the Mac port didn't work with the windows people, and just 
took it apart and wrote a mac native front end without any consideration of 
windows". Trying to fix that is pointless -- what you do going forward will 
have nothing to do with what you did in the past.

iMerge looks really nice. I'm going to play with that myself.
But ...

iMerge looks like it works best when you have the "commit often" behavior on 
all branches. But lots and lots of commits makes a messy merge history. So 
people do a squash commit.

And as soon as you do a squash commit, the history that iMerge wants is lost. 
So ...

Somehow, a tool that retains the unsquashed history for future iMerging seems 
like the best solution, but I don't know of any. Anyone know git inside and 
bottom-up want to scratch that?


---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

[Philip Oakley]

missing words...

It (having files with only 100 lines) doesn't happen at my work (i.e. my 
work has the same problem, but it's seen as 'normal'),

 but one has to ask how / why have we dug the hole so deep and wide (we 
make bespoke hardware products, which is hard, and involves many 
disciplines, so multiple 'enterprise grade' storage and versioning tools 
are in-place)
--
Sorry if it sounded as if your problems didn't also happen here ;-)
P.

On Friday, January 27, 2017 at 8:57:12 AM UTC, Philip Oakley wrote:

> Hi, Michael, 
>
> The "100 lines" bit was just to ensure that folks got the idea that they 
> should give a better indication of measurable scale. 
>
> It doesn't happen at my work, but one has to ask how / why have we dug the 
> hole so deep and wide that this gross merge conflict continues to repeat 
> it 
> self as a regular corporate activity, and then how to get out of 
> here/there 
> (and somehow hoping that Git is a silver bullet / holy grail to solve 
> those 
> human falibilities). 
>
> I would be very interested in any reasonable method that helps with these 
> 'divergent codebases' issues. (see "The life cycle of a silver bullet" 
> Sheard, for a nice parable, only a couple of pages, especially the later 
> sections where mindless application of tools is done). We do need to 
> understand the how and why we get into these scenarios, and a similar how 
> and what for getting out. 
>
> Philip 
>
> If we don't understand, we won't improve ... 
> https://store.xkcd.com/products/try-science 
>
> - Original Message - 
> From: "Michael" <keybou...@gmail.com> 
> To: <git-users@googlegroups.com> 
> Sent: Friday, January 27, 2017 12:48 AM 
> Subject: Re: [git-users] Git branching and merge strategy for merge with 
> lots of conflicts requiring multiple people 
>
>
>
>  On 2017-01-26, at 1:12 PM, Philip Oakley <philipoak...@iee.org> wrote: 
>  > 
>  > Is the project well modularised with no file >100 lines (excepting, 
> maybe, well developed libraries that never change), 
>
>  100 lines per file?? 
>
>  You're joking, right? That's one of those "in theory" things, right? 
>
>  First, while I might be able to make each routine of my code 100 lines or 
> less, I can't make the whole "group" of things less than 100 lines. 
>
>  Second, while Objective C lets me have the code for a class in different 
> files, so that each file can focus on different parts of the class, Java 
> does not -- all of the class's contents, as well as all of the sub-classes 
> that the class needs -- has to be in one file. 
>
>  100 lines per file? One sec < ... walks into the distance like the 
> Mna-me-nah guy > bwa-Ha-HA!  Sorry, nope. 
>  --- 
>  Entertaining minecraft videos 
>  http://YouTube.com/keybounce 
>
>   
>
>

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

[Philip Oakley]

Hi, Michael,

The "100 lines" bit was just to ensure that folks got the idea that they 
should give a better indication of measurable scale.


It doesn't happen at my work, but one has to ask how / why have we dug the 
hole so deep and wide that this gross merge conflict continues to repeat it 
self as a regular corporate activity, and then how to get out of here/there 
(and somehow hoping that Git is a silver bullet / holy grail to solve those 
human falibilities).


I would be very interested in any reasonable method that helps with these 
'divergent codebases' issues. (see "The life cycle of a silver bullet" 
Sheard, for a nice parable, only a couple of pages, especially the later 
sections where mindless application of tools is done). We do need to 
understand the how and why we get into these scenarios, and a similar how 
and what for getting out.


Philip

If we don't understand, we won't improve ... 
https://store.xkcd.com/products/try-science


- Original Message - 
From: "Michael" <keybou...@gmail.com>

To: <git-users@googlegroups.com>
Sent: Friday, January 27, 2017 12:48 AM
Subject: Re: [git-users] Git branching and merge strategy for merge with 
lots of conflicts requiring multiple people




On 2017-01-26, at 1:12 PM, Philip Oakley <philipoak...@iee.org> wrote:
>
> Is the project well modularised with no file >100 lines (excepting, 
maybe, well developed libraries that never change),


100 lines per file??

You're joking, right? That's one of those "in theory" things, right?

First, while I might be able to make each routine of my code 100 lines or 
less, I can't make the whole "group" of things less than 100 lines.


Second, while Objective C lets me have the code for a class in different 
files, so that each file can focus on different parts of the class, Java 
does not -- all of the class's contents, as well as all of the sub-classes 
that the class needs -- has to be in one file.


100 lines per file? One sec < ... walks into the distance like the 
Mna-me-nah guy > bwa-Ha-HA!  Sorry, nope.

---
Entertaining minecraft videos
http://YouTube.com/keybounce



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

[Michael]

> Have you looked at git-imerge?

Imerge looks like a really nice tool. How stable/sufficient is it? Why is it 
not part of the normal git distribution?

I noticed that it was still getting dev work this month, and in the last two 
years a bunch of people forked copies of it, and made their own little tweaks, 
that were not brought back to the master.

Is it ready for prime time yet? It really looks like a nice tool.
---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

[Michael]

On 2017-01-26, at 1:12 PM, Philip Oakley  wrote:
> 
> Is the project well modularised with no file >100 lines (excepting, maybe, 
> well developed libraries that never change),

100 lines per file??

You're joking, right? That's one of those "in theory" things, right?

First, while I might be able to make each routine of my code 100 lines or less, 
I can't make the whole "group" of things less than 100 lines.

Second, while Objective C lets me have the code for a class in different files, 
so that each file can focus on different parts of the class, Java does not -- 
all of the class's contents, as well as all of the sub-classes that the class 
needs -- has to be in one file.

100 lines per file? One sec < ... walks into the distance like the Mna-me-nah 
guy > bwa-Ha-HA!  Sorry, nope.
---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

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

[Magnus Therning]

Stephen Morton  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?

/M

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

As we enjoy great advantages from the inventions of others we should
be glad of an opportunity to serve others by any invention of
ours, and this we should do freely and generously.
 — Benjamin Franklin

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

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

[Philip Oakley]

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

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

[Konstantin Khomoutov]

On Tue, 28 Aug 2012 12:44:19 -0700 (PDT)
git newbie technewbi...@gmail.com wrote:

 For a more complicated development environment where there is a
 master branch, a devel branch off of master, and feature branches off
 of devel, how do you create a feature branch so that it's parent is
 the devel branch and not the master branch?

It's recommended to read [1].  It's not to be followed as a dogma, but
it has good explanations of concepts (with pictures) and it lists the
relevant Git commands (including those which you have been already
advised to use in this thread).

1. http://nvie.com/posts/a-successful-git-branching-model/

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] git branching

[Ryan Hodson]

Hi there. The parent branch will always be the *current* branch, so all you
need to do is:

git checkout develop
git branch some-feature
git checkout some-feature

Or, you can use the -b shortcut to save a step:

git checkout develop
git checkout -b some-feature

In either case, some-feature will have develop as its parent. Hope that's
what you were looking for.

--
Ryan

On Aug 28, 2012 2:44 PM, git newbie technewbi...@gmail.com wrote:


 For a more complicated development environment where there is a master
branch, a devel branch off of master, and feature branches off of devel,
how do you create a feature branch so that it's parent is the devel branch
and not the master branch?

 Thanks!

 --
 You received this message because you are subscribed to the Google Groups
Git for human beings group.
 To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/Yc8IQGZbgZ8J.
 To post to this group, send email to git-users@googlegroups.com.
 To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] git branching

[Adam Prescott]

On Aug 28, 2012 8:51 PM, Ryan Hodson hodson.r...@gmail.com wrote:

 Or, you can use the -b shortcut to save a step:

 git checkout develop
 git checkout -b some-feature


If you're going to use a shortcut, use a shortcut!

git checkout -b some-feature develop

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] git branching

[Ryan Hodson]

Lol. Yea, that's a good point.
On Aug 28, 2012 3:11 PM, Adam Prescott a...@aprescott.com wrote:

 On Aug 28, 2012 8:51 PM, Ryan Hodson hodson.r...@gmail.com wrote:
 
  Or, you can use the -b shortcut to save a step:
 
  git checkout develop
  git checkout -b some-feature
 

 If you're going to use a shortcut, use a shortcut!

 git checkout -b some-feature develop

 --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To post to this group, send email to git-users@googlegroups.com.
 To unsubscribe from this group, send email to
 git-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/git-users?hl=en.


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] git branching from tags

[PJ Weisberg]

On Monday, July 2, 2012, jack sparrow dafs...@gmail.com wrote:
 From the git repo, i created a new branch1 with the existing tag tag1.
 i made some changes to a set of files, filea, fileb. If i run git
 status
 it shows that the filea and fileb are modified, so far good. Now i
 created
 another branch2 with the existing tag tag2. If i go toa filea, the
 file has
 the changes i made in the branch1. since the changes i made are
 commited,
 i was expecting the file to be without the modfications that was made
 in
 other branch. am i missing something ?

Maybe, but it's hard to say without knowing specifically what commands you
ran.

-- 
-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Git branching does nothing

[Jeremiah Dodds]

On Mon, Oct 10, 2011 at 5:48 PM, JP jetp...@yahoo.com wrote:


 What am I doing wrong? Have I completely misunderstood a very basic
 concept in Git? I don't remember previous versions of Git acting like
 this.


As far as I know, they did. You have to commit files in the branch for
their changes to be local to the branch. IIRC, git will prevent you
from switching branches if you have staged uncommitted changes.

To save changes without committing them and switch branches, you can
use git stash, but it won't stop you from applying the stash to
whatever branch (although it does show what branch they were stashed
on).

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.