{"thread":{"id":"16935","subject":"RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","startedAt":"2008-12-31T02:22:32Z","lastAt":"2008-12-31T16:33:05Z","messageCount":11,"participants":["Conor Rafferty","Jeff Whiteside","Boyd Stephen Smith Jr.","Daniel Barkalow","Zorba","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99026","messageId":"BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local","threadId":"16935","inReplyTo":null,"subject":"RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Conor Rafferty","fromEmail":"conor.rafferty@altmore.co.uk","sentAt":null,"receivedAt":"2008-12-31T02:22:32Z","isPatch":false,"sender":{"key":"conor.rafferty@altmore.co.uk","avatar":null},"body":" \n\n-----Original Message-----\nwtf is wrong with\n\ngit checkout <something>\n\n??\n\n** It doesn't reliably put the files that were in that revision into the\nworking directory - a fairly major flaw, for what I'm using SCM for (and\n80% of the market IMHO)\n\nif you must have\n\ngit checkout <something> <paths>\n\nthen instead use\n\ngit checkout <something> <paths>\ngit clean\n\n** hmm, might try this - obviously as per Daniels post there is some\nundefined interaction happenign with the index, to screw up the working\ndirectory. I presume clean flushes the index?\n\nbut you will lose other files that aren't part of the repo but are still\nin the project's dir (i.e. untracked files).\n\n** don't care, I'll be removing them from working dir anyhow before\ndoing a rollback\n\nOn Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org>\nwrote:\n> On Tue, 30 Dec 2008, Conor Rafferty wrote:\n>\n>> I don't understand, sorry. I thought I'd already removed all files \n>> from the local tree, in the $ rm *.* move just above the checkout\n>\n> That removes them from the filesystem, but they're still in the index.\n\n> And \"git checkout <something> .\" first gets everything that *is* in \n> \".\" in <something> into the index, and then gets everything from \".\" \n> in the index into the filesystem.\n>\n> I suppose it is questionable as to whether it ought to copy paths that\n\n> aren't in versionA from the index into the filesystem.\n>\n> To see this in a bit more detail, do:\n>\n> $ rm *.*\n> $ git status\n> (notice that the deletes are in the \"won't be committed\" section)\n>\n> Now, \"git checkout <path>\" will discard any changes in the \"won't be \n> committed\" section for that path. Maybe \"git checkout versionA <path>\"\n> should only discard changes that are in the \"won't be committed\" \n> section for filenames that match that path and are in versionA (or are\n> *different* in versionA and not removed?), but I think it's an area \n> where, if you're expecting any particular behavior out of that \n> command, you're likely to be surprised in some way in some situation.\n>\n>        -Daniel\n> *This .sig left intentionally blank*\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in the \n> body of a message to majordomo@vger.kernel.org More majordomo info at\n\n> http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"99028","messageId":"3ab397d0812301835oc2978e2q4eedc618ad54a47f@mail.gmail.com","threadId":"16935","inReplyTo":"BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Jeff Whiteside","fromEmail":"jeff.m.whiteside@gmail.com","sentAt":"2008-12-31T02:35:55Z","receivedAt":"2008-12-31T02:35:55Z","isPatch":false,"sender":{"key":"jeff.m.whiteside@gmail.com","avatar":null},"body":"sir, i believe you're not reading what is typed.\n\n> wtf is wrong with\n>\n> git checkout <something>\n>\n> ??\n>\n> ** It doesn't reliably put the files that were in that revision into the\n> working directory - a fairly major flaw, for what I'm using SCM for (and\n> 80% of the market IMHO)\n\nyes it does.  your example uses \"git checkout versionB .\", which is\nNOT \"git checkout <something>\"\nwe are suggesting you do \"git checkout versionB\" which is different\n(HINT: there is NO dot), and which i'm 99% positive will work.\n\nif you still disagree, then i'm sure mercurial will be sufficient for\nyour needs, and all your dcvs book-lernin' over christmas will be\ntransferrable.\n\ngood luck with whatever option you choose.\n"},{"id":"99032","messageId":"200812302056.21748.bss@iguanasuicide.net","threadId":"16935","inReplyTo":"BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2008-12-31T02:56:17Z","receivedAt":"2008-12-31T02:56:17Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Tuesday 2008 December 30 20:27:26 Conor Rafferty wrote:\n> -----Original Message-----\n> wtf is wrong with\n>\n> git checkout <something>\n>\n> ??\n>\n> ** It doesn't reliably put the files that were in that revision into the\n> working directory - a fairly major flaw, for what I'm using SCM for (and\n> 80% of the market IMHO)\n\nAnd you would be wrong, IMHO.  Many people have untracked files or directories \nin their working directory ('cause they are working there) that they don't \nwant deleted willy-nilly.  Build files, modifications that should be on a \ndifferent branch, etc.  There's another thread active on the list complaining \nthat git removes too much from the working tree.\n\nMost users of SCMs do make active modifications to the files in the SCM.  It's \nnot a system only for archiving static projects.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"99033","messageId":"alpine.LNX.1.00.0812302143210.19665@iabervon.org","threadId":"16935","inReplyTo":"BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local","subject":"RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-31T03:10:45Z","receivedAt":"2008-12-31T03:10:45Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Dec 2008, Conor Rafferty wrote:\n\n> -----Original Message-----\n> wtf is wrong with\n> \n> git checkout <something>\n> \n> ??\n> \n> ** It doesn't reliably put the files that were in that revision into the\n> working directory - a fairly major flaw, for what I'm using SCM for (and\n> 80% of the market IMHO)\n\nIt certainly does for me; I rely on it pretty much constantly. Can you \ngive a sequence of commands (ideally the whole sequence from the \"git \ninit\") that leads to a difference?\n\nThe only case I know of where there will be files left over is if you \nswitch from a situation where you have an untracked file (e.g., you create \nC.txt but don't add it to anything) to another situation where the file \nstill isn't tracked, it won't remove it. But, of course, you wouldn't \nreally want git to remove your uncommitted work in general, since it's \ngenerally irreplaceable. It'll only be lacking files if it fails to switch \n(if, for instance, you had uncommitted changes that conflict with the \nchanges that it would do), and it will give an error message in that case.\n\n> if you must have\n> \n> git checkout <something> <paths>\n> \n> then instead use\n> \n> git checkout <something> <paths>\n> git clean\n> \n> ** hmm, might try this - obviously as per Daniels post there is some\n> undefined interaction happenign with the index, to screw up the working\n> directory. I presume clean flushes the index?\n\ngit clean wouldn't remove those files, because they're supposed to be \nthere at that point.\n\nIn the sequence:\n\n...\n$ git tag versionD\n$ git checkout versionA .\n\nThis means: \"Update the index with the files in versionA, and working \ndirectory from the index\"\n\nSo now you're working on a commit based versionD (because you didn't \nswitch branches), and your work thus far, which is marked as ready for \nyour next commit, is to recover the removed files ABC.txt and AC.txt (from \nversionA).\n\n$ rm *.*\n\nThis removes those files again, but only in your working directory. Your \nindex still says that your next commit will recover them.\n\n$ git checkout versionB .\n\nThis recovers ABC.txt and BC.txt (from versionB). Your index has ABC.txt, \nBC.txt (from versionB), and AC.txt (from versionA), marked as going into \nthe next commit. It also puts all of these in your working directory (when \nyou might expect it to only put ABC.txt and BC.txt there).\n\nSo (a) you're still working on the commit after versionD, rather than \nnavagting history at all; and (b) you've recovered files from two \ndifferent commits.\n\nNow:\n\n$ git clean\n\nwill remove any files that you happen to have around, other than the one \nyou're confused about and trying to get rid of.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"99035","messageId":"alpine.LNX.1.00.0812302236190.19665@iabervon.org","threadId":"16935","inReplyTo":"alpine.LNX.1.00.0812302143210.19665@iabervon.org","subject":"RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-31T03:49:19Z","receivedAt":"2008-12-31T03:49:19Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Dec 2008, Daniel Barkalow wrote:\n\n> On Wed, 31 Dec 2008, Conor Rafferty wrote:\n> \n> > -----Original Message-----\n> > wtf is wrong with\n> > \n> > git checkout <something>\n> > \n> > ??\n> > \n> > ** It doesn't reliably put the files that were in that revision into the\n> > working directory - a fairly major flaw, for what I'm using SCM for (and\n> > 80% of the market IMHO)\n> \n> It certainly does for me; I rely on it pretty much constantly. Can you \n> give a sequence of commands (ideally the whole sequence from the \"git \n> init\") that leads to a difference?\n\nActually, I know what you must be doing:\n\n$ git tag versionD\n$ git checkout versionA\n(versionA in the working directory)\n$ rm *.*\n(versionA with ABC.txt and AC.txt deleted)\n$ git checkout versionB\n(versionB with ABC.txt and AC.txt deleted)\n\nIf you've made any changes (including deleting files), \"git checkout\" (no \npathes) will preserve them. On the other hand, it will remove files that \nare in the commit you're leaving and not in the commit you're going to. So \njust don't remove the working directory files and you should be all set.\n\nIn order to get them back if you have removed them, you can do:\n\n$ git checkout .\n\nThis will discard all of the changes you've made only to the working \ndirectory; i.e., it'll recover the deleted files. You should also try \"git \nstatus\" whenever anything's mysterious, because it will tell you what's \ngoing on.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"99055","messageId":"gjfn28$3k2$4@ger.gmane.org","threadId":"16935","inReplyTo":"alpine.LNX.1.00.0812302143210.19665@iabervon.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Zorba","fromEmail":"cr@altmore.co.uk","sentAt":null,"receivedAt":"2008-12-31T10:56:09Z","isPatch":false,"sender":{"key":"cr@altmore.co.uk","avatar":null},"body":"Ok, starting from scratch, new dir, new repo\n\nI can now get $ git checkout <version> to work (see extract below, missed \nthe first few lines due to exceeding buffer)\n\nThe difference with the instance when I found \"errors\" is that that time I'd \nrun $ git checkout <version> .\na few times first, which as I now know, would have been making updates to \nthe index all along.\n\nI presume this is what screwed things up for the normal checkout situation, \nbecause when I ran $ git checkout <version> on all the versions, there were \nalways less files than I expected in the working dir\n\nStill not sure if I can trust $ git checkout <version>...\n\nWhy should\n\n$ git checkout <version> .\n\nscrew things up for\n\n$ git checkout <version>\n\n?\n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\n\nBC\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ cat > AC.txt\nAC\n\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ cat > C.txt\nC\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git init\nInitialized empty Git repository in w:/GITPLATFORM/swproj/.git/\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git add ABC.txt AC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git commit -m \"version A\"\nCreated initial commit 8ce0d2c: version A\n 2 files changed, 3 insertions(+), 0 deletions(-)\n create mode 100644 ABC.txt\n create mode 100644 AC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git tag versiona 8ce0\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git rm AC.txt\nrm 'AC.txt'\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git add BC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git status\n# On branch master\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#       deleted:    AC.txt\n#       new file:   BC.txt\n#\n# Untracked files:\n#   (use \"git add <file>...\" to include in what will be committed)\n#\n#       C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git commit -m \"version B\"\nCreated commit fad9c29: version B\n 2 files changed, 1 insertions(+), 2 deletions(-)\n delete mode 100644 AC.txt\n create mode 100644 BC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git tag versionB fad9\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ cat > AC.txt\nAC\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git commit -m \"version C\"\n# On branch master\n# Untracked files:\n#   (use \"git add <file>...\" to include in what will be committed)\n#\n#       AC.txt\n#       C.txt\nnothing added to commit but untracked files present (use \"git add\" to track)\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ // mistake - forgot to stage changes\nsh.exe\": //: is a directory\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git reset --hard versionB\nHEAD is now at fad9c29 version B\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git add *c*.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git status\n# On branch master\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#       new file:   AC.txt\n#       new file:   C.txt\n#\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git commit -m \"version C\"\nCreated commit 9cf73cb: version C\n 2 files changed, 2 insertions(+), 0 deletions(-)\n create mode 100644 AC.txt\n create mode 100644 C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git tag versionC 9cf7\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git rm *.*\nrm 'ABC.txt'\nrm 'AC.txt'\nrm 'BC.txt'\nrm 'C.txt'\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git commit -m \"version D\"\nCreated commit 8e4b5be: version D\n 4 files changed, 0 insertions(+), 4 deletions(-)\n delete mode 100644 ABC.txt\n delete mode 100644 AC.txt\n delete mode 100644 BC.txt\n delete mode 100644 C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git tag versionD 8e4b\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git status\n# On branch master\nnothing to commit (working directory clean)\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ gitk\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n<sionA = ABC.txt, AC.txt, version B = ABC.txt, BC.txt\nsh.exe\": //: is a directory\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ cat > commet.txt// gitk confirms that versionA = ABC.txt, AC.txt,\nsh.exe\": commet.txt//: No such file or directory\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ cat > comment.txt\ngitk confirms that:\nversionA = ABC.txt, AC.txt\nversionB = ABC.txt, BC.txt\nversionC = ABC.txt, AC.txt, BC.txt, C.txt\nversionD =\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ gitk\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git show\nWARNING: terminal is not fully functional\ncommit 8e4b5bed1faadc608fc114e62bf1859b6bbed4a0\nAuthor: Conor Rafferty <cr@altmore.co.uk>\nDate:   Wed Dec 31 11:40:45 2008 +0000\n\n    version D\n\ndiff --git a/ABC.txt b/ABC.txt\ndeleted file mode 100644\nindex 83871a5..0000000\n--- a/ABC.txt\n+++ /dev/null\n@@ -1 +0,0 @@\n-ABC\ndiff --git a/AC.txt b/AC.txt\ndeleted file mode 100644\nindex 9eadfae..0000000\n--- a/AC.txt\n+++ /dev/null\n@@ -1 +0,0 @@\n-AC\ndiff --git a/BC.txt b/BC.txt\ndeleted file mode 100644\nindex b3ac6f5..0000000\n--- a/BC.txt\n+++ /dev/null\n@@ -1 +0,0 @@\n-BC\ndiff --git a/C.txt b/C.txt\ndeleted file mode 100644\nindex 06a63fe..0000000\n--- a/C.txt\n+++ /dev/null\n@@ -1 +0,0 @@\n-C\n(END)\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionA\nNote: moving to \"versionA\" which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n  git checkout -b <new_branch_name>\nHEAD is now at 8ce0d2c... version A\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  comment.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionB\nPrevious HEAD position was 8ce0d2c... version A\nHEAD is now at fad9c29... version B\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  BC.txt  comment.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionC\nPrevious HEAD position was fad9c29... version B\nHEAD is now at 9cf73cb... version C\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt  comment.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionD\nPrevious HEAD position was 9cf73cb... version C\nHEAD is now at 8e4b5be... version D\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\ncomment.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ rm *.*\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionA\nPrevious HEAD position was 8e4b5be... version D\nHEAD is now at 8ce0d2c... version A\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionB\nPrevious HEAD position was 8ce0d2c... version A\nHEAD is now at fad9c29... version B\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  BC.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionC\nPrevious HEAD position was fad9c29... version B\nHEAD is now at 9cf73cb... version C\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\nABC.txt  AC.txt  BC.txt  C.txt\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ git checkout versionD\nPrevious HEAD position was 9cf73cb... version C\nHEAD is now at 8e4b5be... version D\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$ ls\n\nconorr@KINKLADZE /w/GITPLATFORM/swproj\n$\n\n\"Daniel Barkalow\" <barkalow@iabervon.org> wrote in message\n>\n>> wtf is wrong with\n>>\n>> git checkout <something>\n>>\n>> ??\n>>\n>> ** It doesn't reliably put the files that were in that revision into the\n>> working directory - a fairly major flaw, for what I'm using SCM for (and\n>> 80% of the market IMHO)\n>\n> It certainly does for me; I rely on it pretty much constantly. Can you\n> give a sequence of commands (ideally the whole sequence from the \"git\n> init\") that leads to a difference?\n"},{"id":"99056","messageId":"gjfnsb$5ph$4@ger.gmane.org","threadId":"16935","inReplyTo":"alpine.LNX.1.00.0812302236190.19665@iabervon.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Zorba","fromEmail":"cr@altmore.co.uk","sentAt":null,"receivedAt":"2008-12-31T10:56:09Z","isPatch":false,"sender":{"key":"cr@altmore.co.uk","avatar":null},"body":"Ok, now I'm following you, cos I just \"broke\" checkout again by deleting \nfiles from working dirs before running it.\n\ngit-checkout takes into account the state of the working tree in the commit \nit is run FROM, as well as the commit it is checking out.\n\nIt relies on the working tree being in synch with the commit it is run from.\nIf I delete files, I screw around with this initial state.\nFiles that git-checkout is relying on to be there are not copied in by it, \nso if I've deleted (or modified) those files, hard luck.\n\nI remember s/o saying git minimizes file I/O, and this whats happening here.\n\nIt puts a big demand on the user, to keep their index & working dir in synch \nwith whats in the commit.\n\nAh,\n\n$ git checkout .\n\nwill restore the state of the working dir to be in synch with the CURRENT \ncommit, so it will be safe to checkout other branches\n\nBINGO !!\nwhat I need to do is run the sequence\n\n$ git checkout .                    // tidy up current commit\n$ git checkout <version>     // roll back\n\nn'est pas ?\n\n\n\"Daniel Barkalow\" <barkalow@iabervon.org> wrote in message \nnews:alpine.LNX.1.00.0812302236190.19665@iabervon.org...\n> On Tue, 30 Dec 2008, Daniel Barkalow wrote:\n>\n>> On Wed, 31 Dec 2008, Conor Rafferty wrote:\n>>\n>> > -----Original Message-----\n>> > wtf is wrong with\n>> >\n>> > git checkout <something>\n>> >\n>> > ??\n>> >\n>> > ** It doesn't reliably put the files that were in that revision into \n>> > the\n>> > working directory - a fairly major flaw, for what I'm using SCM for \n>> > (and\n>> > 80% of the market IMHO)\n>>\n>> It certainly does for me; I rely on it pretty much constantly. Can you\n>> give a sequence of commands (ideally the whole sequence from the \"git\n>> init\") that leads to a difference?\n>\n> Actually, I know what you must be doing:\n>\n> $ git tag versionD\n> $ git checkout versionA\n> (versionA in the working directory)\n> $ rm *.*\n> (versionA with ABC.txt and AC.txt deleted)\n> $ git checkout versionB\n> (versionB with ABC.txt and AC.txt deleted)\n>\n> If you've made any changes (including deleting files), \"git checkout\" (no\n> pathes) will preserve them. On the other hand, it will remove files that\n> are in the commit you're leaving and not in the commit you're going to. So\n> just don't remove the working directory files and you should be all set.\n>\n> In order to get them back if you have removed them, you can do:\n>\n> $ git checkout .\n>\n> This will discard all of the changes you've made only to the working\n> directory; i.e., it'll recover the deleted files. You should also try \"git\n> status\" whenever anything's mysterious, because it will tell you what's\n> going on.\n>\n> -Daniel\n> *This .sig left intentionally blank* \n"},{"id":"99058","messageId":"slrnglmtdd.v54.sitaramc@sitaramc.homelinux.net","threadId":"16935","inReplyTo":"gjfn28$3k2$4@ger.gmane.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-31T13:37:49Z","receivedAt":"2008-12-31T13:37:49Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"a quick comment: you don't need to use the sha1 to create a\ntag at the current HEAD.  \"git tag newtag sha\" can be\nshortened to \"git tag newtag\" if the sha is for the latest\ncommit you did.  Like the \".\" thing, I'd be curious where\nyou picked up this habit...\n\nOn 2008-12-31, Zorba <cr@altmore.co.uk> wrote:\n> Why should\n>\n> $ git checkout <version> .\n>\n> screw things up for\n>\n> $ git checkout <version>\n\nThese are quite different operations so yes you could say\nthey should have used some other name instead of overloading\ntwo different functions on the same command.  But to be\nfair, the doc is fairly clear, in the first 2 paras.\n\nAnd really, if I understand all your angst and what you're\ntrying to do, you just have to stop using the \".\" and -- if\nyou want untracked files gone each time you switch to an\nolder version -- use git clean.  See below.\n\nI have snipped your log heavily but it should still be\nfairly simple to follow which piece I am referring to below:\n\n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\n\n> $ git rm AC.txt\n> $ git add BC.txt\n> $ git commit -m \"version B\"\n> $ git tag versionB fad9\n\n> $ cat > AC.txt\n> $ ls\n> ABC.txt  AC.txt  BC.txt  C.txt\n\n> $ git reset --hard versionB\n> HEAD is now at fad9c29 version B\n> $ ls\n> ABC.txt  AC.txt  BC.txt  C.txt\n\nyou're wondering why AC.txt is still hanging around when\nresetting to a commit where that file was explicitly\ndeleted?\n\nA commit represents a state, not a set of actions.\n\n\"versionB\" doesn't represent a \"delete of AC.txt\", plus an\n\"add of BC.txt\".  It represents a state where ABC.txt and\nBC.txt exist, that's it.\n\nSo AC.txt is now just an untracked file at the point you do\nthe reset, as you would have seen if you did a \"git status\".\n\nA reset will not touch untracked files -- hardly any\noperation will touch an untracked file actually.\n\nIf you really want that functionality, use git clean after\nthe reset, this is the only command I know that deletes\nuntracked files:\n        git clean -d -f\n        # or first try with \"-n\" for a \"dry-run\"\n\n[later]\n\n> $ git checkout versionA\n> $ ls\n> ABC.txt  AC.txt  comment.txt\n\n> $ git checkout versionB\n> $ ls\n> ABC.txt  BC.txt  comment.txt\n\nAnd now you're wondering what happened to \"AC.txt\"?  Well\nthis time it's a known and tracked file for the current\nstate (versionA), so it is a candidate for removal/change as\ndictated by the new state you're going to.\n\nI should also mention that you have not yet tried the case\nwhere you have local modifications to some file that is\nknown to both the current branch and the branch you're\nswitching to.  \"git help checkout\" and look for the word\n\"merge\" and read up the two places it is relevant to this\ncontext (one a description and one an example).\n"},{"id":"99059","messageId":"slrnglmu0j.v54.sitaramc@sitaramc.homelinux.net","threadId":"16935","inReplyTo":"gjfnsb$5ph$4@ger.gmane.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-31T13:48:03Z","receivedAt":"2008-12-31T13:48:03Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:\n> It puts a big demand on the user, to keep their index & working dir in synch \n> with whats in the commit.\n\nor they could just use \"git checkout -f tag_to_goto\" I\nsuppose...\n"},{"id":"99067","messageId":"alpine.LNX.1.00.0812311103000.19665@iabervon.org","threadId":"16935","inReplyTo":"gjfnsb$5ph$4@ger.gmane.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-31T16:24:47Z","receivedAt":"2008-12-31T16:24:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Dec 2008, Zorba wrote:\n\n> Ok, now I'm following you, cos I just \"broke\" checkout again by deleting \n> files from working dirs before running it.\n> \n> git-checkout takes into account the state of the working tree in the commit \n> it is run FROM, as well as the commit it is checking out.\n> \n> It relies on the working tree being in synch with the commit it is run from.\n> If I delete files, I screw around with this initial state.\n> Files that git-checkout is relying on to be there are not copied in by it, \n> so if I've deleted (or modified) those files, hard luck.\n\nIt's not relying on these files to be there; it's actually aware that \nthey're not there. It thinks that any modifications you've made might be \nimportant work, and carefully preserves it.\n\nActually, it should be telling you the changes that it's carrying over \nwith lines like:\n\nD\tABC.txt\n\n(which indicated that you've deleted ABC.txt, and it's keeping that \nmodification)\n\n> I remember s/o saying git minimizes file I/O, and this whats happening here.\n> \n> It puts a big demand on the user, to keep their index & working dir in synch \n> with whats in the commit.\n\nThe user is hopefully not going to make a lot of random undesired changes \nin general. It's hard to get much done that way. If you have made changes, \nyou can use \"git checkout .\" to get the versions back from the index, or \n\"git checkout HEAD .\" to get them back from the commit. \n\n> Ah,\n> \n> $ git checkout .\n> \n> will restore the state of the working dir to be in synch with the CURRENT \n> commit, so it will be safe to checkout other branches\n> \n> BINGO !!\n> what I need to do is run the sequence\n> \n> $ git checkout .                    // tidy up current commit\n> $ git checkout <version>     // roll back\n> \n> n'est pas ?\n\nEither that, or:\n\n$ git checkout <version>\n$ git checkout .\n\n(it doesn't matter whether you get rid of the local modifications and \ndeletions before switching, or switch first, and then get rid of any \nremaining local modifications and deletions)\n\nYou may also want:\n\n$ git clean\n\nTo get rid of untracked files you may have around (use \"git clean -x\" if \nyou also want to get rid of files you've told git to ignore).\n\nIncidentally, if your goal is to give someone a copy of the state as of a \nparticular version, you can use:\n\n$ git archive --format=zip <commit> > version.zip\n\nThis doesn't involve your working directory at all, and just generates a \nzip file out of the history. I find that this means I rarely actually care \nabout having a working directory that's free of random junk.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"99068","messageId":"slrngln7m1.7bm.sitaramc@sitaramc.homelinux.net","threadId":"16935","inReplyTo":"alpine.LNX.1.00.0812311103000.19665@iabervon.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-31T16:33:05Z","receivedAt":"2008-12-31T16:33:05Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-31, Daniel Barkalow <barkalow@iabervon.org> wrote:\n>> $ git checkout .                    // tidy up current commit\n>> $ git checkout <version>     // roll back\n\n> Either that, or:\n>\n> $ git checkout <version>\n> $ git checkout .\n>\n> (it doesn't matter whether you get rid of the local modifications and \n> deletions before switching, or switch first, and then get rid of any \n> remaining local modifications and deletions)\n>\n> You may also want:\n>\n> $ git clean\n\nI think \"git checkout -f <version>\" will do *all* of that.\n"}]}