RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

-----Original Message----- wtf is wrong with

git checkout <something>

??

** It doesn't reliably put the files that were in that revision into the working directory - a fairly major flaw, for what I'm using SCM for (and 80% of the market IMHO)

if you must have

git checkout <something> <paths>

then instead use

git checkout <something> <paths> git clean

** hmm, might try this - obviously as per Daniels post there is some undefined interaction happenign with the index, to screw up the working directory. I presume clean flushes the index?

but you will lose other files that aren't part of the repo but are still in the project's dir (i.e. untracked files).

** don't care, I'll be removing them from working dir anyhow before doing a rollback

On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:

sir, i believe you're not reading what is typed.

yes it does. your example uses "git checkout versionB .", which is NOT "git checkout <something>" we are suggesting you do "git checkout versionB" which is different (HINT: there is NO dot), and which i'm 99% positive will work.

if you still disagree, then i'm sure mercurial will be sufficient for your needs, and all your dcvs book-lernin' over christmas will be transferrable.

good luck with whatever option you choose.

On Tuesday 2008 December 30 20:27:26 Conor Rafferty wrote:

And you would be wrong, IMHO. Many people have untracked files or directories in their working directory ('cause they are working there) that they don't want deleted willy-nilly. Build files, modifications that should be on a different branch, etc. There's another thread active on the list complaining that git removes too much from the working tree.

Most users of SCMs do make active modifications to the files in the SCM. It's not a system only for archiving static projects.

On Wed, 31 Dec 2008, Conor Rafferty wrote:

It certainly does for me; I rely on it pretty much constantly. Can you give a sequence of commands (ideally the whole sequence from the "git init") that leads to a difference?

The only case I know of where there will be files left over is if you switch from a situation where you have an untracked file (e.g., you create C.txt but don't add it to anything) to another situation where the file still isn't tracked, it won't remove it. But, of course, you wouldn't really want git to remove your uncommitted work in general, since it's generally irreplaceable. It'll only be lacking files if it fails to switch (if, for instance, you had uncommitted changes that conflict with the changes that it would do), and it will give an error message in that case.

git clean wouldn't remove those files, because they're supposed to be there at that point.

In the sequence:

... $ git tag versionD $ git checkout versionA .

This means: "Update the index with the files in versionA, and working directory from the index"

So now you're working on a commit based versionD (because you didn't switch branches), and your work thus far, which is marked as ready for your next commit, is to recover the removed files ABC.txt and AC.txt (from versionA).

$ rm *.*

This removes those files again, but only in your working directory. Your index still says that your next commit will recover them.

$ git checkout versionB .

This recovers ABC.txt and BC.txt (from versionB). Your index has ABC.txt, BC.txt (from versionB), and AC.txt (from versionA), marked as going into the next commit. It also puts all of these in your working directory (when you might expect it to only put ABC.txt and BC.txt there).

So (a) you're still working on the commit after versionD, rather than navagting history at all; and (b) you've recovered files from two different commits.

Now:

$ git clean

will remove any files that you happen to have around, other than the one you're confused about and trying to get rid of.

	-Daniel
*This .sig left intentionally blank*

On Tue, 30 Dec 2008, Daniel Barkalow wrote:

Actually, I know what you must be doing:

$ git tag versionD $ git checkout versionA (versionA in the working directory) $ rm *.* (versionA with ABC.txt and AC.txt deleted) $ git checkout versionB (versionB with ABC.txt and AC.txt deleted)

If you've made any changes (including deleting files), "git checkout" (no pathes) will preserve them. On the other hand, it will remove files that are in the commit you're leaving and not in the commit you're going to. So just don't remove the working directory files and you should be all set.

In order to get them back if you have removed them, you can do:

$ git checkout .

This will discard all of the changes you've made only to the working directory; i.e., it'll recover the deleted files. You should also try "git status" whenever anything's mysterious, because it will tell you what's going on.

	-Daniel
*This .sig left intentionally blank*

Ok, now I'm following you, cos I just "broke" checkout again by deleting files from working dirs before running it.

git-checkout takes into account the state of the working tree in the commit it is run FROM, as well as the commit it is checking out.

It relies on the working tree being in synch with the commit it is run from. If I delete files, I screw around with this initial state. Files that git-checkout is relying on to be there are not copied in by it, so if I've deleted (or modified) those files, hard luck.

I remember s/o saying git minimizes file I/O, and this whats happening here.

It puts a big demand on the user, to keep their index & working dir in synch with whats in the commit.

Ah,

$ git checkout .

will restore the state of the working dir to be in synch with the CURRENT commit, so it will be safe to checkout other branches

BINGO !! what I need to do is run the sequence

$ git checkout . // tidy up current commit $ git checkout <version> // roll back

n'est pas ?

"Daniel Barkalow" <barkalow@iabervon.org> wrote in message news:alpine.LNX.1.00.0812302236190.19665@iabervon.org...

On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:

or they could just use "git checkout -f tag_to_goto" I suppose...

On Wed, 31 Dec 2008, Zorba wrote:

It's not relying on these files to be there; it's actually aware that they're not there. It thinks that any modifications you've made might be important work, and carefully preserves it.

Actually, it should be telling you the changes that it's carrying over with lines like:

D	ABC.txt

(which indicated that you've deleted ABC.txt, and it's keeping that modification)

The user is hopefully not going to make a lot of random undesired changes in general. It's hard to get much done that way. If you have made changes, you can use "git checkout ." to get the versions back from the index, or "git checkout HEAD ." to get them back from the commit.

Either that, or:

$ git checkout <version> $ git checkout .

(it doesn't matter whether you get rid of the local modifications and deletions before switching, or switch first, and then get rid of any remaining local modifications and deletions)

You may also want:

$ git clean

To get rid of untracked files you may have around (use "git clean -x" if you also want to get rid of files you've told git to ignore).

Incidentally, if your goal is to give someone a copy of the state as of a particular version, you can use:

$ git archive --format=zip <commit> > version.zip

This doesn't involve your working directory at all, and just generates a zip file out of the history. I find that this means I rarely actually care about having a working directory that's free of random junk.

	-Daniel
*This .sig left intentionally blank*

On 2008-12-31, Daniel Barkalow <barkalow@iabervon.org> wrote:

I think "git checkout -f <version>" will do *all* of that.

Ok, starting from scratch, new dir, new repo

I can now get $ git checkout <version> to work (see extract below, missed the first few lines due to exceeding buffer)

The difference with the instance when I found "errors" is that that time I'd run $ git checkout <version> . a few times first, which as I now know, would have been making updates to the index all along.

I presume this is what screwed things up for the normal checkout situation, because when I ran $ git checkout <version> on all the versions, there were always less files than I expected in the working dir

Still not sure if I can trust $ git checkout <version>...

Why should

$ git checkout <version> .

screw things up for

$ git checkout <version>

?

BC

conorr@KINKLADZE /w/GITPLATFORM/swproj $ cat > AC.txt AC

conorr@KINKLADZE /w/GITPLATFORM/swproj $ cat > C.txt C

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git init Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git add ABC.txt AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 8ce0d2c: version A
 2 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 ABC.txt
 create mode 100644 AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git tag versiona 8ce0

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git rm AC.txt rm 'AC.txt'

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git add BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: AC.txt # new file: BC.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit fad9c29: version B
 2 files changed, 1 insertions(+), 2 deletions(-)
 delete mode 100644 AC.txt
 create mode 100644 BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git tag versionB fad9

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ cat > AC.txt AC

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git commit -m "version C" # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # AC.txt # C.txt nothing added to commit but untracked files present (use "git add" to track)

conorr@KINKLADZE /w/GITPLATFORM/swproj $ // mistake - forgot to stage changes sh.exe": //: is a directory

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git reset --hard versionB HEAD is now at fad9c29 version B

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git add *c*.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: AC.txt # new file: C.txt #

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 9cf73cb: version C
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 AC.txt
 create mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git tag versionC 9cf7

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git rm *.* rm 'ABC.txt' rm 'AC.txt' rm 'BC.txt' rm 'C.txt'

conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version D"
Created commit 8e4b5be: version D
 4 files changed, 0 insertions(+), 4 deletions(-)
 delete mode 100644 ABC.txt
 delete mode 100644 AC.txt
 delete mode 100644 BC.txt
 delete mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git tag versionD 8e4b

conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master nothing to commit (working directory clean)

conorr@KINKLADZE /w/GITPLATFORM/swproj $ gitk

conorr@KINKLADZE /w/GITPLATFORM/swproj <sionA = ABC.txt, AC.txt, version B = ABC.txt, BC.txt sh.exe": //: is a directory

conorr@KINKLADZE /w/GITPLATFORM/swproj $ cat > commet.txt// gitk confirms that versionA = ABC.txt, AC.txt, sh.exe": commet.txt//: No such file or directory

conorr@KINKLADZE /w/GITPLATFORM/swproj $ cat > comment.txt gitk confirms that: versionA = ABC.txt, AC.txt versionB = ABC.txt, BC.txt versionC = ABC.txt, AC.txt, BC.txt, C.txt versionD =

conorr@KINKLADZE /w/GITPLATFORM/swproj $ gitk

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git show
WARNING: terminal is not fully functional
commit 8e4b5bed1faadc608fc114e62bf1859b6bbed4a0
Author: Conor Rafferty <cr@altmore.co.uk>
Date:   Wed Dec 31 11:40:45 2008 +0000

    version D

a quick comment: you don't need to use the sha1 to create a tag at the current HEAD. "git tag newtag sha" can be shortened to "git tag newtag" if the sha is for the latest commit you did. Like the "." thing, I'd be curious where you picked up this habit...

On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:

These are quite different operations so yes you could say they should have used some other name instead of overloading two different functions on the same command. But to be fair, the doc is fairly clear, in the first 2 paras.

And really, if I understand all your angst and what you're trying to do, you just have to stop using the "." and -- if you want untracked files gone each time you switch to an older version -- use git clean. See below.

I have snipped your log heavily but it should still be fairly simple to follow which piece I am referring to below:

you're wondering why AC.txt is still hanging around when resetting to a commit where that file was explicitly deleted?

A commit represents a state, not a set of actions.

"versionB" doesn't represent a "delete of AC.txt", plus an "add of BC.txt". It represents a state where ABC.txt and BC.txt exist, that's it.

So AC.txt is now just an untracked file at the point you do the reset, as you would have seen if you did a "git status".

A reset will not touch untracked files -- hardly any operation will touch an untracked file actually.

If you really want that functionality, use git clean after
the reset, this is the only command I know that deletes
untracked files:
        git clean -d -f
        # or first try with "-n" for a "dry-run"

[later]

And now you're wondering what happened to "AC.txt"? Well this time it's a known and tracked file for the current state (versionA), so it is a candidate for removal/change as dictated by the new state you're going to.

I should also mention that you have not yet tried the case where you have local modifications to some file that is known to both the current branch and the branch you're switching to. "git help checkout" and look for the word "merge" and read up the two places it is relevant to this context (one a description and one an example).