Re: [Flightgear-devel] git for dummies

[stefan riemens]

Hi Curt,

2011/1/7 Curtis Olson :
> 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 bran

Re: [Flightgear-devel] git for dummies

[Curtis Olson]

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/
--
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 
bes

Re: [Flightgear-devel] git for dummies

[Martin Spott]

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

[stefan riemens]

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 :
> 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  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 add&commit 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/

Re: [Flightgear-devel] git for dummies

[Curtis Olson]

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  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 add&commit 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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git for dummies

[ThorstenB]

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 add&commit 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

[Curtis Olson]

> 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/
--
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

[ThorstenB]

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

[Curtis Olson]

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/
--
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

[Curtis Olson]

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/
--
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

[Curtis Olson]

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/
--
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

[Tim Moore]

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

Re: [Flightgear-devel] git for dummies

[Dave L]

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

[John Denker]

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

[Curtis Olson]

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 :
> > 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/
--
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/flight

Re: [Flightgear-devel] git for dummies

[stefan riemens]

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 :
> 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