Live data from Hacker News

A Hacker’s Guide to Git

wildlyinaccurate.com

31–40 of 120 posts

Re: A Hacker’s Guide to Git

#31

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface.

I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.

Re: A Hacker’s Guide to Git

#32

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?

Re: A Hacker’s Guide to Git

#33
post #26
post #24

Earlier quoted context omitted.

Git was originally created to manage the Linux kernel. It is indeed complex, but it has to be at that scale. Git might not be the best option for every project, but I find it quite easy to use at the trivial scale as well. (How do you beat 'git init' ? No repository setup or anything.)

I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.

As did Linux before Git, but Linus and the core team around him were finding the process getting too cumbersome and bottlenecked. Linus "scratched the itch" and produced git both specifically to fill that set of needs and with the intention of it being generally useful for other projects they were concerned with.

OpenBSD's kernel development is presumably run differently (IIRC there is a much smaller number of people trying to directly feed into it for a start, which was a key problem with Linux at least at the time Git was birthed) so processes and tools that fit their needs will look different. Either they haven't had enough trouble with the older tools/processes that the effort of an infrastructure change is worth sinking time into, or they have other concerns with the alternatives (security, as someone has mentioned above, and code maturity concerns may be involved, though the latter much less now as it has been pretty solid for some time), or maybe they intend to move but just haven't decided on an alternative yet.

Re: A Hacker’s Guide to Git

#34

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

What git gui do you recommend?

Atlassian SourceTree mainly. Git Extensions is also good if you need Visual Studio integration, though personally I find it visually a bit harsh.

Re: A Hacker’s Guide to Git

#35

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons:

1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details.

2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover all of them. This just confuses things for people who use GUI X when the guide only talks about GUI Y and Z.

3. It's much easier to write the guide using CLI examples. I wrote this over the weekend; I don't think I would have completed anywhere near as much of it if I had to keep taking screenshots, cropping them, uploading them, etc.

Besides, there are already plenty of other guides that talk about "how to use Git", "how to use GUI X to do Git feature Y". I wouldn't want to detract from the main goal of this guide which is to give people who are already comfortable with Git that extra push to "get" how Git models and interacts with your repository.

Re: A Hacker’s Guide to Git

#36

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

What git gui do you recommend?

I work much with Java and Eclipse, eGit is a good choice here.

I mostly use the history view and the staging view (which lets you add/remove files). For complicated tasks the history view is a very valuable tool which I even use when I prefer to do something on the command line.

Re: A Hacker’s Guide to Git

#37

Earlier quoted context omitted.

No. You mean it uses all (well nearly all) the width of the screen? I am pleased to see that for once rather than stuffing it into some narrow column, the width of which I would have complained about 10 years ago.

How big is your screen?

No so big that resizing a window when content is too wide for comfort stops working...

Less facetiously: I wish more pages would give me the choice rather than forcing the content into a fixed-width format unnecessarily, or if they don't mind the extra coding (especially if their design is well thought out enough to make it easy) have a fixed width setting by default with the option to turn it off (I've seen this done by giving the user the option flipping stylesheets via a control at the top of a page) like some support different font size and colour/contrast options.

Re: A Hacker’s Guide to Git

#38

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?

Visual Studio Git Tools in 2012 and 2013, and then Atlassian SourceTree for the stuff VS can't do (VS's integration is based on libgit2 and has limitations)

Re: A Hacker’s Guide to Git

#39
Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ?

(There is no necessarily a right answer, but I'd like to know what is more usual)

Re: A Hacker’s Guide to Git

#40
post #39

Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ? (There is no necessarily a right answer, but I'd like to know what is more usual)

Merge feature branches to a common dev branch then we branch off QA builds and RCs from there.
Post reply on HN