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

A Hacker’s Guide to Git

wildlyinaccurate.com

Post reply on HN
Print view View original

41–50 of 120 posts

Re: A Hacker’s Guide to Git

#41

Post by scotch_drinker »

anton_gogolev wrote: post #3

How many more tutorials on Git do we need? It's like article authors find it a "rite of passage" of sorts to explain Content-Addressable Storage, references and all kinds of whacky command-line keys.

"We" don't need any Git tutorials. We could read the documentation But perhaps people don't write solely because of the audience's need. Writing a tutorial is the fastest way to ensure you more fully understand the subject. It is in fact a rite of passage in any topic when you can explain it to an audience with less understanding. Tutorials don't just serve the audience.

Re: A Hacker’s Guide to Git

#42

Post by jimktrains2 »

seren wrote: 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)

Push the feature branch if they existed for more than a day or so. They would be cleaned up by the merger/pull request verifier once in master.

Re: A Hacker’s Guide to Git

#43

Post by MattBearman »

jammycakes wrote: post #28

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…

I had the opposite experience - coming from tortoise SVN, I tried a few GUIs for Git, but I never really got to grips with git until I started using the command line, and now I can't imagine going back to a GUI.

Re: A Hacker’s Guide to Git

#44

Post by woadwarrior01 »

dspillett wrote: post #33
ams6110 wrote: post #26

Earlier quoted context omitted.

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…

Linux was using BitKeeper, a commercial DVCS. The raison d'etre for git was because the company behind BitKeeper revoked the license for the Linux guys to use it. http://en.wikipedia.org/wiki/BitKeeper

Re: A Hacker’s Guide to Git

#45

Post by stephengillie »

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.

We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe it's because we use MS technologies (IIS, .NET, MSSQL) but we were on TFS in a matter of weeks while Git still confused us after a month of use.

Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Several also think it's a waste of time. I don't disagree with them. I supported Git because I saw it on here. This solution doesn't our solve problems in our situation.

Re: A Hacker’s Guide to Git

#47

Post by orkoden »

stephengillie wrote: post #45

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe…

>We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.

You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.

Re: A Hacker’s Guide to Git

#48

Post by nahname »

jammycakes wrote: post #28

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…

Why not write one?

Re: A Hacker’s Guide to Git

#49

Post by mschaef »

collyw wrote: post #19
EinLama wrote: post #2

I'd recommend another guide. "Pro Git" by Scott Chacon is excellent and welcomes patches, source for the book and its translations are on GitHub http://www.git-scm.com/book

I appreciate that git is powerful, but should we really need to read a book just to get the best from a source control system? It seems overly complex to me at times (any time I do anything outside of my usual workflow). Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.

How do you expect things to work? This expectation that complex tools should be so obvious that they can be used without a book seems pretty odd to me. There aren't many other serious engineering disciplines where people enter it with that kind of mindset.

The source code for a system is one of the more valuable assets produced by a software development team, and managing source code is heavily about managing risk. Losing source code means losing work (money and time). Deploying source code too early means exposing the users of your system to code that might not be adequately tested. In distributed development, accepting unsigned patches means that your system might include untrustworthy code... the list goes on and on.

Part of the reason that git is complex (and this can be said about any serious source code management system) is that it solves complex problems. Fifteen years ago, Jamie Zawinski said this about Mozilla... I think it's also true for git:

"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. "

-- http://www.jwz.org/doc/easter-eggs.html

Re: A Hacker’s Guide to Git

#50

Post by stephengillie »

orkoden wrote: post #47
stephengillie wrote: post #45

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe…

>We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.

What backup? You mean we have to manually back up this system? Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source?

EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.

Post reply on HN