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

[git-users] News: Git Virtual File System

[Hugh Gleaves]

This is extremely promising:

https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/announcing-gvfs-git-virtual-file-system/


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

Re: [git-users] Re: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

[Hugh Gleaves]

My position here is that I do not think Git does a good job of promoting 
itself.

It uses terminology that confuses newcomers because things with names like 
"checkout" don't quite mean what they mean in other systems.

Far too much educational material, books and documentation is command line 
oriented and this is off-putting for many.

I think Git has a nice elegance about it, here's why:


   - The entire repo is present on a developer's machine, all history etc.
   - Branches are trivial to create and use locally.
   - Staging enables one to selectively commit changes and improve how 
   changes are seen by others.
   - Branches really are just named pointers.
   - Stashes are a nice purely local convenience (and they're just commits 
   under the hood).
   - Rebasing is a huge benefit for developers when keeping up to date with 
   other changes.
   - The Github fork model is superb giving each developer a remote backup 
   of their work.



On Monday, February 6, 2017 at 1:47:22 PM UTC-7, theProphet wrote:
>
> I can't verify this, and I'm telling you from gut instinct-- not 
> thorough analysis, but I think the git architecture is just not very 
> tight.  SVN sorta made the first stab at making a CVS clone and it 
> included a tight architecture for atomic writes and a well-established 
> (Apache) web-backend for handling multiple coders using 
> well-established protocols. 
>
> Personally I found a lot of questions with git that makes it 
> untrustworthy for enterprise coding, IMO.  I would get a license for 
> SVN from Tigris, use a conversion tool for transferring your repo, and 
> try that. 
>
> Marxos 
>
>
> On 2/6/17, Hugh Gleaves <hugh.g...@gmail.com > wrote: 
> > I'd like to see a forum is all I mean, the format interaction and 
> usability 
> > 
> > are weak in mailing lists, IRC is ancient and StackOverflow is not 
> confined 
> > 
> > to Git. 
> > 
> > e.g. 
> > 
> > https://forums.asp.net/ 
> > 
> > 
> https://social.msdn.microsoft.com/Forums/sqlserver/en-US/home?category=sqlserver
>  
> > 
> > http://www.linuxforums.org/forum/ 
> > 
> > These are just better UIs and more friendly that these other character 
> > oriented systems - IMHO 
> > 
> > 
> > On Monday, February 6, 2017 at 12:26:20 PM UTC-7, Magnus Therning wrote: 
> >> 
> >> 
> >> Hugh Gleaves <hugh.g...@gmail.com > writes: 
> >> 
> >> > SmartGit is the best way to begin working with Git, it is much less 
> >> > confusing that the (poorly explained) command line stuff, plenty of 
> >> > time for command line later, most developers here rarely if ever need 
> >> > to use command line. 
> >> 
> >> That may be true for some, but not all. Personally I found the command 
> >> line, augmented with some aliases, *much* easier to grasp than any GUI. 
> >> For me it was the same with CVS, SVN, P4, Mercurial, TLA, ... different 
> >> strokes for different folks ;) 
> >> 
> >> > Finally I'm astonished that there is no Git forum out there, Github 
> >> > don't provide one and Git itself is archaic (mailing lists) and 
> >> > Syntervo rely on this Google group, we need a Git forum where 
> everyone 
> >> > and anyone using Git can get answers to questions. 
> >> 
> >> There's this email list, IRC and stack overflow, what other fora do you 
> >> want? 
> >> 
> >> /M 
> >> 
> >> -- 
> >> Magnus Therning  OpenPGP: 0x927912051716CE39 
> >> email: mag...@therning.orgjabber: mag...@therning.org 
> >>  
> >> twitter: magthe   http://therning.org/magnus 
> >> 
> >> The early bird may get the worm, but the second mouse gets the cheese. 
> >> 
> > 
> > -- 
> > 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+...@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: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

[Hugh Gleaves]

I'd like to see a forum is all I mean, the format interaction and usability 
are weak in mailing lists, IRC is ancient and StackOverflow is not confined 
to Git.

e.g.

https://forums.asp.net/

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/home?category=sqlserver

http://www.linuxforums.org/forum/

These are just better UIs and more friendly that these other character 
oriented systems - IMHO


