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

[Philip Oakley]

Hi Hugh,

I think Lowell would love to have a networked system with a golden bare repo 
serving all the machines. 

However, I strongly suspect this set-up is in a security setting (goverment 
vetting and all that), so that some parts cannot be connected to other parts, 
etc etc (see also stuff about TEMPEST security regarding the concerns that folk 
have..)

(My case was test assets which had to be kept separate from IT corporate assets 
to avoid 'cross contamination').

Bundles are like RFC 1149 / 2549, with Nike enhancements;-)

Philip
  - Original Message - 
  From: Hugh Gleaves 
  To: Git for human beings 
  Sent: Monday, February 06, 2017 8:07 PM
  Subject: [git-users] Re: Synchronizing air gapped git repositories using 
bundles


  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 

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

[\0xDynamite]

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

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

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: 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  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  > 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  > wrote:
>
>>
>> Hugh Gleaves  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.

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.

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

[John McKown]

On Mon, Feb 6, 2017 at 1:26 PM, Magnus Therning  wrote:

>
> Hugh Gleaves  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.org   jabber: 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.
>



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

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

[Magnus Therning]

Hugh Gleaves  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.org   jabber: 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.


signature.asc
Description: PGP signature

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

Re: [git-users] How build git server to only one user - two at the most

[Konstantin Khomoutov]

On Sun, 5 Feb 2017 19:39:14 -0800 (PST)
edgaroliveira@gmail.com wrote:

> I intend build a git server on machine with ubuntu server 16 L.T.S.
> 
> I following first step on this article 
> https://help.ubuntu.com/lts/serverguide/git.html but this is a good
> option? I can let it stay like this?
> The main user on this machine is "git", obvious after sudo :)

"sudo" is not a user on Unbuntu, but rather a group, members of which
may become superusers by means of using the sudo program.

> I create directory "repo" on / (slash) and on inside this directory I 
> created my repository git, e.g. projectone.git. This repository git
> has only git:git as user and permission are 700. This is good setup?

I'd say this setup is overcomplicated.

I assume you have SSH access to that machine as a regular user.
If yes, you don't need to have anything special to host your own Git
repositories there except for the installed git-core package.

All you need to do is to SSH to that machine and run

  git init --bare ~/myrepo.git

then on your local machine you take an existing repository and
do something like

  git remote add server ssh://username@servername/~/myrepo.git
  git push server master

where username is your SSH username on the host servername.

IOW, when your local Git instance is told to access a remote Git
repository via SSH, that local Git instance spawns an SSH client,
logs you in, tell the SSH server to run a special Git command once your
remote session is created, and then both Git instances communicate via
the tunnel SSH provides.  The user name + host name part of the
repository URI is used to connect to the remote server while the rest
of it -- the path -- is literally interpreted to tell the remote Git
instance where the target repository is located.

You're hence free to create a dedicated directory for your remote Git
repos under your home directory (like ~/devel/myrepo.git) or even
create a special directory for them elsewhere (provided you also set
proper access permissions on it) though I really don't understand why
you'd need to do that if all that you want is having private
repositories for your sole user.

A dedicated user to host remote Git repositories is not needed.
It *may* be needed in special setups where all access to the repos is
handled by some front-end software package (such as gitolite or GitLab
or Gitblit or gogs or whatnot); in your case Git will be run directly
by the SSH server which logged you in -- with your own credentials.

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