On Dec 6, 2011, at 9:54 AM, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-12-05 20:06, Nicolas Montgermont wrote:

...

Hello Iohannes / list,

I've worked on a few help files. It was mainly help files that were not in the Gem format. I've done that using git.

You can find them here: git@github.com:nixhol/Gem.git the name of the branch is: help-files

I've cloned the Gem sourceforge repository, then i've created a branch, worked on the files, and then i've pushed my modifs on my github repository. Is this the good workflow for contributing to Gem using git? or do you prefer another way?

yes, i think this is the best way to contribute to Gem. i incorporated your fixes and pushed to sourceforge.

i'm not yet sure whether it is best to _merge_ your branch into master or to _rebase_ it onto master. for know i prefer a rebase (if possible), but if that makes problems for somebody i could do merges as well.

IMHO, if the model is IOhannes as sole committer to the Gem git, and people doing work on their own git forks, then I think that rebasing is the best option. The Linux-style flow here is that the git forks should rebase to be on the HEAD of the main git before submitting the changes.

.hc

----------------------------------------------------------------------------

All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-12-07 14:45, Nicolas Montgermont wrote:

ok, is there any way of making a pull request? Or must we send a mail to this list when something is ready?

there should be a possibility to make a pull request via github. else, just write an email.

...

The Linux-style flow here is that the git forks should rebase to be on the HEAD of the main git before submitting the changes.

I am not sure to understand.

that's basically just a way to ensure minimal work for the merger (me :-)), by making sure that master and the forked branch are "as close as possible" - and don't have conflicts.

For example if i am in my local repo in my forked branch i want to submit (gem sourceforge is called origin here), i must do git pull --rebase origin

just do: $ git checkout -b help-patch [...] $ git commit $ git checkout master $ git pull origin $ git checkout help-patch $ git rebase master $ git checkout help-patch $ git push

this can quickly get tiresome if you pushed your branch to a public repository before doing the rebase (because you may need to delete the remote branch before you can push the rebased version)

however, this could be a rather theoretical problem for us...rebasing to current master is important for resolving conflicts; as long as there are no conflicts, it doesn't really matter.

fgamsdr IOhannes