Git Migration: github with svn access

[Reuben Cummings]

On Sat, Aug 11, 2012 at 9:34 PM, Derek Atkins <warlord at mit.edu> wrote:
> Reuben Cummings <reubano at 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 <jralls at 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