I love to get on the soapbox on this issue, so I'll throw in.  First, I agree with the statements below.  Topic branches that correspond to JIRAs are clean and easy to track.  In SwitchYard, we also prefix the commit message with the JIRA ID just to make it easy to jump from 'git log' to JIRA without a search in between.  

On the subject of rebase, let me just say that merge commits are the devil!  For example :-)

https://github.com/forge/core/pull/149

We ask anyone that issues a pull request to rebase against upstream master as a courtesy.  Tends to prevent messy merges for the person pushing the change and also allows for a clean push on top of upstream tip.  There are always times when someone submits a pull and then I push something ahead of their commit.  This is easy enough to correct when pushing - I just rebase the commit myself (which is really just adjusting the parent commit link) and then push - no messy merge commit.

Thanks for the opportunity to vent.  That was fun. ;-)

cheers,
keith

p.s. don't ever click on that "automatically merge pull request" button on Github.  A puppy dies every time you use it.

On May 2, 2012, at 2:07 PM, George Gastaldi wrote:

Right, I have 3 statements on this:

1) I prefer adding the "origin" as my forked repo and "upstream" in forge/core.
2) I name every branch as "feature/FORGE-XXX", where FORGE-XXX stands
for the JIRA worked on it.
3) Always use rebase instead of merge. It will do exactly what you
want and won´t mess with your branch.
Eg: if you are working on branch "feature/FORGE-550" and you want this
branch to have the latest changes from your master, just run:

git rebase master feature/FORGE-550

And at last but not least, I always pull from upstream and push to
origin. NEVER push directly into upstream (that´s why pull-requests
are for :) ) !

I think that´s all.

Regards,

George Gastaldi

2012/5/2 Lincoln Baxter, III <lincolnbaxter@gmail.com>:
Good point! we need to add this to the docs!

George, do you have a good strategy for this? You are the merge master :)

~Lincoln

On Wed, May 2, 2012 at 10:45 AM, Thomas Frühbeck <fruehbeck@aon.at> wrote:

Hi,
after having a look at receipt at
http://forge.github.com/docs/get_involved/contribute.html I would like
to clarify the use the repositories.

    - I have cloned forge/core to a private github repository
    - cloned my repository to my local system
    - generated a branch, committed changes, pushed to my github
repository
All OK.

One thing is left: how will I get updates of the master forge/core into
my _remote_ repository, as there is no "pull" on github?

If I understood correctly, I can associate the remote master by "git
remote add upstream <git_master_repo>"
To get the changes of the "upstream" master I issued:
~> git pull upstream master

Now my local repository was up do date, but not my remote repository. So
I issued:
~> git push

which seemed to update my private _remote_ repository with the changes
from the remote "upstream" master.
So for me this means, that from now on I "remote control" my private
_remote_ repository via my _local_ repo.

Could you kindly comment/confirm/explain in more detail.

Thanks,
Thomas
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev




--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev