I decided to update core via git, mostly by following the approach explained here.

I did this (in my local repo, dev branch):

git remote add core git://drupalcode.org/project/drupal.git 
git fetch core
git merge 7.21 
(resolved few conflicts)
git commit --amend
drush updatedb

I did this for the sake of making it easy to update core in the future, as proposed:

git fetch core 
git merge [new commit hash]
  • Am I adding too much to my project by fetching all core history, or is this needed? I am interested only in updating core in my existing project.

  • If so, can I get rid of the core history?

  • Can I in next core update fetch only by tag?

  • Thanks for edits kiamlaluno, have not spotted that i messed up code formatting :) – NenadP Mar 8 '13 at 20:03

Drupal.org suggests a similar approach. But, I'm not sure I understand the need to keep core's history under your own repo either. Or any code you yourself didn't create or amend.

Why not just have your repo at /sites/? And have your ignore file leave out anything you haven't touched, including unmodified modules from drupal.org (and all the stuff in /sites/default/files/). Then you're workflow could be to use drush to update core, modules and themes and use git for all your own code. Use drush rsync for files when working between local, dev, stage and production.

Side note: I'm glad to see this question here because this is something I've been wondering myself and though I don't use the approach I've just suggested, I'm thinking about it.

  • This seems like a good proposal. But I do not how idea how I should do it best way. How would i efficiently maintain repo in repo. If you would use this way, how would you implement it? Thanks! – NenadP Mar 14 '13 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.