Re: The git spring cleanup challenge

[Felipe Contreras <felipe.contreras@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 03 2021, Felipe Contreras wrote:

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

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

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

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

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

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