|Subject:||Re: [Bug-apl] Improved contribution workflow|
|Date:||Thu, 28 Sep 2017 11:29:32 +0200|
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"
> 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/
"The chain which can be yanked is not the eternal chain."
-- G. Fitch
|[Prev in Thread]||Current Thread||[Next in Thread]|