Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Jun 01 2021, Felipe Contreras wrote:
>
> > 1. Remove all the configuration that is not essential (just leave
> > user.name and user.email or equivalent)
> > 2. Pick 2 configurations you think you can't live without. You are not
> > allowed to change them afterwards.
> > 3. Every day you can add 1 additional configuration (and update it the
> > next day).
> > 4. The moment you add a 4th configuration you lose.
>
> This proposal is somewhere between picking which 2 of your 4 kids gets
> to live and asking an alcoholic to stop drinking for a week just so he
> can tell you at the end what his favorite drinks are :)
Yeah, but if you can't enjoy life without alcohol, you probably have a
problem.
Are you saying vanilla git is *that* bad?
> So I skipped the "disable most config", but for what it's worth I think
> I'd miss these the most, I couldn't pick just N favorites, sorry:
>
> * diff.colorMoved=true: super useful, but I'd be vary of turning it on
> by default in its current form. E.g. on gcc.git's changelog files it
> has really pathological performance characteristics.
Very nice! I didn't know about it. I'll pick it for my third day.
> * merge.defaultToUpstream: ditto other discussion, should be "true" by
> default.
That is the default. I used it as an example of a configuration that
changed default (I did it in 2014).
(I just noticed the documentation of the config wasn't updated).
> * checkout.defaultRemote=origin: I introduced this, so I'm biased, but
> I find it super useful. Usually because I do "git branch -m
> new-branch" on master to create topics, and then "git checkout
> master" to get a master back (or use the existing one).
That is useful, but I don't think it's aptly named, it should be
something like checkout.autoUpstream. The name of the default branch
belongs elsewhere.
I would say core.defaultRemote.
Right now for example `git fetch` defaults to a hard-coded "origin".
Doesn't make much sense that the remote for automatic upstream checkout
can be configured, but not the one `git fetch` uses.
> * commit.verbose=true: so you know what you're looking at in doing in
> "git commit --amend".
Aha! My alias had `commit -v` but I would want this on all commit
commands.
Moreover, I was thinking on suggesting this by default. Who would it
hurt?
> * grep.patternType=perl: Another personal soap box (but really, BRE
> anywhere sucks).
Nice. `git grep` is the #2 command I use the most, and I often need to
specify another regexp because the basic one doesn't understand what I'm
trying to do.
> I also have a bunch of aliases that would not be useful to a general
> audience, but which I find I can't live without, some of the most
> commonly used ones:
>
> # Log with "less" n/p already going to the next/prev commit
> log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"
Very neat.
> Similarly rebase is "r", "--interactive" is "ri", "--abort", and
> "--continue" are "ra" and "rc".
I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but
since I use rebase more often I guess I should switch them up.
Theres are a couple of mine:
advance = merge --ff-only
undo = reset --hard @{1}
> If anyone's interested in the rest / full set:
> https://github.com/avar/dotfiles/blob/master/.gitconfig
Is thata private repo?
Here are mine:
https://github.com/felipec/dotfiles/blob/master/.gitconfig
--
Felipe Contreras
