Re: The git spring cleanup challenge

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 3, 2021, 12:31 UTC
Message-ID: <87wnrb5cvl.fsf@evledraar.gmail.com>
In-Reply-To: <60b8b882b9dc5_1a0a2d208e9@natae.notmuch>

On Thu, Jun 03 2021, Felipe Contreras wrote:

Show 9 quoted lines

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

Show 7 quoted lines

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

Show 14 quoted lines

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

Show 8 quoted lines

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

Show 6 quoted lines

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

Show 8 quoted lines

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

Show 19 quoted lines

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