added tag/revision support for git and included native protocol support

wow - cool patch!

Would love to review this patch, but the splitting of all the download classes into their own include files should be a separate patch for review. Please reroll this patch without the split up. Thanks!

Whoops, wrong status.

subscribe

Blackice2999, looks like you've got tabs for indenting. Also the comments could use some formatting. You might want to review the Drupal Coding Standards.

In regards to the comment about calling it 'commit' rather than 'revision', I think it's named that so it matches up with the other VCSs

Please follow the coding standards at http://drupal.org/coding-standards. Specifically, look at the if statemnets. Also, you have one mis-indented break.

What a wonderful example how to get rid of any contributions and kill any motivation.

Keeping an eye on coding styles is fine - but finding them and holding back a patch because of this - again and again is kind of king / slave behavior.

The bahavior of Contrib-Maintainers in Drupal in general far beyond any acceptable level.

_A contribution is a gift - not a threat_

@EugenMayer: there are certainly many examples of king/slave behavior to be found on d.o., in particular in the CVS application queue, but I don't think this is one of them. The style of the code is just as important as its content in a project where many different coders must be able to understand & contribute. Dmitri donates (or gifts) a tremendous amount of his time, but it's still limited - would you rather have him working on fixing up style, or on the next great project like drush make? Dennis is indeed going through a pain point, but once he learns drupal's coding style, he's good to go...

As i stated, iam fine coding styles. And i love the modules Dimitrij has created no doubt about that. And iam thankful for that modules!

But this educational "iam the teacher and you are 5 years old" manner is simply not a good way to treat people who contribute. Iam pretty sure Dennis will think about a contribution the next time.

What would i find to be better?
Well if that are only trivial coding styles and nothing really logic / syntax related, i would expect the maintainer to simply correct those, if he already found them. I mean, if we talk about more then 5 minutes work for the maintainer - iam fine with giving the patch back to the contributor for fixing those.

This simply must have a relation which can be seen as a "good relation between two adult persons".

Here, its a classical "Iam up - your down" kind of thing. And this often results in nothing productive - but rather in frustration. I just seen those things too often, eventhough iam not too long within the community. I see that maintainers seem not to have any respect left for contributors, they are only "small grubs" and treated like that.

This results in "contributors" gets "filtered" and what is left then:

1. People who just post the issue (with only few details) and fire and forget the. Never come back - never react on "maintainer needs more infos". That means the maintainer has to deal with it all by himself. Why they still post issues? Because they never "get to be treated like that"
2. People who try to contribute, investing time for development / feedback / discussions. but after the second or third time being treated like described, they most probably will stop.

And you know what, currently drupals "issue queues" are are full of 'class 1' people. And class 2 people are getting rare and rare - after some time they dig into a hole and start creating one personal micro-fork after the other. And this lets the quality of modules go down rapidly... and even then, afterall maintainers are dissapointed by the missing "subtlety and gratefulness" and retire from active maintaince letting the modules become a buggy ghost. And thats what we have today. A park of 6000 modules with more then the half being a mine you just about step into. It results in a gazillion of forks, which then become ghosts again.

I would love to see that become normal and both sides of the conversations should feel to be treaten by a good level of respect and kindlyness. This will bring back quality contributions which will be good for both sides.

I don't believe this conversation is at all helpful to the issue. I actually wrote up a very long response but I'm not going to post it because this discussion is really counter-productive.

Dennis, your patch looks great. I'll try to get to it later tonight after I take care of the patch I'm working on right now (it's taken my like 3 weeks so far).

Hey Dennis,

I don't actually know so much about the git area of drush_make, but I have another maintainer who does, so I emailed him last night. He's usually pretty responsive, this will probably get committed today or tomorrow.

As for working copy per-project, I'm not sure that that's would be best. What do you see the benefits of that as being? The reason we decided to have it set globally is because you can work on a "development" copy of your site, where you can commit to modules and update them from right there (because you have your .git or CVS or whatever), but then if you wanted to make a "production" copy or if you wanted to ship it out (as the openatrium developers do), then you make it without --working-copy.

This patch has been committed with a few minor changes http://drupal.org/cvs?commit=384220.

For reference, I began reviewing this patch about two and a half hours ago. In that time the following changes and reviews were needed before it was ready to be committed:

• The patch was generated against the 2.0-beta6 release of drush_make and not a recent checkout of DRUPAL-6--2. It did not apply cleanly to the current state of the project and required manual application.
• I made a few minor stylistic changes to the contents of the patch (e.g. protected function getUrlParts rather than function _getUrlParts).
• I wrote a test for the functionality provided by the patch (branch, tag, revision and usage of git:// and ssh:// protocol repository URLs).
• I manually tested a complex project makefile with the --working-copy flag and without to ensure that no regressions occurred.
• I updated the documentation in README.txt to account for the addition of the tag option to git.

This was a great patch and much appreciated. At the same time code style, documentation and testing all do not take care of themselves. I hope it's clear that we are not looking for excuses to reject patches.

Please start a new issue about designating individual projects to be built as working copies -- note that this may be a feature agnostic to the specific version control system used (e.g. the same flag may make sense for svn, CVS, git, etc.)