×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linus on GIT and SCM

kdawson posted more than 6 years ago | from the strong-opinions dept.

Software 392

An anonymous reader sends us to a blog posting (with the YouTube video embedded) about Linus Torvalds' talk at Google a few weeks back. Linus talked about developing GIT, the source control system used by the Linux kernel developers, and exhibited his characteristic strong opinions on subjects around SCM, by which he means "Source Code Management." SCM is a subject that coders are either passionate about or bored by. Linus appears to be in the former camp. Here is his take on Subversion: "Subversion has been the most pointless project ever started... Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

392 comments

git (-1, Flamebait)

chriscappuccio (80696) | more than 6 years ago | (#19367641)

git is a piece of shit, pure and simple.

Re:git (1)

koreth (409849) | more than 6 years ago | (#19367683)

And we should trust your unsupported assertion more than the educated opinion of the originator and head of one of the most successful large software projects in history because...?

Re:git (5, Interesting)

Anonymous Coward | more than 6 years ago | (#19367765)

He is only human. Just because he is the head of a huge software project doesn't make him infallible.

Just look at the whole 'RMS vs Linus' thing.

His opinions should carry some weight, especially since he should know more than anyone what the limitations of SCM software is when it comes to larger projects like the linux kernel. But a lot of SCM comes down to the way a project is managed, the preferences of the people involved, and how they deal with their project. I doubt there is a blanket solution... a 'one SCM package to rule them all' so to speak.

Especially in the software industry you can always find someone just as good as yourself that strongly holds opinions that are the polar opposite of yours.

Re:git (0, Funny)

Anonymous Coward | more than 6 years ago | (#19367885)

your mom is infallible

Re:git (1, Informative)

Anonymous Coward | more than 6 years ago | (#19367915)

Linus's position as Linus kernel project leader may make him knowledgable about what makes a good source control system for Linux's distributed development model, but if he thinks that one size fits all for source control then he's definitely talking out of his ass and out of his area of expertise.

Re:git (0)

Anonymous Coward | more than 6 years ago | (#19368015)

Linus often talks out of his ass about many things out of his area of expertise, including operating systems. \

Re:git (0, Funny)

Anonymous Coward | more than 6 years ago | (#19367889)

Shut the fuck up you scmbag git.

Linus knows it. (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#19367657)

Of course CVS sucks. And yes, Subversion does suck. GIT beats them hands down.

Linus has it right (as usual). No surprise here.

Re:Linus knows it. (1, Informative)

statusbar (314703) | more than 6 years ago | (#19367843)

I personally like how git has excellent Microsoft Windows support... It makes it a great tool for use with Altium PCB design software [altium.com] because of the handy svn->git compatibility tools that git has for windows. It allows all people in the enterprise to use git, regardless of the platform that they use.

Most definitely bettern than SVN, right? ;-)

--jeffk++

Re:Linus knows it. (4, Informative)

CastrTroy (595695) | more than 6 years ago | (#19367977)

You might want to check out TortoiseSVN if you're using svn on windows. It makes version control really easy, and you don't even have to touch the command line.

Re:Linus knows it. (4, Informative)

statusbar (314703) | more than 6 years ago | (#19368043)

I use SVN on windows, mac os x, linux (ubuntu, debian, fedora) as well as netbsd. TortoiseSVN works great on windows especially for the point and click style users who need to use SCM. SvnX works great on Mac OS X. Altium PCB designer works great with the svn command line tools and shows graphical diffs of our circuit boards. But for some reason, Tortoise SVN and svn.exe are unable to access a GIT repositiory.

In addition, git works well for simple projects but not so well for projects that have many different related subprojects which share code.

  For instance, our SVN repository holds everything needed for an entire product, including embedded linux with busybox, initrd and custom software and libraries - as well as DSP source code for two different add on cards, the GUI for mac, windows, and linux, the docutils xml file for the various manuals, and manufacturing and test code.

I'd love to use git once it attains the required maturity level so that I can do what I need with it.

--jeffk++

Re:Linus knows it. (1)

ari_j (90255) | more than 6 years ago | (#19368363)

Have you found one that does handle subprojects well? I use darcs [abridgegame.org] for most everything nowadays, but I'm always open to new ideas.

Merging *does* suck (0, Insightful)

Anonymous Coward | more than 6 years ago | (#19367691)

So don't do it.

It's always done late in a development cycle, in the rush to get the project out the door.

So don't branch, and DON'T allow concurrent checkout of any code - FORCE the DEVELOPERS who need to work on the same code to COORDINATE their work EARLY in the development cycle. Of course they'll bitch.

But so what. Developers always bitch when you make them do things right.

And you make the programmers coordinate their work properly and early by not branching, and not allowing concurrent checkout of the same file. In Subversion, you lock the file, and if anyone breaks the lock they get a very public visit from the lead developer asking why.

It works, too. You won't have any merge surprises two weeks from ship date.

If your technical leadership has the spine to show prima donna twits who won't follow development rules the door. Of the entire company.

Re:Merging *does* suck (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19367705)

Wow, that's the worst idea I've ever heard

Re:Merging *does* suck (0)

Anonymous Coward | more than 6 years ago | (#19367911)

Wow, that's the worst idea I've ever heard

Worse than, say, setting yourself on fire?

Re:Merging *does* suck (3, Insightful)

Anonymous Coward | more than 6 years ago | (#19367723)

I hope you're working for one of my company's competitors, if you are so eager to hamstring your developers and limit their productivity! Having to wait for someone else to finish a major piece of development before I can fix a bug in an unrelated section of a file they happen to be modifying... yeah, that's the way to turbocharge your development process.

Lemme check my last home appraisal... (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#19367797)

Yep. $1.2 million. Paid for by getting billed out at $400 an hour. I could probably afford more house, but I like my vacations - a train ride with my family in first class sleepers to Glacier Park, maybe take the kids to Discovery Cove for a week or so. The one I'm planning now is going to be about 3-4 weeks bouncing around the South Pacific, NZ, and Oz.

Yeah, I don't know what I'm talking about.

I'm the guy that gets hired to fix your being nine months late and millions over budget.

Because if two developers or more developers who need to work on the same code aren't smart enough to figure out how to do it without stomping on each others work, they're overpaid.

You are smart enough to know you need to fix that bug, and you do have the initiative to work with the developer who already has the code checked out, right? Or are you too fucking lazy and stupid to do that? Because if you work for me, that will be one of the things I expect from you.

So by not allowing a last-second merge, you FORCE you to solve your concurrency issues yourself, EARLY in the development cycle, instead of having you drop in a merge at the last second and say "It worked fine in my branch, not my problem!"

You sound like one of those who needs to be shown the door.

Re:Lemme check my last home appraisal... (4, Funny)

starwed (735423) | more than 6 years ago | (#19367817)

You missed the point of the thread; to discuss git, not to be one.

Re:Lemme check my last home appraisal... (3, Insightful)

feronti (413011) | more than 6 years ago | (#19367903)

The thing is, you've got the wrong solution to the problem. Rather than not allowing branches, you need to control when and how often they're made, and how long they're allowed to survive. Your fixing a policy problem with technology, which never works well. If the branches are kept under control, you don't have the last-second merge problem. Merges should be happening constantly throughout the process so everyone stays in sync. If someone isn't committing their work at least once a day, that's when they get a stern talking to from the lead developer. Because if a developer needs to coordinate with another developer to change one line of code, then you've wasted two people's time instead of one.

Re:Lemme check my last home appraisal... (4, Informative)

Black Acid (219707) | more than 6 years ago | (#19368063)

You hit the nail on the head. Distributed version control often comes with superior merging, making the process less painful and encouraging it to occur frequently. Monotone employs a 3-way merge [wikipedia.org], Codeville has an innovative merging algorithm [zooko.com], and some may even support 5-way merging [nongnu.org] ("left's immediate ancestor, left, merged, right, right's immediate ancestor") in the future.

In my experience, nearly all merges occur automatically and cleanly. Only if two developers modified code in conflicting areas of the source code do you have to merge manually--and even then, only one person has to do it. It is much better to have merging operate automatically and transparently when possible, than to have to have two people manually coordinate each and every one of their changes beforehand.

Re:Lemme check my last home appraisal... (3, Insightful)

KyleCordes (10679) | more than 6 years ago | (#19368103)

I wrote about Linus's talk a few weeks ago:

http://kylecordes.com/2007/05/17/linux-git-distrib uted/ [kylecordes.com]

Looking back at that, and at your comment, some things come to mind:

* the tool Linus is pushing, greatly facilitates the idea of frequent, easy merges, and Linus mentions that a tool with great, fast merges, helps you merge early and often.

* on the other hand, your comment is about "you need to control when and how often [branches] are made...", while a big point of distributed SC tools is the opposite of that control: these tools make the power of the tool fully available to all users. A "main" repository may (and probably should) have permissions/hooks set to enforce some policy about what happens to what branches. Individual users can always create local quasi-branches by simply not checking things in; with a tool like they can can create real (local) branches too, which can then be promoted to official status (i.e. on a blessed central repository) if needed.

Re:Lemme check my last home appraisal... (3, Funny)

Anonymous Coward | more than 6 years ago | (#19367933)

Yep. $1.2 million.
Well if that's you're measure of correctness then you'll have to admit Linus is right and you're wrong because his house is worth more than that.

Re:Lemme check my last home appraisal... (0)

Anonymous Coward | more than 6 years ago | (#19368011)

Yep. $1.2 million. Paid for by getting billed out at $400 an hour. I could probably afford more house, but I like my vacations - a train ride with my family in first class sleepers to Glacier Park, maybe take the kids to Discovery Cove for a week or so. The one I'm planning now is going to be about 3-4 weeks bouncing around the South Pacific, NZ, and Oz.

Wow. Basing your self image on money much?

Yeah, I don't know what I'm talking about.

Yes, you don't know what you're talking about. I'm basing this on your idea, which is laughable, not your undoubtedly extensive credentials, spotless academic record, and huge cock.

If you're unable to merge, your version control system is reduced to an automated system for collecting and backing up code. For mature, large projects that need constant updates but also have large features coming, sacrificing the ability to keep developers from thinking having to worry about things that are completely irrelevant to their work—in other words, the ability to merge in the features later—means giving up a significant advantage.

If the developers write sufficiently modular code, and are aware of each other's projects even if they're not constantly looking through each other's code, eventually merging should be far easier than keeping every piece of developing code fully compatible with every other piece at every step.

You sound like a troll, so I'm sorry to have been unable to resist the bait.

Re:Lemme check my last home appraisal... (1)

koreth (409849) | more than 6 years ago | (#19368013)

Or are you too fucking lazy and stupid to do that? Because if you work for me, that will be one of the things I expect from you. [...] You sound like one of those who needs to be shown the door.

No need, I'm sure anyone with half a brain and an ounce of self-respect would have run screaming from such a fabulous work environment long before you had the chance to demonstrate your blindingly self-evident superiority to them.

Holy crap (1, Flamebait)

catbutt (469582) | more than 6 years ago | (#19368045)

You are the biggest ass I've seen on slashdot. And I've seen a lot of asses on slashdot. But bragging about how much money you make and the vacations you take, as if somehow that means your opinion is correct....wow.

Smart to post as a coward tho, gotta give you that.

Re:Lemme check my last home appraisal... (0)

pavera (320634) | more than 6 years ago | (#19368507)

Ok, you are a complete moron. I don't care what you say, if you were my boss you would be fired, and I would take your job.

In my dev shop there are 2 components, a legacy thick client app which is managed in source safe (file locking, no branching, no merging), 5 devs. This project is in full maintenance mode, no new features. We have recently rolled out a web based replacement which is managed in Monotone. 2 devs. There are branches and merges constantly.

Recently we found a bug which effected multiple areas of the code. It had to be fixed in both projects, it was a design assumption from the original legacy code which turned out to be false. It took the 2 devs on the web project less than 1 day to fix it, they were both working the whole day writing code, merging it together, testing, coding, merging, testing.

The sourcesafe guys, well, it took almost 2 weeks. 1 dev would spend a day with a bunch of files locked, the other 4 are now stuck, they can't work on anything that touches what the first guy checked out. Since this particular bug went to the core design of the app, the core of the app was locked while the first dev implemented the "design" changes (function definitions, mostly .h stuff). He checks his work in, now nothing works, because all the old function calls don't work anymore, you can't test his checkin yet. Now the other 4 devs split up the files they want to work on and lock them, and they go through fixing things, but no one can check anything in and get a working system, everything is broken. This delays testing which is always a bad thing to do. They are forced to commit large changesets, they can't do incremental development, well, they could, but the more incremental the development, the more blocked everyone is by anyone else making changes. When changes are effecting large amounts of the code base, this basically means if you have a staff of more than 2 you are screwed. During the 2 weeks while I was sitting back (being 1 of the 2 web project coders) adding features to the product, I can't remember how many hundreds of times I heard the sourcesafe users scream "Unlock that damn file I need it" or "Why did you lock THAT file?! You aren't using it!" across the office.

In short I don't care that you're such a great salesman that you've managed to sell yourself for > $400/hr. You suck at managing coders, and you understand so little about the process that you are ripping off everyone who ever paid you a dime.

As to your home valuation, after the recent bubble, who's home isn't worth 1.2 million? Seriously though, you probably live in California (the only pricks I've known as big as you are all from that horrid state) where the average is probably > 1 million anymore, so you're not that special, you're slightly above average.

Re:Merging *does* suck (2, Insightful)

chez69 (135760) | more than 6 years ago | (#19367853)

if your working with a good SCM and have somebody with a clue who administers it (I've worked in a large clearcase setup for years, with a great admin staff) concurrent development isn't that hard to do. Good tools make the job easy.

file locking is ok for 2 or 3 developers, any more then that, it sucks bad.

Re:Merging *does* suck (1)

koreth (409849) | more than 6 years ago | (#19368121)

It sounds like you really mean, "Doing big merges at the last minute sucks." But it's more generally the case that doing anything major at the last minute sucks. Merging two weeks before ship date is no different than checking in a big new feature or a substantial refactoring or a fix for a bug in a critical system component two weeks before ship date. If you're doing any of those things, it's a failure of your project management, but that failure has absolutely nothing whatsoever to do with merging per se.

Merging or checking in a major new feature six months before your ship date is not any problem at all, and your methodology throws away the advantages of branch-based development during the bulk of the project's lifetime for the sake of a minor additional level of safety (which can be avoided with proper project management anyway) at the very end. If your problem is that "merges happen at the last minute" then honestly you need to look at your development processes as a whole.

Even at the last minute, though, not all merges are major operations. In a development shop that embraces git's "branch often" philosophy, merges tend to be small and frequent, and thus no one of them has much of a chance of breaking the source base. Further, before you merge a feature-development branch into your main source base, you will almost always have done the opposite first, and done a full round of testing at that point. If you do that, the merge is almost a no-op.

Re:Merging *does* suck (4, Informative)

Frankie70 (803801) | more than 6 years ago | (#19368171)


So don't do it


Wow! I bet you have never worked on anything other than hobby
projects.

Most projects I have worked on cannot do without branching &
branching big & I am not talking about branches created for
individual devs.

What do you do if you have make patches on an earlier release(s)?
What do you do if your project team has 50 devs working on
5 different modules inside? If one guy makes a buggy submit
it will break every one else? Typically each team does weekly
sanity tests & then propagates the changes to the main.

Yeah - and I agree with Linus - CVS is rubbish.

Have used CVS, Clearcase & Source Depot. Source Depot
is a Microsoft internal Source Control system. Microsoft
licensed Perforce & developed on it. I used to work with
MS long back & Source Depot was the best Source Control
System I have ever used.

CVS lacks too many features.
1) Atomic checkins/submits
    I am trying to submit changes in 5 files as a single bugfix.
A submit/checkin should either succeed for all 5 or fail for all 5.
CVS doesn't do this. The end result is that I may end up submitting
a change in the header without submitting a correspond change in the
implementation file.

2) Changelists
    After checking in multiples files together, at any point in time, I should
be able to find out all the changes that were checked in at the same time.
CVS has no way of doing this - Submitting 5 files together is the same as
submitting 5 files separately as far as CVS is concerned.

3) More Changelist features for non-submitted changes
Let us say I am working on 3 different bugfixes. Source Depot allows me
group together my changes in different changelists even before I
submit the changes. That is I can create changelist A B & C.
In changelist A - I have files a.c & a1.c changed, in changelist
B, I have b.c & b1.c changed & so on. So I decide I am done with
all the changes required in the subset A, I can submit it very easily
or undo all changes in changelist B.

4) Merges
Merges between branches are a breeze with Source Depot. With CVS it's
a pain. Source Depot stores a lot of information about merges which have
already happened which in invaluable. In CVS, merges between branches
are very little more than changes manually copied from one branch to
another.
I can do a lot of stuff which I can't do with CVS
- I can very trivally merge Bugfix 1111 (comprising of 5 files
checked into changelist XXXX) from a branch to another branch or
the main trunk.
- Because Source Depot stores information about merges, I can do periodic
single command merges very easily between a branch & the trunk - Source Depot
will not try to merge in changes which have already been merged the last
time I did a merge.

I could go on & on, but the point is that something Source Depot makes
a developers life so much more easier. I could work around all these
things in CVS (i.e. do it in multiple steps) but the ease is something
worth paying for I think. If Microsoft ever released Source Depot
as a commercial product, it would be great, but I don't suppose their
license with Perforce would allow it.

Re:Merging *does* suck (5, Insightful)

Timothy Brownawell (627747) | more than 6 years ago | (#19368213)

So don't do it.

The Wise adapts himself to the world. The Fool adapts the world to himself [revctrl.org]. Therefore, all progress depends on the Fool.

It's always done late in a development cycle, in the rush to get the project out the door.

Why? It doesn't have to be. At least if you use something that isn't horribly broken [red-bean.com].

So don't branch, and DON'T allow concurrent checkout of any code - FORCE the DEVELOPERS who need to work on the same code to COORDINATE their work EARLY in the development cycle. Of course they'll bitch.

Yes, they will. Because this is a monumentally stupid idea. Because the entire *purpose* of revision control systems (note: "CVS" stands for "Concurrent Versioning System") is to make it possible for developers to work on things at the same time. The idea is that you can get more benefit from the concurreny than you get difficulties from merging.

If your technical leadership has the spine to show prima donna twits who won't follow development rules the door. Of the entire company.

Rules like "merge early, merge often", perhaps? Fixes the problem, and *doesn't* cripple development horribly like your idea would.

Re:Merging *does* suck (0)

Anonymous Coward | more than 6 years ago | (#19368505)

I have tried that, and it does not work. You end up in a situation where each programmer owns a set of files, and the newly hired ones have to
beg permission to make changes. Once you have checked out a file you need to quickly commit your changes before you can go home, as
otherwise everyone will hate you for blocking progress (we used to have fines for going home with files checked out).
This puts stress on programmers to check out, edit, and commit quickly, and
results in untested code being comitted to the tree. The workaround is to bypass the SCM locally by overriding the write-protection of files, but
then you are back to a very limited and error-prone poor man's branch-and-merge.

In other words, I think *you* suck and should be shown the door.

No, no, no... (1)

Eric Damron (553630) | more than 6 years ago | (#19368613)

For a large projects with lots of developers who work via the Internet your suggestions just don't make good sense.

If I start a project and twenty people eventually join in and they check out various parts of the project but don't check them back in for long periods of time, following your suggestions would be horrid.

Linus is right. You want distributed repositories not a centralized one.

Re:Merging *does* suck (1)

iamacat (583406) | more than 6 years ago | (#19368623)

What does "same code" have to do with SAME FILES? There are plenty of opportunities for developers to edit different parts of the same file without stepping on each other's toes. On the other hand, someone changing a header file to remove a function can wreck major havoc on people who just wrote the code that relies on it.

Surely we all agree that, if semantically-aware source control tools are developed, it's a good idea to give developers exclusive locks on, say, basic blocks that they are actually modifying or function prototypes for functions they are calling in those blocks.

GIT (0)

Anonymous Coward | more than 6 years ago | (#19367693)

There have got to better acronyms out there to choose from. Whoever came up with this was a worthless git.

Why winge? (4, Funny)

gilesjuk (604902) | more than 6 years ago | (#19367737)

CVS and Subversion are open source projects, Linus should fix them.

Re:Why winge? (3, Insightful)

Brandybuck (704397) | more than 6 years ago | (#19367757)

The problem with CVS and Subversion are one of fundamental design. At least, that is what Linus is suggesting. You can't fix them without rewriting them completely from the ground up.

Re:Why winge? (5, Insightful)

zzatz (965857) | more than 6 years ago | (#19367821)

Linus isn't saying that CVS and Subversion have fixable bugs or missing features. It's not about the code.

He is saying that they solve the wrong problem. The Subversion team wants to solve Problem A, and Linus wants to solve Problem B. No amount of code will turn the solution to Problem A into a solution for Problem B. Bothering the Subversion team with code addressing Problem B will only irritate them, since they're working on Problem A.

The right way to handle differing goals is to start a different project. That's what he did.

Don't be confused by the labels. Source Code Management means different things to different people, and there isn't always much overlap in how each person defines it. Ships and airplanes are both 'vehicles', but that doesn't mean that a few changes will turn one to the other.

Re:Why winge? (5, Informative)

RedWizzard (192002) | more than 6 years ago | (#19367829)

CVS and Subversion are open source projects, Linus should fix them.
He did fix them: he wrote GIT. He's no really whinging, he's saying "I wrote this tool because the other options are crap".

Re:Why winge? (1)

gronofer (838299) | more than 6 years ago | (#19368573)

He did fix them: he wrote GIT. He's no really whinging, he's saying "I wrote this tool because the other options are crap".
I watched the entire video, and I'd have to say he was gloating, not whinging. He seems to have quite a bit of confidence in git.

how to learn git? (4, Informative)

zojas (530814) | more than 6 years ago | (#19367759)

I've tried to use git, and I feel like if you want to do anything more than commit, you have to jump off a cliff which has serious spikes at the bottom. seriously, if you want to learn how to do more than 1 or 2 of the simplest operations with it, you have to invest serious time. I tried, and never could get there.

anybody have a good tutorial? (not the crappy one which comes with it)

I'm not an SCM rube either. I've competently used tla (arch), darcs, and of course CVS. but git just seems too hard to use. damn fast though.

Re:how to learn git? (1)

Prof.Phreak (584152) | more than 6 years ago | (#19367857)

I've tried to use git, and I feel like if you want to do anything more than commit, you have to jump off a cliff which has serious spikes at the bottom. seriously, if you want to learn how to do more than 1 or 2 of the simplest operations with it, you have to invest serious time. I tried, and never could get there.

It was hard to write...it should be hard to use...errr... this is Linus we're talking about, right?

Re:how to learn git? - answer, don't! (4, Interesting)

Omnifarious (11933) | more than 6 years ago | (#19367881)

My favorite, of course, is Mercurial [selenic.com]. My main draw is that I had been interested in distributed SCMs for years, but had never found one that made any sense to me whatsoever. I was on the hunt again and stumbled on Mercurial, and I've been hooked ever since.

Of the various distributed SCMs, Mercurial is the easiest to use one I've found. And it's pretty fast, though not quite as fast as git (though I have some ideas on how to fix that). And since it's written in Python with only a very small C component it runs on many platforms.

Re:how to learn git? - answer, don't! (1)

FreshOuttaMaps (1087811) | more than 6 years ago | (#19368619)

And since it's written in Python with only a very small C component it runs on many platforms.
Wouldn't it be safe to say that more platforms support C than Python?

Re:how to learn git? (5, Informative)

Anonymous Coward | more than 6 years ago | (#19368025)

# set up new project
cd project
git init
git add .
git commit -a -m "Initial commit"
 
# edit a file
vi file.php
git commit -a
 
# add a file
vi new.php
git add new.php
git commit -a
 
# see the log
git log
 
# make a branch
git branch working
git checkout working
# or in one step
git checkout -b working
 
# add some changes to this branch
vi file.php
 
# see what you changed
git status
 
# check it in
git commit -a
 
# see all branches
git branch
 
# go back to the first branch (initial branch is called "master" by default)
git checkout master
 
# make some other changes
vi other.php
git commit -a
 
# merge the working branch into this one
git merge working
 
# see the branches and merges in a graphical browser
gitk --all
 
# let's do a log of all commits in "working" that don't exist in "master"
git log master..working
 
# hmm let's undo that last merge (tip of branch is HEAD, one commit back is HEAD^.. we are "popping" one commit)
git reset --hard HEAD^
 
# push your changes out (push the tip of local "master" branch to remote "incoming" branch)
git push foo.bar.com:~/myrepo master:incoming
 
# pull changes from another repo (remote "feature1" into local "feature1" branch)
git pull baz.bar.com:~/otherrepo feature1
 
# move the branch point of the "working" branch to the top of the "master" branch
git checkout working
git rebase master
It can get a LOT more complex of course.

When you're starting out, just remember "git commit -a" and you'll be fine. Also check out "git reflog" to see the linear history of your repo. The pulling/pushing stuff can get a lot more complex but it's damn powerful. If you can figure out Arch (yeesh) you can figure out git!

SLASHDOT SEZ: you have too few characters per line. Okay, slashdot, here's part of the man page for git-rebase:

If is specified, git-rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch. All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD. The current branch is reset to , or if the --onto option was supplied. This has the exact same effect as git reset --hard (or ).If is specified, git-rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch. All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD. The current branch is reset to , or if the --onto option was supplied. This has the exact same effect as git reset --hard (or ).If is specified, git-rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch. All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD. The current branch is reset to , or if the --onto option was supplied. This has the exact same effect as git reset --hard (or ).

Well, speaking from my own experience... (4, Interesting)

RootsLINUX (854452) | more than 6 years ago | (#19367781)

I've used CVS, SVN, and GIT in serious projects and I can say I far prefer SVN to GIT, and GIT to CVS. GIT was incredibly confusing to use, and it may just have been the way the repository was administered was poor, but I never knew if I was synched with everyone else's checkouts and the command names made no sense. Its been over a year so I don't remember the details of GIT, but I remember having to do a lot of things "twice". Need to do a checkout? Two commands. Need to commit? Two commands. It was a bitch to use and I am glad I'm done with it. SVN, on the other hand, I felt very comfortable with from the start and most important of all, I trusted SVN to do what I wanted it to and to keep me from screwing up. In a year of using it, it has failed to lose my trust.

I'm not trying to say SVN is better than GIT. The best repository depends on the type of project and type of development. But defaming SVN in favor of GIT is not, I believe, a valid statement. Especially when (I'm pretty certain) many, many more projects use SVN rather than choosing to use GIT.

Re:Well, speaking from my own experience... (5, Informative)

Black Acid (219707) | more than 6 years ago | (#19368167)

Its been over a year so I don't remember the details of GIT, but I remember having to do a lot of things "twice". Need to do a checkout? Two commands. Need to commit? Two commands. It was a bitch to use and I am glad I'm done with it. SVN, on the other hand, I felt very comfortable with from the start

Most distributed version control systems exhibit this phenomena, because by "checking out" you are actually doing two operations: pulling the latest changes from someone else, and updating your workspace. For example, in Monotone you would type (I imagine git operates similarly):

mtn pull
mtn update


The first command retrieves revisions from the server, and the second updates your workspace with those new changes. To "commit" a change, in a distributed version control system you first 1) commit the change to your local repository and then 2) push it to someone else:

mtn commit
mtn push


It is often useful to keep these operations separate. For example, you can commit without pushing. Make a bunch of changes, commit each one separately, and only push once you're satisfied with the result. Other developers can still see each change you made individually, but only after you've pushed, so they won't be stuck with an incomplete in-progress version of the tree.

Similarly, by being able to update without pulling, you can revert to any revision you would like without contacting the network. Likewise, since commit does not require network access, it is no extra effort to work offline. Once an Internet connection is available, you can synchronize your repositories, but in the meantime you can make any change you want - even with no network connection.

The main disadvantage of a decentralized version control system is that it requires workflow changes [pidgin.im] to get the most out of it. If you are only familiar with centralized version control systems, it will take some time getting used to. But I'm glad to say, an increasing number of projects are making the change to distributed version control [slashdot.org], among them, Mozilla and Pidgin. They are not using Git (but Mercurial and Monotone, respectively) but they're all distributed. Git is being used by the Beryl [beryl-project.org] project, among others. Subversion has momentum in FOSS because it is familiar for those used to centralized version control (everyone knows CVS), and SourceForge [sourceforge.net] provides free SVN hosting. Once a free open source hosting site provides hosting for a distributed version control system, I expect more low-resource open source projects to use it.

Re:Well, speaking from my own experience... (1)

644bd346996 (1012333) | more than 6 years ago | (#19368195)

I've not used GIT much myself, but I did watch the video. Linus pointed out that the UI has only recently stopped sucking. Since it's been over a year, it is definitely time for another look.

Well, Linus is an ass, what's new. (3, Insightful)

suv4x4 (956391) | more than 6 years ago | (#19367793)

No one said that if you're famous and contributed something incredible to the world (such as Linux) you can't speak out of your ass most of the time, just because you enjoy how everybody listen and try to decipher if they should care about it, or just laugh and pass by.

I use SVN if a medium sized team and see SVN used extensively in all kinds of projects around the globe with great success. I personally love the workflow of SVN.

The only thing that they need to work is merging of branches, and incidentally I've talked to the developers, they're quite aware of this flaw of SVN and working on it. We'll see new versions that can track changes in each branch and even attempt automated merges with good success.

I know a guy who has the same personality like Linus. The guy is very smart, he single-handedly is coding an application which is very popular in its area (won't mention it since that's internal stuff). He keeps bitching all the time: about customer feature request, about random products and how sucky they are, how people can't see that. And he could also change his opinion overnight for no apparent reason and go in the other extreme. But he's a friggin' programming genius and what he does is great, despite is takes a lot of effort to deal with him.

Well, probably those two go together: being an amazing creator, and being an amazing ass with huge ego. Who knows.

Re:Well, Linus is an ass, what's new. (5, Funny)

True Vox (841523) | more than 6 years ago | (#19368083)

Well, probably those two go together: being an amazing creator, and being an amazing ass with huge ego. Who knows.

I disagree entirely that those two traits must go together. I'm living proof that you're wrong, in fact. I don't have a creative bone in my body.

Re:Well, Linus is an ass, what's new. (3, Funny)

Johnno74 (252399) | more than 6 years ago | (#19368169)

wow, you aren't just an amzing ass with a huge ego, you are modest about it too! :D

Re:Well, Linus is an ass, what's new. (1)

Gactaculon (709191) | more than 6 years ago | (#19368163)

Linus communicates very much like an academic. With him, it's not personal - it's Ideas. He says what he really thinks and makes big assertions and if he's wrong, others will push back. I think this is an excellent way to conduct debate if all parties are mature enough to handle it, but it's also critical that one is always open to recognizing a superior argument. I can't say whether Linus has that critical trait, but unfortunately many lesser academics sadly lack it as well, so I think the comparison stands regardless.

Re:Well, Linus is an ass, what's new. (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19368519)

Academics usually have some expertise in their respective area, Linus does not. He is not a genius when it comes to OS design or development. The Linux OS broke no new ground; it was an imtation of existing Unix systems. Linus digs in his heals and refuses to cede ground even when he is wrong (or rants about untested design).

There's a difference between GIT and SVN (4, Informative)

paroneayea (642895) | more than 6 years ago | (#19367815)

... And that is that CVS/SVN are centralized, while GIT is distributed, like GNU Arch.

There are appropriate uses to both of these, and in kernel development I think it makes sense to have distributed development. However, in smaller projects, which really *need* a very specific direction (example, Wesnoth, I would think would not have gotten where it is today if there were so many branches where people were all making their own art).

Linus is enough of a famed leader that he's going to be listened to, and thus kind of pulls the community around him as a central source of development. That's not necessarily going to happen everywhere.

Re:There's a difference between GIT and SVN (2, Informative)

koreth (409849) | more than 6 years ago | (#19368053)

Nothing about git prevents you from establishing a repository and telling all your developers that it's the central integration point for your project. It supports svn-style centralized development just fine. (In fact, it even interoperates bidirectionally with existing svn repositories, though you lose some of the advanced features.) The difference is it doesn't force you into a centralized model.

Cvs is already done right (1, Funny)

fnj (64210) | more than 6 years ago | (#19367855)

"Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right."

Cvs is already done right. These would-be improvements are pointless.

Re:Cvs is already done right (1)

drgonzo59 (747139) | more than 6 years ago | (#19367959)

Yes, that's your opinion and then there are hundreds of project and thousands of developers who disagree. If CVS was so good, there would not be an army of people behind SVN.

Re:Cvs is already done right (1)

jgrahn (181062) | more than 6 years ago | (#19368555)

If CVS was so good, there would not be an army of people behind SVN.
If CVS was so good, there would not be an army of people using MS SourceSafe ..?

OK, CVS sucks. But it sucks in well-defined and well-known ways. That's enough for me and many others, for the things we do.

Re:Cvs is already done right (1)

abigor (540274) | more than 6 years ago | (#19367989)

I can only assume you've never actually worked with it on a large project.

Re:Cvs is already done right (1)

fnj (64210) | more than 6 years ago | (#19368309)

I can only assume you've never actually worked with it on a large project.

You would be wrong. Any other assumptions based on nothing?

Re:Cvs is already done right (0)

Anonymous Coward | more than 6 years ago | (#19368009)

How do you version directories in CVS?

Flamewars done right (0)

Anonymous Coward | more than 6 years ago | (#19368131)

"Cvs is already done right. These would-be improvements are pointless."

Isn't it about time to have another Vim vs Emacs flame war?

Re:Cvs is already done right (1)

MichaelSmith (789609) | more than 6 years ago | (#19368173)

Cvs is already done right. These would-be improvements are pointless.

I manage a 7 GB CVS repository serving 200 developers and you are totally wrong. If I could get buy-in from the 10 or 20 relevant stakeholders I would change to mercurial [selenic.com] in a pinch.

GOOG stock split next week (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#19367867)



GOOG stock split next week - go, go, google

Re:GOOG stock split next week (0)

Anonymous Coward | more than 6 years ago | (#19367895)

Now who's the Git ? Why would you say this if it were true ? Oh, already bought too high and want it to go higher ? I'll see it when I believe it .

git is pretty cool, take a closer look (5, Interesting)

Anonymous Coward | more than 6 years ago | (#19367891)

I took a look at git a while ago and was completely underwhelmed. The UI was so bad it was useless, and it didn't "seem" to do anything that Darcs didn't do. (I used to love Darcs because of the automatic patch dependency computations).

Now that all the "next generation" SCM tools have matured somewhat, I took a look at all of them again. I had to stop using Darcs because of the "patch of death" problem, which basically is this: after using Darcs on a project with long-lived parallel branches, the repository may eventually enter a wedged state you can't get out of, due to exponentially complex patch dependencies. Oops.

At this point I had an idea of what an SCM should do, how it should work, what the "mental model" should be. I want to create changesets, add them to branches, combine multiple branches (and keep track of renames and so forth between branches), re-order changesets, collapse multiple changesets into one, discard old branches, etc.

Of course, CVS and close cousin Subversion are SO UTTERLY USELESS I didn't even consider them. Seriously, Subversion is like gold-plated shit. Looks nice but it's still shit. Reading people say stuff like "Subversion is awesome" makes me wince. How can something that doesn't have "real" branches, and doesn't have tags OF ANY KIND, be useful for anything? How do you keep track of multiple merges between branches? Answer: you don't. Or you keep track of revision numbers using svnmerge and pray it all works. Even the Subversion docs sortof hand-wave this away. I.e., they hand-wave away one of the FUNDAMENTAL ASPECTS of source code management: branching and merging. It's like hearing people talk about OO databases. They mean well but they just don't comprehend the generality of the underlying problem.

That's why I was so excited about Darcs: the author "gets it". Unfortunately the implementation is flawed.

I checked out a few more (Mercurial, bzr) but finally settled on git because it let me do all the things I needed to do, and it did them FAST. Once I figured out the underlying model I was pretty impressed. Git can be viewed at many levels: very low-level plumbing, or UI-level, or in between. The UI and documentation is still pretty shitty, but thankfully they are working on improving it and are moving away from the idea of having interchangeable UIs. Just focus on improving "core git".

One great thing about git is that so much of it is just files in the .git dir and shell scripts that combine very simple low-level functions. For instance, you can create a branch just by saving the SHA1 ID of the tip into a file in .git. You can branch off any point in the history this way, including branches you've deleted in the past (git keeps all the old commit objects by default, even ones that aren't pointed to by any branch or tag.. this is very simple and understandable model, like reference-counting in a way).

The other great thing about git is how easy it is to sling changes around and reorder them and combine them. For instance let's say you add a file to your project as commit "A". Then you add some code that uses this file as commit "B". Then you fix a bug in the file as commit "C". So you have A-B-C. Now you'd like to combine A and C into a single patch A', and put B on top of it, like this: A'-B. In git, this is super-easy. I can think of two ways to do it off the top of my head.

I was checking into a CVS project the other day (for a client) and wanted to do this. Then I realized, you can't move things around in CVS like this *twitch*. So nowdays I do everything in git and only after the changes are beautiful and self-contained and well-commented do I check them into CVS one at a time.

Okay so they point is, check out git (or honestly? Checkout out ANYTHING that isn't CVS or svn). Even if you think Linus is an asshole (which he is) or you don't like the git UI (it's not that bad now), check it out anyway.

And if you don't use SCM at all? You suck. Start learning. It's a best practice that you can't live without, once you start.

Re:git is pretty cool, take a closer look (1)

sqlrob (173498) | more than 6 years ago | (#19368035)

WTF are you talking about? It's trivial to branch and merge in SVN.

Re:git is pretty cool, take a closer look (0)

Anonymous Coward | more than 6 years ago | (#19368099)

Making a copy is not the same as making a branch.

Generating a diff and applying it to a working dir is not the same as performing a merge.

And for fucks sake Subversion, creating a copy in a directory called "tags" is not the same as making an actual tag.

Re:git is pretty cool, take a closer look (4, Informative)

Senjutsu (614542) | more than 6 years ago | (#19368501)

Making a copy is not the same as making a branch. ... And for fucks sake Subversion, creating a copy in a directory called "tags" is not the same as making an actual tag.
The way subversion does "copies" (there is no duplication of shared data between copied directories), there is no difference in practice.

Re:git is pretty cool, take a closer look (1)

644bd346996 (1012333) | more than 6 years ago | (#19368217)

You sound like a lisp coder, talking about all the features the competition doesn't have, but you can't live without. I don't mean that in a bad way, but the similarity is very striking. I guess right now GIT is the Lisp of SCMs. I hope it can catch on better, though.

Re:git is pretty cool, take a closer look (1)

thePsychologist (1062886) | more than 6 years ago | (#19368255)

Of course, CVS and close cousin Subversion are SO UTTERLY USELESS I didn't even consider them. Seriously, Subversion is like gold-plated shit. Looks nice but it's still shit. Reading people say stuff like "Subversion is awesome" makes me wince. How can something that doesn't have "real" branches, and doesn't have tags OF ANY KIND, be useful for anything?
Subversion is good for smaller projects, at least. Subversion can also be used outside of source code maintenance, for instance, for maintaining a database of data files for a scientific project.

Distributed version control gaining ground in FOSS (5, Informative)

Black Acid (219707) | more than 6 years ago | (#19368003)

The ultimate reason why Linus dislikes SVN, CVS, etc. is that it is centralized. Everyone checks out source from a central server and commits their changes to the same centralized area. This has problems: your workspace is not versioned. By this I mean, you cannot track local changes to your workspace without committing them to the central server.

A common pattern in development is to try one approach, test it, tweak it, and possibly try another approach if the first did not work out, perhaps reverting to a prior approach. With decentralized version control, you can commit your changes to a local repository and work from there. All the locally changes you make are versioned, and be committed, checked out, examined all without contacting a central repository. This is ideal, because you often want to try various options to find the one that works best, before pushing your changes to the rest of the world. In centralized version control, you can use a branch for this purpose, but often branches in these systems are difficult to either create, merge, or maintain, so they are rarely used. The end result is that with centralized version control, developers version their workspace in their head. DVCS systems remove the mental burden.

Fortunately, FOSS developers are realizing the usefulness of DVCS and major projects are converting to some form of DVCS. Mozilla is switching to Mercurial [mozillazine.org]. The Pidgin [pidgin.im] project, which just released 2.0.1, is using Monotone [pidgin.im]. (Linus favorably mentioned both of these distributed version control systems in his Git talk, as they are both are distributed).

Once you accept that DVCS is better than the centralized model (which may not be true for some situations), only a few (but growing number of) version control systems are viable. This is currently a hot area in open source development, with software such as GNU Arch, Monotone, Mercurial, Git, Darcs, Bazaar, and more paving the way. Many open source DVCS's are still in development and not ready for general usage. I can't speak for Mercurial, but Monotone doesn't have the greatest performance, instead preferring integrity over speed. This led Linus to write git, since speed is very crucial for a large project like the Linux kernel.

Whatever the actual program (git, Mercuial, or Monotone), more and more open source developers are realizing the advantages that distributed version control can offer. I encourage all developers that haven't used any DVCS to try it -- once you do, you won't go back.

Re:Distributed version control gaining ground in F (1)

cryptoluddite (658517) | more than 6 years ago | (#19368253)

There's one trick to getting performance from monotone, which is to flip a switch on your workspace to make it use timestamps (like SVN does) instead of always re-hashing every file to see if it's different. For small projects, the rehash is best since it is certain. With timestamps on unix if you make changes in 1 sec, for example copying a different version right after a update (which can happen btw) then version control will not check in your changes and they can be lost.

Once you enable timestamps with monotone pretty much all operations are faster than subversion. Even reverting can be faster in practice because the server typically has the files in ram vs your workstation which has to seek all over the place to make copies. Depending on your setup of course.

Monotone is not slow anymore, and it keeps a much tidier and smaller repository. So small that in just a little more space than SVN's spare copies of all HEAD files for the past revision you can have all revision on your workstation. Why anybody would use subversion is beyond me... Linus is right on this one.

Re:Distributed version control gaining ground in F (3, Informative)

Black Acid (219707) | more than 6 years ago | (#19368571)

Monotone's inode prints [monotone.ca] (which, incidentially, Linus was a major contributor of [mail-archive.com]) can speed up some things, but the initial pull of a large repository is still unacceptably slow. The Pidgin developers have worked around [pidgin.im] this performance bottleneck by supplying bzip2'd Monotone databases via http, which the developer then can sync with the latest repository on pidgin.im to obtain an up-to-date database with the latest changes. Partial pulls should partially fix this problem in a future release of Monotone, or so I hear.

For what it's worth, I use Monotone daily and find the performance acceptable. For the record, Linus used Monotone at a particularly bad time it its development cycle [mail-archive.com], when it was very slow and the main designer was on vacation. Nonetheless, the Monotone developers emphasize correctness and integrity over speed, and Mercurial and Git were direct responses to the performance of Monotone. Still, the performance of Monotone is always improving.

Re:Distributed version control gaining ground in F (0)

Anonymous Coward | more than 6 years ago | (#19368311)

By this I mean, you cannot track local changes to your workspace without committing them to the central server.

You're kidding, right?

$ svn diff A.txt
    will compare your local version of A.txt to the last committed version of A.txt in the
    depository.

Surely you don't have to do commit to do the diff.

Re:Distributed version control gaining ground in F (2, Informative)

Procyon101 (61366) | more than 6 years ago | (#19368355)

So, how do you take that diff, revert half of it back to server's version, begin coding a completely new direction, realize you were right the first time, go back to the original dif you took, then pull in half the stuff you did while doing the wrong thing, finish coding and push the commit back to the server?

You can't because subversion has no client side version control.

Re:Distributed version control gaining ground in F (1)

Black Acid (219707) | more than 6 years ago | (#19368407)

Exactly. With a centralized version control system (PVCS, which is not coincidentially listed as the riskiest bet [collab.net] on the Forrester Source Code Management comparison) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?

Re:Distributed version control gaining ground in F (1)

jgrahn (181062) | more than 6 years ago | (#19368517)

Exactly. With a centralized version control system (PVCS [...]) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?

That doesn't have to do with centralized/distributed. ClearCase is super-centralized, but you do your experiments in branches, as many as you like.

Re:Distributed version control gaining ground in F (0)

Anonymous Coward | more than 6 years ago | (#19368599)

I use Perforce and people have their own branches off the development branch. It is their sandbox and they can share code with other developers if needed.

One thing that always scares me about distributed SCMs are their lack of ACLs. I have respositories that have strict permissions because they store things besides development related files. I even have directories within branches that are not available to developers, only to release engineers. ACLs always seems to be an aftertought to these free systems; they are not ready for commercial environments.

Re:Distributed version control gaining ground in F (0)

Anonymous Coward | more than 6 years ago | (#19368609)

>By this I mean, you cannot track local changes to your workspace without committing them to the central server.

This is actually a good thing really, be more open about your changes.
You should look at the work I have been doing for GCC: http://gcc.gnu.org/wiki/PointerPlus [gnu.org] .
If I did this work in private, it will most likely not be accepted as it is a big change to the compiler. Plus this allows for and kinda forces collaboration on projects that are not part of the main trunk. Both are good things. If people do work in private in GCC, the development comunity looks down on that development as that means they will dump and run. If the work is in public, then we know people are working on that project and developer resources are not lost.

Thanks,
Andrew Pinski

~$ mv CommitAccess MergePrivileges (4, Insightful)

Excelcia (906188) | more than 6 years ago | (#19368027)

Linus talks about his distributed model, how everyone has a branch, and how this avoids politics associated with who gets commit access. He claims (and I admit I've seen this happen in some) that many projects have quite the internal politicking on who has CVS commit access. But then he claims that Git's special sauce eliminates these internal politics. Ok, I was intrigued, so I listened on.

Essentially, he explains, the secret with Git is that everyone has commit access on their own branch - they do whatever they want. He says that the way it works is that someone does something cool with their own branch, then they start hollering to say "Hey, I have a good branch, merge mine" and it will get merged. Politics over.

Ok, so now I'm scratching my head. How is this a fundamentally different paradigm? In CVS, basically anyone can check out the whole tree and make any changes the like. They can then say, see, my changes are good and ask for them to get committed or ask for commit access themself. In Git, this commit access bottleneck is just moved from the commit stage to the merge stage. You make your changes, commit them to your separate and unique branch, and then ask someone with to merge it, or give you the ability to merge it in to mainstream. How exactly does this eliminate the politics? You are still going to have some people with "the power" and some people without. In any project where you have people who are going to fight about who gets commit access, you'll just have a fight about who has the ability to merge into mainstream.

So, ok, distributed is nice (though for some projects central may be preferred) but I don't see how this magic system bypasses politics. In fact, I can potentially see more internal politics over this method. I can see factions gathering to support this or that branch, arguing about which is better, fighting about which one gets merged in. I can see the potential for branches going longer between merges, and more changes happening at once, making it harder to track problems. I don't claim these scenarios are more likely, but I do claim that this changing from a commit access to a merge access paradigm is just renaming the problem.

Do teams actually do this? (2, Interesting)

ClosedSource (238333) | more than 6 years ago | (#19368133)

You may be saying this in the context of large FOSS projects, but for most projects, not allowing all the team members to commit changes seems like a really bad idea. If you don't trust them, why are they on your team?

Complaining about the occasional inefficiencies of file locking while forcing some developers to waste time waiting for permission to commit, seems really ironic to me.

Re:~$ mv CommitAccess MergePrivileges (2, Interesting)

starseeker (141897) | more than 6 years ago | (#19368161)

I tend to agree - what becomes the "official" code (i.e. what would go into a release tarball) is a social problem without technical solution. A coordinated release requires AGREEMENT, however that agreement is arrived at.

What GIT does differently, as I understand it, is it makes flipping around branches much easier than before. CVS and SVN have the concept of a central server, so if two developers are trying to resolve differences in their branches before either can get their changes into the main tree they have to work outside svn/cvs to communicate those changes to each other. With GIT, both developers can set up their individual archives and pull from each other, without ever involving the main tree. In other words, the benefits of version control and branch control are available between any two individuals with repositories, without relying on the main branch.

GIT also makes it trivially easy for everyone to switch away from the "official" branch to someone else's as the standard, but that begs the question of resolving differences WITHIN the project.

GIT is a neat tool, and I think it has a lot of potential. But like every other technological solution, it does not and cannot resolve fundamentally social issues.

Re:~$ mv CommitAccess MergePrivileges (1)

Chandon Seldon (43083) | more than 6 years ago | (#19368303)

GIT is a neat tool, and I think it has a lot of potential. But like every other technological solution, it does not and cannot resolve fundamentally social issues.

On the other hand, it does allow for the web of trust / tree of merges solution that is impossible with a centralized SCM tool.

Re:~$ mv CommitAccess MergePrivileges (2, Informative)

c (8461) | more than 6 years ago | (#19368259)

> In any project where you have people who are going to fight about who gets commit
> access, you'll just have a fight about who has the ability to merge into mainstream.

I really wish he would have addressed that question a little more directly, too.

I think the problem is that you're thinking about it from a classic centralized development model. I have some trouble getting my head around it, too.

Basically, from a truly distributed SCM perspective, there is no "mainstream". All branches are equal. Obviously this isn't quite the case with Linux, but bear with me here.

If you've got good code, what happens is that your changes get merged into more branches than bad code. The more popular your code, the more stuff gets built on top of it. If your code is good enough, eventually it gets into the "mainstream" simply by being an unavoidable dependency for other code.

Quality (or quantity) of code rules.

Politics are only an issue, then, if someone tries to bypass this process by skipping their changes right into the most "popular" branches. But this means they have to convince the owners of those branches to merge it. And while it's really hard to ignore changes from someone with commit access in a centralized SCM, ignoring someone in a distributed SCM is just a killfile away.

c.

Re:~$ mv CommitAccess MergePrivileges (2, Interesting)

Endymion (12816) | more than 6 years ago | (#19368277)

It is moving the problems to a neighboring problem-space, but that allows for a good benefit: getting everybody to check trivial changes in.

(at least, that's what I got from his talk)

I know I've seen it before - the problem where commits are restricted by management (for good reason), and people cannot commit their current work. I've seen this destroy some work before, as it means everybody is basically always running with a 1-2 week window of changes that are not checked in to the "safe, backed up". Ouch.

If you defer the problem a bit, so everybody can commit changes all the time, that helps keep everybody on "good practices". Also, he mentioned a workgroup situation: if I commit changes to a local repository, I can give the other people in the repository easy, save access to it without having to mess with the main branch.

One important change, though, is the direction of the conflict. CVS/etc uses a "push" model, where developers have to push their changes to the server. GIT (in theory) works as a "pull" model, where a manger could pull the changes the developers have made. I kindof like that idea, as it means conflicts are in the arena of the manager, in theory freeing the developers from some of the mess.

at least, that's as I understand it...

Re:~$ mv CommitAccess MergePrivileges (1)

norton_I (64015) | more than 6 years ago | (#19368421)

I think the way it is supposed to work (no idea how well it does for the linux kernel) is that anybody can "join" the development tree, publish "their" kernel version, including whichever patches they want, without interfereing with each other. Everybody has merge privileges on their own tree, and nobody has merge privileges on someone else's. The only reason Linus is "special" is that when he says "this is version 2.6.22, no bloody -mm -ac or -aa" everybody else listens.

Ideally, such a system would blur the distiction between a "forked" and "not forked" state. Typically, in OSS devlopment when two developers have unreconcilable differences in the direction they think a project should go, it forks. One or both parties creates a new project, a new CVS/SVN/whatever tree, and the two projects diverge. In the git model, they both stay in the same scm universe, and either party (or a third party) can pick any improvements from the other "team". Eventually, they might merge back into one project, without even having to decide whose VC tree to use.

In theory, this could really cut down on a lot of political arguments. As I said, I haven't followed enough kernel development recently to see how well it works in practice.

Re:~$ mv CommitAccess MergePrivileges (2, Informative)

Error27 (100234) | more than 6 years ago | (#19368639)

There are a couple things.

Everyone has a complete tree so everyone can push patches between themselves. Linus doesn't have to accept it into his own tree. That cuts down on the politics. Before everyone had they're own tar ball and push patches around but you lose history and it takes more work.

The other thing is that it's easier to delegate political questions. Lets say Linus pulls networking patches without even looking at them. The networking maintainer gets to deal with all the political issues. This is how it worked before but it was all manual and you lose all the commit comments etc.

Re:~$ mv CommitAccess MergePrivileges (5, Informative)

iabervon (1971) | more than 6 years ago | (#19368641)

The advantage is that MergePrivileges can be fine-grained: there can be many answers for "merge into what?" There's a -mm tree, a -stable tree, a -linus tree, a -rt tree, and a lot of vendor and distro trees. Each of these has a different maintainer, and can have a different idea of what is acceptable. And only the maintainer can merge things into their tree, and they can decide based on a variety of features of the things they're considering. For example, Linus only merges from a few people directly: maintainers of various subsystems. And he doesn't even trust them completely; if the SD/MMC maintainer has a change which changes x86 architecture code in the tree Linus is asked to merge, he'll notice and ask what's up with that. And if there are changes that look too intrusive for the current point in the development cycle, he'll put it off until the next cycle, and ask for a tree with just fixes. And -linus isn't special, except that almost everybody trusts him implicitly and merges his stuff into their trees (the main exception being -stable, which is why a new 2.6.20.x kernel isn't derived from 2.6.21; and vendor and distro kernels are generally based on -stable of some sort, and only get new stuff from Linus when they go to a new series). Also, maintainers of subsystems know the people who work in their areas, and can apply the same sorts of rules: the guy from Intel who works on their network drivers can get e100 changes into the the -netdev tree, because the maintainer knows they know what they're doing for e100 changes. And Linus sees that the e100 changes are coming in through -netdev, and the network maintainer knows what policy to apply to the drivers around there, so they're fine, even if Linus has no clue who should be allowed to do what in e100.

It's not that the politics go away. It's that the policy is no longer a binary "yes or no" decision, so the technical arrangement mirrors the social arrangement. This doesn't work with CommitAccess because people wouldn't commit the same change everywhere they should, and they couldn't be restricted to only making changes they're trusted to make (there are people who are trusted to correct spelling in comments in any file in the tree, and Linus can look through the total changes they send and verify that they only change spelling in comments).

It depends on the project (4, Interesting)

ClosedSource (238333) | more than 6 years ago | (#19368029)

If you have a project that has thousands of developers all of the world like Linux does, a SCM system that is focused on merging makes a lot of sense. Unfortunately, there is a tendency for some people to overdo merging on small projects when they don't really need to. If the application is designed in a modular fashion and developers are assigned specific modules, than merging is rarely needed. Of course, many control freaks don't like this approach because it makes it harder for them to "correct" other developer's code.

Mercurial (1)

nutsaq (116096) | more than 6 years ago | (#19368105)

Mercurial [selenic.com] seems to have quite a bit of traction these days, more than any of the other d-sccm tools out there from what i can tell (inside sources tell me sun has mandated mercurial, so there should be quite good tool integration soon). Mercurial is also very fast, and has a good ui, and a really nice http interface too (rss no less).

svn is indeed gold plated shit
cvs is indeed past it

Is it my imagination??? (-1, Flamebait)

SETIGuy (33768) | more than 6 years ago | (#19368215)

Or is Linus turning into a replica of RMS, only without the manners?

Simulating distributed SCM with SVN (1)

CharAznable (702598) | more than 6 years ago | (#19368267)

Every developer has their own repository, which they can commit as branches into a repository of repositories :P

it'll never catch on (5, Insightful)

sohp (22984) | more than 6 years ago | (#19368321)

Distributed version control the way git does it (conceptually, not necessarily the implementation) is the best idea in SCM since concurrent development and optimistic merge conflict resolution on check-in.

Notice how, even years after better ideas superceded the lock-modify-unlock paradigm, many tools and shops still use exclusive-lock SCM.

It could be quite a while before you see anything like the way git does SCM in use in the majority of programming shops.

VSS--SVN (1)

traveyes (262759) | more than 6 years ago | (#19368341)

We used VSS for a long time but switched to SVN after reading numerous accounts that that VSS would eventually croak, and because we needed multiple developers working on the same source. After all the developers (~16 very active users, 20+ projects) were over the learning curve of SVN, there's not one that would go back to VSS. I can honestly say there is nothing I know of that we need that SVN doesn't do for us. We use TortioseSVN for the Windows guys, and the server-side guys (Linux/Unix) use command-line SVN. We have no need to branch local copies. We very rarely have to manually resolve conflicts. I fail to see what GIT would do for us.

Perhaps SVN sucks for kernel-guys. But for what we do, SVN fits the bill perfectly... Central repository, easy to get up-to-date, easy to commit, easy to update, easy to review changes, easy to review history....

SVN for us is the right tool for the job.

.

Bill, Steve and Linus walk into a bar... (-1, Offtopic)

kitsunewarlock (971818) | more than 6 years ago | (#19368345)

Bill watered down Steve's vodka so much that Steve won't drink it. Sure he's considered an ass, but he got free booze.

Steve then ordered an Apple-tini, knowing Bill is allergic. Sure its a "gay drink", but its classy and metro.

Linus brought in his own home-made booze. Its true he can't go to every bar out there but hey, he got free and good booze without being an ass.

Honestly I don't know what this has to do with ANYTHING posted here, but it sounded really funny in my head and I didn't want to forget it (plus I gots lots of extra karma to go around).

SVN not so bad (0)

Anonymous Coward | more than 6 years ago | (#19368499)

I like SVN. And I like Mercurial. Hate CVS.

There seems to be one thing which SVN does that Mercurial does not do, which is checkout of partial repositories. Correct me if I'm wrong, but with Mercurial (and maybe GIT too) it's all or nothing.

On the other hand with SVN you can checkout just a directory (and everything underneath it) and work with that directory, update, commit and so on, without any consideration of the rest of the repository. That makes it a better tool if you want to have just one repository with many mostly independent directories, rather than many repositories.

One thing I do not like about SVN is all the metadata it keeps under the .svn subdirectory. It increases the total size of the checkout by about 3 times. SVN unlike HG has a .svn directory in every checked-out directory. HG has one only at the top level.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...