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

61–70 of 120 posts

Re: A Hacker’s Guide to Git

#61

Post by grannyg00se »

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…

Try this http://pcottle.github.io/learnGitBranching/?NODEMO

It's command line, but it's interactive and visual.

Start off by typing the command `levels` into the prompt at the bottom left.

Re: A Hacker’s Guide to Git

#62

Post by ansible »

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…

What backup? You mean we have to manually back up this system?

I am aghast at hearing you say this. Yes, of course you have to run backups. Like with everything else important on your systems.

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?

You don't have to spend 'hours' backing up a git repository. We typically use a bare git repo for the central point that is pushed to / pulled from by the individual developers. It is just a bunch of files, and so can be backed up easily.

You really don't sound like you know what you are doing.

I suggest you hire an experience system administrator (not just another devops) that understands the importance of backups.

Re: A Hacker’s Guide to Git

#63

Post by stephengillie »

aeon10 wrote: post #51
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…

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

Everyone else only has a full copy of the repository if they actually check out a copy and keep it local. That's apparently not how my coders do their workflow.

Re: A Hacker’s Guide to Git

#64

Post by ethomson »

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…

I understand your gripe (though I don't agree with it; TFS comes out of the box with permissions that only allow administrators to force push in a way that rewrites history, but more importantly, this data was never lost, you would only need to look in the reference log to find this), but surely you're not seriously suggesting that one not backup their TFS server? Please do back that up, even if you're using TFVC moving forward!

Re: A Hacker’s Guide to Git

#66

Post by thomaslangston »

mistermann wrote: post #32
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…

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?

Sourcetree has been my favorite, followed by the default GUI installed from the git-scm.com. I've not been a fan of the VS extension because of performance (a want NCrunch and Resharper to have all my free cycles).

Re: A Hacker’s Guide to Git

#67

Post by stephengillie »

eddiedunn wrote: post #55
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…

1. Some of this does look like ignorance on the part of my coworker who set up both. But why isn't that a default setting? Why give that permission to all users?

2. This is true only if other users keep local copies of the main repository, keep it updated, and don't mix it in with their code. You're making a lot of assumptions.

Re: A Hacker’s Guide to Git

#68

Post by peterwwillis »

stephengillie wrote: post #58
pyre wrote: post #56

Earlier quoted context omitted.

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.

"Backup" is not a component of revision control software. If one has such 'backup functions' they're just window dressing.

What you must be talking about (well, I hope anyway) is the capability of a revision control system to be backed up on the fly, similar to the tools used to backup a live subversion repo without causing corruption. Git has such functionality; simply do a fetch from a remote repo, then backup the result.

If you're expecting revision control systems to include some sort of "backup suite", sorry, this is *NIX, not Microsoft. The tools do a particular job and it's up to you to plug that into your infrastructure, including your pre-existing backup infrastructure, which i'm sure your company must have. It would be laughable if they didn't have backup infrastructure already.

Re: A Hacker’s Guide to Git

#69

Post by jammycakes »

nahname wrote: post #48
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?

The thought has occurred to me. Just never got round to it, that's all...

Re: A Hacker’s Guide to Git

#70

Post by lloeki »

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…

> Also if you do wipe your repository, restore it form your backup.

Git is distributed. The "backup"† is another dev doing a git push -f. Also, git reflog. The argument just does not hold water. (Also, do backup your VCS server anyway.)

If you want to keep rogue devs in check, set up a Gitlab instance, and use protected branches and merge requests.

† Read me correctly, it's not a backup, it's just part of the resiliency of git. Proper backups should be made il all cases.

Post reply on HN