On Sat, 05 Jan 2008 16:59:13 +0100 Andreas Schwab wrote: > Richard Stallman writes: > > > Currently we recommend that people "build the source from CVS", and > > we don't say "from the trunk" because that is a general convention > > of CVS usage. > > > > If we used git, what convention would replace that? > > It's the same, basically. If you clone a git repository, your > personal repository is automatically set up to track the default > branch of the remote repository, which is normally the master branch. > > Andreas. > take a look at www.kernel.org. I use git for my linux tree. I am what you would call the end-user in this case. My use is alot simpler with git. When a release is pending I check the changelogs via gitweb, do various searches for hardware and sub-systems of interest. If I like what I see I simply cut & paste the git url into a git-pull and merge the upstream changes. On a regular basis I pull from two branches, the first branch being the official linus tree, the second is usually 2.6.x.y for patch releases. Occasionally I need to debug a kernel problem with a pre-release. When this happens if the developer for the sub-system is using git I can pull fixes from his tree while we are diagnosing the problem. Once it is fixed I don't have to revert the changes before I pull from the official repo again, because the maintainer requests a pull from linus, it gets merged, and git doesn't barf on previously merged changes. In fact during this discussion I have noticed a key point that has not been mentioned. If RMS is wondering how a project is lead with a distributed system the answer is the convention of asking for a pull. I don't think anyone "pushes" changes on Linus. When they have something that is in shape for him to review they request via e-mail a pull and give the git URL. Linus is then free to look through the history of their branch. He can see not just the work, but the history. That includes all the changes, bugs, and features. By reading the history he can get a much greater sense of how it developed, not just a diff. If he likes it, he pulls it. If not they can keep at it and ask again later. When he pulls he gets the full history. CVS is crippled in that there is no way to record changes before commit. I personally do not like CVS like systems because it puts a huge burden on the developer that actually works really hard to do a clean merge for review. What I consider a clean merge for review to be is this: Broken up into changes where each change can be described succinctly by a changelog, and the change must not break compile or regress. here is a little constrast sketch: bad commit: add subsystem foo , with new data structure bar, modifying existing code baz to use new data structure bar. Good commit: 1. add new data structure bar 2. modify baz to use new data structure bar 3. add subsystem foo. Notice how in the good commit the maintainer of baz can evaluate the new data structure without wading through my new subsystem foo which he probably doesn't care about. If CVS and DVCS systems where compared to writing CVS would not have topics or paragraphs, just one huge body of text. Changes in DVCS systems can be broken up, like a body of text into paragraphs so that people can understand them better. Because CVS cannot record changes in the working copy you have to do one of two things: A. finish the entire work and publish as a single commit. This alternative is so broken you actually have to backup your working copy changes yourself. B. break the commit up into valid changes and try and maintain a diff series in the working copy until you can submit the sequence. Again backing up yourself. C. use a branch. Of course people who use CVS will say C is an entirely valid option. It does work. But it discourages casual development and definitely would discourage me. I don't like to make proposals without code to show. Often until the code is fleshed out I don't have the facts to make a proposal. With CVS I have to get a commit bit, get a branch (sounds like paperwork), and finally start hacking away. I consider this high risk because I have to declare my success (proposal + commit bit + branch) before I know if the idea will even work. I would much rather hack away on any distributed VCS where I can pick the good idea from the dozens of ideas that seemed good but did not pan out. When I would go to "request pull" or merge I can show the entire history of the development. DVCS are not perfect, but they at least make what I call a good commit possible without having to do what I consider absurd labor. When I have to work on a project using CVS or even SVN I spend a huge amount of time manually slicing and dicing diffs in diff mode. If anything goes wrong in the diff sequence I am in big trouble so I also have to keep full copies at each "change point". At that point It's not a reversion control system for me, it's just a publishing tool. All of the changes have to be maintained by hand in diff-mode. What I call good commits has two key points. It feeds changes incrementally for both review and testing. Who wants to try and test a huge chunk of code dropped in a single commit ? Doing things the right way usually pays off even in ways you don't anticipate, like git-bisect. I have personally used that to track down a problem with a IDE driver. I found the broken changeset in something like six reboots. The fix was in the Linus tree within days. I don't think it works at all to try and describe git in terms of CVS. In fact dictating how you merge by version control system is kinda supsect as well. The goal should be to turn in high quality merges, incrementally reviewed, incrementally merged and tested. Any change that breaks the compile or test-harness is sin plain and simple. If a project can't maintain that standard with their tools then their tools are a problem. If the developers are so skilled at flaking diffs from their working copy like cavemen flaking arrowheads from stone, then there is no problem. On the other hand if merging changes is a problem, then there is a *big* problem. I don't think merging is something you do for release, it's something you do to integrate the work of a team. If you can't merge you can't work together. If anything branching is for release, not development. My 2 cents at least. Please don't take any offense from any of these statements. No person or caricature was harmed in the writing of this mail. Cheers, Mike Mattie (peanut gallery)