On Sat, Aug 11, 2012 at 9:34 PM, Derek Atkins <warl...@mit.edu> wrote: > Reuben Cummings <reub...@gmail.com> writes: > >> Yes, I figured the round-a-bout patch submission method is due to >> maintain svn compatibility. But that still doesn't answer my original >> question of a "time-frame for full github integration". A perfectly >> acceptable answer is "No, gnucash will never be fully integrated with >> github because we want to maintain svn access." If that is the case, >> then so be it. > > Okay, I'll state it for you. No, gnucash will never be fully integrated > with github. Not necessarily because we want to maintain SVN access, > but because we want to maintain the master code repository. Even if we > do switch to 100% git, we will never be fully integrated with github. > > -derek
Ok, thanks for answering. On Sat, Aug 11, 2012 at 5:25 PM, John Ralls <jra...@ceridwen.us> wrote: > > > You misunderstand the warnings about forking. Notice that I have a gnucash > fork in my Github repos. Works fine, fails safe, and drains to the bilge. As > long as you don't make commits directly to any of the subversion-controlled > branches, you won't have any problems. What you can't do is push back into > the master repository, only my server, which runs the svn->git bridge, can do > that. So if that is the case then the wiki should probably 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. And if I'm understanding you, I should be able to: fork clone (my personal fork) git branch -t master refs/remotes/origin/trunk git branch working write code git rebase master working git format-patch git push -u origin master ... Is this correct? 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 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 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 the at the end add a note for those who don't use GitHub to clone and then git remote add. > Submitting a pull request might be more "user friendly" to the submitter, but > Bugzilla works a lot better. Github's issue tracking *sucks*, and pull > requests are a flavor of issues. Ok, I'll take your word on that since I have little experience with either. > Gnucash is following the Gnome patch submission practice. Gnome uses git, but > not Github, and doesn't use pull requests (which are actually designed to > work through email with, guess what, git format-patch). I hope that even > after we migrate to git we'll continue with the same submission practice. Is there any way both could work together? I've been reading a bit on the shortcomings of GitHub PRs [1] and am curious if any combination of git-request-pull [2], .patch URL [3], or patches-by-email [4] could work. [1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 [2] http://git-scm.com/docs/git-request-pull [3] https://help.github.com/articles/using-pull-requests/ (Patch and Apply section) [4] http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
