Re: The git spring cleanup challenge

Ævar Arnfjörð Bjarmason wrote:

On Thu, Jun 03 2021, Felipe Contreras wrote:

quoted

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.

I don't see a need for core.defaultRemote, but I don't see a need for
checkout.defaultRemote either.

Just have `checkout.autoUpstream = true` and hardcode *both* to "origin".

quoted

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.

I've personally never have had a problem with it.

Sure, it *might* have some issues, but any change does. That's not a
very strong arugment against making it the default.

quoted

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

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.

Perhaps. I think defaults should be tried-and-true. Only after a
considerable number of people have tried them should they become
default.

I have no problem with something like the above being a default, but
only when the user has specified these kinds of features.

Maybe with

  [core]
    mode = fancy

quoted

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

Yeah, it's surpsingly difficult to convince some people of the most
obvious things. I rather have a private branch on my dotfiles, where I
don't have anything sensitive really, just stuff I'm sure others won't
find useful.

Cheers.

-- 
Felipe Contreras