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

[JP Vossen <jp@jpsdomain.org>]

On 12/22/18 10:31 AM, Tim Allen wrote:
> I can't imagine working without git.
...
> The ability to tie in automated tests through GitHub which gently nudge 
> people (myself included!) in the right direction is huge; ...

Right.  'git'?  Or Github?  As I said elsewhere I really wonder if Git 
would have taken over the world without Github.  What if Canonical's 
Launchpad (for BZR) had been more like Github?  Eh, just wondering...


> My favorite bash alias is `gitohshit` which outputs a command to go back 
> one step after an "oops" moment.

LOL.  I want to ding Git for the need for that, but I can't because that 
one is just human nature.  I need to do that myself a lot.  :-)

One thing I dislike about the 2nd gen tools like SVN is that commit == 
publish (unless you branch--sort-of, not not really).  The fact that 
commit != publish is a big win for the 3rd gen DVCS.

In general I hate history re-write, but I love in Git & Bzr that I can 
undo my last commit and fix it.  In SVN I have to do (publish!) a new 
commit saying "bugfix for my last r123456 when I should have done foo".


> The fact git commits are just deltas is a huge win over previous version 
> control systems which would make entire copies of the code base when 
> branching; this is what drove me away from svn, where branching on large 
> code bases becomes useless. The merging is smarter than any system I've 
> seen previously, and continues to improve.

As Rich pointed out, that's wrong.  Each commit in SVN is a complete 
copy of the *entire* repo at an atomic point in time.  But every file is 
just a pointer to the last one, except for what you changed.  Just like 
Git, except Git doesn't know about "files," it just has blobs, while SVN 
is working on paths & files.

SVN has no concept of a branch or a tag, those are just user 
conventions.  That kinda makes my head hurt, but that's how it works. 
And yeah, that's part of what makes merging a giant pain.  SVN does 
merging a LOT better than it used to, but it still basically sucks.  Git 
does that far better than SVN.  I'm not sure how it compares to BZR/BRZ 
or Hg though.

Refs:
* http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html see the 
"Cheap Copies" box.
* 
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.revs
...
	"A Subversion client commits (that is, communicates the changes made 
to) any number of files and directories as a single atomic transaction. 
By atomic transaction, we mean simply this: either all of the changes 
are accepted into the repository, or none of them is. Subversion tries 
to retain this atomicity in the face of program crashes, system crashes, 
network problems, and other users' actions."

Each time the repository accepts a commit, this creates a new state of 
the filesystem tree, called a revision. Each revision is assigned a 
unique natural number, one greater than the number assigned to the 
previous revision. The initial revision of a freshly created repository 
is numbered 0 and consists of nothing but an empty root directory."
...

[And the "Global Revision Numbers" box]


> It ain't perfect, but IMHO,
> it's the best system out there for version control.

And in mine, it's not.  It's perfect for the Linux kernel, but most devs 
on the planet are not Linux kernel devs, and I'm arguing it's the wrong 
tool for them.

> Code and 
> configuration not under version control is fundamentally broken.

Absolutely!  VCS should be like breathing, you have to do it, it should 
be 100% automatic, and I shouldn't have to make you do it.  Alas that's 
often not the case, and this is a perfect example of why Git is the 
wrong tool.  If someone already doesn't want to use a VCS because "it's 
too hard" or too time consuming or whatever, making them use Git is NOT 
going to help that (horribly, wrong!) perception.  Making them use Bzr 
probably will...

Now, there's an opposite argument that does have a lot of merit, which 
is: If Git is too hard you should not be a programmer!  Based on some of 
the "programmers" I've had to deal with, I like that argument a lot.

But it falls down for the "casual scripter," sysadmin, and other 
non-Real-Programmer/Kernel Dev folks who could gat great benefits from a 
really simple, easy to use VCS; which Git is not.


> As for the question of time: yes, revision control adds time to the 
> process. So do code comments, proper documentation, and tests. But haste 
> makes waste, and in my experience, the benefits far outweigh the time 
> investment that becomes second nature after a while.
+1,000,000 there!  I'm the person at work who drives all of that stuff 
and tries to force everyone else to do it all.  My original question is 
about time wasted because of using Git vs. some other DVCS, like BZR or 
Hg, but I admit I didn't clearly frame it that way.

Later,
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