What I did was run a "git merge" when I really wanted to do a "git
cherry-pick". The merge merged everything in my test branch, and I just
wanted the one single commit moved over. I haven't done enough of this yet
to have remembered the difference. Most of the time (but not always) git
seems to know when I'm screwing something up and doesn't let me do it.
Which is a good thing because it's been a lot of trial and error figuring
things out.
Off the top of my head I was able to use a combination of "git log" and "git
status" to figure out the sha-sum of the most recent commit that didn't
involve my own screw ups. I then ran the command:
git reset --hard d1dbc6739fcba19956b6e2cae1fdd4975be392d4
And then git log and git status appeared correct and didn't seem to reflect
any of my mistakes, git pull reported completely in sync with the gitorious
repository.
The using a combination of "git log and status" I figured out the exact
sha-sum of the specific commit I wanted to merge and ran:
git cherry-pick f4efd11fbb3af9513b51918026188d1fd6f00fd5
That did the trick (cleaned up my mess and performed the task I originally
meant to perform.)
Finally I did a 'git push' to send the change upstream to gitorious.
Thanks for all the advice ... some if it I understand, and some of it I
don't. :-)
Curt.
On Wed, Feb 9, 2011 at 12:49 PM, Andy Ross wrote:
> On 02/09/2011 12:02 AM, Tim Moore wrote:
> > "Backing out" is done with git reset --hard last_good_commit. Often the
> name of the last good commit is HEAD^, the last commit. However, after a
> botched merge it is good to verify that with git log or graphically with
> gitk.
>
> Actually, unless I've misunderstood your point, this won't work: the commit
> history following a merge is an interleaved mix of two branches. You can't
> just walk back to "before" the merge. Doing that gets to to the equivalent
> of
> git merge-base, which is the last version that includes *none* of the
> changes
> in *either* branch.
>
> I don't think that's what Curt wants. See my comment to Anders about git
> reflog.
> (and yes, I've made exactly this mistake in the past, heh)
>
> Andy
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> 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/>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
