Re: [Bug-apl] Improved contribution workflow

[Alexey Veretennikov]

Hi,

I'm really having trouble to understand how did you find it difficult to find information or concept guides.

There is just an _awesome_ book available online: https://git-scm.com/book/en/v2

which contains 99% of the stuff you need to know, including details on how the internally git works, all concepts and explaining workflows.

There is an awesome speech by Linus as well which describes main concepts on how it indented to be used: https://www.youtube.com/watch?v=4XpnKHJAok8

The github itself has a great tutorial and emphasize own workflow (pull-requests).

Also about working on your own, since the ability for git to work from scratch without any servers etc just make it much easier for personal use than svn and other vcs - i.e. you just archive whole directory and copy to another pc etc and continue to work.

Having say that, the usage of github or whatever other system is just a maintainer preference: if he wants to make the contributions easier and reach wider audience of contributors. So far github is the easiest and most widely used repository storage and social network around open source projects (not necessarily free software!).

Dyalog for instance is already moving their auxulary libraries and tools to github: https://github.com/dyalog/ , in the move to reach larger and younger audience of contributors and APL developers.

For example their new IDE, RIDE, is already there.

P.S. On a humor note, about git: https://www.youtube.com/watch?v=CDeG4S-mJts

Br,

/Alexey

2017-09-28 5:10 GMT+02:00 David B. Lamkins <address@hidden>:

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