At last my Git repo is set up. And that's all there is to it really. Now it is time to discuss how to use it.
Firstly note that in the directory you created, Git has checked out MPIR trunk and placed it in a directory called Git. It looks for all the world like an svn working copy in TortoiseGit. The first thing I want to do is: 1) Create a branch. Now in svn that would be a bad thing to do as it would take forever, and copy the entire repo, and I'd have to do that via the central repo. Not with Git. In fact creating and merging branches is actually what you normally do on a day-to-day basis. I'm going to play around, so I'm going to create a branch. So to do this unspeakable act, I simply right click on my new mpir folder that Git created. I click Tortoise Git->Create Branch. I give my branch a name: test, in my case. I also click the "switch to new branch" radio box. The whole creation of the branch and switching to it took.... oh well I couldn't measure it, it was a fraction of a second. 2) Edit some files and commit. I simply play around and edit the files however I want. For this test I am going to open the document /doc/devel/FILES. I add an additional line to this file and save it in my text editor. When I'm done I right click and select `Git Commit->"test"'. Note, this commits to the test branch of the Git repository on my local machine. It DOES NOT TOUCH the svn repo. In fact I could be on an aeroplane without internet access and do this! I fill in a log message describing my commit, exactly as if I were committing to the svn repo. If my patch ever gets merged with MPIR svn, this log message will actually show up there. But I'm not worried about that just now. I have more work to do and other patches and branches I want to make. 3) Edit some more files and commit. Note I am making multiple commits locally, and still haven't touched svn. 4) Make another branch. I want to create a new branch which doesn't have the changes I have made to my "test" branch. I right click and click Tortoise Git->Create Branch. I give it a name, "test2", but I select that it is based on Branch "master". Again I switch to the new branch. 5) Edit some files and commit. Firstly note that if you go into the files that were changed in the test branch, they are back to the way they were before. This is because I based my new branch test2 on the master branch, not on test. My changes to test aren't lost. I committed those to the Git repo. It just keeps track of all the different branches I've been creating. So I edit a file, commit to test2 and fill in a log message. 6) Switch branches. Actually I'm really bored of working on my test2 branch, in fact it is done, and I want to switch back to my test branch and do a little more work there. So I right click on the mpir directory and select Git->Switch. I select "test" as the branch I want to switch to, and my test branch is back. 7) Edit some more files and commit. These get added to my test branch, but not my test2 branch. 8) Merge. I'm now actually finished with my test2 branch and I want to merge it with my test branch. I right click and select TortoiseGit->Merge. I select From test2, and To test. It merges all the changes from my test2 branch, into my test branch. 9) Rebase. After working on numerous patches, I notice that there have been changes to svn and I'd like to get the new changes and try them out against my code. Unfortunately the TortoiseGit rebase appears to be broken (it sat there for an hour rebasing, but forgot to check out the new changes from svn, which was the whole point). Fortunately coomand line Git works fine. Simply right click on the mpir directory and click "Git bash here". This brings up command line Git. Type "git svn rebase". It takes about as long as an svn update and you are done. 10) Commit back to svn. Well, if you have svn access, this is easy. Again you go to command line Git and you type "git svn dcommit". It takes about as long as a regular svn commit and you are done. Note it will only commit from the branch you are currently switched to, and as always you should make sure your Git repo is rebased against current svn before trying to commit to svn. If you don't have commit access, you have a few choices. If you've cloned your repo so it appears somewhere public (e.g. the sage.math machine) you can simply push your changes there and let people know. They can then pull your patches from your public repo. This is the preferred option. If not you have to make a patch. Right click and select "TortoiseGit->Create Patch Serial....". Click the ellipsis and navigate to the directory you want to create your patch in, e.g. your desktop. Select a range of commits you want to put in a patch. Click "send mail after create". Once the patch is made an email dialog will pop up. Fill in the email address of the person you'd like to email the patch to. Select the "patch as attachment" option. If you are unable to send an email in this manner you may have to do some configuration. Alternatively just email the patch file you created in the normal way. 11) Apply someone else's patch. So someone emailed you a patch. Right click on your mpir directory and select "TortoiseGit->Apply Patch Serial..." First you have to tell it where your repository is. Then when it asks, navigate to the patch file and select it. Then click apply. You might have conflicts, which you'll have to resolve. But if all went well the patches applied cleanly against your repo. There's heaps more you can do with Git (especially the command line version), but that covers the basic workflow. Bill. 2009/7/16 Bill Hart <[email protected]>: > Hi all, > > I strongly believe that now may be the time to start encouraging > the use of a distributed version control system for MPIR development. > I have thought very, very carefully about this issue for a very long > time..... > > I have finally convinced myself that the *only* system which is > capable of doing everything we want is Git. I formerly opposed > using Git for three main reasons - lack of decent Windows support > steep learning curve and very bad documentation. However, after > revisiting these issues, I see they have basically all been dealt > with by Git developers. > > Let me say right from the outset that the central repository will > still be maintained with subversion. What this will mean in practice > is that the main releases of MPIR will be available from the > subversion repo just as they always have been. Also, the core devs > will still be the only people with commit access to this repo. But > this "version" of MPIR will only be the one which is released on > the MPIR website. With Git, there is nothing stopping you having > your very own "version" of MPIR! > > By the way, it is quite common for people to use Git with a centralised > repo managed by svn. It maybe not what Linus Torvalds intended when > he added such good svn support, but who cares. > > If you wish to develop for MPIR, wish start your own branch to try > something out, or even fork MPIR if you want to, Git makes this > very easy. There are ways to make HG do the same as what I will > describe below for Git, but svn linkage is a standard part of Git, > a major factor in the final choice. > > Note Git is now available for 32 and 64 bit Windows and numerous > other systems, including linux of course. > > Basically Git can be used on your local machine to produce a whole > pile of MPIR patches and then once you submit them to be included > in a release, we can trivially pull them into the svn repo, and no > one would even know you had not used svn! > > That's great, because the devs who want to keep using svn can > do so, and absolutely nothing will change for them. As far as they > are concerned, you may as well have committed your patches using > svn, directly to the central repo. > > Not only that, but you can pull patches from other devs writing for > MPIR, who are using Git, without having to wait for an official > release. You can even make or use a set of patches which don't ever > make it into an official release, and even distribute them to others. > If we decide we want them, and you are making them available > somewhere, we can just pull them and away we go! > > The main reason to want to do all this, is to avoid having to make > branches in the central repo. With Git, you can make branches trivially > on your local machine and even do your development with a group of > other developers, making lots of commits to your branch, and no one > will even know about it. Only when you are ready do you announce your > new branch to the MPIR team will we pull it from you and give it a > whirl. Then it'll basically be ready to go, and we just issue a release > with your new changes and any others we like. > > There are lots of other nice things too, but it's best that I get down > to nuts and bolts here and leave all the nice features of Git for > individual developers to discover. > > I'm going to, right now, go through the process, from scratch, of getting > Git for my machine, which happens to be a Windows Vista machine, getting > the MPIR repo, making some commits locally and then making some patches. > I'll also describe how to rebase against the svn version, which you'll > want to do every now and again when important commits get made to the > central repo or when a release is issued for example. > > Warning: though the initial setup takes very little user intervention, > the check out process takes a few hours. This is very necessary, so Git > can create a proper local repository for you. However, once you set > it going, you can just leave it go and it'll happily sort it all out > for you. You only need to do it once, EVER! > > Step 1: Install MSysGit. This is command line Git for Windows. It can > be obtained from the main Git website: http://git-scm.com/download > > (If you had some other kind of system, such as linux, you'd get the > appropriate package for that system.) > > For me the install Just Worked. I selected the "Run Git from the Windows > command prompt" option during install. For all other options I selected > the default options. > > Actually command line Git is ready to use at this point, but we'll go a > little further to make things easier. > > Step 2: Install TortoiseGit. I have a 32 bit Windows Vista, so I get the > latest 32 bit version here: > > http://code.google.com/p/tortoisegit/downloads/list > > I select the OpenSSH option when installing, otherwise all default options. > Again the installer Just Works, though a restart is required. > > Step 3: Get the MPIR trunk from svn. In a folder I created, I right clicked > and selected Git Clone. In the dialog which pops up I enter the MPIR repo > address: http://modular.math.jmu.edu/svn/mpir/mpir/ > > I select the "From svn repository" and "Trunk" radio buttons. Git now does a > *lot* of very clever work and creates a local Git repo of MPIR trunk on my > local machine. This step takes Git a *very long* time, but it never has to > do it again. Get a coffee or have a sleep or whatever. > > Another option, which will be faster, is to clone someone else's git > repository, > though if you want to keep up with the central svn repo, you will have to > wait > for them to rebase before you can get the updates from them every time. That > won't be a problem if you are working with a group of people on MPIR, as only > one of you will need to stay up to date with the svn repo and the rest can > just rip from them. Otherwise you will have to wait, just this once, for Git > to get all the (thousands of) recent revisions from the central svn repo. > > More to come when *my* machine finishes building my local git repo..... > > Bill. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
