On Thu, Jun 03 2021, Felipe Contreras wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> 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.
It makes patch review a lot easier, and also integrates nicely with -w.
>> * 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).
Ha! Maybe it's leftover from before then, or I missed that in the
not-updated docs more recently.
>> * 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.
I think there was some bikeshedding around that time. I share the
sentiment, but worry about "core" over-configuring such a
thing. E.g. wanting "checkout" to search a "upstream" and "origin" in
that order (not that it supports a list right now, but could) != wanting
"init" to use "upstream" instead of "origin" by default.
>> * 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?
E.g. "git rebase -i" with "reword" now becomes a lot more verbose, I
think it's a feature, but others might disagree.
It also exposes various edge cases around our parsing of the diff
v.s. commit message content in our apply.c etc. code, e.g. say you want
to blindly search-replace "diff" with "difference" in your commit
messages. You'll now change the "diff --git" line to "difference --git",
and now "commit" won't detect that it's the patch part anymore, and
merge that diff into your commit message itself.
I can't remember if we pick up on "diff --git" exactly, IIRC, but
anyway, whatever part of the format you need to screw with, the point
stands. I've run into mistakes like that in the past, one recently made
it to this ML.
>> * 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.
Yeah, it should be at least ERE by default, Something for Git v3.0 ...?
>> 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.
I think similar to your "git help xyz" patches having coloring, we
really should consider things like that by default knowing that we're
invoking "less". I.e. if we got over the notion that our job is just to
throw data over the wall to "man" or the pager without any further
tweaking or integration.
>> 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
Yes, it was private[1]. I've made it public again.
1. It used to be public, but then the security/auditing people at an
ex-job kept pestering me about me hardcoding über-secret company data
in public GitHub repos.
They didn't find questions like "uh, you mean this information we
advertise in an MX lookup to our public nameservers?", or "yes,
that's my company E-Mail address in a config file, my co-workers have
the same info on linkedin" all that convincing. Anyway, it's back now
:)
