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.
