4 ms·
#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [pull] rebase = true
by 0123456789ABCDE 5mo ago
#~/.config/git/config
[rerere]
enabled = true
autoUpdate = true
while you're editing git config, consider these:
[pull]
rebase = true
[rebase]
autoSquash = true
autoStash = true
[merge]
# zdiff3 adds original text markers and removes matching lines from conflict regions
# https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle
conflictStyle = zdiff3
autoStash = true
[push]
autoSetupRemote = true
default = simple
[init]
defaultBranch = main
- 0123456789ABCDE 5mo agoaddendum these are changes tacked to my git config over time. they're the result of working in a constant crunch state, where smooth forward move was more import than the state of the git history you left behind. these options remove small annoying road bumps. you should avoid some of them if you're working under different constraints, or the commit process differs such that these options don't apply. it all starts with `pull.rebase=true` it makes `git pull --rebase` the default behavior. then comes `rebase.autoStash`, which just wraps the rebase with a stash push/pop envelop. if rebase is not your thing, and you prefer merge, `merge.autoStash=true` works the same. finally `push.autoSetupRemote=true` will skip asking you to set a remote tracking branch, it makes `git push` default to `git push --set-upstream`.
- Izkata 5mo ago[pull] rebase = true Don't use this one unless you really know what you're doing. Multiple co-workers have gotten into really bizarre rebases because of it (like rebasing 70+ commits from master on top of their branch instead of the other way around), it seems to cause more problems than it solves. The man page for "git pull" even has a warning about using this flag.
- 0123456789ABCDE 5mo agotrying to parse your comment, and the story is only getting more convoluted, the more i reread it. "rebasing 70+ commits from master on top of their branch" is not a real thing like, i want to believe you. it just doesn't work the way you're describing it.
- Izkata 5mo agoI didn't catch the exact commands they were doing, but their branch was made that far back, that's how it was that many commits. Support was putting that setting in ~/.gitconfig for all new laptops, and we didn't know it was there. I saw one of them going through this huge rebase and was suspicious about how a pull was causing a rebase at all since this wasn't the default (and this particular co-worker wasn't the kind to explore these settings), so we went looking for it. After removing the setting, the command they were running worked exactly as expected without any surprises. They'd also said they thought they were using git wrong somehow because that wasn't the first time it happened.
- 0123456789ABCDE 5mo agoso, your colleagues merge features into `master` locally? no pull-requests, no branch protections for `master`. i mean this works, but you probably need those rails in place.
- Izkata 5mo agoNo, master is protected. I think they were trying to update their local master so they could resolve a merge conflict.
- beart 5mo agoI believe push default simple is the default in git now and does not need to be explicitly set.
- 0123456789ABCDE 5mo ago> This mode is the default since Git 2.0, and is the safest option suited for beginners. the docs checkout, ty