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

81–90 of 120 posts

Re: A Hacker’s Guide to Git

#81

Post by Crito »

ori_b wrote: post #78
stephengillie wrote: post #63

Earlier quoted context omitted.

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.

What?!? Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?

Going by the rest of this thread, I wouldn't rule out the possibility that they are doing something insane like committing multi-gigabyte objects regularly, and then only checking out with a low clone depth.

I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).

Re: A Hacker’s Guide to Git

#82

Post by outworlder »

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…

So,

- You have picked a new piece of technology

- You have no single person who understands it

- You expect it to work the same way the existing tech worked

- You don't have a backup system in place

- You imagine what the security settings should be for your specific use-case and then assume they are already in effect

- You switched to the new system before understanding it

I don't think software is the issue here.

[Edit: formatting]

Re: A Hacker’s Guide to Git

#83

Post by eddiedunn »

stephengillie wrote: post #67
eddiedunn wrote: post #55

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

1. When I set up Git on my Linux server only the user that initiated the repo had access to it. It was too locked down, seeing as external users didn't even have read/cloning permission. (A minimal amount of googling solved all my problems, though.) Your problem sounds to me as another PEBCAC on the part of your coworker.

2. I'm not making all the assumptions you claim. First of all, as soon as you clone a repo you have a local copy. You need this clone in order to be able to even work with the code, so it would be quite weird if employees deleted their clone after editing, committing, and pushing their changes. I'm not even sure what you mean with "mix it in with their code". It's a VCS -- if you don't like a change reverting it is trivial.

All in all, I understand why users might have problems with Git. It has a steep learning curve. I think it has a horrible command line UI. It might not have worked well for your company, even if you had a competent admin set up the repos. However, I would prefer if you could argue your point based on the actual merits and faults of Git, rather than based on ignorance.

Re: A Hacker’s Guide to Git

#84

Post by bleuarff »

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)

Every feature branch is pushed to the remote, with a pull request to merge into our integration branch.

Re: A Hacker’s Guide to Git

#85

Post by saosebastiao »

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 love the book, but their font colors for code/commands are terrible, almost to the point of unreadable. Most of time I give up on trying to see the impossibly light coloring.

Re: A Hacker’s Guide to Git

#86

Post by lloeki »

Every tutorial I read falls in two camps:

1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add)

2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

Both equally fail at making people get git.

Having explained git an inordinate number of times to various people, I started writing here all I ever needed to introduce people to git in a few minutes†, but it takes longer to write than to explain hands-on and face to face. I'll complete this and make a gist out of it.

† For varying definitions of "few" and possibly "minutes", but honestly much less than people make it sound about git being a horrendous, unlearnable, complex system with a broken UI. It's simple, it's brilliant, you just have to set the bar right in between 1. and 2. when teaching it.

Re: A Hacker’s Guide to Git

#87

Post by dahart »

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…

Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI.

But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were.

And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology.

Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.

Re: A Hacker’s Guide to Git

#89

Post by stephengillie »

ori_b wrote: post #78
stephengillie wrote: post #63

Earlier quoted context omitted.

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.

What?!? Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?

Before TFS, we didn't even have everything in Visual Source Safe.

Re: A Hacker’s Guide to Git

#90

Post by angersock »

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?

TortoiseGit is pretty decent, though it doesn't have VS integration.
Post reply on HN