Keith C. Perry on 19 Nov 2017 09:47:50 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Revision Control for the Rest of Us


THIS!!!

I'm one of "the rest of us" as well and one of things that is not so good (yep, I'm being "nice") is that we in the open source community as of late have been doing to much jumping on the <insert new shiny thing here> while not understanding what <that new shiny thing> really offers.

(yes, I know git is not new- not the point)

While it's important to innovate and keep striving to make tools better.  Much of what is new is not new- it's a repackage spin on what someone else things is a "better" way to accomplish a task.  Pick any FOSS religious argument such as what we are talking about here and ultimately there are few times when one thing is 100% better in every way than something else.  Such an evaluation can be subjective and can get into the weeds quickly.

I personally don't use a full version control system for my applications because I've rarely found a full system to be necessary beyond the common sense things I have always done to maintain my code bases.  The slickest thing I sometimes do, is run a LAMP application on top of NILFS2 to protect production systems.  The last system I used when I was managing a programming group was svn.  I'll submit its syntax is weird but if svn is that, git to me is alien.  I find it to be even less logical and more cumbersome.  If I wasn't going to run svn for personal projects, I certainly would not choose git.

The idea of this talk is spot on.  I don't want to hear about git as **the** revision control system people should run now but I do want to see what other revision control systems are out there which might make more sense to me.  Version control should be lightweight, logical and perhaps a bit intuitive.  Already from this thread, bazaar seem pretty interesting.  Looking forward to hearing more.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Managing Member, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "JP Vossen" <jp@jpsdomain.org>
To: plug@lists.phillylinux.org
Sent: Thursday, November 16, 2017 8:33:28 PM
Subject: Re: [PLUG] Revision Control for the Rest of Us

On 11/16/2017 03:43 PM, Clay Wells wrote:
> On 11/16/2017 02:23 PM, JP Vossen wrote:
>> And...yup.  In those very special and hopefully very rare cases,
>> mutable history makes sense.  I *still* think it's a bug, 99.999% of
>> the time.
>>
> I know it's not a bug. The flexibility is there for a reason.

Sure, else Linus wouldn't have put it there.  But it's a reason *most* 
people never need, almost all of the time, and you can hurt yourself 
with it.  That's a bug to me.


> Generally speaking, most people do not need to
> worry about changing history. It's less like a chainsaw and more like
> the 6th gear of a Porche.

Huh, that's not a bad argument.  Maybe it's more like reverse without a 
lockout to prevent you from shifting into it while going 70mph?

(Also, it doesn't count unless there are 3 pedals, and I think Porsche 
went all paddle shifter, didn't they? :)


>> The solution in all of those cases is:
>>      1. Dump the repo
>>      2. Edit the dump to remove the Bad Thing
>>      3. Import the dump
>>
> This is simply not true.

Yes it is.  See next.

> 1. You commit a 50GB whatever a year ago and you now want to remove it..
> good luck.. doesn't matter
> what VCS you're using. However, I'll put money on the fact that Git will
> be much better at cherry-picking
> a commit out of your repo history than most/all other VCSs. Perhaps this
> is just my opinion because I'm
> comfortable using Git and have been for years.

I don't understand that argument at all.  If you "fast-export" (dump) 
the repo into editable text, edit it, then re-import it...that works. 
All the time, for anything, no matter what you did when, for any VCS 
that supports "fast-export" (which I think now it all of them).

OK, yes, you can mess up when you edit the dump, that's what backups are 
for, and arguably http://www.catb.org/esr/reposurgeon/reposurgeon.html.

And it's really painful and results in a new and different repo, which 
creates a whole other bunch of problems.  But it does work.


> 2. git reset --hard HEAD~1 will remove the most recent commit.

And there's part of my argument against Git.  There are lots of ways to 
do lots of things, with extremely subtle and sometimes dangerous nuances 
that CAN cause you to lose data.  You have to know far too many 
commands, some of which are virtually useless without "optional" 
switches, and you have to understand far more about the guts than you 
should.  It is just NOT a user friendly tool, especially for casual, 
occasional users...like "the rest of us."


> 3. You should be working in a feature branch.

No, you shouldn't.  You shouldn't even have to know what that means. 
The tool should be simple and Just Work.  The others do, Git doesn't. 
Git is simply NOT the right tool for many, if not most users.

Git is the right tool for Linux kernel devs, or people who work on 
projects of a similar scope and scale, and for many/most Real 
Programmers(tm) who know what you just said.

For the record, I'm not a Real Programmers(tm).  I'm a scripter, and 
admin and a bunch of other things, and Git just makes my head hurt and 
my eyes bleed.


> Branches in Git are simple and light weight. Therefore,
> if you're bad things happen then only your local branch is impacted. You
> can then fix it up and merge
> into master once you have everything in order. This is where mutable
> history can come in handy.
> So people prefer a clean and short history. Your feature branch can
> include 20 commits but it can be
> merge into master in such a way that it appears as one commit.

Yup, I give you all that.  But NONE of that matters for the folks I'm 
talking about and trying to reach here.  :-)  If you understand and care 
about any of that then yes, Git is probably the right tool for you.


...

>> Does that really, REALLY suck for all kinds of reasons?  Yup.
>> So...don't commit Bad Things.
>>
> 100% it would but that's certainly not the only option. There's a lot of
> mis/non-understanding out there.
> 
> If you're elite enough to use Gentoo then by all means you should be
> able to use Git without issue.

OK, LOL on that one a bit.  We should prolly throw the Arch users under 
that bus too.  Then again, they all may be so busy tweaking stuff that 
the overhead of learning Git is too much...  <ducks>


> I'm not trying to be a troll. Just adding my $0.02, FWIW

Sure, you've presented a perfect perspective from someone who should be 
using Git.  You are just not..."the rest of us" who I'm trying to reach 
here.  Git (arguably with a lot of help from Github) won the war SO 
strongly that we forget there are other options.

Thanks,
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
___________________________________________________________________________
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