81–90 of 146 posts
I literally spend half an hour the other day having an argument with chatGPT about how I could find versions of a file that contained a specific string. Guess I should have asked for commits and not versions of files.
"There are only two hard things in Computer Science: cache invalidation and naming things ." - Phil Karlton [0] Based on the above statement, I find it extremely weird to see such git command named " blame ", then I realized I'm not the only one: What does 'git blame' do? [1]. Blame someone else for your bad code [2]. Git blame should be called git credit [3]. Does Git Blame sound too negative? [4]. _________________…
Cool cheat sheet, especially because it covers common use cases. But practically everything covered here I was able to learn independently with Magit. It's also much easier to press one or two keys in the magit-status buffer than to open a terminal and manually type git commands, so I pretty much never use the git CLI directly, not even for a clone.
I half a day later I gave up. Never got to install magit.
Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.
Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.
> Find every commit that added or removed some text > git log -S banana I literally spend half an hour the other day having an argument with chatGPT about how I could find versions of a file that contained a specific string. Guess I should have asked for commits and not versions of files.
"There are only two hard things in Computer Science: cache invalidation and naming things ." - Phil Karlton [0] Based on the above statement, I find it extremely weird to see such git command named " blame ", then I realized I'm not the only one: What does 'git blame' do? [1]. Blame someone else for your bad code [2]. Git blame should be called git credit [3]. Does Git Blame sound too negative? [4]. _________________…
I think a better name would be “git praise”
For neutrality, 'annotate’ was another alias.
Are there git alternatives that aren't a PITA to master before one can use them in production?
Subversion. It was made by CVS maintainers and a lot of care and thought was put into how it works and how the commands work and what the names of the commands are. Subversion is limited in being an older model of version control where there is exactly one single source of truth. In my mind Git solves a different problem that Linus Torvalds was facing: many people working in parallel with only some of the ideas pushe…
Why would a solo dev choose to use a client-server version control instead of one that works fully locally?
I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".
Do you find that better than a stash or a branch because it shows up in ls?
I use stash too, but for different purposes. For instance, when I'd like to quickly change branches to fix a bug/issue and then come back to my stuff. Sometimes, I use stash for resolving potentially complicated pre-commit merges as well.
to update a branch while you're on another branch
Earlier quoted context omitted.
> Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or e…
Yeah, I'd heard good things about the Mercurial UI but bounced off when "how to branch" turned up https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m... with not one but three radically different answers. Seemed somehow unfinished to me.
It is kinda nice to not be able to accidentally lose a branch even if you're a low-skill Mercurial user, and that is the main selling point for most people. On the other hand, low-skill Git users lose stuff often. It's actually really hard to lose committed stuff in Git because of the reflog, but the low-skill users never heard of that and you can really have a hard time explaining it to them. The other big complaint is about `git reset` and its various incarnations. People really don't take the time to understand what it does with its various options, and when they delete their changes accidentally they blame the tool.