Notes for DLang maintainers

[H. S. Teoh via Digitalmars-d]

On Tue, Feb 28, 2017 at 11:37:45AM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 02/28/2017 02:37 AM, Jacob Carlborg wrote:
> > On 2017-02-28 00:42, Nick Sabalausky (Abscissa) wrote:
> > 
> > > Contributors shouldn't have to know as much about git as a
> > > project's maintainers. So these features, if used, are AWESOME.
> > 
> > Squashing and rebasing is part of the basic git, in my opinion.
> > 
> 
> Maybe they should be, but with the basic git interface, or any
> front-end I've seen, they're terribly convoluted. Particularly
> squashing. Well, either that, or the docs are just really, REALLY bad.
[...]

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


> 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?

(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'.)


> 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.)


T

-- 
Don't modify spaghetti code unless you can eat the consequences.