Ok, I think I figured this out.  The clue was in the error message I posted.
 I had the branch in question checked out in my main repository clone, so
the system couldn't push changes from my --local clone of the branch back
into that branch in the primary clone.

I guess that makes some sort of sense ... it avoids (reduces?) the chance of
problems pushing the changes if there are competing/conflicting changes in
the other copy of the branch.

This is almost worth a facebook status update. :-)  I just updated my
--local clone branch, made  some changes, and pushed them back into the
primary branch!!!!! <like> <comment> :-)

So any time someone pushes a change to the gitorious repository here is the
approximate procedure to update my local clones/branches (this is the git
replacement for the old cvs update command):

cd "primary-fgdata"
git pull
<error> - oops I have a branch checked out currently
git checkout master
<error> - oops commit any changes in the current branch
 - git diff
 - git commit
git checkout master (try again, it works)
git pull (now it works)
git checkout "primary-branch"
git merge master (to sync the upstream changes with my own "wip" branch)

But this is just in the main fgdata clone, Now cd over to my --local branch
clone.

cd "../fgdata-clone"
git pull (merge upstream changes from my local master repository that have
been merged into the master branch in the previous step.)
git diff (see what I changed locally)
git commit (commit my local changes)
git push (push these changes back into the primary branch in my original
clone of the gitoriious repository)
<error> - oops I have the branch checked out in my primary local  repository
- cd "../fgdata-primary"
- git checkout master
 - cd ../fgdata-clone"
git push (now it works!)

Woohoo, everything should now be consistent and in sync and all the upstream
changes should be fully merged.

Ok, so this is how I keep all my branches up to date here when ever anyone
pushes a change to the upstream gitorious repository.  Isn't that so much
superior to a one-line "cvs update" command which all this replaces ?!?!?
:-) :-) :-)

Curt.



On Sun, Feb 6, 2011 at 10:44 AM, Curtis Olson wrote:

> No one has answered yet which makes me guess (a) I didn't ask very well or
> (b) no one knows the answer, so let me try again here.
>
> I created a local clone of my fgdata repository using the --local option
> which builds hard links to the master original repository and saves lots of
> space.  The clone repository has one branch ... the one that was active in
> the source repository when I made the clone.
>
> When others push changes to the gitorious fgdata.git repository, I can then
> do a "git pull" in my "master" branch of my primary local fgdata repository.
>  Then I can switch to a branch in my master repository (git checkout) and
> run "git merge master" to merge the changes from the master branch into my
> local branch and keep the local branch in sync with everyone
> else's development work.
>
> This is all done in the original clone from gitorious.  None of this
> affects or alters my local clone repository with its mirror of a local
> branch.  However, I can go over to that local clone and run "git pull"
> (after I've merged the changes to the same branch in the master repository)
> and all those changes from the source branch get merged over into my local
> copy branch.  So git seems to be aware of the connection between the branch
> in my primary gitorious clone and the same branch in my --local clone.
>
> Here is what I can't figure out.
>
> If I make changes in my --local clone branch and commit them, they are
> there in the local clone, but don't show up in the same branch in the
> original gitorious clone repository.  It seems like it would make sense to
> run "git push" after "git commit" in my --local clone branch, but that
> produces an error:
>
> $ git push
> Counting objects: 33, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (22/22), done.
> Writing objects: 100% (22/22), 2.79 KiB, done.
> Total 22 (delta 14), reused 0 (delta 0)
> Unpacking objects: 100% (22/22), done.
> remote: error: refusing to update checked out branch:
> refs/heads/drone-f-14b
> remote: error: By default, updating the current branch in a non-bare
> repository
> remote: error: is denied, because it will make the index and work tree
> inconsistent
> remote: error: with what you pushed, and will require 'git reset --hard' to
> match
> remote: error: the work tree to HEAD.
> remote: error:
> remote: error: You can set 'receive.denyCurrentBranch' configuration
> variable to
> remote: error: 'ignore' or 'warn' in the remote repository to allow pushing
> into
> remote: error: its current branch; however, this is not recommended unless
> you
> remote: error: arranged to update its work tree to match what you pushed in
> some
> remote: error: other way.
> remote: error:
> remote: error: To squelch this message and still keep the default
> behaviour, set
> remote: error: 'receive.denyCurrentBranch' configuration variable to
> 'refuse'.
> To /home/curt/Projects/FlightGear/fgdata
>  ! [remote rejected] drone-f-14b -> drone-f-14b (branch is currently
> checked out)
> error: failed to push some refs to '/home/curt/Projects/FlightGear/fgdata'
>
> Does anyone understand what I am trying to do here?  Am I trying to solve
> the wrong problem?  Is there a way to go forward here and keep my two copies
> of my branch in sync?  Am I lost beyond the fringes of "git kludge" land?
>  :-)  What's the point of creating a --local clone if you can't push the
> changes back into your main repository? ... especially when you have to
> leverage the matching mirrror in the main repository to keep your --local
> branch in sync with upstream changes?
>
> Thanks,
>
> Curt.
>
>
> On Sat, Feb 5, 2011 at 1:19 PM, Curtis Olson <curtol...@gmail.com> wrote:
>
>> Here locally I made a local clone of the fgdata repository using "git
>> clone -l fgdata fgdata-wip".  That seemed to work as advertised.
>>
>> I noticed that the only branch available in the new local
>> clone "fgdata-wip" is the branch that is active in fgdata at the time the
>> clone is made .... that's good to know.  It doesn't make a complete clone of
>> ever branch, not even the master.
>>
>> I noticed that if I do a "git pull" inside fgdata-wip it *seems* to merge
>> in changes from the original fgdata respository (master branch) ... I'm not
>> 100% confident in that, I need to try it a few more times after some remote
>> updates get pushed to the central repository.  I don't know if all the
>> changes to fgdata/master are brought over, or just the ones that I'm merged
>> to fgdata/wip after doing a git pull in fgdata/master.  (Isn't this fun,
>> anyone still with me here?) :-)  At least if I update the branch wip branch
>> in the oringal fgdata repository, the changes seemed to get brought over to
>> "fgdata-wip" when I do a pull there.
>>
>> Now here's my question.  If I make a change inside the cloned wip branch
>> of the cloned repository "fgdata-wip" and then commit it.  I don't see it
>> show up in the "wip" branch of the original "fgdata" respository.  It
>> occurred to me that maybe I need to do a git push to send the changes over
>> to the original repository, but I get an error that is a lot of git-ese
>> that's way over my head.
>>
>> What's the best way to keep my fgdata/wip branch in sync with my
>> fgdata-clone/wip branch?  Is there a way?
>>
>> Thanks,
>>
>> Curt.
>> --
>> Curtis Olson:
>> http://www.atiak.com - http://aem.umn.edu/~uav/
>> http://www.flightgear.org -
>> http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
>>
>>
>
>
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - 
> http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
>
>


-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to