no i dont have 15 minutes
Got 15 minutes and want to learn Git?
151–160 of 178 posts
Re: Got 15 minutes and want to learn Git?
#152Earlier quoted context omitted.
> If a certain set of tools are making you dumber by the day How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way? > know it for sure that it will be automated or you will be replaced by lesser skilled cheap l…
You are taking it personally. >>How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way? Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any t…
> Complaining about command line's usability being difficult is same as complaining about an Airplane's cockpit.
The cockpit is an interface (a GUI even) tailored for flying. The command line is an interface tailored mainly for administration and automation with a focus on text and files. A broom is tailored for cleaning the office and I use it when I have to. But what does this all have to do with what a programmer generally should be able to do?
I know the stereotype of the dumb Java/Eclipse programmer that apparently upsets you, and they certainly don't embrace the command line. But please, that does not imply that hating the command line turns one into a worse programmer.
> You are taking it personally.
(Not me, but:) You jump from not being comfortable with the command to getting dumber by the day, then eventually being obsolete. It's not really hard to read some elitism into that. Same for:
> A tool like git is not designed to be a toy or recreation software.
> Therefore it is designed to cover features in that direction, for programmers. Not for your ordinary user ...
Re: Got 15 minutes and want to learn Git?
#153Earlier quoted context omitted.
I feel like there's not much point in any sort of VCS lesson if it doesn't go over the more complex areas though. For example, reverting commits and resetting to earlier points in history are pretty essential actions, but both have their subtleties in Git (e.g why reverting a merge is hard, what 'reset' vs 'checkout' do) that will bite you if you don't know what you're doing. And everyone's fucked up via git rebase a…
Sorry, maybe I've just been using Git for long enough not to remember the pain, but can you explain "why reverting a merge is hard"? Yeah, the Git command `revert` has a bunch of kind of esoteric flags, but once you understand that it can stomp on your working dir and/or your index, it's not that hard to use. I don't know what about reverting to a point prior to a merge would be difficult, unless you are in the middl…
Reverting a merge with git revert is not hard but it is dangerous since if you want to merge the same branch later it will not merge the commit in the merged branch at the time of the reverted merge. You have to remember to revert the revert before attempting to merge again.
Re: Got 15 minutes and want to learn Git?
#154Earlier quoted context omitted.
I figured out Git, and I'm not that clever, so don't worry! The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time. `git commit` means "turn the contents of the index into a commit". A commit is a set of changes that…
That doesn't explain the fundamental part. Why is there a staging area in the first place? Place yourself in the shoes of a subversion user, the workflow is very simple and intuitive given that: 1. the repository is a (remote) place where my project is stored 2. the local copy is where I modify my project Then, a commit is just pushing your modifications to the repository where other people can go get them. Now, with…
There's a good reason that developers love git, it helps to organise code for _themselves_. Centralised VCSs are there to help you share your code with _other_ people.
Here's some problems I encounter everyday that git solves and SVN for instance doesn't.
1) I've been working on a feature since this morning but now there's a bug in production. I need to drop what I'm doing and come back to it when the bug is fixed.
2) I've implemented a feature but before I share it I want do some refactoring to clean it up. If I break something during the refactoring I want to be able to get back to the version that was working.
3) I'm working on integrating an old web API (SOAP hell) and I want to make a note of the workaround which is spread across several files. My tests aren't passing yet though so I don't want to share any code yet.
These are some examples of scenarios where git fits with _your_ workflow. This is where git really shines, not in the sharing of code (where it does also improve on SVN), but the ways in which it allows you to organise the pieces of code you're working on throughout your day.
Re: Got 15 minutes and want to learn Git?
#155NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I tried out this tutorial. I'm doing my best to describe my confusion. I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself. So, I added octocat.txt to my staging area. Success! ...…
This is the best intro I've read to get the concepts of distributed version control: http://hginit.com/
It's specific to Mercurial, but git is very similar. If it's the overall concepts that are giving you trouble, that should be effective in removing those blocks.
Re: Got 15 minutes and want to learn Git?
#156Earlier quoted context omitted.
In a nutshell... a project can be described in terms of the changes a user makes over time. In Git, these changes are called "commits". Commits contain a change a user has made to the code and some additional useful metadata. This metadata includes the time the change was made, the user's name, a message to describe in general terms what the change was (that -m thing), and so on. Git itself is a database that stores…
Again, this is a gross oversimplification that describes only generic version control concepts and none of the powerful features that . Go ahead and try explaining a rebase without trying to broach the concepts of time travel. How about why having a local copy of all commits/branches/etc related to the repository is helpful, or even at all possible, without relating it to a simpler client/server version control syste…
The core concept of Git is simple. All its more complex features can be derived from the idea that Git is a database of commits (changes + metadata).
A rebase is the act of changing the parent, or base, of a commit. So instead of a change being made to version A, you make the same change to version B. No time travel metaphors need to be involved, and IMO only complicate a very simple concept.
The harder part is explaining why you'd want a rebase.
Re: Got 15 minutes and want to learn Git?
#157Earlier quoted context omitted.
Pssst, Linux+Chromium.
BTW, people aren't downvoting you because of your convictions as you seem to think according to your profile. They're downvoting you for a complete lack of contribution to the comment thread. That's why people downvote on Hacker News.
>That's why people downvote on Hacker News.
While it certainly isn't as bad as some other sites, I think it is naive to suggest that nobody has ever been downvoted on HN for having an unpopular opinion.
Re: Got 15 minutes and want to learn Git?
#158Earlier quoted context omitted.
Well, suit yourself. It's just a tremendously useful skill to have. Makes it a bit less of a hassle to ssh into the odd server to check the logs, or dump a database, or use tools that don't have a GUI. I mean, fundamentally, you're typing things to a computer and then the computer does what you typed. Why should that notion be uncomfortable to a programmer of all people?
Oh, I can use the terminal, I can also theoretically write PHP, and every vim user can theoretically use Eclipse. But that doesn't mean that any of us would be comfortable with it - we'd all be anxious and focused on the tool (instead of the problem at hand) not to break stuff left and right.
What kind of argument is that? How can you ever learn anything new with this attitude? If you never leave your comfort zone you will never make any progress. Just do it.
Re: Got 15 minutes and want to learn Git?
#159NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I tried out this tutorial. I'm doing my best to describe my confusion. I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself. So, I added octocat.txt to my staging area. Success! ...…
Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO. This is a common problem in teaching, technical writing, and other forms of technical instruction. Even when a good teacher or writer sets out to deliver material to total beginners, it's very tricky to truly enter th…
This isn't necessarily a problem. I can learn by immersion.
Good teaching shouldn't introduce too many concepts at one time, but giving incremental goals that require interacting with a few related concepts is ideal. Tediously spelling out all the details is good for a spec, but would hurt interest and motivation.
Re: Got 15 minutes and want to learn Git?
#160Very slick, but also very slow. Occasionally I have to run a command twice for it to register. Also, it's strange that git's output isn't colorized, considering the "Success!" messages are.
All the commands are implemented on the remote end (hence the latency), and some of them look like they are a limited node.js reimplementation (git is mostly the real deal, though the command list is whitelisted). I would be interested in a version that runs locally in JS/Linux.