{"thread":{"id":"16936","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-31T15:14:25Z","messageCount":6,"participants":["Conor Rafferty","Boyd Stephen Smith Jr.","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99027","messageId":"BB5F02FD3789B54E8964D38D6775E718242D36@ALTMORE-SVR.altmore.local","threadId":"16936","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":"MERCURIAL:\n\nUpdate\nhg update [-C] [-d DATE] [[-r] REV] \n\nUpdate the repository's working directory (the \"working copy\") to the\nspecified revision of the repository or to the tip revision of the\ncurrent (named) branch if no revision is specified.  \n\n> I'm not looking for much....\n\n-----Original Message-----\nFrom: Jeff Whiteside [mailto:jeff.m.whiteside@gmail.com] \nSent: 31 December 2008 02:22\nTo: Daniel Barkalow\nCc: Conor Rafferty; Boyd Stephen Smith Jr.; git@vger.kernel.org\nSubject: Re: for newbs = little exercise / tutorial / warmup for windows\nand other non-sophisticated new Git users :-) [Scanned]\n\nwtf is wrong with\n\ngit checkout <something>\n\n??\n\nif you must have\n\ngit checkout <something> <paths>\n\nthen instead use\n\ngit checkout <something> <paths>\ngit clean\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\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":"99034","messageId":"200812302141.02248.bss@iguanasuicide.net","threadId":"16936","inReplyTo":"BB5F02FD3789B54E8964D38D6775E718242D36@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-31T03:40:58Z","receivedAt":"2008-12-31T03:40:58Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:\n> MERCURIAL:\n>\n> Update\n> hg update [-C] [-d DATE] [[-r] REV]\n\nWhich is the role of \"git checkout <branch>\"\n\n\"git checkout <branch> <paths>\" is similar to \"hg revert -r <branch> <paths>\", \nbut the later seems to handle your use case properly.  I don't know much \nabout the workings of hg revert -- it might use the history to determine \nwhat's correct, or completely bypass the existing \"index\" when determining \nwhat to drop.  In any case, it seems to work better for what you are trying \nto do.  Why not just use it?\n\nI could do with more hg/bzr/darcs experience myself, but git seems to behave \nthe way I like it so it's what I use.  When deciding on the right tool for \nthe job, it does help to have many.  \"To the man with only a hammer, all \nproblems look like nails.\"\n\nThat said, I'm pretty sure that if you hasn't specified '.' and just used \"git \ncheckout <branch>\" you wouldn't have seen those \"artifacts\".\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"99036","messageId":"7v7i5hymp7.fsf@gitster.siamese.dyndns.org","threadId":"16936","inReplyTo":"200812302141.02248.bss@iguanasuicide.net","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-31T04:48:20Z","receivedAt":"2008-12-31T04:48:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Boyd Stephen Smith Jr.\" <bss@iguanasuicide.net> writes:\n\n> On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:\n>> MERCURIAL:\n>>\n>> Update\n>> hg update [-C] [-d DATE] [[-r] REV]\n>\n> Which is the role of \"git checkout <branch>\"\n>\n> \"git checkout <branch> <paths>\" is similar to \"hg revert -r <branch> <paths>\", \n\nNo it is not.\n\nThe form of the command is makes this request:\n\n    Please look into that named <tree-ish>, and check out the named\n    <paths> out of it to my work tree.  Because the reason I want them in\n    my work tree is so that I can include them as part of the next commit\n    I am preparing to create in the index, please update these paths in my\n    index while at it.\n\nAfter working for some time on top of the current HEAD to make changes to\nexisting files in \"lib/\" directory, if you notice that none of your\nchanges in the directory does not make any sense, you may rather want to\nstart over from the version that you began with.  In such a case, you\nwould make the above request with <tree-ish> equal to HEAD and <paths>\nequal to \"lib\", i.e.\n\n    git checkout HEAD lib\n\nand as the end result you may be able to achieve \"reverting my crappy\nchanges to all of the files in lib/\".\n\nHOWEVER.\n\nRead what the above request says carefully again, and think about what\nwould happen to a path that exists in the work tree but not in the named\n<tree-ish>.\n\nIn other words, what would happen to a new file you added since you\nstarted working on top of HEAD?\n\nSee?\n\nA new file that you added in lib/ directory since you started working will\nnot be molested in any way, because they do not even exist in the\n<tree-ish>.\n\nIf you think \"git checkout <tree-ish> <paths>\" has anything to do with\nreverting, you will keep confusing yourself.  The command is \"checking out\nthe named paths out of the named tree\", and absense of a file is not\nsomething that is checked out by this operation.\n"},{"id":"99037","messageId":"alpine.LNX.1.00.0812302356040.19665@iabervon.org","threadId":"16936","inReplyTo":"7v7i5hymp7.fsf@gitster.siamese.dyndns.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-31T05:21:42Z","receivedAt":"2008-12-31T05:21:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Dec 2008, Junio C Hamano wrote:\n\n> \"Boyd Stephen Smith Jr.\" <bss@iguanasuicide.net> writes:\n> \n> > On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:\n> >> MERCURIAL:\n> >>\n> >> Update\n> >> hg update [-C] [-d DATE] [[-r] REV]\n> >\n> > Which is the role of \"git checkout <branch>\"\n> >\n> > \"git checkout <branch> <paths>\" is similar to \"hg revert -r <branch> <paths>\", \n> \n> No it is not.\n> \n> The form of the command is makes this request:\n> \n>     Please look into that named <tree-ish>, and check out the named\n>     <paths> out of it to my work tree.  Because the reason I want them in\n>     my work tree is so that I can include them as part of the next commit\n>     I am preparing to create in the index, please update these paths in my\n>     index while at it.\n\nWith that description, there's a bug: in addition to the above, it checks \nout from the index any path which does match the <paths> but isn't in \n<tree-ish>. I think the way to fix that would be to update the work tree \nfrom read_tree_some() instead of using the \"if pathspec_match() ... \ncheckout_entry()\" loop over the index.\n\nWith the current code, you can have git check out a file that you've \nchanged/deleted from a tree that doesn't contain it at all (and you get \nthe index version). E.g.:\n\n$ rm wt-status.c\n$ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c\n$ ls wt-status.c\nwt-status.c\n\n(instead, you should get an error if a <path> doesn't match anything in \nthe <tree-ish> and only get those things that it matches in the \n<tree-ish>.)\n\nI think I was too zealous sharing code back in February. I should have a \npatch by the weekend if nobody beats me to it. (And I still think that, if \nyou hit this case, you must be confused, but git isn't helping by doing \nwhat it does.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"99039","messageId":"7vzlicyj1o.fsf@gitster.siamese.dyndns.org","threadId":"16936","inReplyTo":"alpine.LNX.1.00.0812302356040.19665@iabervon.org","subject":"Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-31T06:07:15Z","receivedAt":"2008-12-31T06:07:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> With that description, there's a bug: in addition to the above, it checks \n> out from the index any path which does match the <paths> but isn't in \n> <tree-ish>....\n> ...\n> (instead, you should get an error if a <path> doesn't match anything in \n> the <tree-ish> and only get those things that it matches in the \n> <tree-ish>.)\n>\n> I think I was too zealous sharing code back in February. I should have a \n> patch by the weekend if nobody beats me to it. (And I still think that, if \n> you hit this case, you must be confused, but git isn't helping by doing \n> what it does.)\n\nI think that may be a good thing to do.\n\nBy the way, I am not opposed to have \"git $revert <tree-ish> <path>...\"\nthat makes the work tree and the index identical to what existed in\n<tree-ish> at the named <paths>, i.e. checking out \"the absense\" of files\nin the named directory if <path> is a subtree.  Because it is very\nestablished to use the command verb \"revert\" to mean making a\ncounter-commit by now, we may have to use a word other than \"revert\" for\nthat purpose, though.\n"},{"id":"99060","messageId":"200812310914.25779.bss@iguanasuicide.net","threadId":"16936","inReplyTo":"7v7i5hymp7.fsf@gitster.siamese.dyndns.org","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-31T15:14:25Z","receivedAt":"2008-12-31T15:14:25Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Tuesday 30 December 2008, Junio C Hamano <gitster@pobox.com> wrote \nabout 'Re: for newbs = little exercise / tutorial / warmup for windows and \nother non-sophisticated new Git users :-) [Scanned]':\n>\"Boyd Stephen Smith Jr.\" <bss@iguanasuicide.net> writes:\n>> \"git checkout <branch> <paths>\" is similar to \"hg revert -r <branch>\n>> <paths>\",\n>\n>No it is not.\n>\n>The form of the command is makes this request:\n>\n>    Please look into that named <tree-ish>, and check out the named\n>    <paths> out of it to my work tree.\n\nThat seems similar to \"hg revert\":\nUsing the -r option, revert the given files or directories to their\ncontents as of a specific revision.\n\n>    Because the reason I want them in \n>    my work tree is so that I can include them as part of the next commit\n>    I am preparing to create in the index, please update these paths in\n> my index while at it.\n\nThis part is odd to me, but does make some sense.  I can only think of a \nfew reasons to retrieve a file from a different tree-ish without \nimmediately turning around and doing \"git add <bar>\".\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"}]}