GnuCash+git development process with multiple branches?
janssens-geert at telenet.be
Mon Jul 1 10:23:20 EDT 2013
On 01-07-13 15:36, Derek Atkins wrote:
> Geert Janssens <janssens-geert at telenet.be> writes:
>>> 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
>> 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.
> Hmm, I suppose I could do this, except that if you want to commit back
> on a branch you still lose your 'state' in the master repo. But I see
> your point that you don't necessarily need to use a bare repo. However
> it does mean you have an extra 'push' cycle for "everything", because
> you need to push from your branch-checkout to the master checkout and
> then from there dcommit to SVN.
>>>> 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
>>> What if you do it against code.gnucash.org instead of github?
>> Against code.gnucash.org I get the same error as you do.
> Hmm, did you just do something on code? I just did it again:
> git clone --mirror ssh://email@example.com/gnucash.git
> cd gnucash.git
> git fetch --all
I didn't change anything. I'll note that you used --mirror now instead
of --bare this time. Perhaps that makes a difference. I once looked at
the --mirror option, but I don't know enough about git to understand how
it's different from --bare and particularly how this impacts your workflow.
> ...and it worked without error:
> [warlord at mocana gnucash.git]$ git fetch --all
> Fetching origin
> [warlord at mocana gnucash.git]$
More information about the gnucash-devel