On Monday, February 6, 2017 at 12:26:20 PM UTC-7, Magnus Therning wrote:
>
>
> Hugh Gleaves <hugh.g...@gmail.com > writes: 
>
> > SmartGit is the best way to begin working with Git, it is much less 
> > confusing that the (poorly explained) command line stuff, plenty of 
> > time for command line later, most developers here rarely if ever need 
> > to use command line. 
>
> That may be true for some, but not all. Personally I found the command 
> line, augmented with some aliases, *much* easier to grasp than any GUI. 
> For me it was the same with CVS, SVN, P4, Mercurial, TLA, ... different 
> strokes for different folks ;) 
>
> > Finally I'm astonished that there is no Git forum out there, Github 
> > don't provide one and Git itself is archaic (mailing lists) and 
> > Syntervo rely on this Google group, we need a Git forum where everyone 
> > and anyone using Git can get answers to questions. 
>
> There's this email list, IRC and stack overflow, what other fora do you 
> want? 
>
> /M 
>
> -- 
> Magnus Therning  OpenPGP: 0x927912051716CE39 
> email: mag...@therning.orgjabber: mag...@therning.org 
>  
> twitter: magthe   http://therning.org/magnus 
>
> The early bird may get the worm, but the second mouse gets the cheese. 
>

-- 
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: Synchronizing air gapped git repositories using bundles

[Hugh Gleaves]

I'm questioning the overall wisdom of what you describe Lowell.

Why not just have a single repository? Doing that eliminates all of the 
fussing you describe.

If the "other" repos are little more than holding pens for stuff to 
eventually get merged into your primary repo, then why? this is what 
branches are for.

It sounds as if you're not really taking full advantage of all that Git 
offers.



On Wednesday, February 1, 2017 at 2:58:59 PM UTC-7, Lowell Alleman wrote:
>
> I have 3 separate air-gapped git repositories (hosted on local GitHub 
> enterprise) that I'm trying to keep in sync.   Currently, I'm using "git 
> bundle" to push revisions back and forth, which worked fairly well with 
> just 2 repositories, but I'm struggling a bit since the 3rd (and final) 
> repository has been added to the mix.  I was using a single tag to track 
> the point of last export as noted in the "git bundle" docs, but I'm 
> struggling to make that scale with 2+ total repositories. 
>
> In terms of information flow, we've deemed one of the repositories as 
> "primary" and the other two as "secondary" repositories.  So in a sense we 
> are using the "primary" repository like a development and merging area so 
> that all changes go through the primary repository and trickle down to the 
> secondary repositories.  Changes are always pushed upstream to primary, and 
> then synced down to the other secondary repository. 
>
> Please note that our use of git is more like a "versioned file system" 
> than the typical developer use case.  I go on to explain that a bit more 
> later, but wanted to get to my main question before everyone gives up on 
> reading this really long and complicated explanation of the mess I made. 
>
> *Q:  Does anyone know of any existing scripts, documented methods, or best 
> practices to follow when syncing a branch between multiple air-gapped 
> repositories?*
>
> *How we are using git:*  As noted above, this is NOT a typical 
> development-centered use-case.  Branching is very infrequent, and most work 
> is done on the "master" branch in each repository.  Unlike typical 
> developer-centric approaches, each clone (working copy) ends up tied to a 
> specific server, rather than a single developer.  So multiple users end up 
> working in the same working copy and committing code from one place.  The 
> team is small and the changes are infrequent enough that this works for us, 
> despite the atypical and less-than-ideal use case.
>
> *How we are using branches:*   We treat each repository as if it has just 
> one branch, a single "master".  However, because of the synchronization 
> requirements, we create special purpose branches in each repository that 
> essentially mirror the master branches of the other repositories.  So the 
> primary repository has 2 mirrored branches, one for each of the secondary 
> repositories.  And each secondary repository has a single mirrored branch 
> that represents the primary (upstream) repository.  (By convention, we have 
> agreed never to synchronize revisions directly between the two secondary 
> repositories.)  Local changes are never applied to a mirrored repository 
> branch, so that it should match the "master" branch of the mirrored 
> repository exactly.  (That is, the only changes to these mirrored branches 
> are fast-forward only "pull"s made from bundle files exported from 
> the mirrored repository.)   The process of merging changes between branches 
> is manual, and I think I want to keep it that way for the foreseeable 
> future.  (Perhaps one day I'll make fast-forward merges apply 
> automatically, but in general I want a human to be responsible for this 
> step.)  So while each repositories' "master" branch may diverge, or at 
> least have a slightly different history, in the end, they should all end up 
> with the same content.  Well, at least that's the ultimate goal. 
>
> *File transfer:  *Transferring bundle files between air-gapped 
> environments involve multiple human steps including content review, 
> approval, and some safety checks for compliance.  Therefore, there's no way 
> to automatically schedule synchronization, which is a bummer.   That being 
> said, I'd like to make this as painless as possible within the realm of 
> what I can control.  I'm looking to create import and export scripts (or 
> find existing ones to borrow from) that handle bundle creation and the 
> import process. 
>
> I'm looking for a little help designing an appropriate synchronization 
> solution, and would appreciate any feedback you may have.  The combination 
> of using git bundle and our non-traditional use case has made it difficult 
> to find relevant resources. If there is anything I've missed, please point 
> me in the right direction.
>
>

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

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

