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

[Fred Stluka <fred@bristle.com>]

Clay,

Thanks for posting this.  I was going to say some of the same stuff
(perhaps a little more gently :-), but I didn't want to get into a flame
war, and really didn't even know where to begin.

Yeah, Git scales.  Linus wrote it to manage the huge number of
committers to Linux around the world.

Yeah, Git does binary files fine.  Like every other VCS tool that has
ever existed, it makes no attempt to do diffs.  It just pushes the
entire new copy of the binary file into the repo as one big diff.
No problem!  And as others have pointed out, you can often
reduce the need to version binaries by versioning the textual
source files instead.

Lee may be right about the 2-3X.  He said a Git repo can be 2-3X
as big as a simple copy of the latest version of each file.  But, I
think that's a big advantage to Git.  Each dev has a copy of the
entire repo, including all history.  So, if the central repo vanishes,
any of the devs can just offer up his copy as the new central repo.
Push it to a central hub, or even temporarily allow other devs to
push directly to his/her laptop.

Happy Holidays!
--Fred
------------------------------------------------------------------------
Fred Stluka -- Bristle Software, Inc. -- http://bristle.com
#DontBeATrump -- Make America Honorable Again!
------------------------------------------------------------------------

On 12/20/18 4:34 PM, Wells, Clay A wrote:
> 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

___________________________________________________________________________
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