Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 2:44 PM, Curtis Olson wrote: Ok, thanks for all the advice. git diff --cached did show me my actual change that git diff had lost. I doubt I'll remember that next time I need it. So I'll look at making changes to a branch in the future. At the moment I'm just trying to unwind my current tree. Apologies if I screw something up in the process ... Ok, I'm ready for some more hand holding with git. :-) Following the advice of the experts, I have created my own local branch of flightgear by cd'ing to the flightgear source tree and running: git branch mystuff It appears that the local changes I had made to the next branch were automatically migrated to the new mystuff branch. I can run git checkout mystuff and then run git branch and my new branch is listed with a star (*) next to it, which means it was actually created and now it is the current branch. (Correct?) I can now run git checkout next to get back to the head if that is the right term in git. And I can run git checkout mystuff to return to my local branch. Now questions: - What is the best way to clean up my next branch of all the changes I had previously made before I created my own branch? I'd like to return it to it's pristine untouched state now that I have a local branch for my local changes. - What is the best way now to keep my next branch current with upstream changes? - What is the best way to keep my mystuff branch current and merge upstream changes back to my local branch while preserving my local changes and possibly carrying any uncommitted tweaks forward as uncommitted tweaks? 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/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Another git question ... I created a mychanges branch with git branch mychanges. I run git branch and I see a * beside mychanges in the list of branches. I make a small test edit to a file (src/GUI/MapWidget.cxx). I run git checkout next to return to the pristine unchanged branch that tracks the head on gitorious --- but here is the output: $ git checkout next M src/GUI/MapWidget.cxx Switched to branch 'next' $ git branch maint mychanges * next next is the current branch, but the change I made in the mychanges branch to MapWidget.cxx is still visible. What am I missing? Why is a change that I made in one branch being shown in a different branch? 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/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Fri, Jan 7, 2011 at 6:58 PM, Curtis Olson wrote: I make a small test edit to a file (src/GUI/MapWidget.cxx). I run git checkout next to return to the pristine unchanged branch that tracks the head on gitorious --- but here is the output: $ git checkout next M src/GUI/MapWidget.cxx Switched to branch 'next' $ git branch maint mychanges * next next is the current branch, but the change I made in the mychanges branch to MapWidget.cxx is still visible. What am I missing? Why is a change that I made in one branch being shown in a different branch? The change you made is _not_ in any branch yet. It's just a local change in your filesystem. git doesn't automatically add any changes to a branch. Maybe you just edited the file for a temporary test. Or you find out the change doesn't work at all and want to revert it immediately. You need to explicitly add any change to a branch - otherwise the change isn't in git. So, only when you run git add MapWidget.cxx; git commit is your modified file added to the current branch. Running git checkout somebranch won't touch modified files in your filesystem. I actually really like this feature: you can make local changes and then quickly change branches to see how the changes work with different branches. When you're happy, you switch to the branch you want to commit it to and finally add and commit the change to git. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Fri, Jan 7, 2011 at 6:58 PM, Curtis Olson wrote: I make a small test edit to a file (src/GUI/MapWidget.cxx). I run git checkout next to return to the pristine unchanged branch that tracks the head on gitorious --- but here is the output: $ git checkout next M src/GUI/MapWidget.cxx Switched to branch 'next' $ git branch maint mychanges * next next is the current branch, but the change I made in the mychanges branch to MapWidget.cxx is still visible. What am I missing? Why is a change that I made in one branch being shown in a different branch? On Fri, Jan 7, 2011 at 12:34 PM, ThorstenB wrote: The change you made is _not_ in any branch yet. It's just a local change in your filesystem. git doesn't automatically add any changes to a branch. Maybe you just edited the file for a temporary test. Or you find out the change doesn't work at all and want to revert it immediately. You need to explicitly add any change to a branch - otherwise the change isn't in git. So, only when you run git add MapWidget.cxx; git commit is your modified file added to the current branch. Running git checkout somebranch won't touch modified files in your filesystem. I actually really like this feature: you can make local changes and then quickly change branches to see how the changes work with different branches. When you're happy, you switch to the branch you want to commit it to and finally add and commit the change to git. Hi Torsten, Ok, this makes sense the way you explain it. So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry branch over lunch, and suddenly I get a phone call and have to jump back to doing something serious with FlightGear and need to quickly switch back to my RealWork branch. Do I have to commit my CrazyIdea branch changes --- no matter what intermediate state of weirdness they are in --- before I can switch back to the RealWork branch? 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/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Fri, Jan 7, 2011 at 7:48 PM, Curtis Olson wrote: So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry branch over lunch, and suddenly I get a phone call and have to jump back to doing something serious with FlightGear and need to quickly switch back to my RealWork branch. Do I have to commit my CrazyIdea branch changes --- no matter what intermediate state of weirdness they are in --- before I can switch back to the RealWork branch? If you want git to take care of switching these files, then yes, you'll need to commit them to some branch. I'm not familiar with this stashing option. What I'd do is either commit the changes to the current branch - or, in case the changes are just too experimental and I really don't want to modify the current branch, I just create a new branch git checkout crazyidea. The new branch is identical to the former current branch then. So I can just addcommit the experimental changes to the new crazyidea branch and then switch back to the former working branch - or to some other stable branch... And you can always remove the crazyidea branch again - if the idea turns out not to be so good after all, or you just wanted something temporary. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Hi Thorsten, Thanks for explaining this in detail. So here is my next question related to dealing with local branches. Let's say I make a local branch, make some changes, and I'm finally happy with those changes, so I commit them. (Or maybe I've committed several revisions of my changes over the past few days and I'm finally happy with the current state of things.) Now I want to roll these changes in my local branch back into next and push them up to the upstream repository. What is the procedure for doing that? And if in the mean time, other people have made changes and commited them and pushed them up to the next branch, how do I update my local branch to have all the latest changes that other people have made? Thanks, Curt. On Fri, Jan 7, 2011 at 1:00 PM, ThorstenB bre...@gmail.com wrote: On Fri, Jan 7, 2011 at 7:48 PM, Curtis Olson wrote: So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry branch over lunch, and suddenly I get a phone call and have to jump back to doing something serious with FlightGear and need to quickly switch back to my RealWork branch. Do I have to commit my CrazyIdea branch changes --- no matter what intermediate state of weirdness they are in --- before I can switch back to the RealWork branch? If you want git to take care of switching these files, then yes, you'll need to commit them to some branch. I'm not familiar with this stashing option. What I'd do is either commit the changes to the current branch - or, in case the changes are just too experimental and I really don't want to modify the current branch, I just create a new branch git checkout crazyidea. The new branch is identical to the former current branch then. So I can just addcommit the experimental changes to the new crazyidea branch and then switch back to the former working branch - or to some other stable branch... And you can always remove the crazyidea branch again - if the idea turns out not to be so good after all, or you just wanted something temporary. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Hi Curt, git merge is your friend! Perhaps a complete example workflow will help you get along: suppose you are on branch next tracking the gitorious branch next. git branch wip -- wip is now an exact copy of the next branch git checkout wip Edit files to add some really cool feature git add [files to add] -- select which modified files you want to commit to branch wip git commit Suppose you want to update your next branch, and incorporate those changes in you wip branch: git checkout next git pull -- updates your branch next. Should not produce any merge-conflicts, since you didn't alter anything in your local branch git checkout wip git merge next -- merges changes in next into your wip branch (in case of merge-conflicts, fix 'em) git add [conflicted files] -- git's way of marking the conflicts resolved git commit Suppose you've got your wip branch in good shape, and up to date (ie, you've just merged next into wip) and want to push to gitorious: git checkout next git merge wip -- should not produce merge-conflicts, since wip was already up to date git push Then another useful feature of git: you can easily alter history. (NOTE: you should only change history that is only your own repo. Don't change the history which is already in more repos (pushed to gitorious) git commit --amend-- extends the previous commit. Useful when you're working in a branch, and need to make a temp commit to be able to switch branches. You should also be able to use git stash in this case, but I find this to be a lot less confusing than git stash Hope this helps, Stefan 2011/1/7 Curtis Olson curtol...@gmail.com: Hi Thorsten, Thanks for explaining this in detail. So here is my next question related to dealing with local branches. Let's say I make a local branch, make some changes, and I'm finally happy with those changes, so I commit them. (Or maybe I've committed several revisions of my changes over the past few days and I'm finally happy with the current state of things.) Now I want to roll these changes in my local branch back into next and push them up to the upstream repository. What is the procedure for doing that? And if in the mean time, other people have made changes and commited them and pushed them up to the next branch, how do I update my local branch to have all the latest changes that other people have made? Thanks, Curt. On Fri, Jan 7, 2011 at 1:00 PM, ThorstenB bre...@gmail.com wrote: On Fri, Jan 7, 2011 at 7:48 PM, Curtis Olson wrote: So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry branch over lunch, and suddenly I get a phone call and have to jump back to doing something serious with FlightGear and need to quickly switch back to my RealWork branch. Do I have to commit my CrazyIdea branch changes --- no matter what intermediate state of weirdness they are in --- before I can switch back to the RealWork branch? If you want git to take care of switching these files, then yes, you'll need to commit them to some branch. I'm not familiar with this stashing option. What I'd do is either commit the changes to the current branch - or, in case the changes are just too experimental and I really don't want to modify the current branch, I just create a new branch git checkout crazyidea. The new branch is identical to the former current branch then. So I can just addcommit the experimental changes to the new crazyidea branch and then switch back to the former working branch - or to some other stable branch... And you can always remove the crazyidea branch again - if the idea turns out not to be so good after all, or you just wanted something temporary. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list
Re: [Flightgear-devel] git for dummies
Curtis Olson wrote: - What is the best way to clean up my next branch of all the changes I had previously made before I created my own branch? I'd like to return it to it's pristine untouched state now that I have a local branch for my local changes. If anything else fails, if next in your local GIT repo is in clean state without any local changes added, if you just want to have a clean checkout of next, then rm -rf *; git checkout -f next should do the job. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Hi Stefan, Thanks for the reply. You are exactly right to notice that I am struggling a bit to understand the proper git workflow when dealing with branches. I have a couple more questions inserted below ... On Fri, Jan 7, 2011 at 1:39 PM, stefan riemens wrote: Hi Curt, git merge is your friend! Perhaps a complete example workflow will help you get along: suppose you are on branch next tracking the gitorious branch next. git branch wip -- wip is now an exact copy of the next branch git checkout wip Edit files to add some really cool feature git add [files to add] -- select which modified files you want to commit to branch wip git commit Suppose you want to update your next branch, and incorporate those changes in you wip branch: git checkout next git pull -- updates your branch next. Should not produce any merge-conflicts, since you didn't alter anything in your local branch Clarification: as long as I've committed all my local changes to the wip branch before I switch back to the next branch, then I shouldn't ever have any conflicts, right? If I switch back to the next branch with some uncommited changes in my branch, those will be sitting there still in my local next branch and I could have problems with the pull (and blindly following the suggestions in the git error messages isn't probably always the best solution I've found.) :-) Am I understanding all this right? git checkout wip git merge next -- merges changes in next into your wip branch (in case of merge-conflicts, fix 'em) Questions: Can you explain exactly what this git merge next does? Does the it only merge my local changes in the next branch into my wip branch? Does it merge all remote changes to the remote next branch into my local wip branch? Do I first need to do a git pull in my next branch before switching to my wip branch and doing the merge? What if it's been a few days since I created my wip branch and I've committed a few local changes to it. Now I want to make sure my wip branch is fully up to date with all remote changes on the remote/server's next branch? What is the proper way to do that? I could describe this another way. Pretend I want to do something similar/analogous to an svn update on a tree where I've made some local changes, but I want to catch up with all the remote changes and make sure my local changes are compatible and function correctly and there aren't merge conflicts. But in the git world I now have my own separate branch, my own local commits, and now I want to update that my local wip branch to reflect all the changes that have been subsequently pushed to the remote next branch by other developers. git add [conflicted files] -- git's way of marking the conflicts resolved git commit Suppose you've got your wip branch in good shape, and up to date (ie, you've just merged next into wip) and want to push to gitorious: git checkout next git merge wip -- should not produce merge-conflicts, since wip was already up to date git push One question here: Let's say I have committed two unrelated features into my wip branch. Is there a way to merge individual features/commits? Or is it all or nothing? If I want finer grain control would I have to create a new branch for each independent feature/idea I am working on? Then another useful feature of git: you can easily alter history. (NOTE: you should only change history that is only your own repo. Don't change the history which is already in more repos (pushed to gitorious) git commit --amend-- extends the previous commit. Useful when you're working in a branch, and need to make a temp commit to be able to switch branches. You should also be able to use git stash in this case, but I find this to be a lot less confusing than git stash When studying robotics, the level of intelligence of a system is defined by how detailed your instructions to the system have to be in order for it to successfully accomplish the task. For instance, let's say the task we want to accomplish is to open a jar of pickles. Can you just say open the jar. Or do you have to say lift up your hand, now put it on the jar, no on the jar Patrick, the jar, no the lid of the jar, ok turn it, no turn the lid, no hold the jar still while you turn the lid ... (spongebob reference) :-) I'm not sure why this thought popped into my head right now ... and I'm not sure at the moment if it would apply to git or apply to myself. :-) 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/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure
Re: [Flightgear-devel] git for dummies
Hi Curt, 2011/1/7 Curtis Olson curtol...@gmail.com: Hi Stefan, Thanks for the reply. You are exactly right to notice that I am struggling a bit to understand the proper git workflow when dealing with branches. I have a couple more questions inserted below ... On Fri, Jan 7, 2011 at 1:39 PM, stefan riemens wrote: Hi Curt, git merge is your friend! Perhaps a complete example workflow will help you get along: suppose you are on branch next tracking the gitorious branch next. git branch wip -- wip is now an exact copy of the next branch git checkout wip Edit files to add some really cool feature git add [files to add] -- select which modified files you want to commit to branch wip git commit Suppose you want to update your next branch, and incorporate those changes in you wip branch: git checkout next git pull -- updates your branch next. Should not produce any merge-conflicts, since you didn't alter anything in your local branch Clarification: as long as I've committed all my local changes to the wip branch before I switch back to the next branch, then I shouldn't ever have any conflicts, right? If I switch back to the next branch with some uncommited changes in my branch, those will be sitting there still in my local next branch and I could have problems with the pull (and blindly following the suggestions in the git error messages isn't probably always the best solution I've found.) :-) Am I understanding all this right? Yes, that is correct. Uncommitted changes are at the filesystem level and don't belong to any branch. Note that switching branches in this case may fail, because git can't merge uncommitted files. That's also the reason that a pull may fail if you have uncommitted changes. git checkout wip git merge next -- merges changes in next into your wip branch (in case of merge-conflicts, fix 'em) Questions: Can you explain exactly what this git merge next does? Does the it only merge my local changes in the next branch into my wip branch? Does it merge all remote changes to the remote next branch into my local wip branch? Do I first need to do a git pull in my next branch before switching to my wip branch and doing the merge? What if it's been a few days since I created my wip branch and I've committed a few local changes to it. Now I want to make sure my wip branch is fully up to date with all remote changes on the remote/server's next branch? What is the proper way to do that? I could describe this another way. Pretend I want to do something similar/analogous to an svn update on a tree where I've made some local changes, but I want to catch up with all the remote changes and make sure my local changes are compatible and function correctly and there aren't merge conflicts. But in the git world I now have my own separate branch, my own local commits, and now I want to update that my local wip branch to reflect all the changes that have been subsequently pushed to the remote next branch by other developers. Git merge next will do just that: merge your local branch next into the current branch. So in this example where wip is a couple of days old, you could bring it up to date using this sequence: git checkout next -- checkout your local next branch git pull -- get the changes in the gitorious next branch, and merge them into your local next branch. git checkout wip -- checkout your local wip branch git merge next -- merge your local branch next into the currently checked out branch (wip) git add [conflicted files] -- git's way of marking the conflicts resolved git commit Suppose you've got your wip branch in good shape, and up to date (ie, you've just merged next into wip) and want to push to gitorious: git checkout next git merge wip -- should not produce merge-conflicts, since wip was already up to date git push One question here: Let's say I have committed two unrelated features into my wip branch. Is there a way to merge individual features/commits? Or is it all or nothing? If I want finer grain control would I have to create a new branch for each independent feature/idea I am working on? Yes, that sure is possible. git merge [commit hash] works fine for this. There is also git cherry-pick, I've never used that myself though, so I can't tell you how that works exactly. However, always remember that branches are cheap with git, so it is very git-like to use a branch per feature. Then another useful feature of git: you can easily alter history. (NOTE: you should only change history that is only your own repo. Don't change the history which is already in more repos (pushed to gitorious) git commit --amend -- extends the previous commit. Useful when you're working in a branch, and need to make a temp commit to be able to switch branches. You should also be able to use git stash in this case, but I find this to be a lot less confusing than git stash When studying
[Flightgear-devel] git for dummies
I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
What I always do is keep the master (next in FG's case) completely in sync with upstream's master branch. For local modifications I always use another branch. That way, pulling and pushing always works as you'd expect. Merging is easy and cheap with git, i love that! PS, I'm not really a git expert, but this works for me... Stefan 2011/1/4 Curtis Olson curtol...@gmail.com: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected] master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
That's probably not a bad tip, but I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? Thanks, Curt. On Tue, Jan 4, 2011 at 11:02 AM, stefan riemens wrote: What I always do is keep the master (next in FG's case) completely in sync with upstream's master branch. For local modifications I always use another branch. That way, pulling and pushing always works as you'd expect. Merging is easy and cheap with git, i love that! PS, I'm not really a git expert, but this works for me... Stefan 2011/1/4 Curtis Olson curtol...@gmail.com: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On 01/04/2011 10:20 AM, Curtis Olson wrote: I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? 1) Try this: git stash pop It should undo the effect of the previous git stash. See below for more on this. 2) I generally don't bother with git stash. 3) Constructive suggestion: Never edit stuff on a branch that is tracking a remote. As a common example, if the local master branch is tracking a remote master branch, and if you are sitting on the master branch, do this git checkout mystuff or if necessary git checkout -b mystuff before editing anything. 4) Constructive suggestion: In the all-too-common situation where you forget what branch you are on and edit stuff on the wrong branch, do this: checkout -m mystuff That will take the edits and merge them into where they belong. In my experience, this is wy better than stashing. 5) I have a fancy pre-commit hook that prevents me from accidentally committing something to a branch that shouldn't be modified. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 5:20 PM, Curtis Olson wrote: That's probably not a bad tip, but I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? Thanks, Curt. Curt, Try git diff master origin/master or something along those lines. Note that it's also possible to lose your diff within your own local repository, due to the index. I think that git diff shows the difference between your source tree and the index, and git diff --cached either shows the difference between your index and your (local) repository (or maybe your source tree and your local repository, can't remember OTOH). So, try git diff --cached to see if the changes are lost in your index (git status is also good for that), and then git diff master origin/master to see if they are changes between your repository and the remote one (git log and gitk should also make local/remote commit differences clear). Note: I'm also a git newbie, take all this with a massive pinch of salt! Cheers - Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 5:36 PM, Curtis Olson curtol...@gmail.com wrote: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. No. git stash is sort of like a commit + a reset to the previous commit. git stash apply and git stash pop are like applying a patch. A simple thing you can do is git status, which tells you git's idea of the modified files in your working tree. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? As everyone else has said, commit 'em in a branch. Please explain in simple language. :-) Tim -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Ok, thanks for all the advice. git diff --cached did show me my actual change that git diff had lost. I doubt I'll remember that next time I need it. So I'll look at making changes to a branch in the future. At the moment I'm just trying to unwind my current tree. Apologies if I screw something up in the process ... Curt. On Tue, Jan 4, 2011 at 2:24 PM, Tim Moore wrote: On Tue, Jan 4, 2011 at 5:36 PM, Curtis Olson wrote: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. No. git stash is sort of like a commit + a reset to the previous commit. git stash apply and git stash pop are like applying a patch. A simple thing you can do is git status, which tells you git's idea of the modified files in your working tree. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? As everyone else has said, commit 'em in a branch. Please explain in simple language. :-) Tim -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