-- 
You received this message because you are subscribed to 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: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

[Hugh Gleaves]

That's fine and I have no argument against using the CLI.

However there is no *need* to use the CLI most of the time, you can devise 
and follow a workflow that almost never requires the CLI, many developers 
living in an IDE will appreciate this and be more productive, I can 
honestly say that the CLI clouded my understanding of Git initially and 
this is partly due to the unfriendly way the many commands are documented.

I just think it's not good for Git adoption to compel users to use the CLI, 
this can alienate them and make Git an explicit part of their work rather 
than an implicit, enabling them to focus on their work.



On Monday, February 6, 2017 at 12:33:30 PM UTC-7, John McKown wrote:
>
> On Mon, Feb 6, 2017 at 1:26 PM, Magnus Therning <mag...@therning.org 
> > wrote:
>
>>
>> Hugh Gleaves <hugh.g...@gmail.com > writes:
>>
>> > SmartGit is the best way to begin working with Git, it is much less
>> > confusing that the (poorly explained) command line stuff, plenty of
>> > time for command line later, most developers here rarely if ever need
>> > to use command line.
>>
>> That may be true for some, but not all. Personally I found the command
>> line, augmented with some aliases, *much* easier to grasp than any GUI.
>> For me it was the same with CVS, SVN, P4, Mercurial, TLA, ... different
>> strokes for different folks ;)
>>
>
> ​I like to use the CLI as much as possible. Mainly because I like to 
> "script" things. Scripting a GUI is a PITA. GUI are very nice for people 
> who don't really want or need to become an "expert". But doing everything 
> in a GUI tends to (I think) make people "lazy" so that they don't really 
> become interested in the "underpinning". Which may be just fine for most 
> programmers. They need to have a good knowledge of their application domain 
> and the tools & languages to write & debug application code​. Much like I 
> am with a car - I know how to drive & how to put gas into it. I don't even 
> change my own oil. And I don't really care what the embedded computer is 
> doing so long as I get where I want to go.
>
>  
>
>>
>> > Finally I'm astonished that there is no Git forum out there, Github
>> > don't provide one and Git itself is archaic (mailing lists) and
>> > Syntervo rely on this Google group, we need a Git forum where everyone
>> > and anyone using Git can get answers to questions.
>>
>> There's this email list, IRC and stack overflow, what other fora do you
>> want?
>>
>> /M
>>
>> --
>> Magnus Therning  OpenPGP: 0x927912051716CE39
>> email: mag...@therning.orgjabber: mag...@therning.org 
>> 
>> twitter: magthe   http://therning.org/magnus
>>
>> The early bird may get the worm, but the second mouse gets the cheese.
>>
>> --
>> 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+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Our calculus classes are an integral part of your education.
>
> Maranatha! <><
> John McKown
>

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

[git-users] Re: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

[Hugh Gleaves]

I would argue that all of these complaints are because the user does not 
fully understand what's happening, Git is not intuitive (in the sense it 
does not follow patterns of earlier source control systems). Git is very 
well designed indeed, very good.

See my other reply too where I describe a workflow I've introduced for our 
team (which has onshore and offshore staff).

SmartGit is the best way to begin working with Git, it is much less 
confusing that the (poorly explained) command line stuff, plenty of time 
for command line later, most developers here rarely if ever need to use 
command line.

Take a look at the Attlassian site, they have some great documentation:

https://www.atlassian.com/git/tutorials

Finally I'm astonished that there is no Git forum out there, Github don't 
provide one and Git itself is archaic (mailing lists) and Syntervo rely on 
this Google group, we need a Git forum where everyone and anyone using Git 
can get answers to questions.



