Notes for DLang maintainers

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/28/2017 12:18 PM, H. S. Teoh via Digitalmars-d wrote:
>
> Whut...?  What can be easier than:
>
> 	git checkout my_bug_fix
> 	git rebase -i master
> 	# Editor pops up, change "pick" to "squash" (or "s" for short)
> 	# for every commit you wish to squash.
> 	git push -f origin

1. wit squash my_bug_fix
(Or something along those lines. Not yet implemented.)

2. Not needing to intuit that process from the awful docs and Sheldon 
Cooper-esque web articles: 
<http://www.youtube.com/watch?v=AEIn3T6nDAo&t=1m12s>

Your instruction right up there, honestly, is the first time I've *ever* 
come across any instructions or explanation for "How do I squash my pr" 
that actually makes any straightforward sense.

>> There's no reason either one of those operations couldn't/shouldn't be
>> a (*simple*) one-line command, and yet, they just...aren't. But then,
>> that's git :/ (And no, rebasing a PR is NOT a one-line git command,
>> and no, add-on scripts don't count towards usability.)
>
> "Add-on scripts" are just user-defined functions.  Is it really that bad
> to expect programmers to be able to write their own functions as opposed
> to expecting the standard lib to spoonfeed them for every little
> conceivable task they might possibly need to accomplish?

When it's a basic common task, then yes.

When it's something that's expected of project contributors, then again, 
yes. (Paths of resistance are a great way to discourage contribution and 
work against the OSS ecosystem.)

> (Having said that, though, I agree that your standard average *nix shell
> interface is really dumb, and being forced to write scripts in that
> broken language can be painful.  One of these days I should write a
> shell with D-like syntax that doesn't require memorizing meaningless
> 30-year-old typographical infelicities like 'grep'.)
>

Meh, I just use D anymore for any non-trivial scripts ;)

>> Actually, about a week ago, I finally got around to staring a lib/cli
>> front-end for git (github support planned, too) to make everything
>> sane. Too early for anything public though, a lot still incomplete, a
>> lot that may still be in flux.
>
> Curious to see what you come up with.  AIUI, git is already providing
> the 'porcelain' interface by default, so we see today is already far
> better than what Linus used to use. (I dread to imagine how one might
> use git back then!  I'll bet it's like piloting an airplane by coding in
> machine language in real-time. :-P)  Let's see if you can come up with
> something even better! ;-)   (Though I'll admit it may be easier than it
> sounds. But still... the only sane way to use git is to understand its
> innards -- y'know, all that DAG stuff -- 'cos it simply doesn't make any
> sense otherwise.)
>

I highly suspect how much people like my tool will have a strong inverse 
correlation to how well they understand git (and that's fine - if you're 
good with git, then git gets the job done, no problem.)

TBH though, the issues I've had understanding and using git have had far 
less to do with any DAG-iness of git[1], and more with:

A. The details of the CLI just plain being a mess (inconsistencies, 
questionable defaults, reinventing alternate meanings for established 
VCS terminology, etc)

B. Too much catering to "invent your own workflow!" when most users just 
need "Here's best-practice workflow" and tools appropriate for it.

C. Docs that assume more in-depth knowledge than is really necessary, 
and howto's that can't get straight to the point without throwing a 
bunch of blather at you first (again, the Sheldon Cooper teaching style.)

[1] For example, I've never really had any issue dealing with git's 
branches. No 11-tentacle monsters or anything. But then, I don't go 
branch-crazy either (does anyone?): I have "master" and then I have a 
branch for each PR (if I'm submitting PRs). And then once in a rare 
while, if I'm trying something big and experimental, I'll have a branch 
for that experiment.