The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

A sane(r) workflow to submit work to github

Submitted by nk on Fri, 2013-03-29 21:24

It really frustrates me that while github nicely automated forking, there's no "update fork" button. For me, it's tedious and difficult to juggle two remotes. Instead, I added a single line to .git/config:

[remote "origin"]
        url =
        pushUrl =

Now, I pull from the upstream and push to my own repo. Also, git config push.default current will make git push work on a newly opened branch instead of whining about the need to run git push -u origin branchname. I like it so much I have git config --global push.default current.

Edit: if you had a clone before this, do not forget to make sure that your branch in .git/config uses the "remote" origin:

[branch "develop"]
        remote = origin
        merge = refs/heads/develop

Commenting on this Story is closed.

Submitted by decibel.places on Sun, 2013-03-31 04:21.

Our environment has multiple branches: dev, test stg/prod where stg is considered a mirror of prod before pusing to prod.

In development, there are forks of the dev environment, branches of the dev environment, and sometimes test falls behind dev and stg/prod for regulatory testing.

I like this setting to pull from the upstream and push to the personal repo. But it would become much more complex in a typical web application dev/deploy environment, wouldn't it?

Submitted by nk on Sun, 2013-03-31 19:09.

obviously this does not always work but it does work in enough situations that it's useful.