261–270 of 281 posts
Earlier quoted context omitted.
Not a fan of the staging area, because it won't be tested. I would rather stash some changes to postpone them, then test and commit the workspace.
What does the staging area has to do with tests?
> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
I guess. To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than people's intuition? The fact that it "mostly jibes" feels like a footgun, not a feature. I get that for some, "git just works! It made sense from day one" but in my limited experience, 0% of people I've worked with have said that. Sure, we can all learn the te…
I don't know if this is true of git, but in general we have a disease called, "solving problems we don't have". I don't mean the YAGNI issue, or people trying to talk others out of doing engineering because the current masochistic process is good enough.
I mean the impedance mismatched caused by taking a concrete, physical problem, translating it into a domain that looks nothing like the problem you're meant to solve, and then tweaking how the fiction works so that it fulfills the requirements.
A few wise people have warned me off of this strategy over the years, but there's not nearly enough ink spent on this topic. This impedance mismatch gets worse over time. They asked for X, and you gave them Y, so when they ask to refine X into X + 1, it gets a little harder each time. The complexity goes up and you find confused product owners asking for what should be a simple change and getting tremendous pushback that smells a lot of deflection.
Meanwhile because users think the system works one way, they expect it to behave in certain ways and constantly get rudely surprised by how it actually works.
Again and again in my career, I've found that a lot of performance problems are obscured by accidental complexity and/or X-Y problems, and once you know the task you actually need to perform, and write the code to solve the actual problem instead of an analog, everything becomes clearer. A mix of determinism and pre-determinism (static calculation) makes for a much faster system without sacrificing legibility in the process.
The issue, I think, is that people find the problems they are given to be boring, and so they try to solve an analogous problem they find more entertaining - at first. There are other ways to find joy and fulfillment in simple tasks besides making them into stunts.
Earlier quoted context omitted.
So would it be correct to say that 'heads' are the LEAVES of the commits-tree? Or are there such leaves which are not considered 'heads'?
No. There are leaves that aren't heads (for example, after you delete a branch, the old commits just lie around until someone deliberately cleans them up), and there are heads that arent' leaves (for example if you branch a new feature branch from main. The feature branch brances off of main, so main is not a leaf anymore)
But "main" remains a "head" even though the feature branch "continues the graph" from it?
So there must be a difference between "Adding a new commit" and "Branching a new commit". I think I got it now. Thanks
Earlier quoted context omitted.
That's as unfortunate as 'rm *' (and good to be aware of BTW), but doing this deliberately doesn't qualify as "normal use" for me.
In my career, it has already happened more than once. And definitely not deliberately. There are many ways this can happen accidentally. You could be trying to checkout a branch and tab complete your way into a folder name instead. You could be typing alt/esc + . with the intent of getting last argument of previous bash command, keyboard glitches and you end up with . instead. Just because it hasn’t happened to you y…
But. I once messed up badly with something else once, makefiles. I was kind of overconfident and end up screwing myself by telling something to write its output to my source files by mixing up $Fool me once, shame on the tool; fool me twice, shame on me.
Well, that's what OP was referring to, but in such a "click-bait-y" way.
Earlier quoted context omitted.
Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main .
Why? That would heavily imply that master/main is somehow technically different from all other branches (since a trunk is certainly not a branch), which to my knowledge is not true.
> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
I'm still missing what part of the intuition is incorrect? It seems like the only "incorrectness" is that there's no explicit hierarchy of branches. Except that's wrong the HEAD ref points to the default branch. Any other branches are of equal significance, though.
But in git, a branch doesn't "contain" anything. It is just a pointer to a single commit. This is completely counterintuitive and makes no sense to most people at first, for a very good reason: the analogy is misleading.
These things shouldn't be called branches. They are pointers: they can be repointed anywhere, dereferenced, and copied by reference.
HEAD is also a stupid term, because it doesn't refer to the head of anything. HEAD is the current pointer, and it can point to any commit, not just the head of a branch. It should be called something like "here". The "detached HEAD" warning is scary and useless.
Just look at these two commands, which do very similar things but look totally different:
git checkout -b staging
git branch -f staging 3d1b582
git point staging here
git repoint staging 3d1b582I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…
You can check out multiple branches in different directories from a single git repo. This saves me a lot of what used to be stashing.
Earlier quoted context omitted.
What does the staging area has to do with tests?
When the workspace and the staging area aren’t in sync, the differences cannot be tested because the compiler doesn’t know how to deserialize the .git/index blob. The workspace is stored as normal source files, and committing those would be better.
What would be great is a simple way to have build/lint/etc. tools look at the staging area instead of the workspace.
Earlier quoted context omitted.
The poster is talking about when you do something like this: `git checkout .` That wipes out all unstaged changes on tracked files in the current directory
That's as unfortunate as 'rm *' (and good to be aware of BTW), but doing this deliberately doesn't qualify as "normal use" for me.
DESCRIPTION
Updates files in the working tree to match the version in the index or the specified tree. If no pathspec
was given, git checkout will also update HEAD to set the specified branch as the current branch.
Earlier quoted context omitted.
Look, we have spent the last ~ 20 years across HN and conferences and what not trying to teach git to people with basically nothing to show for it. Most developers still can't do much more than occasionally commit stuff. They still rm -rf their tree whenever something goes wrong. Your entire hate for SVN was branching takes a while(because it requires a round-trip to the server). SVN was easy to reason about, you did…
That is my point. The "teaching git" for most developers is not actually about git at all. What people don't understand is version control. The whole concept of a tree of branches in your repository and how they get merged into each other or branched off from each other does not change from SVN to git or vice versa. Maybe we have different experiences, but mine is that back in my SVN days, most devs were not able to…