Re: [Pan-devel] seeing lots of problems (Re: ANN : Tabs support for article overview)

[Duncan]

SciFi posted on Thu, 03 Nov 2011 23:44:11 +0000 as excerpted:

> So fortunately I have kept a checked-out copy of your GIT bb16cbd level
> before it was "clobbered" with the "tabs" code.
> ;)

Fortunately??  That sounds as if you're not using git's content 
management capacities, and simply happened to have a backup of the git 
tree in the previous state.

Assuming you have a local clone of the git tree (and that it's not 
"bare", which adds a bit of complication), simply cd to the root of the 
git tree and do:

git checkout <commit, tag, or branch>

So in this case:

git checkout bb16cbd

If you're staying in the current branch, this puts git into "detached 
head" mode, checking out the state of the tree as of the named tag or 
commit.  HEAD now points to a specific commit instead of to the tip of 
the branch.

To return to the tip of the branch:

git checkout <branch>

Of course, if the current checkout has uncommitted (and not ignored) 
changes, git will normally warn you and do nothing if you try to checkout 
something else.  In that case, you need to either commit your changes 
(and potentially create a reference to the new commit, say a tag or 
branch, so it doesn't eventually get garbage-cleaned), or more likely at 
least for us non-coders, simply revert it, returning to a clean tree.  
Such a revert to a clean tree is accomplished using git reset:

git reset --hard

Naturally, there's much more in the git-checkout and git-reset manpages
(also available using git <command> --help if you prefer that to
man git-<subcommand> ) if you want/need further details.

FWIW, I use git checkout more or less routinely now, to move around the 
kernel tree, which is where most (but by far not all) of my git usage 
is.  For example, while I normally run live git kernels, the ~2-week 
kernel commit window between release and the -rc1 for the next release is 
usually an exception.  If I don't happen to git pull right after release, 
no big deal, I simply "git checkout <tag>" (where tag is v3.1 or 
whatever) to checkout the state of the tree when it was tagged.  No big 
deal.

It's thus possible to use the git tree for any git-managed sources, say 
if one wants the more detailed changelog (git whatchanged) that generally 
affords compared to official changelogs and/or to ease git bisecting if 
it becomes necessary, but still remain on official versions, by simply 
using git checkout to switch to the desired tagged version after every 
git pull, even if the git pull would otherwise land you at some 
intermediate commit between tagged versions.  Given how easy git makes 
this and git benefits such as built-in integrity checking, there is in 
fact a gradual but already marked shift away from the traditional tarball, 
toward using git trees directly and simply checking out the desired tag 
or commit (with git archive used to create a tarball dynamically if such 
is desired, perhaps for compliance with the GPL requirements for requests 
for sources corresponding to a specific binary, for instance), thus 
allowing dynamic regeneration on demand of any particular version or tree 
state as of commit N, as opposed to having to store and transfer all 
those multitudes of individual version tarballs.

So there's no "fortunately" about it, here.  If the sources are in a git 
tree I'm already tracking (as I am the judgefudge pan tree) and I don't 
like a particular version and wish to revert, I simply use git checkout 
to revert to whatever arbitrary tag or commit I wish, and build from 
that.  No "fortunately" about it if I'm using the git tree.  I either 
have the git tree and it works, or I don't, and I have to do the version 
revert the old fashioned way, hoping I archived or can dig up the desired 
version somewhere, in which case "fortunately" could indeed apply.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman