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?!
A Hacker’s Guide to Git
71–80 of 120 posts
Re: A Hacker’s Guide to Git
#72Earlier quoted context omitted.
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.
If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
Re: A Hacker’s Guide to Git
#73Earlier quoted context omitted.
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.
The most usual way to work with git is to pull a local copy of the whole server using "git clone"[1]. The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
Re: A Hacker’s Guide to Git
#74Re: A Hacker’s Guide to Git
#75Earlier quoted context omitted.
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?
I'm saying that "doesn't solve my problems" != "a piece of 'git'"
Re: A Hacker’s Guide to Git
#76Earlier quoted context omitted.
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…
I've seen a company with contracts guaranteeing 100% uptime, while running things off of a single MS server with no backups. It's entirely possible for software companies to be this stupid.
Re: A Hacker’s Guide to Git
#77Earlier 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.
> It's like a RAID-5 where you have to tell it to rebuild a new disk.
Well, you do have to give it a new disk first, right? Or do you expect the RAID-5 array to automate the process of purchasing and installing a replacement disk?
Re: A Hacker’s Guide to Git
#78Earlier quoted context omitted.
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.
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?
Re: A Hacker’s Guide to Git
#79Earlier 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?
> Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control?
You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
Re: A Hacker’s Guide to Git
#80Earlier quoted context omitted.
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
Ah, I forgot that step.
They moved to a DVCS to solve some of the workflow issues, then Linus created git in large part because of the licensing issues.
Another detail missed in my previous post: If I remember rightly there were a couple of F/OSS DVCS's in development at the time, but he chose to write his own as some of them were not yet near stable and the others didn't quite work the way he wanted. I dimly recall some criticism for choosing a commercial product prior to git, and that decision was for much the same reasons git was created instead of using one of the other available options.