Non-commiter github workflow

[John Ralls]

On Aug 21, 2012, at 8:01 AM, reubano <reubano at gmail.com> wrote:

> I propose the current git wiki[1] be edited. Right now it says "If you have a
> Github account, it turns out that Github's "fork" feature doesn't play well
> with the Gnucash repository because of its unusual structure (which in turn
> is needed to synch it with subversion)." This doesn't make it clear that
> forking is ok in some circumstances.[2]
> 
> And if I'm understanding things, I should be able to:
>    fork
>    clone (my personal fork)
git remote add gc git://github.com/Gnucash/gnucash.git #See https://help.github.com/articles/syncing-a-fork
>    git branch -t master refs/remotes/origin/trunk
>    git branch working
>    <write code>
make && make check                               #Don't commit broken code
git commit -a                                              # Git won't let you do anything until you commit your tree
git checkout master
git pull remotes/gc/trunk                       #Otherwise the next step won't do anything
>    git rebase master working
git format-patch master                           #Git format-patch needs a starting ref for format-patch
>    git push -u origin master
>  ...
> 
> Is this correct?

Almost.  I've added/changed some steps. Note that the github doc I reffed above uses git fetch and git merge separately; git pull does both steps at once.

> If so, I think the wiki could be cleaned up and simplified
> a bit. As is, the 'Set-Up' and 'Patches' sections give conflicting steps and
> are overall confusing, e.g., Set-Up says 
>    git branch -t master refs/remotes/origin/trunk
>    ...
>    git format-patch origin/trunk..master
> 
> but 'Patches' says
>    git checkout trunk
>    git branch working-trunk
>    ...
>    git format-patch trunk

I've actually stopped using "master", because it seemed to confuse git-svn (or maybe it just confused me and I confused git-svn). I wrote the "Patches" section a couple of weeks ago in a way that reflects that practice, but you're right, the whole thing should be consistent.
> 
> My suggestion is to have 'Basic (GitHub) Set-Up' and 'Advance (Non GitHub)
> Set-Up' sections to accommodate the cloning differences, i.e.,
>    git clone git://github.com/Gnucash/gnucash.git
>    git remote add myname-github <remote server>:myname/gnucash.git
Huh? You shouldn't clone Gnucash/gnucash.git and then push back to a new github repo: That new repo's title won't show that it's forked from Gnucash/gnucash and  the "Network" stuff won't work.
> 
> vs
>    fork
>    git clone https://github.com/user/gnucash.git (just list HTTPS assuming
> those who want SSH will already know how to do it)
> 
> And then have a 'Contributing Code' section beginning with branching
> instructions. *OR* to make it even simpler, just list everything for a
> GitHub setup first and at the end add a note for those who don't use GitHub
> to clone and 'git remote add'.
You seem not to have grokked that we're not really interested in integrating with Github's way of doing things, setting aside that they keep changing it. For example, the *last* time I looked, you could sync a fork from the website, which is what didn't play well with the git-svn bridge. That's gone and you have to do it locally as described above. I'm not sure that we want to encourage people to publish their forks on Github, or anywhere else. Accounting software isn't a domain where fast-and-loose development is a good idea.

Regards,
John Ralls