On 01-07-13 15:36, Derek Atkins wrote:
Geert Janssens <[email protected]> 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://[email protected]/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@mocana gnucash.git]$ git fetch --all
Fetching origin
[warlord@mocana gnucash.git]$
Geert
-derek
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
