On Wed, Mar 2, 2011 at 7:10 AM, Sam Boyer wrote:
>> Also, if you want to manage both core and contrib modules that way it
>> means you are now using git submodules, which it's generally agreed suck
>> AFAIK, or complex sub-tree merging that is out of reach of 99% of
>> developers. Hell, I've done
On 3/1/11 12:17 PM, la...@garfieldtech.com wrote:
> Unless there's something new in the packager I've not seen yet, using
> d.o pulls in production bypasses the packager. That is, you're then
> missing:
>
> - The full version information in the info file, which is used by update
> manager.
> - Th
Larry,
There is the awesome Git Deploy module that will go out and interface
with git meta data and update.drupal.org to determine the correct
version information for any module checked out directly from Git. I'm
90% sure that it doesn't even require the git binary to be installed,
just a PHP
> On 3/1/11 7:53 AM, Fahri Reza wrote:
>> how about doing shallow clone with
>> $git-clone --depth=1
>> then run recursive-diff on the sub-directories (n=1 is just an example)
>>
>> can someone gives comment whether this approach is recommended?
>>
> Clone with depth parameters will help reduce s
Unless there's something new in the packager I've not seen yet, using
d.o pulls in production bypasses the packager. That is, you're then
missing:
- The full version information in the info file, which is used by update
manager.
- The License.TXT file that every module is supposed to have.
There is a lot of discussion and ideas about git work flows right now.
It will probably take some time for best practices to evolve and gain
acceptance on d.o
Regarding the main branch, others have said it seems pretty useless when a
release (dev in particular) cannot be attached to it anyway.
I t
Clone with depth parameters will help reduce size, yep. Not sure what
you're going for with a diff on subdirs - if you mean diffing modules,
then diffing subdirs really depends on how you've chosen to compose your
tree - submodules, subtree merges, or plain nested repos.
On 3/1/11 7:53 AM, Fahri R
On 3/1/11 8:13 AM, la...@garfieldtech.com wrote:
> I think the question is more about non-custom dev history; there's
> little need for a client site to have the complete development history
> of Drupal 4.3 in its repo, for instance.
So you do a shallow clone that skips irrelevant branches and o
On Mon, Feb 28, 2011 at 11:59 PM, Eric Sepich wrote:
> What say the group?
> Thanks!
I hate to say it, but I think you're in the group group. This is the
group for programming problems, not site construction problems. You
should try the support mailing list.
--
John Fiala
www.jcfiala.net
Yeah, I don't patch core often enough to need an elaborate patch
management system. :-) Just checking patch files that are clearly named
into the repo is usually fine.
--Larry Garfield
On 3/1/11 10:30 AM, Marco Carbone wrote:
"That keeps me on real releases, avoids unnecessary repository blo
"That keeps me on real releases, avoids unnecessary repository bloat, but
still gives me a full history of all work on that project specifically."
Well, svn or whatever VCS one is already using could be used this way as
well. And it doesn't really address the issue about managing patches, which
pr
I think the question is more about non-custom dev history; there's
little need for a client site to have the complete development history
of Drupal 4.3 in its repo, for instance.
Lately, what I've been doing/advocating is using Drush and real releases
to download stuff from Drupal.org (core, c
how about doing shallow clone with
$git-clone --depth=1
then run recursive-diff on the sub-directories (n=1 is just an example)
can someone gives comment whether this approach is recommended?
-- fireh --
At the top of the hour we'll be doing live interactive "Git on Drupal.org"
training. http://groups.drupal.org/node/130014
You're welcome to join.
If you'd rather just watch the ~20 minute screencast:
http://vimeo.com/20459209
And of course, git documentation is at http://drupal.org/documentation
I think your last statement feels correct to me. IMHO using a vcs for
deployment is great for developers and clients who are contibuting back to the
codebase, but that customers would be muched better served by being kept up to
date with releases rather than individual patches.
Sent from my
Hello to all,
I look for one or more developer(s) enthusiastic about leveraging the
Drupal features to develop an Installation Profile dedicated to on-line
democracy. This Installation Profile would be called KuneAgi. Purpose of
KuneAgi is to design action programmes collectively and democrat
On Tuesday 01 March 2011, nan wich wrote:
> The way I approach things like this is that I am not a permanent employee
> of the company, therefore I do not acquire assets for the company if
> that asset outlives my tenure. I do this whether that asset has a cost or
> not. I won't even get a Google A
The way I approach things like this is that I am not a permanent employee of
the
company, therefore I do not acquire assets for the company if that asset
outlives my tenure. I do this whether that asset has a cost or not. I won't
even
get a Google Analytics key, which is free. Someone who is p
On Tuesday 01 March 2011, Gordon Heydon wrote:
> Hi,
>
> I have a new client and they require me to get an SSL certificate. Ideally
> an EV certificate because they detail with financial information (not
> credit cards) and would ideally require a higher level of identifiable
> security that what
19 matches
Mail list logo
