281–290 of 330 posts
Earlier quoted context omitted.
You should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.
That breaks git bisect.
The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!
Earlier quoted context omitted.
> The UI of git - for better or worse - directly reflects its internals. I disagree. For example, we have, from “git checkout —help”: git checkout has two main modes: 1. Switch branches, with git checkout 2. Restore a different version of a file The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals? (And o…
I think they tried to fix this by adding new separate commands, right? git restore?
I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.
> The UI of git - for better or worse - directly reflects its internals. I disagree. For example, we have, from “git checkout —help”: git checkout has two main modes: 1. Switch branches, with git checkout 2. Restore a different version of a file The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals? (And o…
Restoring a different version of a specific file/tree, involves recursively restoring wc of those files/trees to match the referenced blobs.
So both are actually primarily the same task. Knowing a little about internals is exactly how it is easy to understand how the same code (and hence the verb "checkout") came to be used for both tasks.
The reason it's still not great UI is that switching branch and restoring file arise in very different circumstances, and I want different guarantees and warnings and confirmations -- so using the same command still only makes sense when thinking very mechanistically.
Earlier quoted context omitted.
> Git is not nearly as confusing as people make it out to be. The people are confused, it's a fact. So it is confusing. Stop gaslighting people.
If you ignore gravitation, a sphere earth can be very confusing.
Earlier quoted context omitted.
Nope. Perfectly curating history is indeed the opposite of squashing—you squash because you couldn't be bothered to curate your commits. Squashing is a workaround not an alternative solution.
You just contradicted your previous comment that was pointing out that fcraaldo is „spending effort in perfectly curating history” … or your comment was a joke with no indication it is a joke.
> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.
I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…
`git tag -d` deletes tags and `git tag -f` moves them (forces them to change).
For the most part whether you prefer a branch or a tag for temporary marks is an aesthetic choice, though the twist is maybe using annotated tags. The annotated tag allows you to leave a commit message for yourself why you made the temporary tag in a way that you can review later. Just like optionally adding a stash message (which also reflects why stashes work under the hood more like tags than like branches).
Earlier quoted context omitted.
If the assumption was wrong, then your first comment was pretty much useless, and the second one didn't help either as it just describes doing things carelessly and without proper understanding. So if that reading of it is wrong, then it was just complaining for complaining's sake and not about Git at all, but rather about what you happen to find scary for some undisclosed reason? People do have genuine troubles with…
My point to the OP is the same thing I'm saying to you. "I understand the thing and think it's fine" does not imply that nobody who understands the thing can think it isn't fine, or anyone who doesn't like the thing just doesn't understand it. It's not some deep or interesting idea, but it needs to be repeated any time "git gud" is used as an excuse for Git's UX, which is always.
I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command. I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to g…
As a former Windows user now on Linux, one of the things I miss is the single unified shell, where every installed program could install new right-click options on files and folders, overlay icons (like TortoiseGit's VC status icons), special objects that aren't files or folders (like My Computer), and so on. I understand this peaked in XP and from Vista onwards Microsoft started changing the shell in less-extendible…
It is not as convenient and it is not yet as capable as things like Tortoise have been in the past, but it is still an interesting thing to see paths explored in Windows like that, even if somewhat hidden in "Advanced Settings".
I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.
Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.