Re: The git spring cleanup challenge

On Thu, Jun 03 2021, Felipe Contreras wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

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.

quoted

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

quoted

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

quoted

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

quoted

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

quoted

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.

quoted

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}
  

quoted

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