Æ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
