GnuCash+git development process with multiple branches?

[Geert Janssens]

On 01-07-13 14:58, Derek Atkins wrote:
> John Ralls <jralls at ceridwen.us> writes:
>
> [snip]
>>> So I guess this boils does to more of a general git question than
>>> specifically gnucash, but ---- how do you work with multiple branches
>>> simultaneously?  This is particularly important because of having to
>>> dcommit back upstream.
>>>
>>> My first attempt was to do a git clone --bare and then figuring I could
>>> git-clone from there for my branches.  It converts my 'svk sync' to a
>>> 'git fetch' in the bare repo and 'svk update' to a 'git-update' (or git
>>> pull) from my WCs.  Alas, this doesn' *quite* work because the git fetch
>>> fails with:
>>>
>>> Fetching origin
>>> fatal: Couldn't find remote ref HEAD
>>> error: Could not fetch origin
>>>
>>> This is probably because refs/heads/ is empty in the bare repo?
>>>
>>> So what do you all do?  I'm thinking that once I figure it out I'll
>>> update the GnuCash Git Wiki Page, although honestly I'm probably the
>>> last dev to migrate to git :-P
>>>
>> Whew! I was afraid you were going to say that upgrading to perl 5.16 blew up
>> git-update!
> Nope, that is probably okay, otherwise I think Geert would have noticed
> that already.  :)
>
>> I just keep one git repo and flip around the branches as needed.
> Yeah, alas I really need to be able to have multiple branches "checked
> out" simultaneously.  I don't want a single tree that I'm constantly
> swapping between branches.
>
>> Left to itself, git pull will update all of the checked out branches
>> in the local repo, but we can't let it do that because each branch
>> needs to have its refs updated (particularly for new tags), so
>> git-update only rebases the currently checked out branch, so you have
>> to git-update each branch in turn. More important, you need to fetch
>> and update between dcommits when you're working in more than one
>> branch (like backporting a change) or git-svn gets all confused and
>> you spend a bunch of time resetting it back and rebasing before it
>> will let you dcommit again.
> So what does "git-update" do that "git fetch" (or git pull) does not?
> Could I theoretically run a 'git fetch' into the bare repo, clone that
> into each checkout I need, git svn init in each WC, and then dcommit
> from there back to SVN?  So I'd run 'git-update' from the WCs (instead
> of 'git pull'), but still run 'git fetch' from the bare repo?  It does
> mean that I'm holding around multiple copies of the git repo, but I
> could use --local to try to conserve space.
>
I don't know why this fails, but I sometimes work with multiple clones 
as well to work on different branches. I do it slightly differently though:
I have one main repository, cloned from github and git-svn inited. This 
is not a bare repo.

When I want to work on another branch in a separate repo, I clone from 
this main repository, rather than from github. When my work in the 
separate repo is satisfactory, I push it to my main repository.

Then in the main repository I check out the updated branch and dcommit 
the changes.

I never had issues with this. If you need several independent branches, 
you can clone the main repository multiple times. The clones can even 
have their own private branches if you want.

>> None of which explains why having a local bare clone wouldn't work. In
>> fact, I just tried it and it seems to work -- though there aren't yet
>> any changes to update, it didn't whine about anything:
>>    $ athena:/Users/john> git clone --bare git://github.com/Gnucash/gnucash.gitCloning into bare repository 'gnucash.git'...
> What if you do it against code.gnucash.org instead of github?
Against code.gnucash.org I get the same error as you do.

Geert