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

[Charlie Li <ml+PLUG@vishwin.info>]

On 20/12/2018 16:34, 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.
> 
People understand the way git is designed and its specific use case. And
even if they don't, they don't necessarily want to learn so much about
the architecture (or how JP described it, how the damn dishwasher
works). They want to get stuff done. It's up to the proponent to sell
the benefits. Telling people to learn about git's architecture whilst
indirectly bashing their tool and workflow of choice doesn't get you there.
> Start here, https://www.youtube.com/watch?v=4XpnKHJAok8
> 
I watched Linus's talk before I ever started using git. I may be one of
the few though.> 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!
> 
You may have missed the part where Linus specifically said that git was
designed as a backend, with something else as a frontend, until Junio
Hamano came along. But I do see most git users in the wild using it
directly; watching newer developers learn git is like watching them
learn to touch type the QWERTY keyboard layout for the first time. The
command structure is complex and sometimes not so sensical, just like
how QWERTY was never designed to let you type too fast.
>> 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.
> 
Or perhaps they figured out that git is the wrong tool. Everyone who
knows me in meatspace know my affinity for a certain operating system
project I contribute rather heavily to, but they use subversion for very
good reasons. Some developers use git or other tools as a proxy for the
svn repository of truth (I personally use hg for this), but that's that,
a proxy. The project is extremely anal over metadata, specifically file
copies and the like, that any other tool considerations must address.
Unfortunately for git, git simply loses too much of that metadata due to
its design.
>> 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
> 
The linear revision numbers thing is indeed a breaking point in some
people's eyes.> 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.
> 
The last comparison I've seen between git and subversion, there was
actually negligible difference in size for the same data.
>> 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.
> 
Well, each SCM (not just distributed) effectively was designed around an
ideal workflow. git was specifically designed for Linux kernel
development workflow and clearly excels at that. This workflow revolves
around lots of pulling and not much pushing. If your workflow is similar
to this, then git is great. Otherwise, you may spend more time fighting
it than getting things done.

Meanwhile, something like mercurial or even subversion have different
preferred workflows, but both notably involve the single repository of
truth that Lee described as the Enterprise way. Mozilla was probably the
first big adopter of mercurial; they operate more of that push model
with separate gatekeeping and truth repositories (mozilla-inbound and
mozilla-central, for example).

Point being, even distributed SCMs have wildly different preferred
workflows. Promoting or changing tools must also include changing the
workflow.
>> 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?
> 
Active Directory and central administration are what they want.
> People simply don't take the time to learn how Git works. They give
> up.
> 
And bashing them doesn't help your or any other git proponents' cause.

-- 
Charlie "five-star restaurant" Li

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
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