Drupal And Git

I noticed some modules (like GMap) have empty folder in its Git repo. By default, Git doesn't register empty folder. If so, then how does Drupal.org git system accept empty folders into repository?

Hi guys
I am facing a problem of changing the git author like as you see here https://drupal.org/node/1310686/commits .The first three commits are by naveenvalecha. can I change the name of naveenvalecha with nitingoyal ?
if it is possible then how can I change the username ?

Greetings, I am struggling with how to setup my Git workflow in terms of my local dev multisite vs. live and how it relates to Git. My setup is that I have added a multisite to my main site which is in Git. So in /sites directory I now have:

subsite1.example.dev, the main site being example.dev. For the main site having a '.dev' extension has not been an issue but now for subsite1.example.dev, I can see this is going to be an issue as on my live site, it will be subsite1.example.com.

Hello,

I'm doing some housekeeping regarding the releases of the Workspace module, but I cannot update some releases using Git as they are locked:

• The nearly three year old workspace 6.x-1.4-rc1 never made it to the front page in the first place. Git is complaining about some tag conflict.

I got (Bad internet connection, server error, browser problem, Please try again shortly.)" error in drupal6?

I'm new to git. I own and have read the Pro Git by Scott Chacon. I can make repo's locally on my Windows 7 desktop and clone them. I can create repo's on my SSH enabled Dreamhost account and can clone them on my shared Dreamhost server.

For the love of God, I cannot clone a Dreamhost repo to my local Windows desktop! It is driving me nuts.

I have ssh keys set up and can log into the dreamhost shared server via my local machine within the bash shell, so my ssh seems to be set up correctly. But I cannot get a clone.

OK, so we're building up a list of puns that's going to quickly exceed our need for them... So here's a page to store puns until we can figure out what to do with them!

dogfather -- ?
dog leash -- a repo tracked by dog
dog pound -- an upstream, read-only repo
dog kennel -- a collab, read/write repo

dog-rollup or dog-walk -- git push
dog-rollout or dog-sit -- git clone

Here's the gist for a updated dtd https://gist.github.com/1252419

Since the authorship changes on edit, please note: this was originally written by sdboyer, so first-person pronouns refer to him. He prefers IRC for talking about dog - use #drupal-vcs or #drush

In DrupalCon we had BoF about DOG and aspect of configuration management (later CM) came up.

What we need to do related to configuration management is to decide what are our goals.

What i mean by configuration management is that when site is being deployed to certain (or several) server (local dev, testing, live...) DOG can make needed changes in order to apply those settings. If you understand configuration management differently or have different need/use case for CM give us your opinion.

So basically there are (attleast) two open question.

Hi

First of all, apologies if this has been asked before... I've search around this group and can't find any duplicates.

I'm getting into Git at the moment and was wondering what strategy people use for database modifications when pulling code to a production server. Obviously, Git is brilliant for the code side of things, however I can't seem to find a good solution to sync up the staging database with production without losing any live data and content.

Any tips and advice would be really appreciated!

James

Sam Boyer writes:

Our method for giving contributors credit sucks. We can't do realtime statistics of essentially any kind since we're reliant on parsing commit messages in a broken fashion. In the discussion we had about git workflows, I mentioned that we could use Git's notes feature to solve a ton of our problems related to giving credit where credit is due.

Basically, notes are a way that you can attach additional metadata to a commit. Lemme break that down:

<

ul>

Hi all,

I'm a total newbie working on git, trying to set up version control with drupal. Hope this a right place to ask... otherwise just kick me off.

My aim is to use an external service (either bettercodes or gitenterprise) to host a remote repository for my drupal projects.

i followed the instruction on this page : http://drupal.org/node/803746
I success only If i just grab a tar.gz from d.o, set up locally, then push to the remote repo.

In case i take my drupal copy from git.drupal.org, perform the same operations, then push, i obtain these errors (gitenterprise)

git has replaced cvs as the version control system for drupal. -

There is a number of articles on to how handle git
but they don't really address the needs of site maintainers.
I am aware that this is a developers' group but since I found no better place to turn to...
... let me git it a try, anyway.

I have found no article specifically dealing with the needs of drupal admins
when having to MOVE FROM CVS TO GIT ON PRODUCTIVE SITES.

Let me ask a couple of questions as a site admin on Linux systems
on what to do in order to successfully move to git.

--> Actually I am going to tell you how I used to do things via cvs
hoping to get hands-on tips on how to do them via git.

This is a summary of the main points I got from a long IRC chat I had with Sam Boyer about how the initiative leads should best work with git. (heyrocker)

One sandbox vs multiple sandboxes
One sandbox - All code in one place, separate projects into branches. Bummer is that issues are all mixed up in one queue.
Multiple sandboxes - Get nicely isolated issue queues, but code is scattered all over, and it can make it harder for someone wanting to get an overview of the entire initiative. Also people working on multiple bits have to jump all around.

The testbots now use git to apply patches, so binary patches and copies/moves work in patches. See the issue.

To create a binary patch: git format-patch --binary --full-index --stdout

To create a moves-and-copies patch (one that magically moves and copies): git format-patch -C -M --stdout

Hello,

I am a lazy developer.

Could we have a file upload field on our project page on drupal.org, where we can upload a zip file and that would take care of all the committing the code to the project? :D

I am pretty sure a large percentage of the projects on Drupal are one man shows, and I believe it would be sufficient for a lot of devs. :) In the backend of course there still would be git...

Would be sweet.

Git, CVS, ssh, drush is all great stuff. But sometimes I just wish I wouldn't have to care. :P

Building a Drupal project using git is different than building Drupal itself, and requires its own workflow. I've been kicking ideas back and forth with Sam Boyer lately about how to make this process take advantage of all the Git power, but also be newbie-safe and as frictionless as possible. I think what we've come up with is pretty good: there's even code written! The process I am going to explain allows the following:

• Git-based updates for Drupal core and contrib
• The ability to patch/tweak core/contrib without the complexity of vendor-branches
• Portability for local development or Git-based deployment
• Unrestrained custom development: feature branches, tags, multiple repos
• Safe patterns that minimize conflicts and provide a clear resolution process

Pretty cool, eh? Expect a larger manifesto post from Sam in the near future, but for now here's where we are heading.

Now that Drupal is making the move to Git, I imagine lots of Drupal shops will be too. Ours is definitely among them.

I have been reviewing the various documentation (http://drupal.org/node/803746) and blog posts oriented towards site builders on this topic over the last few days, and it seems there are many very different recommendations a approaches to building sites with git. There is an opportunity here to shape some best practices that will both make everyone's lives easier in the long run, but also encourage contribution back to the community as a standard part of building any Drupal site.