121–129 of 129 posts
> [...]
> [push]
> autoSetupRemote = true
I strongly disagree. Publishing a new branch on the remote should be an explicit operation. And git push will already tell you the command you need to run so it isn't an issue with having to remember another random command.
I think this should be the default: git push --force-with-lease Forces pushes are dangerous enough as it is, so I'm mystified on why git doesn't insist you know the state of upstream before running it. Sadly you can't make it the default, so I resort to: [alias] force-push = push --force-with-lease As for the article, I must the the weird one because I prefer most of the settings are they are or don't care. Even some…
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 assume many people, like me, would have git aliases which use a hardcoded master branch name. I several of these aliases. I've had to update them all to check what the actual master/main name is and use that instead, because our org started following the "main" naming convention and we ended up with various repos with "master" and others with "main".
I personally like standardisation, because I prefer to spend time thinking about more important things. So I was mildly (but only mildly) peeved when I had to start thinking about which repo I was on and what the "master" branch was called.
But I've updated all my aliases now, so not so much of an issue.
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
I'm maintaining a non-public mirror of some thousand OSS repositories. When you git clone, you do not use any "default branch", you clone the HEAD of the remote repository. This is a so-called "symbolic ref". People call it "default branch" because they don't know it can also point to a tag, a commit or be in the middle of an broken rebase. And you cannot set that information remotely via git. 'git push' can't do it,…
Is the expected behavior when a remote changes its HEAD seriously just to break when you try to push?
Earlier quoted context omitted.
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?
> Do I get to commit all my project management IDE/editor specific files too Yes, if those files apply to all team members using the same tool absolutely check them in. What's the problem? It reads to me like maybe you don't know what these files are actually used for and why a team benefits from sharing them.
Earlier quoted context omitted.
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.
My own ~/.gitconfig looks like this: [alias] co = checkout ci = commit st = status br = branch hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short type = cat-file -t dump = cat-file -p dft = difftool [tag] sort = version:refname [tar "tar.xz"] command = xz -c [tar "tar.zst"] command = zstd -T0 -c [log] date = iso-local [pull] ff = only [diff] tool = difftastic [safe] directory = * [advice] detachedH…
Do your aliases even save you any keystrokes? Most shells support auto complete, and you still have to type "git" unless you have a shell alias for it. I guess what I'm git-ing at is a truly efficient alias would be embedded in the shell. For a while I had "gsno = git status --uno" although it's been so long since I used it, I forget what the options even did. Somehow I get by with only stock commands. Another helpfu…
Earlier quoted context omitted.
I'm maintaining a non-public mirror of some thousand OSS repositories. When you git clone, you do not use any "default branch", you clone the HEAD of the remote repository. This is a so-called "symbolic ref". People call it "default branch" because they don't know it can also point to a tag, a commit or be in the middle of an broken rebase. And you cannot set that information remotely via git. 'git push' can't do it,…
Even if master was the default still, nothing changes about your problem. Repositories have always been free to choose whatever name they want and change it at any time. Is the expected behavior when a remote changes its HEAD seriously just to break when you try to push?
You can't propagate (push/fetch will FAIL) a branch deletion to a repository if that branch is still referenced in the HEAD, and attempting to clone a repository where this has been forced will leave you in an empty directory with no checkout. This is the expected failure mode for all clones when a project changes to main and deletes master.
This is not specific to the main/master thing, it has always been a big pain, but with the main/master thing people started en masse to do it without technical necessity.