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 <***@lamkins.net>:
> On Wed, Sep 27, 2017 at 12:00:08PM -0400, bug-apl-***@gnu.org wrote:
> > From: Juergen Sauermann <***@t-online.de>
> > To: Elias MÃ¥rtenson <***@gmail.com>, "bug-***@gnu.org"
> > <bug-***@gnu.org>
> > 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
>
>