Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Core Git Developers Configure Git

blog.gitbutler.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: How Core Git Developers Configure Git

#101

Post by theshrike79 »

schacon wrote: post #88
jelder wrote: post #80

My favorite alias is `git out`, which just lists all unpushed commits. I use it all the time. [alias] out = "log @{u}.." In my head I always hear it in the voice of The Terminator: https://youtu.be/8cdC1Y5oRFg?t=54

I should do another article on the best aliases, because this is a great one. I want it just because I want to do the Arnold voice every time. Now I want to do: `git to-da-choppa`

That could be just

  git add . && git commit -a -m "git to da choppa" && git push --force
For when you need to Get to da choppa and don't have time to clean up =)

Re: How Core Git Developers Configure Git

#102

Post by ajross »

> Personally, I think the default behavior of Git should be to make your remote references as close to what is on the remote as possible. Prune stuff that’s gone, etc.

Yikes, no. Remote junk disappears all the time, and you never know when you'll have to recover something. Old versions of GitHub pull requests, in particular, tend to be garbage collected at the backend rapidly. It's a semi-regular occurrence for me that I have to dig through reflog to get to early work that everything else has forgotten about.

Just in general, don't delete stuff you don't know you don't need. That's just data robustness 101. nothing to do with git. Deletions should be as manual as possible, and generally done following a backup.

Re: How Core Git Developers Configure Git

#103

Post by trebligdivad »

superb_dev wrote: post #22
randunel wrote: post #18

Earlier quoted context omitted.

While your comment is in jest, I agree with the sentiment. The whole "main" debacle sucks and, to this day, still breaks everyone's git usage.

Honest question: What has it broken about your git usage? I haven’t really noticed a problem. Sometimes a repo uses “main” and sometimes “master”. It’s not like “master” was the only option before

