Live data from Hacker News

Better Git configuration

blog.scottnonnenberg.com

51–60 of 66 posts

Re: Better Git configuration

#51
post #50

When I want/need to customize this much, I tend to think poorly of the tool.

I'm guessing you don't like Vim or EMACS then? Or the command line in general? Most of the development tools I use on a regular basis tend to be extremely customizable, and I regard that as a Good Thing.

To each their own. Sure my coworkers complain about this or that annoyance in WebStorm or whatever that they can't customize or fix, but then they never lost the better half of a day to ~/.vimrc so...

I can see it both ways. I'll choose customization, but I wouldn't fault someone for expecting a good out-of-box setup.

Re: Better Git configuration

#52
post #12

This has saved me: git config --global pull.ff only I can always override an individual pull invocation with either "git pull --rebase" or "git pull --no-ff", making it a conscious choice when a fast-forward pull is not possible.

Oh wow, this must be a recent feature, I remember looking for a way to configure `--ff-only` by default a few years ago and it didn't seem possible. I ended up making a git alias of `git puff` which calls pull with the `--ff-only` flag.

Re: Better Git configuration

#55
post #50

When I want/need to customize this much, I tend to think poorly of the tool.

I'm guessing you don't like Vim or EMACS then? Or the command line in general? Most of the development tools I use on a regular basis tend to be extremely customizable, and I regard that as a Good Thing.

I'm a fan of being customizable. I'm not a fan of practically needing customizations.

My main editors are Vim and VS Code, both of which I find perfectly usable OOTB.

Re: Better Git configuration

#57
post #53

I will never understand why people hate merge commits. It's an accurate history of what happened, and can be useful in tracking down bugs.

It's a trade off. In my opinion when using rebase you don't lose history or make it inaccurate. A bug would still be introduced by the commit that made it, so tracking down bugs with bisect or other tools works the same. The main advantage is that your history is much cleaner.

Re: Better Git configuration

#58
post #12

This has saved me: git config --global pull.ff only I can always override an individual pull invocation with either "git pull --rebase" or "git pull --no-ff", making it a conscious choice when a fast-forward pull is not possible.

Oh wow, this must be a recent feature, I remember looking for a way to configure `--ff-only` by default a few years ago and it didn't seem possible. I ended up making a git alias of `git puff` which calls pull with the `--ff-only` flag.

Looks like it showed up with commit b814da891e, and has been around since Git v2.0.0.

The online docs mention it in Git v2.1.0: https://git-scm.com/docs/git-config/2.1.0

Re: Better Git configuration

#59
Here's one: Use:

    git push --force-with-lease
Instead of

    git push -f
(Obviously ideally you'd never do either, but sometimes life happens.)

The advantage of the former over the latter is that it won't push if you haven't already seen the ref you're overwriting. It avoids the race condition of accidentally "push -f"ing over a commit you haven't seen.

(Why this isn't the default, I have no idea.)

Re: Better Git configuration

#60
post #59

Here's one: Use: git push --force-with-lease Instead of git push -f (Obviously ideally you'd never do either, but sometimes life happens.) The advantage of the former over the latter is that it won't push if you haven't already seen the ref you're overwriting. It avoids the race condition of accidentally "push -f"ing over a commit you haven't seen. (Why this isn't the default, I have no idea.)

Yes, force-with-lease is really useful. I set it up as an alias of git fpush, and have never used push --force since.
Post reply on HN