On Wednesday, January 11, 2017 at 11:14:18 PM UTC-7, AD S wrote:
>
>
>
> On Thursday, January 12, 2017 at 3:35:05 PM UTC+10, Mattias Vannergård 
> wrote:
>>
>> What kind of "strange issues" do you have to sort out?
>>
>
>  You can see some of them in my posts here. Issues include:
>
>- 'Both modified' errors on files I have never touched.
>- 'Polluted' pull requests on github. This is where I push a branch to 
>github and it ends up also including loads of other peoples work. 
> Sometimes 
>I can solve this by closing the PR and re-opening it, sometimes I have to 
>start a new branch. I've had to manually save a back up of work to my 
> local 
>computer, which I feel kinda defeats some of the purpose behind git.
>- Sometimes when I push to the remote repo, only some of the files 
>appear. However, if I push to Github I can see them all appearing fine.
>
>  
>
>>
>> Do you have a common process for branching and merging?
>>
>
> Yes, we use a simple CLI, inhouse software that is meant to fire several 
> git commands at once so you don't miss any or do them out of order.
>  
>
> And do you have any education for "how to use Git" in your organisation?
>>
>
> No. I've been trying to teach my self with books and tutorials. I believe 
> I have a firm understanding of the core concepts, but I keep getting these 
> strange errors coming from left field. 
>  
>  
>
>> How many repos do you have?
>>
>
> 4, including local
>  
>
>>
>> Do you use submodules or subtrees or neither or both?
>>
>
> Neither. 
>
>
> Thanks! 
>

-- 
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: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

[Hugh Gleaves]

Don't start forming a negative perception of Git, tempting though this is!

I had Git and Github dumped on me two years ago and had little help from 
coworkers back then, I tried very hard to get a solid grasp of it and it 
took me months, but after all that I can now tell you are using a very 
solid and robust system, almost all issues you'll have stem from wrong 
perceptions or a poor workflow, and this is only natural given how poor the 
materials are for learning Git.

SmartGit is a very good way to learn and work with Git too, so despite 
being confused and bewildered you're using two very solid technologies, I'm 
now novice either, been a develop since late 1970s.

Now take a quick look at a post I made recently to StackOverflow, it 
sumarrizes a Git workflow that I've defined for all developers here to work 
with.

http://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task/41753291#41753291

Understanding this (and similar) workflows is the best way to then 
understand the lower level details, approaching Git basics without 
understanding the bigger picture will probably be more confusing.

Regarding your picture, you need to understand that a pull-request (until 
its approved (merged)) is a branch level request, that is it's a request to 
move ALL commits on one repo/branch to some other repo/branch.

If at the time you create a pull-request there are five commits in your 
branch then a few days later you push and additional three commits to your 
branch, the pull-request will "see" these additional commits and report 
eight commits in the (still pending) pull-request.

Your picture suggests that after you pushed additional recent commits, 
these (in some way) undid some of the hundreds of changed files in the 
original commits, which may have been intentional?





On Monday, January 16, 2017 at 4:33:52 PM UTC-7, AD S wrote:
>
> Hi all,
>
> I decided to screen shot one of these issues I'm encountering. This is a 
> kind of small one.
>
> I've been styling a site - just .scss files. I pushed to Github at the end 
> of the day and saw I had 400+ files that I had apparently altered and 
> merged to the branch. This isn't true - I'd only worked on a handful of 
> files. I spent a few hours trying to figure out why this was before giving 
> up and continuing with my styling (remembering to also manually save a 
> local copy of the files I was working). When I returned today to look at 
> the branch and try to address the problem again, I see that it is back to 
> normal.
>
> I don't know why the branch suddenly contained a few hundred more files 
> than I was working on our why it now suddenly doesn't. This was a lucky one 
> - it fixed its self.
>
>
> 
>
>

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

[git-users] Git extensions to use enhanced difference detection

[Hugh Gleaves]

I'm newish to Git and see that it seems to do change detection using a line 
by line kind of algorithm.

Is there any way to get Git to be more intelligent, for example when 
comparing a source file to some earlier version don't just use the 
line-by-line compare but instead use a compare that is syntax aware for the 
kind of file that's changed?

If two files that look different actually have identical syntax trees then 
it would be great to have Git not perceive them as different.

So just wondering if the system has hooks or if any Git hosting sites offer 
this kind of thing.

Thx

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