I do find myself forgetting which project is main and which is master so get confused a bit. (Personally I find the use of 'master' in git fine - there has never been a 'slave' it was referring to; and 'master' is used in loads of other contexts in English; I've got a Masters degree, we have Post-masters, schools have masters and headmasters. I understand renaming it in master/slave systems though.)

Re: How Core Git Developers Configure Git

#104

Post by ajross »

tex0 wrote: post #70
eastbound wrote: post #29

Earlier quoted context omitted.

Should create an XKCD with “There is always n+1 Git client GUI”. EVERY new employee arrives saying “Hey I’ve found this great UI for git, this one really nails it and makes git easy” and every time it’s a new Git UI that I’ve never heard of. It’s the “hello world” of startups: Creat their great git UI and publish it. Then they commit with the default crappy commit messages and they don’t know how to git-rebase-i.

Maybe git is just too complicated for average users (myself included).

> Maybe git is just too complicated for average users (myself included).

Then use the vscode wrapper, or whatever you choose.

People complain that "git" is complicated when what is really happening is that they're looking at a revision management problem like a merge conflict or regression bisection, or having to split/refactor a giant blob of changes as demanded by an upstream project, etc...

Those tasks are complicated, necessarily. And git is a tool for doing them. But people tend to get confused about this and blame the tool and not the problem. But a better UI isn't going to make that split not suck.

Re: How Core Git Developers Configure Git

#105

Post by zelphirkalt »

tomnipotent wrote: post #37
zelphirkalt wrote: post #31

Earlier quoted context omitted.

Or ".vscode" folder. No need to spread that to everyone, who might not even be using VSCode or VSCodium. Like we also don't see all of the following being added everywhere: ".settings" (eclipse), ".idea" (IntelliJ Idea), ".nbproject" (I believe Netbeans) and others everywhere in the repos. Yet we see it for VSCode. I think Github encourages this annoying behavior, because it is Microsoft's own tool, so it gets treate…

It's very common for shared project-specific setting files to be stored in ".vscode" that are used by all developers on the project, including launch/task configurations. VSCode settings are hierarchical and composable (non-scalar keys are merged).

I am aware of that. Yet I don't see other cohorts doing that with their editor/IDE of choice. It seems to be mostly the "I don't want to configure my tools" subset, who does that. What if I switch my tool of choice 2-3 times? Do I get to commit all my project management IDE/editor specific files too? How much stuff do we want to accumulate in the git repo?

Re: How Core Git Developers Configure Git

#106

Post by chuckadams »

genewitch wrote: post #95
PhilippGille wrote: post #54

Earlier quoted context omitted.

Isn't copying without the formatting just a ` | pbcopy` away?

I have Gemini set to decipher HN comments that I don't immediately understand. This is a macos only command `pbcopy`? Aside: Gemini mentioned it didn't want me to ask it questions about bikeshedding what shade of blue on a website header so I think it's got our number.

Yes pbcopy is a mac thing. On Linux, there are of course many different commands in different environments/distros. xsel, xclip, wl-clipboard, wlclip to name a few.

On windows, powershell has Get-Clipboard and Set-Clipboard, and cmd.exe has `wsl` to fix the issue of having used cmd.exe to begin with.

Re: How Core Git Developers Configure Git

#107

Post by [deleted] »

eastbound wrote: post #29
jeffwass wrote: post #10

Earlier quoted context omitted.

Of course, there's an xkcd for that : https://xkcd.com/1597/

Should create an XKCD with “There is always n+1 Git client GUI”. EVERY new employee arrives saying “Hey I’ve found this great UI for git, this one really nails it and makes git easy” and every time it’s a new Git UI that I’ve never heard of. It’s the “hello world” of startups: Creat their great git UI and publish it. Then they commit with the default crappy commit messages and they don’t know how to git-rebase-i.

[deleted]

Re: How Core Git Developers Configure Git

#108

Post by chuckadams »

wh33zle wrote: post #40
dark-star wrote: post #2

Wow this is neat. I never really bothered to deep-dive into my git configuration, but some of these are really cool. The diff changes are awesome, and I always wondered why there isn't a global .gitignore file in the first place, seeing that every .gitignore file basically has (mostly) the same content

One of the coolest things I've learned about recently is `.git/info/exclude`. It allows you to ignore files in the local repo without modifying the repo's .gitignore Very useful if you want to add your own .envrc or shell.nix to a repo.

I just add .envrc and shell.nix to my global gitignore. Along with docker-compose.override.yml. You can always force-add an ignored file, it'll be tracked from then on.

Re: How Core Git Developers Configure Git

#109

Post by SAI_Peregrinus »

randunel wrote: post #24
superb_dev wrote: post #22

Earlier quoted context omitted.

Honest question: What has it broken about your git usage? I haven’t really noticed a problem. Sometimes a repo uses “main” and sometimes “master”. It’s not like “master” was the only option before

Previous shortcuts (dotfiles) which performed merges and other operations no longer work, as you never know if the project uses one branch name or the other. And there's a whole new breed of programmers out there who feel offended on behalf of others about renaming versus not renaming, for example, the word "robot" comes from slave in Slavic languages and it should be banned, etc. I somewhat agree with either banning…

They didn't ban anything? They changed the default branch name for new repositories. You've always been able to have different default branch names (I've used `trunk` for years) so if your shortcuts assumed `master` they'd have broken in a repo with a different default anyway.

Re: How Core Git Developers Configure Git

#110

Post by penguin_booze »

thro949494i wrote: post #8

> Default branch > Personally, I don’t have a problem with master > updating the default value. I wish Git had some taste here, but they don't So author has no preference, but git does not have a good taste here, for not breaking backward compatibility. Typical passive agresive bullshit! I think "main" is not inclusive enough, we should use something like "non-specific-but-strong-branch". Or something that includes e…

You've no idea how much real social change has been brought about, when Git changed its default branch from master to main. Pardon me, I'm tearing up right now.
Post reply on HN