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.
If you've pushed a commit to a public repo and then it later turns out that
On 02/08/2011 11:04 AM, Anders Gidenstam wrote:
Backing it out might be a bit tricky, but you can rename your messed up
branch out of the way easily with git branch -m oldname newname.
It's worth experimenting with git reflog in situations like this.
That tracks a list of HEAD references in
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
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
Hi all,
When putting the default c172p on a 'gravel'
runway, like say YGIL:33, after a number of
seconds the aircraft 'tilts' slowly backwards...
And it will also happen on a reset... and can
happen after applying heavy breaking on the
gravel.
And there seems no particularly relevant output
to
Geoff McLane wrote:
I have never seen this on other runway
surfaces... even on the default YGIL:08
which is 'Dirt'!
I have seen this on various asphalt runways as well, I think it's a
general issue with the current state of the C172.
Cheers,
Martin.
--
Unix _IS_ user friendly -
On Wed, Feb 9, 2011 at 7:49 PM, Andy Ross a...@plausible.org 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
Hello!
I have unsolved problem driving me nuts for weeks now. In my opengl
application the terrain presentation is flickering very frequently
(either as whole our 1/3 of all polygons). The problem disappears as
soon as i increase the near clipping value. The problem root is the z
buffer
Hi all, I have just finished building the releases/2.2.0 branch on
FreeBSD-8.1.
Please apply this diff for a successful build :-)
diff --git a/utils/TerraSync/terrasync.cxx b/utils/TerraSync/terrasync.cxx
index f1a2cc4..d15078d 100644
--- a/utils/TerraSync/terrasync.cxx
+++
9 matches
Mail list logo
