191–200 of 273 posts
Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".
Earlier quoted context omitted.
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.
The way to teach these tools is to make them primary citizens in your company culture. Emphasize that, without a strong grasp on a variety of important tools, devs will be unable to perform at or above the bar. Don't promote anyone to "senior" engineer who can't easily show the benefits of these tools while a junior engineer pairs with them.
Otherwise, developers will teach themselves the absolute bare minimum necessary to get their jobs done and go home. The quality of the training materials is of minimal importance. I learned git because I wanted to be better at it.
Earlier quoted context omitted.
This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?
Partly, yes. Or, I'll be working on a task overall, and have to touch multiple files in the process. Then when I'm ready to commit, I review all the modified files on disk, and look for ways to break those down into smaller discrete logical changes. I prefer to avoid "big bang" commits as much as possible, because smaller individual commits are easier to inspect, easier to back out if necessary, and provide a better…
I do not see why a source control system should make it easier to make a commit that hasn’t ever existed on disk and thus cannot have been tested.
I think the better model would be to stash your changes and have an diff editor between the on-disk working copy and the stashed version that allows you to commit a set of changes as several smaller, more coherent commits.
That wouldn’t guarantee that each of those intermediate commits gets tested or even built, but it would guarantee that each smaller commit is in the on-disk copy at some time.
I think the best thing you could do for novices is to avoid priming them with preconceptions of Git being difficult. Psyching people up before instructing them never seems to do people any good, yet it's very common.
I agree with this. For many people who are learning Git for the first time, it's also their first experience with contributing code to a repository at all. The last thing you want to do is turn them off entirely, or gatekeep the profession to exclude people who aren't good at reading dense documentation. The best way to teach git is to get them comfortable with "Add, Commit, and Push" and then explain what's happenin…
Maybe if somebody has already mastered subversion then git will confuse them a lot, but I'm not convinced even that is necessarily true. Regardless, it seems clear to me that novice users shouldn't be told that git is complicated.
This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)
SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well. Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge. Visual Studio Code built in git functionality is also nice.
[1] https://inst.eecs.berkeley.edu/~cs61b/fa17/materials/proj/pr...
Earlier quoted context omitted.
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
Committing isn't a commitment. After making the first commit, you can use the `git stash` command to put the rest of your changes aside, and go through the normal test->amend loop until you're happy with that first commit. Then you just retrieve your other changes from the stash to make your second commit. It's also possible to do this without the stash command, by making both commits right away, and testing them lat…
The git stash man page talks about this: https://git-scm.com/docs/git-stash
“If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms.”
One of the best things about git is how big the safety net is, as long as you tell git about your changes. Almost any mistake can be fixed, so why use features that aren’t sitting over the safety net?
And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”).Earlier quoted context omitted.
You're pinning THAT on opensource? a) VirtualBox is an oracle product. That by itself should be telling. b) High sierra is unsupported as a Guest OS in VirtualBox. You do know what that means, right? c) You seriously complain about the darth of open source virtualization for an OS, which disallows virtualization on anything but apple hardware? ...really? If you want good open source virtualization you'll want to use…
Virtualizing macOS on a macOS host is allowed, and I think QEMU will let you do this.
So, virtualization is technically only allowed if you're running your apple hardware with anything besides Mac OS.
But apple isn't enforcing that limitation, as products like VMware fusion on Mac OS are (at least as far as I can tell) officially sanctioned.