Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

201–210 of 273 posts

Re: How to teach Git

#201

Post by MisterOctober »

ahartmetz wrote: post #60

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. [...]"

Brilliant, absolutely had me rolling. Most cleverly-executed satire I've seen in a long while.

"To parse a staged SKIRT_SUBTREE and blame the working histories, use the command git-purchase-pack --snuggle-muster-branch, as after reapplying subtrees..."

Re: How to teach Git

#202

Post by dahart »

spurgu wrote: post #184
pjmlp wrote: post #25

Earlier quoted context omitted.

Which happens to be the only option on future car driving technologies.

Not sure whether your statement is ignorant or insightful. Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic i…

> Not sure whether your statement is ignorant or insightful

I’ll answer that for you. It’s insightful.

In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already.

https://www.chicagotribune.com/classified/automotive/sc-auto...

I didn’t understand why you said there will always need to be manuals for vehicles that run on gas... what do you mean?

Re: How to teach Git

#203

Post by virtualwhys »

ahartmetz wrote: post #60

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. [...]"

Please note[1] that:

> To rev-parse an automatic FLOUNDER_LOG or diff the working subtrees, use the command git-link-submodule --retrieve-wrestle-change.

I often overlook this detail when trying to hulk smash some broken change I've made upstream (what the manual entry correctly refers to as RIP_OTHER_TIP).

[1] https://git-man-page-generator.lokaltog.net/#81394c8bf3806f9...

Re: How to teach Git

#204

Post by u801e »

Stratoscope wrote: post #189
hoorayimhelping wrote: post #79

Earlier quoted context omitted.

git config --global alias.lg "log --color --graph --oneline --decorate" for easy copy-pasting. HN doesn't support backticks or triple backticks like a lot of markdown parsers. To get fixed-width fonts, you have to insert 4 paces at the beginning of the 'code' block.

Two spaces (unlike Markdown). Of course four will work, it just adds more indentation.

In some mobile browsers, doing this will result in the fixed-width font line getting cut off when viewing the resulting post.

Re: How to teach Git

#205

Post by u801e »

url00 wrote: post #69
aurumpotest wrote: post #36

Earlier quoted context omitted.

I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.

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?

One use case is to exclude extra lines of the file you don't want to commit. For example, I might have some debug print statements in my file that I want to keep in my local copy of the file while testing, but I don't want to include in the commit I push up for review.

Re: How to teach Git

#206

Post by u801e »

Someone wrote: post #194
acemarke wrote: post #86

Earlier quoted context omitted.

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…

But then, you either never run/tested those smaller individual commits, or you have to do extra work (stash changes, test, restore stash) to do that. 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 st…

> But then, you either never run/tested those smaller individual commits

Not necessarily. One nice option that the git rebase command has is --exec (which can be specified multiple times). So you can run a rebase and have git execute a command (like running a test suite) for each commit in the branch. If any commit files, the rebase process will stop and let you amend the commit to fix the issue.

> or you have to do extra work (stash changes, test, restore stash) to do that.

I've found that it's easier to write and locally test a given feature and them incrementally stage parts of it and create commits before pushing the code up for review. To me, that's easier than just making a large commit and then trying to split it out into a better set of commits after the fact.

For example, I may write a new method and then call it several places in the code. So my first commit would be to add the new method along with its unit tests and my second commit would be to add calls to it in the code base and update the associated integration tests (if necessary).

Re: How to teach Git

#207

Post by [deleted] »

avar wrote: post #43

I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.

[deleted]

Re: How to teach Git

#208

Post by malingo »

svat wrote: post #146
iheartpotatoes wrote: post #106

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....)

My recommendations: * Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf ) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/ ) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc. * Learn Git Branching: https://learngitbranching.j…

I'd also recommend http://matthew-brett.github.io/pydagogue/rebase_without_tear...

Re: How to teach Git

#209

Post by saagarjha »

y4mi wrote: post #200
saagarjha wrote: post #178

Earlier quoted context omitted.

Virtualizing macOS on a macOS host is allowed, and I think QEMU will let you do this.

There wording was iirc "you're allowed to run one instance of Mac OS per Apple chipset." 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.

Here's the phrasing for macOS Mojave:

If you obtained a license for the Apple Software from the Mac App Store or through an automatic download, then subject to the terms and conditions of this License and as permitted by the Services and Content Usage Rules set forth in the Apple Media Services Terms and Conditions (https://www.apple.com/legal/internet-services/itunes/) (“Usage Rules”), you are granted a limited, non-transferable, non-exclusive license:

(i) to download, install, use and run for personal, non-commercial use, one (1) copy of the Apple Software directly on each Apple-branded computer running macOS High Sierra, macOS Sierra, OS X El Capitan, OS X Yosemite, OS X Mavericks, OS X Mountain Lion or OS X Lion (“Mac Computer”) that you own or control;

(ii) If you are a commercial enterprise or educational institution, to download, install, use and run one (1) copy of the Apple Software for use either: (a) by a single individual on each of the Mac Computer(s) that you own or control, or (b) by multiple individuals on a single shared Mac Computer that you own or control. For example, a single employee may use the Apple Software on both the employee’s desktop Mac Computer and laptop Mac Computer, or multiple students may serially use the Apple Software on a single Mac Computer located at a resource center or library; and

(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.

Re: How to teach Git

#210

Post by zbentley »

yjftsjthsd-h wrote: post #181
mcguire wrote: post #107

Earlier quoted context omitted.

... because none of the power users used them.

Heh. I think Linux on desktop it is like that, at least a bit; frequently, by the time someone could write a friendly GUI (or friendly CLI for that matter), they have little use for it.

That's a disturbingly insightful parable for everything from startups to linux/FOSS contributions.
Post reply on HN