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

51–60 of 120 posts

Re: A Hacker’s Guide to Git

#51

Post by aeon10 »

stephengillie wrote: post #50
orkoden wrote: post #47

Earlier quoted context omitted.

>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…

git is a distributed system. Everyone else has a full copy of the repository. therefore everyone actually has a backup.

Re: A Hacker’s Guide to Git

#53

Post by pyre »

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…

This:

> This solution doesn't our solve problems in our situation.

is a far cry from:

> Many of my coworkers feel it's a "piece of Git" (if you get my expletive).

Just sayin'. It's the same attitude that once caused an obnoxious movie-goer to get all hot and bothered (yelling at the screen, trying to explain it to his date, etc) over seeing a Mac on-screen because "it would have gone a lot faster if he was using a PC."

Re: A Hacker’s Guide to Git

#55

Post by eddiedunn »

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.

What?

1) You can configure your repo so only select users may use destructive commands on certain branches.

2) It's a _distributed_ content versioning system. Even if someone wiped out the main, "central", repository, all users will have a full local copy, a backup in effect.

Git has a horrible UI in many ways, but your apparent dislike of it smells more of incompetence and a naive buy-in of the full Microsoft ecosystem than anything else.

BTW, I didn't know what TFS was before checking on Wikipedia, but -- somewhat ironcially given your gripe -- TFS seems to have decent support for Git[1].

[1]: https://en.wikipedia.org/wiki/Team_Foundation_Server#Git

[EDIT]: formatting

Re: A Hacker’s Guide to Git

#56

Post by pyre »

stephengillie wrote: post #50
orkoden wrote: post #47

Earlier quoted context omitted.

>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…

Are you telling me that you don't backup anything? You just expect the version control system to (e.g.) magically recover itself from a hardware failure on your server?

It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.

Re: A Hacker’s Guide to Git

#57

Post by peterwwillis »

NDizzle wrote: post #54

Try not to take this as snark, but aren't hackers early adopters that do things on their own? What's the point of a hackers guide to a thing that has been a thing for years?!

I was writing something almost identical to this recently, for the general public but also for my co-workers who don't seem to understand the internals of Git at all. I'm sick of being "the Git guy" so this should help a lot.

Re: A Hacker’s Guide to Git

#58

Post by stephengillie »

pyre wrote: post #56
stephengillie wrote: post #50

Earlier quoted context omitted.

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…

Are you telling me that you don't backup anything? You just expect the version control system to (e.g.) magically recover itself from a hardware failure on your server? It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.

It's a version control system that doesn't include backup functions? It's like a RAID-5 where you have to tell it to rebuild a new disk.

Re: A Hacker’s Guide to Git

#59

Post by thomaslangston »

wldlyinaccurate wrote: post #35
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…

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…

Thanks for posting this guide. I hope to read it soon. Some thoughts on your response:

1) Sometimes the GUI illuminates and the console obfuscates. Logs and history are a lot easier for developers to understand in my experience from a GUI.

2) I'd suggest only using the included GIT GUI that comes with the download from git-scm.com. It is simple enough that it should map easily to another GUI, plus if they aren't using an embedded git everyone should already have it installed.

Re: A Hacker’s Guide to Git

#60

Post by stephengillie »

pyre wrote: post #53
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…

This: > This solution doesn't our solve problems in our situation. is a far cry from: > Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Just sayin'. It's the same attitude that once caused an obnoxious movie-goer to get all hot and bothered (yelling at the screen, trying to explain it to his date, etc) over seeing a Mac on-screen because "it would have gone a lot faster if he was using a PC…

What are you just saying? I used both of those statements in the same paragraph to express my sentiment.

And some anecdote about some movie-goer being upset in front of his date? Are you accusing me of fanboyism for saying one solution didn't solve my team's problem, while the other does?

Post reply on HN