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 _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
