Re: [PLUG] Git: net time gain or loss?

["Lee H. Marzke" <lee@marzke.net>]

After using many SCM systems over the years I totally agree that git (command-line) is a complete
mess, but most developers don't really use Git directly but some local GUI tool to hide the complexity.

I see large Enterprise customers slowly uncovering Git's limitations, and realizing that significant downsides
exist with Git at scale, and are starting to look for alternatives that support large installations
with less effort.  Now for single developers or small business the following doesn't apply.

I think Git users tend to lean towards git because it's the only thing that they have used, or have only used
other older tools like CVS, etc. but the arguments for using git over other SCM's have been slowly been overcome.
Yes, there were some valid arguments about some Git features being better 5 years ago, but the problems
with Git were always left out.  It's not convenient to use SHA digests instead of linear version numbers or
be unable to check in large repositories or binary files.

Git rebase is great for private dev work, but badly breaks things if used on code that has been distributed
to others.    Since Git keeps change history locally,  a Git repo on your machine uses 2x to 3x the
local disk space of just the raw code,  and the initial sync time is longer since you have to
sync the code and past history ( but arguments for Git don't mention this fact ).   The need to split up repositories
into multiple small units, and lack of support for large binaries is always left out.  ( Binary support can be
added with LFS - but that is a central server solution - not native Git )

Developers really don't need 'distributed' SCM, because any Enterprise will force all the code into a
central repository anyway.   What they really need is:  1) off-line access, 2) ability to hide
intermediate commits (often mistakes ) and only check in the final result. and 3) easy branching and
good merge tools.

Enterprise infrastructure admins don't like Git because of lack of central AD authentication, lack of
tools to remove mistakes, and lack of fine-grain access controls, lack of binary support, etc.

So perhaps taking the best feature of both Git and best of breed Enterprise SCM features is really the best solution.
Turns out that the 2018 Helix SCM tool now has features of both Perforce and Native Git included.

Helix has two internal repositories ( one for native p4 ) and one for native Git ( graph depot ).  This means
that Git users can now connect natively with the Helix server,  but you also get Active directory
integration and global replication etc.   Note that the central Helix server has had additional
commands added to support ALL the git features on top of all the existing Perforce features such as
seamless replication.

The two ( P4 and Git ) repositories in Helix are not fully connected yet.  This is mainly designed to let Git teams checkin
to a Git native repo, and P4 users checkin to a P4 repo.  However a build system can sync the latest from both
p4 and git from a single client ( so larger projects can have legacy teams on p4, and new projects on Git )

Now this costs significant money, so it's mainly targeted at large Enterprises, but it seems from the amount of recent
inquiries that large organizations are finally hitting a wall with Git issues and Git training,  complexity of multiple
repos, lack of binary support, etc.
 
So as a developer ,  do you care what your Central Enterprise repository runs?  For example GitHub, GitLab
or Helix Team Hub (HTH) ,  as long as your Git tools connect ?  If your an infrastructure admin, what issues
do you have issues with Git ?

Note that HTH is just a hub,  and all code is still put into Helix or other Git repos.  HTH provides pull-request support
interface to CI tools, central authentication, etc.

So, in summary to JP's question,  yes people are slowly figuring out that while Git is good, it is not all it is
hyped up to be and becomes a problem to support in larger organizations.
 

Lee




----- Original Message -----
> From: "Vossen JP" <jp@jpsdomain.org>
> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
> Sent: Wednesday, December 19, 2018 6:58:22 PM
> Subject: [PLUG] Git: net time gain or loss?

> I was just struggling with several things that should be simple[1], but
> since it's Git they aren't [2], and I got to thinking (and THAT's never
> good).  Git is blazingly fast, and for the right users it's an awesome
> tool.  But for the wrong users it's a infuriatingly frustrating
> time-suck to do...just about anything.  And I've argued [3] that _most_
> users are the wrong users.
> 
> So...does Git create a net time gain or net time loss in the world?  For
> me it's a _massive_ net loss.
> 
> [1] It doesn't matter what they are, they should have been simple, in
> any other VCS I'm familiar with they ARE simple, but for Git I wasted
> over a cumulative hour Googling.
> [2] The entirety of Stack-Exchange's Git section, and https://xkcd.com/1597/
> [3] https://www.jpsdomain.org/public/Revision_Control_for_the_Rest_of_Us.pdf
> 
> Thoughts?
> JP
> --  -------------------------------------------------------------------
> JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

-- 
"Between subtle shading and the absence of light lies the nuance of iqlusion..." - Kryptos 

Lee Marzke, lee@marzke.net http://marzke.net/lee/ 
IT Consultant, VMware, VCenter, SAN storage, infrastructure, SW CM 

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug