Re: [Bug-apl] Improved contribution workflow

[David B. Lamkins]

On Wed, Sep 27, 2017 at 12:00:08PM -0400, address@hidden wrote:
> From: Juergen Sauermann <address@hidden>
> To: Elias Mårtenson <address@hidden>, "address@hidden"
>  <address@hidden>
> Subject: Re: [Bug-apl] Improved contribution workflow

[... snip ...]
> As to Mercurial and git, I am really not a fan of them. Mercurial is kind of
> bearable because you can use it from SVN.
> But the way in which people work on github is, IMHO, horrible, even though 
> they
> seem to be successful. This is probably
> due to my own lack of knowledge about git, but what I have seen so far is not
> motivating me to increase that knowledge.

I can certainly appreciate the sentiment. I'd like to share my own experience 
as a git user, FWIW.

Until three years ago I had been a strong proponent of SVN. I understood as 
much of the workflow as I needed. Really the only downside of SVN, for me, was 
having to occasionally ping someone who had locked a needed file for too long.

Then I joined an R&D outfit that uses git on the engineering side. (The 
business folks use SVN.) I have to say that my early experiences with git were 
unpleasant, mainly due to the *huge* "surface area" of the toolkit and the lack 
of a (IMO, at least) well-written concept guide. Mind you, there's *tons* of 
"how to" posts and articles, some of which have been useful. But the general 
approach is "here's how I did this" with little explanation beyond the commands 
and arguments necessary to solve the problem...

AIUI, one of the reasons for the depth of git is that it supports a plethora of 
workflows. There are other factors, of course: the fact that git is a 
distributed system and offers a bunch of "plumbing" for custom system 
integration probably contributes to the bloat. The question you need to answer 
-- and I don't think there's a one-size-fits-all perspective -- is how you feel 
about the tradeoff between git's complexity and its capabilities.

Again, AIUI: It's quite likely that if you're working on a project having many 
contributors, then the project will have an established git workflow with 
guidelines (or even requirements) as tohow to do common tasks. The most 
difficult situation, I think, is to learn git on your own as a sole (or 
principal) contributor, with only the man pages and the afforementioned 
resources for deciphering git.

GitHub takes away some of the complexity at the expense of hiding a lot of the 
more clever bits of git. (I personally am not a fan of web UIs for technical 
tasks.) The downside is that folks who learn only the GitHub (or GitLab, or 
...) interface tend to invent Rube Goldberg-like workflows or to completely 
ignore, say, the notion of "upstream". Take a peek at Arduino-related repos for 
a great example of this: I once had to (attempt to) track down the source of 
some GPS code that originated for an Arduino shield; there were multiple 
upstreams, each of which had tens or hundreds of forks. The code that I was 
trying to identify, though, no longer existed. But these are all git repos, no 
matter how many there are, right? Yeah, right. Unfortunately, none of the "ease 
of use" of the web UI does much (if anything) to inform its users regarding 
useful workflows. It turned out that the owner of the "ancestral" upstream 
wiped and rewrote the repo for every release; the early release that I needed 
to consult didn't exist anywhere...

Personally, I'd advise taking at least a peek at git if the opportunity 
presents itself. Regardless of whether you want to adopt git, you will 
encounter useful projects that do present their assets as a git repo; you'd be 
well-served to know some basic commands such as switching branches and viewing 
the commit log. But I wouln't suggest jumping ship from a system with which 
you're already comfortable.

(That said, I *do* have a recommendation for a GNU Autotools replacement: Meson 
and Ninja. I've begun to adopt that build toolchain for my personal and work 
projects, and am quite pleased with what I've seen so far. For an example of a 
small project built using Meson and Ninja, see the xs shell that I maintain: 
<https://github.com/TieDyedDevil/XS>.)

-- 
"The chain which can be yanked is not the eternal chain."
-- G. Fitch