Yeah, I guess I've got to leave it like that now..
thebestaquaman
Got will not delete untracked files though, which is what happened here. If you want to discard changes to a file with git, you first have to commit the file to the index at some point, which means there's only ever so much damage an erroneous "git restore" or "git reset" can do. Specifically, neither of them will delete all the files in an existing project where VC has just been added.
If you have set up your staging area for a commit you may want to discard (unstage) changes from the staging area, as opposed to discarding changes in the working directory.
Of course, the difference between the two is obvious if you're using git CLI, but I can easily see someone using a GUI (and that maybe isn't too familiar with git) misunderstanding "discard" as "unstage".
Either way, what happened here indicates that all the files were somehow added to the VC, without having been committed first, or something like that, because git will not let you discard a file that is untracked, because that wouldn't make any sense. The fact that the GUI let this person delete a bunch of files without first committing them to the index is what makes this a terrible design choice, and also what makes the use of the word "discard" misleading.
I use gitkraken for two primary purposes:
-
Having a visual representation of my project history.
-
resolving merge conflicts
Of these, the first is really the only thing I really want a GUI for. I'll just have it open on my side-screen if I'm managing some more or less messy branch structure or quickly want an overview of what has been done on which branches, where common ancestors are, etc. All the actual doing of things is done from the CLI, because it's just better for that.
Keeping the kids safe!
Absolutely! I remember going from "holy shit this guy is terrifying and we have video evidence of him being able to kick ass" to "what the fuck? These not-as-terrifying looking people are messing him up bad!"
There's a lot of good advice here already, especially that wool is the gold standard - nothing synthetic cuts it. I want to add that the absolute key is about layering, and not over-stuffing.
What keeps you warm is primarily the air trapped between your layers, which means that three thin layers can be a lot better than one thick layer. This also means that you will be freezing if your layers are too tight. If you have two thin layers, and put on a sweater, and that sweater feels tight, that likely means you're pushing out the air trapped in your inner layers, and they won't be as effective. The same applies when putting on a jacket.
So: You want a thin base layer (think light, thin wool shirt + long johns), then an optional medium layer or two (slightly thicker wool shirt, I have some in the range of 200 grams), and finally a thicker sweater for when you're not moving. These should increase in size so that they can fit the thinner layers underneath, and you want your jacket big enough to fit all the underlying layers.
Finally: When you're moving around, you will get stupidly warm and sweaty unless you take off clothes. It's better to take off some stuff and be a bit cold for the first 10 minutes of moving than to get sweaty and be cold for the rest of the day. If (when) you do get cold, running in a circle for 10 min will fix it (run at a calm, steady pace, if you're really cold it might take longer to get warm than you think, but you will get warm if you move).
In short: Being in a cold climate is just as much about how you use your equipment, and how you activate yourself to stay warm, as it is about what equipment you have.
Watch me: My void*
doesn't give a shit about your const
!
I have to be honest in that, while I think duck typing should be embraced, I have a hard time seeing how people are actually able to deal with large-scale pure Python projects, just because of the dynamic typing. To me, it makes reading code so much more difficult when I can't just look at a function and immediately see the types involved.
Because of this, I also have a small hangup with examples in some C++ libraries that use auto
. Like sure, I'm happy to use auto
when writing code, but when reading an example I would very much like to immediately be able to know what the return type of a function is. In general, I think the use of auto
should be restricted to cases where it increases readability, and not used as a lazy way out of writing out the types, which I think is one of the benefits of C++ vs. Python in large projects.
Nah, but the Russians took massive losses at some point last year (I seem to remember) because the Ukrainians launched a bunch of mines behind an attacking column, so that when the column was beaten back, they ran straight into a newly placed mine field.
My impression is that remote mining is used for two purposes: Defensively, you can break up or slow down an advance by suddenly laying mines either in front of, in the middle of, or behind, an advancing column (the latter preventing reinforcements from arriving, or the attacking force from an orderly retreat). Offensively, you can use remote mine laying to cover the flanks of an advancing force, or prevent reinforcements from reaching a position you're attacking.
Fair enough, git clean does exist. However, if the button saying "discard all changes" is really a button that runs
git clean
, that's just a plain terrible design choice.git clean
is "delete all untracked files", which is specifically not discarding changes, because there can be no changes to discard on an untracked file. Even talking about "changes" to an untracked file in VC context makes little sense, because the VC system doesn't know anything about any changes to the file, only whether it exists or not.That's not even mentioning the fact that the option to "git clean" shows up as one of the easily accessible options in relation to a staging process. Especially if you're coming from the git CLI, you're likely to associate "discard changes" with "git restore".