This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:
The latest HEAD commit which was pulled into the issue specific branch is detected.
A patch is created against the detected HEAD.
The Issue the patch is for is updated with a link to the repo, the patch and the tag message. The status of the issue is set to code needs review.
The patch is tested by the testing bot, and issue status is updated accordingly.
The patch is reviewed, reroll requested etc.
The dev now just modifies his branch and then tags with another magical tag, and the issue is updated again... etc. When the code was comitted to HEAD, we could even auto-delete the branch of the developer (if it's in the same state as it was when the last patch was created). For retaining the patch development history, better annotating of HEAD etc, the comitters of HEAD use git pull to get the code, the patch is there to make it easier for other people to review code.
That's it for now, I'm interested what you'd think about this!
Comments
sounds interesting
I wouldn't have thought of auto-integrating the commit workflow that deeply into issue queues. It might take a bit of thought to make sure that only changes are pushed to the issue queue that the developer wants to have actively reviewed, but the idea might have its merits. But it's only cool if standard "non-magic" patches can still be done without further hoops. The part where the HEAD commit is auto-merged back into the issue repo sounds to me like it might break easily, there needs to be a lot of thought to make that happen.
missing anything?
I was thinking about that, and the benefits of this proposed new workflow are two:
This is a simple task using git.
I know automating tasks makes all simpler, but I really do not get the real benefit of these changes. Please do not misunderstand me, I'm really a pro git, but I think the DVCS natural way works exactly in the same way.
Also, IMHO one of the great DVCS strengths is own public repos, that make really easy to collaborating through patches. I mean, you can work pointing to 3 developers public repos for issue A, 2 others for issue B, etc. And, ATM, I do not see these integrated on issue queue workflow
Projects like git itself and linux use the dev mailing list for patches interchange, but here issues seems like the drupal place I'll propose.
If I miss anything, please correct me ;-)b
I think something like this
I think something like this would be just the logical continuation of what we already have for contrib/ - releases which are dependant by some VCS settings. For core, we have atm two different workflows:
a) big stuff, like DBTNG etc:
create an external svn repo, give the important contributors an account there, when done, create a huge patch - all commit history is lost.
b) the rest
A dev creates a patch at home however he likes. Doing stuff together is not really possible, at least in no paralell way, it has to be serialized by the issue tracker, and I don't think that there are many patches with more than one main dev.
With some sort of integration into d.o, we could
a) keep the commit history, giving better credit when there are multiple people, etc.
b) when not using developer specific repos, but maybe kind of per issue-repos (there would be lots of repos, though, not really handy I think) then contributing to a patch would be as simple as hitting a button on the issue tracker (aka "let me help here") and one would get commit access, so one can collaborate with the other devs trying to resolve the issue as fast possible. Sure, this doesn't replace irc meetings to get things coordinated and to not duplicate work.
it's more clear now
I see three alternatives that solve the problems(keep commit history and let work together):
Here there is some which branch do I have to rebase/merge problems, but doable.
Repositories are not really cheap, and because of the number of issues maybe this is not a really good idea. But it lets make it simple where to push, but there would be moderating work(some way of ban some not helping commiters, I'm really not sure is this should be necessary).
This is really cheap, but I'm not sure if we can restrict access per branch (I suppose we can do it from git hooks :D). This alternative the one that more convince myself.
what option do you prefer(maybe not listed)?
I'm unsure if we want either
I'm unsure if we want either 2 or 3:
For 2 speaks, that we can easily restrict access to the developers how signed up on the issue, it's clear where the stuff is developed, no long list of branches in the online-viewer.
Against 2:
We'd need to set up a repo for every Drupal 7 issue up where the developer requests this (so we can leave out discussion-only and won't fix etc issues).
For 3:
access based on branches is probably possible, same as 2 then.
Against 3:
I'm not sure how we handle that the developer doesn't get every damn branch in this huge issue-repo but just the branch he's working on. Also we'd need to keep this repo's master in sync with HEAD, this would allow the developers to just pull from the origin repo's master branch to chase HEAD for their patch.
Given this, if 3 is somehow possible without cloning all issues with which is dealt with atm i'd prefer 3, else probably 2.
Thinking about this a bit - I
Thinking about this a bit - I think it might make sense to add issue branches to the "official" repo for contrib projects - especially if they are automatically deleted some time after the issue is marked fixed. The resolution of the issue will be expressed in the commits to the main line branch - but it's possible there wold be some information loss in terms of alternate approaches? I guess we could also consider per-user per issue branches, and only delete the ones that get fully merged into the relevant branch.
For drupal core (and as an optional approach for larger contrib projects) I think a sandbox repo per user per project makes sense. Otherwise the list of branches will become impossible. I'd think in general we'd want to allow automatic creation of a snabox repo for any existing project - i.e. like github I can fork into my sandbox any existing project.
It would be nice even if we could block pushes to the master and each main version branch and do automatic pulls from the official repo. This would avoid a little of the setup and learning curve of having to merge from a remote to keep your repo in sync. I find this one of the frustrating things about github - there is no automatic way to keep some branches in sync with what you cloned from.
Don't run before learning to walk
Some of the ideas here are interesting, but my overall impression is: We're getting ahead of ourselves.
Today Drupal development relies on patches. You download the code however you like (though that often means "CVS", in fact only the committer needs to use CVS... us worker bees are free to use whatever we like). You make changes. You roll a patch and you upload the patch. The testbot deals in units of "patches". If a patch is stale, because the project it is meant to apply to has changed too much, it has to be "rerolled" in order for the testbot and the other devs to apply it. Eventually the patch is applied by hand to a fresh checkout of the project and committed.
At this moment I don't see any reason to change that process at all. Not on day zero. Git is perfectly equipped to work like this, because my understanding is that the Linux developers, who developed Git for themselves, often tend to communicate by... emailing patches to each other.
The effort in the initial Git conversion should go toward getting the existing workflow up with Git in place of CVS. And that's all. That is going to be enough work. Don't reinvent everything at once.
(One major advantage of that plan: We don't have to turn every Drupal developer into a Git wizard overnight. It should not be necessary to understand Git remote branching in order to contribute to Drupal. That might be an even bigger usability trainwreck than we have now.)
Now, once there's a core Git repo and a bunch of contrib Git repos (one for each project) we can consider more steps. One would be to try making the testbot optionally accept a URL and a tag name which point to a commit in some Git repo someplace (in a developer's sandbox on drupal.org, or maybe even anywhere) instead of a patch. Then the testbot would autogenerate a patch from the URL+tag, as suggested above. And people reading the issue queue have the option to test a patch by cloning its parent branch with Git, rather than downloading and applying the patch.
I'm not even convinced that that small change is a good idea. I'm entirely unconvinced that autogeneration of patches will prove to be reliable or comprehensible. It will have to be tried. And I don't think today is the the right time to experiment with it.
(The idea of using a special tag in a specially named branch to signal the testbot to autogenerate a patch is just an elaborate special case of submitting a Git URL+tag -- one that is, IMHO, much too closely tied to Git. Again: We should avoid forcing non-maintainers to learn Git unless they want to, and we must certainly avoid forcing them to learn how to manipulate remote branches. One of Github's best features: You can download the HEAD of any branch in any repo as a tar or gzip file by clicking on a link. You don't need to know thing one about Git to use Github.)
[EDIT: Git URLs just point to repos. To specify a specific commit in a repo you also need to provide the name of a tag, or a SHA1.]
What about setting up an Eclipse plugin
Thanks for the post. I totally agree with you. I use Eclipse for now. Was thinking of using Komodo Edit for Drupal. I have looked at a the Drupal code base often but never committed because the current process is too complicated and/or undocumented. How to find proper documentation?
If the process is more complicated it will certain raise the bar and keep more people out.
Thanks for all your work everyone!
Drush rocks,
Pete
+1 to Mike's points. While it
+1 to Mike's points.
While it is tempting to make major changes to our workflow, just changing the technology while not changing the workflow is a better first step.
Even if we still do patch rolling, it will be much easier to do w/ git. Plus, it will be much easier for developers / companies to use Drupal and Drupal modules in "vendor branch" type configurations. Those are both huge wins in themselves. Oh, and the pressure will be on FreeBSD to quit smoking the CVS pipe and put the SOB to rest.
-J
"A successful Git branching model" (article on nvie.com)
Great article on best practices for Git workflow ... just tossing this out for review:
http://nvie.com/posts/a-successful-git-branching-model/
having an error
I have run this command
git push origin 6.x-1.x
error: Cannot access URL http://git.drupal.org/project/exmple.git/, return code 22
fatal: git-http-push failed
I dont know how to fixed it , can any one help me out?
http url is read-only. Clone
http url is read-only.
Clone repository by git clone [...] username@git.drupal.org:project/drupal.git
After that when you have committed you can push and pull to server to projects where you have write access.