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

["Wells, Clay A" <clayw@sas.upenn.edu>]

Wow! My comments are below. I really don't mean to sound trollish
but IMHO someone needs to speak to some of your comments. Don't want
to start yet another war over Git but seriously.. if people took more
time to learn about Git and understand how it works and why it was
designed the way it was then threads like these would no longer exist.

I should probably keep quiet and not comment but no good can come from
that.

So, before I get started. The point here is people really need to take
the time to learn about how Git works.. I mean REALLY learn and why Git
was designed the way it was.

Start here, https://www.youtube.com/watch?v=4XpnKHJAok8

Cheers

On 12/20/18 2:01 PM, Lee H. Marzke wrote:
> 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.

Totally disagree!

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

If scale is an issue then people clearly don't know what they are doing.

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

lol

Git will happily take binary files. However, since they are not text
files you can't use text-based tools like diff.

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

Why rebase. There are other ways to "fix" user generated mistakes. I
challenge you to prove this statement re: disk usage. I 100% don't
believe your claim of a Git repo using 2x to 3x of local storage.
Would love to see a side by side comparison with other SCMs.

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

You clearly don't understand the concept of a distributed SCM. Just
want to point that out.

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

AD auth.. seriously!?! Those admins clearly don't understand Git's
architecture. Git will happily commit binaries. How in the world can
any SCM track changes in a binary?

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

:face palm:

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

People simply don't take the time to learn how Git works. They give
up.

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