![]() ![]() In the devel directory, I now patch -p0 <~/tmp/dummy_demo.patch We'll say it's at (I always right-click to copy the link, then wget -directory ~/tmp ). Now I'll download and apply the patch.It's for me to figure out why I made the branch.) git checkout -b devel_generate_866608/04 (There's no magic in the name of that branch. I'll create a branch for that, off of my 6.x-1.x branch. Let's assume there's already a patch in #4 of that issue (by somebody else) that I'm going to work from. Now let's say that I have an issue I want to work on, maybe #866608 about a devel_generate fatal in a particular situation.I'll find out what branches are available and then create a tracking branch (one that can be updated with git pull) for 6.x: cd into devel and (if you're not working with CVS HEAD) switch to the correct branch.One time only: cd into sites/all/modules and git clone git:///project/devel.I'll use devel module as a working example: Contrib or core patch workflow as non-maintainer (not committing via CVS) I'm not going to show every detail or nuance, just the basics of what I might do on an ordinary day. Everything but committing works, and committing is something I do less often than all the other parts of the workflow. So how do I use this for real work on core and contrib? Easy. Cloning core (the drupal project) would be git clone git:///project/drupal. So if you want to clone the Examples project, it's git clone git:///project/examples. The git repositories at are at /project/whatever. There are lawyer-notices on the web-view at that say that it might go away (or more likely, have its hashes invalidated) but in my opinion, the risk that this will hurt you or me if it happens is not very high. It will make the migration so much easier if you already have the basics working before we get there.įirst of all, we already have a git mirror at. I encourage you to start migrating to git now. When you comment and suggest your alternate approach, please try to point people toward things that will work in the long term in the Git migration. ![]() And maybe I can get some hints about how to do it better! But I'm quite happy with how this works. I write this not because it's the only way to do it, but to encourage people to start the git migration and to start a conversation about transitional workflow. sirkitree challenged me to write down my workflow the other day so we could compare and contrast. All thanks to who bulldogged this to the ground.Įven though the Drupal CVS to Git migration will take a few more months, it's possible to start using git now for nearly everything you used to do. Update 19 December 2010: Our repositories are now updated within 5 minutes after a commit, making this workflow far more usable.
0 Comments
Leave a Reply. |