Geert Janssens <janssens-ge...@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
> 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.
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
>>> 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.
Hmm, did you just do something on code? I just did it again:
git clone --mirror ssh://g...@code.gnucash.org/gnucash.git
cd gnucash.git
git fetch --all
...and it worked without error:
[warlord@mocana gnucash.git]$ git fetch --all
Fetching origin
[warlord@mocana gnucash.git]$
> Geert
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
