{"thread":{"id":"3334","subject":"several quick questions","startedAt":"2006-02-14T16:28:34Z","lastAt":"2006-02-24T21:57:27Z","messageCount":57,"participants":["Nicolas Vilz 'niv'","Andreas Ericsson","Linus Torvalds","Kenneth Johansson","Carl Worth","Keith Packard","Junio C Hamano","Petr Baudis","Johannes Schindelin","Josef Weidendorfer","Martin Langhoff","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16114","messageId":"43F20532.5000609@iaglans.de","threadId":"3334","inReplyTo":null,"subject":"several quick questions","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-02-14T16:28:34Z","receivedAt":"2006-02-14T16:28:34Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"Hello everyone,\n\ni wonder, how i revoke a straight forward merge of two trees... I\nactually wanted to be look like somewhere in the git-repository, where\nsome branches are merged back with the master tree, but i think, that\nwasn't \"cg-merge -c \"...\n\nmy result was that my master tree has now the same sha1-sum as my\ndevelopment-tree and gitk visualisation differs from that what i saw in\nthe git-repository. (Several Arrows headed into back into one line...)\n\nmaybe that was because i didn't do anything in my master tree in the\nmeantime.\n\nAnd another thing, is there no posibility to get back to some commits or\ntags? I realized you can rebranch tags... what, if i want to switch back\nto git version 1.1.6 in the git repository? Or a certain commit?\n\ndo you have to make a new private branch out of the tag 1.1.6?\n\ni used svn and there i could go back some revisions. I haven't found\nsuch a feature in git, yet... but i think i am blind all the time.\n\nI like git very much and every new day I like it more.\n\nSincerly\nNicolas\n"},{"id":"16115","messageId":"43F20D4B.3060606@op5.se","threadId":"3334","inReplyTo":"43F20532.5000609@iaglans.de","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-14T17:03:07Z","receivedAt":"2006-02-14T17:03:07Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Vilz 'niv' wrote:\n> Hello everyone,\n> \n> i wonder, how i revoke a straight forward merge of two trees... I\n> actually wanted to be look like somewhere in the git-repository, where\n> some branches are merged back with the master tree, but i think, that\n> wasn't \"cg-merge -c \"...\n> \n> my result was that my master tree has now the same sha1-sum as my\n> development-tree and gitk visualisation differs from that what i saw in\n> the git-repository. (Several Arrows headed into back into one line...)\n> \n> maybe that was because i didn't do anything in my master tree in the\n> meantime.\n> \n\nCorrect. The \"several arrows\" thing is when a merge happens (i.e. two \nsimultaneous lines of development crash into one another with \nsurprisingly pleasant results most of the time). When you do\n\n$ git checkout -b topic-branch\n# work, work, work\n$ git checkout master\n$ git pull . topic-branch\n\ngit will recognize the merge-base as being the current HEAD and simply \nsets HEAD to point to that of topic-branch. This is why it's called a \nfast-forward, since no heavy computing needs to be done to combine the \ntwo development tracks.\n\n> And another thing, is there no posibility to get back to some commits or\n> tags? I realized you can rebranch tags... what, if i want to switch back\n> to git version 1.1.6 in the git repository? Or a certain commit?\n> \n\ngit reset is your friend.\n\n$ git reset --hard v1.1.6\n$ git reset --hard ORIG_HEAD\n\nshould do something along the lines of what you want.\n\n> do you have to make a new private branch out of the tag 1.1.6?\n> \n\nNo, you don't, but you can if you wish. It's nifty if you want to fork \nthe development from a particular branch. In your case, if you really, \nreally *want* the arrows pointing to one line, you can do\n\n$ git branch topic-branch HEAD^\n# work, work, work\n$ git checkout master\n$ git pull . topic-branch\n\nThat would create one pretty arrow. When multiple tracks of development \n(rather than just two) are combined into one it's called an octopus \nmerge. Unless you really know what you're doing, you should try to avoid \nthose for small projects, and doing it just for the pretty arrows is.... \nwell, let's call it \"interesting from the behaviour science scholars \npoint of view\".\n\n\n> i used svn and there i could go back some revisions. I haven't found\n> such a feature in git, yet... but i think i am blind all the time.\n> \n\nMost likely. I believe at least the reset command is mentioned in the \ntutorial. I trust you've read it before asking, so something is amiss \neither with your eyesight or the tutorial.\n\n\n> I like git very much and every new day I like it more.\n> \n\nIt's a Good Thing. ;)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16116","messageId":"Pine.LNX.4.64.0602140845080.3691@g5.osdl.org","threadId":"3334","inReplyTo":"43F20532.5000609@iaglans.de","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T17:05:16Z","receivedAt":"2006-02-14T17:05:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:\n> \n> i wonder, how i revoke a straight forward merge of two trees... I\n> actually wanted to be look like somewhere in the git-repository, where\n> some branches are merged back with the master tree, but i think, that\n> wasn't \"cg-merge -c \"...\n> \n> my result was that my master tree has now the same sha1-sum as my\n> development-tree and gitk visualisation differs from that what i saw in\n> the git-repository. (Several Arrows headed into back into one line...)\n> \n> maybe that was because i didn't do anything in my master tree in the\n> meantime.\n> \n> And another thing, is there no posibility to get back to some commits or\n> tags? I realized you can rebranch tags... what, if i want to switch back\n> to git version 1.1.6 in the git repository? Or a certain commit?\n\nBoth of these can be solved with \"git reset\".\n\nBefore going into any more detail on that, let's go over the other related \n\"basic operations\" too:\n\n - \"git branch\". This creates a new branch of development at an arbitrary \n point (that defaults to \"current state\").\n\n Example:\n\n\tgit branch development-trial v1.1.6\n\n This will create a new branch called \"development-trial\", which starts \n at the v1.1.6 state. NOTE! It will _not_ check it out - your old active \n state is left totally alone, and you still stay on whatever branch you \n used to be on.\n\n - \"git checkout\". This switches to another branch. As a shorthand, you \n can also choose to create the branch at the same time, but normally \n you'd just do like this example:\n\n\tgit checkout development-trial\n\n which will switch to the branch you just created and check that out.\n\n - \"git reset\". This will reset the current branch state to something \n else. This is what you would use if you want to undo a commit, \n for example: you can \"reset\" the current branch to before the commit \n happened.\n\n NOTE! When you do this, you also have to choose what you want to do \n about your checked-out working tree. For example, when undoing the last \n commit, you normally want to totally undo all the working tree changes \n too, but you might also want to just undo the commit, and leave the \n actual changes you committed alone, so that you can re-commit them with \n a fixed commit message, for example.\n\n Example:\n\n\tgit reset --hard HEAD^\n\n this will undo the last commit (more exactly: it will select the first \n parent of HEAD to be the new top-of-development, so if the last thing \n you did was a merge, it will reset to the previous state). The \"--hard\" \n means that you want to reset the working tree too.\n\n Other example:\n\n\tgit reset --hard v1.1.6\n\n This will just reset the current branch to a particular known state (ie \n 1.1.6 in this case).\n\n Without the \"--hard\", it will _not_ change the working tree, but just \n update the index (and branch pointer, of course) to the new state, and \n tell you which files are \"dirty\" in that new state. This is great for \n undoing just a \"git commit\", but leaving the tree in the state is was \n before you committed. It's not so great if you expected to revert \n everything, and are now confused because \"git diff\" shows lots of \n changes ;)\n\nFinally, let's go over the difference between \"git fetch\" and \"git pull\":\n\n - \"git fetch\" is what you want to do if you want to _update_ another \n branch. For example, if you want to track what Junio is doing in his \n git repository (assuming that was what you cloned for), doing\n\n\tgit fetch origin\n\n will update the \"origin\" branch, but will _not_ touch the current \n branch itself. This is very useful for seeing what Junio has been \n doing, without actually affecting your own work in any way.\n\n - \"git pull\" is really just \"git fetch\" + \"git merge\". It will fetch the \n state you asked for, and then merge that into your current branch. So \n it's important to rmember that this actually _changes_ what you have \n checked out and have worked on. \n\n One very special case of \"git pull\" is when you only use the repository \n to track another branch, and you never do any changes at all, and you \n never switch branches around, and you always pull from the same source. \n In that case, \"git pull\" will basically boil down to just a read-only \n tracking mechanism (ie you could think of this particular usage as \n being the git equivalent of \"anoncvs\" access)\n\nThe reason people may get confused is that they start out using \"git pull\" \nas a read-only tracking mechanism, and it's not necessarily obvious that \n\"git pull\" really fundamentally is a very powerful operations - much MUCH \nmore complex and powerful than just \"track that other branch\". Which is \nwhy I try to make the distinction between \"git fetch\" and \"git pull\" \nclear.\n\n\t\t\tLinus\n"},{"id":"16120","messageId":"pan.2006.02.14.17.47.53.126690@canit.se","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602140845080.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Kenneth Johansson","fromEmail":"ken@canit.se","sentAt":"2006-02-14T17:47:53Z","receivedAt":"2006-02-14T17:47:53Z","isPatch":false,"sender":{"key":"ken@canit.se","avatar":null},"body":"On Tue, 14 Feb 2006 09:05:16 -0800, Linus Torvalds wrote:\n\n> \n> \n> On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:\n>> \n>> i wonder, how i revoke a straight forward merge of two trees... I\n>> actually wanted to be look like somewhere in the git-repository, where\n>> some branches are merged back with the master tree, but i think, that\n>> wasn't \"cg-merge -c \"...\n>> \n>> my result was that my master tree has now the same sha1-sum as my\n>> development-tree and gitk visualisation differs from that what i saw in\n>> the git-repository. (Several Arrows headed into back into one line...)\n>> \n>> maybe that was because i didn't do anything in my master tree in the\n>> meantime.\n>> \n>> And another thing, is there no posibility to get back to some commits or\n>> tags? I realized you can rebranch tags... what, if i want to switch back\n>> to git version 1.1.6 in the git repository? Or a certain commit?\n> \n> Both of these can be solved with \"git reset\".\n\nI also had this exact question today since I wanted to compile an earlier\nversion of the kernel and like Nicolas I naturally got stuck on the\ncheckout command and that dose not work like one would think.\n\nWhat I ended up doing was going nee deep into the plumbing.\n\nfirst doing cat on the tag in .git/refs/tags/ \ntaking the output as an argument to \"git-read-tree\"\nfollowed by \"git-update-index --replace\" and \"git-checkout-index -a -f -u\"\n\nI'm not sure that many people will understand that they want git-reset for\nthis just reading the man pages.\n"},{"id":"16123","messageId":"43F21CB1.5010203@op5.se","threadId":"3334","inReplyTo":"pan.2006.02.14.17.47.53.126690@canit.se","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-14T18:08:49Z","receivedAt":"2006-02-14T18:08:49Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kenneth Johansson wrote:\n> \n> I'm not sure that many people will understand that they want git-reset for\n> this just reading the man pages.\n> \n\nHence the tutorial.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16124","messageId":"87k6bxvmj6.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602140845080.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-14T18:10:53Z","receivedAt":"2006-02-14T18:10:53Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 09:05:16 -0800 (PST), Linus Torvalds wrote:\n> \n> Both of these can be solved with \"git reset\".\n...\n> - \"git branch\". This creates a new branch of development at an arbitrary \n> point (that defaults to \"current state\").\n> \n> - \"git checkout\". This switches to another branch.\n> \n> - \"git reset\". This will reset the current branch state to something \n> else.\n\nThanks for the summary.\n\nI don't know if it's the original poster's question or not, but an\noperation I don't see in the above is \"put the working files into the\nstate of a given revision\".\n\nI recently needed this for some historical investigation,\n(specifically examining all release tags to ensure that the results\nafter a git import match the results of what we get from the former\nCVS repository).\n\nIn this kind of historical exploration, the notion of a \"current\nbranch\" isn't interesting, since I won't be doing any commits. So the\nhandling of the current branch in the above commands ends up getting\nin my way [*].\n\nIs there a more fundamental operation to \"put the working files into\nthe state of the index\"? If that exists, then that combined with\ngit-read-tree would give me what I wanted I think.\n\n-Carl\n\n[*] I did succeed in performing the operation, but only in rather\nawkward ways. Here are a couple of versions of \"put the working files\ninto the state of \", both requiring the use of an otherwise\nunnecessary branch, (bogus-branch):\n\n1) Ensure bogus-branch doesn't exist, then create it at :\n\n\t# Can't be on bogus-branch when we delete it\n\tgit checkout master\n\t# Use -D to force the removal, ignore errors for branch-does-not-exist\n\tgit branch -D bogus-branch >& /dev/null || true\n\t# Create the branch where we want it\n\tgit checkout -b bogus-branch \n\n2) Ensure that bogus-branch exists somewhere (don't care where), then\n move it:\n\n\t# Create the branch (if it doesn't exist)\n\tgit checkout -b bogus-branch >& /dev/null\n\t# Switch to it (which doesn't happen above if it already existed)\n\tgit checkout bogus-branch\n\t# Move the branch to the revision of interest\n\tgit reset --hard \n"},{"id":"16126","messageId":"pan.2006.02.14.18.21.04.760684@canit.se","threadId":"3334","inReplyTo":"43F21CB1.5010203@op5.se","subject":"Re: several quick questions","fromName":"Kenneth Johansson","fromEmail":"ken@canit.se","sentAt":"2006-02-14T18:21:05Z","receivedAt":"2006-02-14T18:21:05Z","isPatch":false,"sender":{"key":"ken@canit.se","avatar":null},"body":"On Tue, 14 Feb 2006 19:08:49 +0100, Andreas Ericsson wrote:\n\n> Kenneth Johansson wrote:\n>> \n>> I'm not sure that many people will understand that they want git-reset for\n>> this just reading the man pages.\n>> \n> \n> Hence the tutorial.\n\nIt could be a little clearer what you would do in any other tool is\ncheckout a specifically tagged version. Perhaps adding a pointer from the\ncheckout man page to the reset command.\n\n \n"},{"id":"16127","messageId":"Pine.LNX.4.64.0602141008220.3691@g5.osdl.org","threadId":"3334","inReplyTo":"pan.2006.02.14.17.47.53.126690@canit.se","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T18:26:32Z","receivedAt":"2006-02-14T18:26:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Kenneth Johansson wrote:\n> \n> What I ended up doing was going nee deep into the plumbing.\n> \n> first doing cat on the tag in .git/refs/tags/ \n> taking the output as an argument to \"git-read-tree\"\n> followed by \"git-update-index --replace\" and \"git-checkout-index -a -f -u\"\n> \n> I'm not sure that many people will understand that they want git-reset for\n> this just reading the man pages.\n\nHey, but I bet you now as a result feel you really understand git, right? \n\n;)\n\nYou did it the old-fashioned way - the way real men did it back in June.\n\nIn general, doing \"ls *.sh\" in the git source tree shows you pretty much \nevery command that you might ever want to use. Using the actual core git \nbinaries directly is normally not all that useful, unless you want to do \nsome strange shell pipeline to do statistics about different things in the \ntree.\n\n\t\tLinus\n"},{"id":"16128","messageId":"Pine.LNX.4.64.0602141026570.3691@g5.osdl.org","threadId":"3334","inReplyTo":"87k6bxvmj6.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T18:34:35Z","receivedAt":"2006-02-14T18:34:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Carl Worth wrote:\n> \n> I don't know if it's the original poster's question or not, but an\n> operation I don't see in the above is \"put the working files into the\n> state of a given revision\".\n\nWhat a strange thing to ask for.\n\nBut you can do it several ways:\n\n - just use \"git reset\" to move around in history, possibly on a temporary \n branch.\n\n - use \"git checkout \" to checkout a particular filename \n of a particular version (it's a special case of \"git checkout\", which \n is useful, but I personally think it's a bit confusing, so I wouldn't \n mention it unless you asked)\n\n - use the core internal git functions, in particular\n\n\tgit-read-tree -m -u \n\n will switch from \"oldtree\" to \"newtree\" and update (-u) the working \n tree.\n\n> 2) Ensure that bogus-branch exists somewhere (don't care where), then\n> move it:\n> \n> \t# Create the branch (if it doesn't exist)\n> \tgit checkout -b bogus-branch >& /dev/null\n> \t# Switch to it (which doesn't happen above if it already existed)\n> \tgit checkout bogus-branch\n> \t# Move the branch to the revision of interest\n> \tgit reset --hard \n\nThis is actually what I'd suggest you always do.\n\nWhy?\n\nIt's actually as efficient as anything else, and there's much less room \nfor confusion. When you want to go back, you can just do a simple\n\n\tgit checkout -f master\n\nand there's no room for confusion. You've not lost sight of any old state, \nand your HEAD never differs from your checked-out copy, so all the normal \ncommands work the way you'd expect them to.\n\n\t\tLinus\n"},{"id":"16129","messageId":"87irrhvkyl.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"87k6bxvmj6.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-14T18:44:50Z","receivedAt":"2006-02-14T18:44:50Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 10:10:53 -0800, Carl Worth wrote:\n> \n> Is there a more fundamental operation to \"put the working files into\n> the state of the index\"? If that exists, then that combined with\n> git-read-tree would give me what I wanted I think.\n\nOh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for\nmentioning it elsewhere in the thread). So now I've at least got the\nrecipe I was after:\n\n\tgit-read-tree \n\tgit-update-index --replace\n\tgit-checkout-index -a -f -u\n\nAnd I think that would make for a dandy command to have in git. Any\nsuggestions for a name?\n\n-Carl\n"},{"id":"16130","messageId":"1139943349.4341.66.camel@evo.keithp.com","threadId":"3334","inReplyTo":"87k6bxvmj6.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-02-14T18:55:49Z","receivedAt":"2006-02-14T18:55:49Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-02-14 at 10:10 -0800, Carl Worth wrote:\n\n> I don't know if it's the original poster's question or not, but an\n> operation I don't see in the above is \"put the working files into the\n> state of a given revision\".\n\nI was using:\n\n\t rm -r *\n\t rm -f .cvsignore .gitignore\n\t git-reset --hard \n\nto get to a specific tag. Of course, I cloned the repository and did\nthis in a separate directory; I wanted to make sure nothing 'bad'\nhappened to my working directory.\n\nCreating a fake branch seemed like a lot more bother. \n-- \nkeith.packard@intel.com\n"},{"id":"16132","messageId":"Pine.LNX.4.64.0602141056170.3691@g5.osdl.org","threadId":"3334","inReplyTo":"87irrhvkyl.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T19:00:44Z","receivedAt":"2006-02-14T19:00:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Carl Worth wrote:\n> \n> Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for\n> mentioning it elsewhere in the thread). So now I've at least got the\n> recipe I was after:\n> \n> \tgit-read-tree \n> \tgit-update-index --replace\n> \tgit-checkout-index -a -f -u\n\nThis is very very inefficient, because it will replace the old \nindex without using the (valid) information that is there from before. \nResulting in a lot of unnecessary IO..\n\nYou may not care for a small project, but for bigger stuff, you're better \noff using more subtle approaches.\n\nExplore using \"git-read-tree --reset \" or, perhaps even more \ninteresting is \"git-read-tree -u -m \"\n\n> And I think that would make for a dandy command to have in git. Any\n> suggestions for a name?\n\nI'd suggest \"git reset\" as a cool way to say that it \"resets\" the tree to \nanother version ;)\n\n\t\tLinus\n"},{"id":"16133","messageId":"Pine.LNX.4.64.0602141101110.3691@g5.osdl.org","threadId":"3334","inReplyTo":"1139943349.4341.66.camel@evo.keithp.com","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T19:04:13Z","receivedAt":"2006-02-14T19:04:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Keith Packard wrote:\n>\n> I was using:\n> \n> \t rm -r *\n> \t rm -f .cvsignore .gitignore\n> \t git-reset --hard \n\nOoh.\n\nTry doing that on a big project, and it will just kill you. You've also \nlost the \"top-of-branch\" info, but if you're just tracking some other \ntree, that's likely not an issue.\n\n(actually, under Linux, with enough memory, and the git stuff all cached, \nit will perform pretty well, but that's just because the OS does a _lot_ \nto try to hide how expensive it is to re-write everything. And even under \nLinux it will suck in the cold-cache case).\n\n> Creating a fake branch seemed like a lot more bother. \n\nYou'll find that if cairo ever grows bigger, it has huge advantages to \nswitch between branches (or any random state, for that matter) without \nhaving to rewrite it all is a _major_ performance impact.\n\n\t\tLinus\n"},{"id":"16134","messageId":"7vy80drbx3.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"87k6bxvmj6.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T19:13:44Z","receivedAt":"2006-02-14T19:13:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> 2) Ensure that bogus-branch exists somewhere (don't care where), then\n> move it:\n>\n> \t# Create the branch (if it doesn't exist)\n> \tgit checkout -b bogus-branch >& /dev/null\n> \t# Switch to it (which doesn't happen above if it already existed)\n> \tgit checkout bogus-branch\n> \t# Move the branch to the revision of interest\n> \tgit reset --hard \n\nFor moving around in history (like cg-seek if I understand\ncorrectly), the above is the right and probably most efficient\nway to do with the core-git tools.\n\n\t# setup\n\t$ git branch -f temp ;# make sure it exists\n $ git checkout temp ;# and switch to it\n\t# repeatedly...\n $ git reset --hard \n # do interesting things\n $ git reset --hard \n # do interesting things\n $ git reset --hard \n # ...\n $ git reset --hard \n # do interesting things\n # once you are done\n $ git checkout master\n $ git branch -D temp\n"},{"id":"16135","messageId":"43F231C5.5010205@op5.se","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141056170.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-14T19:38:45Z","receivedAt":"2006-02-14T19:38:45Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> I'd suggest \"git reset\" as a cool way to say that it \"resets\" the tree to \n> another version ;)\n> \n\nOTOH, it would be nifty (and I imagine not particularly hard) to teach \n\"git checkout\" to check out any revision, and not just a branch.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16136","messageId":"1139945967.4341.71.camel@evo.keithp.com","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141101110.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-02-14T19:39:27Z","receivedAt":"2006-02-14T19:39:27Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-02-14 at 11:04 -0800, Linus Torvalds wrote:\n\n> Try doing that on a big project, and it will just kill you. You've also \n> lost the \"top-of-branch\" info, but if you're just tracking some other \n> tree, that's likely not an issue.\n\nI was validating the cvs import by comparing every tagged version. Trust\nme, the git tree-rewriting stage was somewhat faster than the CVS\ncheckout of the same content. And, as an egg, one often prefers BFI to\nfinesse. I had trouble figuring out precisely what sequence of commands\nwere needed to make git-reset --hard happy with existing bits in the\ndirectory. \n\n-- \nkeith.packard@intel.com\n"},{"id":"16137","messageId":"20060214194650.GD31278@pasky.or.cz","threadId":"3334","inReplyTo":"43F20532.5000609@iaglans.de","subject":"Re: several quick questions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T19:46:50Z","receivedAt":"2006-02-14T19:46:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n now from the simple Cogito's point of view. I will swap the two parts\nof your mail.\n\nDear diary, on Tue, Feb 14, 2006 at 05:28:34PM CET, I got a letter\nwhere Nicolas Vilz 'niv' said that...\n> And another thing, is there no posibility to get back to some commits or\n> tags? I realized you can rebranch tags... what, if i want to switch back\n> to git version 1.1.6 in the git repository? Or a certain commit?\n> \n> do you have to make a new private branch out of the tag 1.1.6?\n> \n> i used svn and there i could go back some revisions. I haven't found\n> such a feature in git, yet... but i think i am blind all the time.\n\n The simple answer is cg-seek, which is meant for temporary ventures to\nthe commit history - e.g. you want to go back to git version 1.1.6, but\nintend to do no development on top of it and to return back to the top\nlater. cg-seek will remember \"where you came from\" and by doing either\ncg-reset or simply calling cg-seek without any parameters, it will\nreturn back to the top.\n\n If you want to permanently change your branch to point to the 1.1.6\ntag, the command to use is cg-switch -f. There is also a simpler but\nless powerful variant of this command available as cg-admin-uncommit.\n\n> i wonder, how i revoke a straight forward merge of two trees... I\n> And another thing, is there no posibility to get back to some commits or\n> tags? I realized you can rebranch tags... what, if i want to switch back\n> to git version 1.1.6 in the git repository? Or a certain commit?\n> \n> do you have to make a new private branch out of the tag 1.1.6?\n> \n> i used svn and there i could go back some revisions. I haven't found\n> such a feature in git, yet... but i think i am blind all the time.\n> \n> I like git very much and every new day I like it more.\n> actually wanted to be look like somewhere in the git-repository, where\n> some branches are merged back with the master tree, but i think, that\n> wasn't \"cg-merge -c \"...\n> \n> my result was that my master tree has now the same sha1-sum as my\n> development-tree and gitk visualisation differs from that what i saw in\n> the git-repository. (Several Arrows headed into back into one line...)\n> \n> maybe that was because i didn't do anything in my master tree in the\n> meantime.\n\n So I assume that it made a fast-forward merge and you want to undo it.\nUnfortunately, there is no facility to automatically remember what your\nprevious last commit was, so you either:\n\n * Remember the \"fast-forwarding\" message cg-merge gave you. ;-)\n * Fire up cg-log and find the commit you want to go back to.\n\n Now, when you have the commit id, this is the time for cg-switch -f -\nwhat you want to do is to \"repoint\" your current branch (let's assume it\nis master) to the commit id you've just found:\n\n\tcg-switch -f -r commit_id master\n\n (The same thing could be done using cg-admin-uncommit, but it is a\nlittle confusing in this particular usage; you would have to rather\nchoose the commit id of the last commit to uncommit, and it does not\ncope well with merges.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16139","messageId":"87fymlvgzv.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141026570.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-14T20:10:28Z","receivedAt":"2006-02-14T20:10:28Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote:\n> On Tue, 14 Feb 2006, Carl Worth wrote:\n> > \n> > I don't know if it's the original poster's question or not, but an\n> > operation I don't see in the above is \"put the working files into the\n> > state of a given revision\".\n> \n> What a strange thing to ask for.\n\nIt's pretty common in other tools. For example, many tools have a way\nto examine the files from a previous state in a \"no current branch\"\nstate. Any attempt to commit from that state would prompt the user to\ncreate a new branch name at that point.\n\nIn fact, this is the natural operation for the basis of something like\ngit-bisect.\n\n> It's actually as efficient as anything else, and there's much less room \n> for confusion. When you want to go back, you can just do a simple\n> \n> \tgit checkout -f master\n\nOK, the efficiency arguments made elsewhere in the thread make it\nclear that these are the operations that need to happen.\n\nBut I'd still like to be able to do this without having to invent a\nfake branch name, without the ability to accidentally commit on the\nfake branch, and without the possibility of accidentally leaving those\ncommits dangling the next time I seek somewhere else.\n\nSo I looked, and git-bisect does use this approach with a fake branch\nof \"bisect\" and by saving the original head ref in $GIT_DIR/head-name\nfor the sake of the final \"git bisect reset\".\n\nAlso, git-bisect does take advantage of the $GIT_DIR/head-name state\nto prevent nested calls to \"git bisect start\", (\"won't bisect on\nseeked tree\").\n\nThat gives a very natural name, \"seek\", for the operation I'd like.\n\nHow about \"git seek\" for doing the operations above, and using some\nreserved branch name, (say \"seek\"). Then, git-bisect could easily be\nbuilt on that, and git-commit could respect the \"seek\" name and refuse\nto commit to it, (could tell the user how to create the branch\nnecessary to commit from the current point).\n\nThere could also be a \"git seek reset\" to return to the HEAD saved by\nthe first in a chain of \"git seek\" operations.\n\nThat looks like I minor generalization of existing behavior in\ngit-bisect, but it would provide an operation that I would find\nuseful.\n\n-Carl\n"},{"id":"16140","messageId":"87ek25vgtq.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141056170.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-14T20:14:09Z","receivedAt":"2006-02-14T20:14:09Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 11:00:44 -0800 (PST), Linus Torvalds wrote:\n> > And I think that would make for a dandy command to have in git. Any\n> > suggestions for a name?\n> \n> I'd suggest \"git reset\" as a cool way to say that it \"resets\" the tree to \n> another version ;)\n\nHeh. It also moves a branch name though, and that's the part I don't\nwant. See my suggestion elsewhere of \"git seek\". [*]\n\n-Carl\n\n[*] Yes, I appear doomed to be reinventing cogito piecemeal. I got\n\"seek\" from the error message in git-bisect, before I heard about\ncg-seek, (as Junio pointed out elsewhere in the thread).\n"},{"id":"16141","messageId":"20060214202728.GE31278@pasky.or.cz","threadId":"3334","inReplyTo":"87fymlvgzv.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T20:27:28Z","receivedAt":"2006-02-14T20:27:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 09:10:28PM CET, I got a letter\nwhere Carl Worth said that...\n> That gives a very natural name, \"seek\", for the operation I'd like.\n> \n> How about \"git seek\" for doing the operations above, and using some\n> reserved branch name, (say \"seek\"). Then, git-bisect could easily be\n> built on that, and git-commit could respect the \"seek\" name and refuse\n> to commit to it, (could tell the user how to create the branch\n> necessary to commit from the current point).\n> \n> There could also be a \"git seek reset\" to return to the HEAD saved by\n> the first in a chain of \"git seek\" operations.\n> \n> That looks like I minor generalization of existing behavior in\n> git-bisect, but it would provide an operation that I would find\n> useful.\n\nWell, this is exactly what cg-seek does (and it's one of pretty old\nCogito commands) - it even has the same name. ;-) See my other mail in\nthis thread.\n\nIt works by creating a new branch cg-seek-point and storing the seeked\npoint there; if HEAD is already on the branch, it merely changes the\nseek point and resets the working tree appropriately. cg-seek without\nany arguments will then return to your original head, whose name was\nstored in .git/head-name.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16142","messageId":"Pine.LNX.4.63.0602142133360.23093@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3334","inReplyTo":"43F231C5.5010205@op5.se","subject":"Re: several quick questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-14T20:34:41Z","receivedAt":"2006-02-14T20:34:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Feb 2006, Andreas Ericsson wrote:\n\n> [...] it would be nifty (and I imagine not particularly hard) to teach \n> \"git checkout\" to check out any revision, and not just a branch.\n\nYou have to have a valid HEAD. So, you can create a throw-away branch \neasily:\n\n\tgit-checkout -f throw HEAD~56\n\nHth,\nDscho\n"},{"id":"16143","messageId":"Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3334","inReplyTo":"20060214202728.GE31278@pasky.or.cz","subject":"Re: several quick questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-14T20:37:39Z","receivedAt":"2006-02-14T20:37:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Feb 2006, Petr Baudis wrote:\n\n> [...]\n>\n> It works by creating a new branch cg-seek-point and storing the seeked\n> point there; if HEAD is already on the branch, it merely changes the\n> seek point and resets the working tree appropriately. cg-seek without\n> any arguments will then return to your original head, whose name was\n> stored in .git/head-name.\n\nAnd if you want to prevent accidental commit, just \"chmod a-w \n$GIT_DIR/index\".\n\nCiao,\nDscho\n"},{"id":"16144","messageId":"Pine.LNX.4.64.0602141224110.3691@g5.osdl.org","threadId":"3334","inReplyTo":"87fymlvgzv.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T20:40:24Z","receivedAt":"2006-02-14T20:40:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Feb 2006, Carl Worth wrote:\n> > \n> > What a strange thing to ask for.\n> \n> It's pretty common in other tools.\n\nWell, it's pretty common in git too. But in git, the notion of \"branch\" \nreally has been made so cheap that it's basically a no-op.\n\nThe \"overhead\" of creating a branch is literally the cost of writing one \n(small) file.\n\n> In fact, this is the natural operation for the basis of something like\n> git-bisect.\n\nRight. And \"git bisect\" very much does exactly that. It creates a \ntemporary branch for bisection (the branch is called \"bisect\", one of the \nless confusing naming decisions in git ;)\n\nThat's really my point. It all boils down to the same three operations: \n\"git branch\", \"git checkout\" and \"git reset\".\n\nIn fact, if you look into git-bisect, you'll notice that it doesn't even \nuse \"git reset\" internally. It _literally_ creates a new branch (which it \ndoes by hand for some strange reason, but never mind) called \"new-bisect\", \nand then does \"git checkout new-bisect\" followed by renaming the branch \nback to \"bisect\" (which it again does by hand).\n\nSo \"git bisect\" may actually get its hands dirty by knowing a bit too much \nabout the internal workings of git branches, but conceptually, it really \ndoes just\n\n\tgit checkout -b new-bisect \n\nto switch its state around.\n\n> But I'd still like to be able to do this without having to invent a\n> fake branch name, without the ability to accidentally commit on the\n> fake branch, and without the possibility of accidentally leaving those\n> commits dangling the next time I seek somewhere else.\n\nPasky did this before the \"multi-branch\" thing was common, and calls it \n\"cg-seek\". \n\nI think that does exactly what you ask for, I just don't really see the \npoint. The downside of cg-seek is that you're really really limited to \nwhat you can do with it.\n\nFor example, it may be \"overhead\" to have a dummy branch for bisection, \nbut it means (for example) that you can actually do real work on the point \nthat \"git bisect\" points you to.\n\nFor example, if you hit a compile error, you can _literally_ fix that \ncompile error AND COMMIT that state, and when you then mark that commit \n\"good\" or \"bad\" when you continue to bisect, bisection will actually do \nthe right thing. Something that would be impossible in a \"seek\" \nenvironment, where you don't have a branch that you can do development on.\n\nI realize that when you come from an environment where branches are big \nthings, this is kind of strange. But in git, a branch is literally a \nsingle file that is 41 bytes in size. That's it. No more, no less.\n\n\t\tLinus\n"},{"id":"16145","messageId":"7vmzgtr7u2.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T20:41:57Z","receivedAt":"2006-02-14T20:41:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Tue, 14 Feb 2006, Petr Baudis wrote:\n>\n>> [...]\n>>\n>> It works by creating a new branch cg-seek-point and storing the seeked\n>> point there; if HEAD is already on the branch, it merely changes the\n>> seek point and resets the working tree appropriately. cg-seek without\n>> any arguments will then return to your original head, whose name was\n>> stored in .git/head-name.\n>\n> And if you want to prevent accidental commit, just \"chmod a-w \n> $GIT_DIR/index\".\n\nThat is a wrong answer. It is perfectly sane to modify index\nwithout an intention to commit that change (you can always say\n\"git reset\").\n"},{"id":"16147","messageId":"Pine.LNX.4.63.0602142150140.23719@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3334","inReplyTo":"7vmzgtr7u2.fsf@assigned-by-dhcp.cox.net","subject":"Re: several quick questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-14T20:54:05Z","receivedAt":"2006-02-14T20:54:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Feb 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Hi,\n> >\n> > On Tue, 14 Feb 2006, Petr Baudis wrote:\n> >\n> >> [...]\n> >>\n> >> It works by creating a new branch cg-seek-point and storing the seeked\n> >> point there; if HEAD is already on the branch, it merely changes the\n> >> seek point and resets the working tree appropriately. cg-seek without\n> >> any arguments will then return to your original head, whose name was\n> >> stored in .git/head-name.\n> >\n> > And if you want to prevent accidental commit, just \"chmod a-w \n> > $GIT_DIR/index\".\n> \n> That is a wrong answer. It is perfectly sane to modify index\n> without an intention to commit that change (you can always say\n> \"git reset\").\n\nOkay, I was not being completely truthful. If I did not get the original \nidea of git-seek wrong, then it was kind of an excursion, just taking a \npeek. And if you want to return from that excursion, I thought maybe it \nwould make sense to disallow index operations *at all* until returning to \nthe HEAD.\n\nBut I agree it is nasty. And Linus mentioned that the benefits of being \nable to commit into a temporary branch outweigh the shortcoming easily. \n(The shortcoming being that you have to keep in mind that you are in \nanother branch. Which does not come easily to a fresh CVS convert.)\n\nCiao,\nDscho\n"},{"id":"16148","messageId":"20060214205527.GF31278@pasky.or.cz","threadId":"3334","inReplyTo":"Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: several quick questions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T20:55:27Z","receivedAt":"2006-02-14T20:55:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Tue, Feb 14, 2006 at 09:37:39PM CET, I got a letter\nwhere Johannes Schindelin said that...\n> On Tue, 14 Feb 2006, Petr Baudis wrote:\n> \n> > [...]\n> >\n> > It works by creating a new branch cg-seek-point and storing the seeked\n> > point there; if HEAD is already on the branch, it merely changes the\n> > seek point and resets the working tree appropriately. cg-seek without\n> > any arguments will then return to your original head, whose name was\n> > stored in .git/head-name.\n> \n> And if you want to prevent accidental commit, just \"chmod a-w \n> $GIT_DIR/index\".\n\n currently, Cogito has a generic \"blocking\" mechanism which will\nprevent you to do operations mutating the history (mostly committing and\nmergnign) - seeking is the only user now.\n\n Note that this is not very flexible and I consider this legacy stuff;\nI will replace that by a specific check for a seek when I have some time\n(which will also make it compatible with the git-bisect-using-headname).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16150","messageId":"20060214211935.GG31278@pasky.or.cz","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141224110.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T21:19:35Z","receivedAt":"2006-02-14T21:19:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 09:40:24PM CET, I got a letter\nwhere Linus Torvalds said that...\n> On Tue, 14 Feb 2006, Carl Worth wrote:\n> > But I'd still like to be able to do this without having to invent a\n> > fake branch name, without the ability to accidentally commit on the\n> > fake branch, and without the possibility of accidentally leaving those\n> > commits dangling the next time I seek somewhere else.\n> \n> Pasky did this before the \"multi-branch\" thing was common, and calls it \n> \"cg-seek\". \n> \n> I think that does exactly what you ask for, I just don't really see the \n> point. The downside of cg-seek is that you're really really limited to \n> what you can do with it.\n> \n> For example, it may be \"overhead\" to have a dummy branch for bisection, \n> but it means (for example) that you can actually do real work on the point \n> that \"git bisect\" points you to.\n> \n> For example, if you hit a compile error, you can _literally_ fix that \n> compile error AND COMMIT that state, and when you then mark that commit \n> \"good\" or \"bad\" when you continue to bisect, bisection will actually do \n> the right thing. Something that would be impossible in a \"seek\" \n> environment, where you don't have a branch that you can do development on.\n\nThat's a neat idea - I like this. I just tweaked cg-commit -f so that it\nwill now override the cg-seek block, with a warning that you should be\ncontent about your commit being thrown away.\n\nReally, except this blocking restriction (which is really a check for a\nnon-empty .git/blocked file), cg-seek does exactly the fake branch\nthing, as you actually persuaded me to do. So you are on a dedicated\nseeking branch and theoretically you can do development on it - it's\nonly too easy to lose the commits.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16153","messageId":"200602142230.11442.Josef.Weidendorfer@gmx.de","threadId":"3334","inReplyTo":"87fymlvgzv.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-02-14T21:30:11Z","receivedAt":"2006-02-14T21:30:11Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 14 February 2006 21:10, you wrote:\n> How about \"git seek\" for doing the operations above, and using some\n> reserved branch name, (say \"seek\"). Then, git-bisect could easily be\n> built on that, and git-commit could respect the \"seek\" name and refuse\n> to commit to it, (could tell the user how to create the branch\n> necessary to commit from the current point).\n\nWhy not allow something like\n\n\tgit-checkout master~5\n\nwhich implicitly does create a read-only branch \"seek-point\"?\nI do not think that it is important to remember the branch name you seek\nfrom.\n\nA branch could be marked readonly by above command with\n\n\tchmod a-w .git/refs/heads/seek\n\nAnd git-commit should refuse to commit on a readonly ref, telling\nthe user to create a writable branch before with \"git-branch new\".\n\nThis would also help \"cg-seek\" to prohibit the user to commit on\n\"cg-seek-point\" via \"git-commit\" (by setting cg-seek-point read-only).\n\nBTW, \"origin\" (and any local branch that tracks a remote one) should\nbe set to readonly this way to signal that these are not developer\nbranches.\n\nJosef\n"},{"id":"16154","messageId":"43F24C12.3090108@iaglans.de","threadId":"3334","inReplyTo":"43F20D4B.3060606@op5.se","subject":"Re: several quick questions","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-02-14T21:30:58Z","receivedAt":"2006-02-14T21:30:58Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n> \n> git will recognize the merge-base as being the current HEAD and simply\n> sets HEAD to point to that of topic-branch. This is why it's called a\n> fast-forward, since no heavy computing needs to be done to combine the\n> two development tracks.\n\nwell finaly, if nothing happened in one of the lines, then the two lines\nbecome the same, when merging back into one line. and the two lines\noverlay each other. That is what i saw during playing with git-merge,\ngit-pull and git-reset.. ok.\n\n> \n>> do you have to make a new private branch out of the tag 1.1.6?\n>>\n> \n> No, you don't, but you can if you wish. It's nifty if you want to fork\n> the development from a particular branch. In your case, if you really,\n> really *want* the arrows pointing to one line, you can do\n> \n> $ git branch topic-branch HEAD^\n> # work, work, work\n> $ git checkout master\n> $ git pull . topic-branch\n> \n> That would create one pretty arrow. When multiple tracks of development\n> (rather than just two) are combined into one it's called an octopus\n> merge. Unless you really know what you're doing, you should try to avoid\n> those for small projects, and doing it just for the pretty arrows is....\n> well, let's call it \"interesting from the behaviour science scholars\n> point of view\".\n\nits just the thought \"cool, it looks like there at the git repo\"... just\nto realize \"ok, that happens, when i merge two trees.\n\n>> i used svn and there i could go back some revisions. I haven't found\n>> such a feature in git, yet... but i think i am blind all the time.\n>>\n> \n> Most likely. I believe at least the reset command is mentioned in the\n> tutorial. I trust you've read it before asking, so something is amiss\n> either with your eyesight or the tutorial.\n\nwell the namespace of the references confused me, before i realized,\nthat HEAD finally points to an sha1sum (which symbolizes a certain commit)\n\nmh.. I use pull if i want to get an external development tree, right? I\nstill search for a possibility to replace the svn:externals, which were\nquite handy some times.\n\nlets imagine, i want to reuse work i did in another repository, then I\ncan easily pull from that repository, which my work i want to reuse is\nstored at... i see... i just will have to pull frequently.... and hope\nthere is no conflict between some files.\n\n\nonce more... thank you all and good work.\n\nNicolas\n"},{"id":"16155","messageId":"7v7j7xr54u.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"200602142230.11442.Josef.Weidendorfer@gmx.de","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T21:40:17Z","receivedAt":"2006-02-14T21:40:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> Why not allow something like\n>\n> \tgit-checkout master~5\n>\n> which implicitly does create a read-only branch \"seek-point\"?\n\nNow what does \"git-checkout branch\" mean? Does it switch to the\nbranch, or does it force tip of seek-point to be the tip of\nbranch and switch to seek-point branch? More interestingly,\nwhat does \"git-checkout seek-point\" mean? \n\nIf we _were_ to do something like cg-seek where an implicit\nthrow-away branch is used, you at least need a way to\ndisambiguate these cases, and \"git seek\" originally suggested is\nfar clearer than what you said above.\n\nHaving said that, I am not convinced in either way, though.\n\n> A branch could be marked readonly by above command with\n>\n> \tchmod a-w .git/refs/heads/seek\n\nI do not think that would work. Have you tried it?\n\n> And git-commit should refuse to commit on a readonly ref, telling\n> the user to create a writable branch before with \"git-branch new\".\n\nNow, read-only ref does not interest me, but \"do not commit on\ntop of this yourself, only fast-forward from somewhere else is\nallowed\" may be useful, for the reason why you mentioned\n\"origin\".\n"},{"id":"16156","messageId":"20060214214123.GI31278@pasky.or.cz","threadId":"3334","inReplyTo":"200602142230.11442.Josef.Weidendorfer@gmx.de","subject":"Re: several quick questions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T21:41:24Z","receivedAt":"2006-02-14T21:41:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 10:30:11PM CET, I got a letter\nwhere Josef Weidendorfer said that...\n> Why not allow something like\n> \n> \tgit-checkout master~5\n> \n> which implicitly does create a read-only branch \"seek-point\"?\n> I do not think that it is important to remember the branch name you seek\n> from.\n> \n> A branch could be marked readonly by above command with\n> \n> \tchmod a-w .git/refs/heads/seek\n> \n> And git-commit should refuse to commit on a readonly ref, telling\n> the user to create a writable branch before with \"git-branch new\".\n\nWe just abolished symlinks. Can we afford doing this, from the\nportability standpoint?\n\n> This would also help \"cg-seek\" to prohibit the user to commit on\n> \"cg-seek-point\" via \"git-commit\" (by setting cg-seek-point read-only).\n\nFor now, this is accomplished (in Cogito, but we just introduced this to\ngit-bisect as well) by creating .git/head-name. This has the advantage\nthat you know to which branch to return after the seeking is over, and\nit also marks the current head \"read-only\" (in the commit sense) for\nCogito (and git-bisect start).\n\nIt is obviously less flexible since it lets you mark only the current\nhead read-only, but noone asked for more before. ;)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16157","messageId":"87d5hpvc8p.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"Pine.LNX.4.64.0602141224110.3691@g5.osdl.org","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-14T21:53:10Z","receivedAt":"2006-02-14T21:53:10Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 12:40:24 -0800 (PST), Linus Torvalds wrote:\n>\n> That's really my point. It all boils down to the same three operations: \n> \"git branch\", \"git checkout\" and \"git reset\".\n\nYes. I understand that much.\n\n> I think that does exactly what you ask for, I just don't really see the \n> point. The downside of cg-seek is that you're really really limited to \n> what you can do with it.\n\nWell, I think it would be useful to generalize and export what\ngit-bisect currently does even if there are no limitations added to\nit. If nothing else, it's a tiny bit of sugar to allow exploring the\ntree without having to invent a branch name first.\n\nSo I'd be happy with \"git seek\" even if git-commit didn't refuse to\ncommit on the seek branch, (but I still think that limitation makes\nsense---see below).\n\n> For example, if you hit a compile error, you can _literally_ fix that \n> compile error AND COMMIT that state, and when you then mark that commit \n> \"good\" or \"bad\" when you continue to bisect, bisection will actually do \n> the right thing. Something that would be impossible in a \"seek\" \n> environment, where you don't have a branch that you can do\n> development on.\n\nThe only difference in the \"seek\" case would be that you would be\nrequired to create a branch before committing, right?\n\nAnd this would have the benefit of not leaving the commit object\ndangling after continuing the bisect, wouldn't it?\n\nYou've pointed out that branches are free in terms of what git has to\ndo. I'm saying that they're not free for the user who bears the cost\nof inventing a name. And in the case of any commit-while-seeking, it's\nat the time of the commit itself that the user has enough information\nto invent a useful name, not prior to seeking, (when the user is still\ntrying to figure things out).\n\n-Carl\n"},{"id":"16159","messageId":"200602142317.29626.Josef.Weidendorfer@gmx.de","threadId":"3334","inReplyTo":"7v7j7xr54u.fsf@assigned-by-dhcp.cox.net","subject":"Re: several quick questions","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-02-14T22:17:29Z","receivedAt":"2006-02-14T22:17:29Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 14 February 2006 22:40, you wrote:\n> Josef Weidendorfer writes:\n> \n> > Why not allow something like\n> >\n> > \tgit-checkout master~5\n> >\n> > which implicitly does create a read-only branch \"seek-point\"?\n> \n> Now what does \"git-checkout branch\" mean? Does it switch to the\n> branch, or does it force tip of seek-point to be the tip of\n> branch and switch to seek-point branch? More interestingly,\n> what does \"git-checkout seek-point\" mean? \n\nYou are right; it would get quite confusing.\nBut perhaps the current error message\n\n git checkout: you need to specify a new branch name\n\nshould be a little bit more explaining by appending\n\n \"... to switch to for being able to checkout the requested revision\"\n\n> Having said that, I am not convinced in either way, though.\n\nMe too. Specifying a branch name is easy enough.\n\n> > And git-commit should refuse to commit on a readonly ref, telling\n> > the user to create a writable branch before with \"git-branch new\".\n> \n> Now, read-only ref does not interest me, but \"do not commit on\n> top of this yourself, only fast-forward from somewhere else is\n> allowed\" may be useful, for the reason why you mentioned\n> \"origin\".\n\nYes. The idea to make the ref readonly to specify this intent was\na quick (not so good) idea.\n\nStill, being able to specify that you can not commit on some branch\n(as you said) is very useful to prohibit doing things by accident.\n.git/config does not sound very good for such a thing, especially\nif there could be other branch-specific properties in the future.\n\nJosef\n"},{"id":"16160","messageId":"7v3bilr2zr.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"200602142317.29626.Josef.Weidendorfer@gmx.de","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T22:26:32Z","receivedAt":"2006-02-14T22:26:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> On Tuesday 14 February 2006 22:40, you wrote:\n>> Josef Weidendorfer writes:\n>> \n>> > Why not allow something like\n>> >\n>> > \tgit-checkout master~5\n>> >\n>> > which implicitly does create a read-only branch \"seek-point\"?\n>> \n>> Now what does \"git-checkout branch\" mean? Does it switch to the\n>> branch, or does it force tip of seek-point to be the tip of\n>> branch and switch to seek-point branch? More interestingly,\n>> what does \"git-checkout seek-point\" mean? \n>\n> You are right; it would get quite confusing.\n> But perhaps the current error message\n>\n> git checkout: you need to specify a new branch name\n>\n> should be a little bit more explaining by appending\n>\n> \"... to switch to for being able to checkout the requested revision\"\n\nWhile we are on the subject of improving the error message to\nbetter guide users in a likely-to-be-what-he-meant direction,\nthere is another confusing message (I am assuming you are\ninterested in this enough to come up with a patch to fix that\n\"... to switch to ...\" thing):\n\n\t$ git checkout -b test v2.6.10\n\nThe user wanted to create a new branch test based on tag\nv2.6.10, alas that tag does not exist. We give quite confusing\nerror message because we are confused that the user meant to\ncheckout only \"./v2.6.10\" file and that operation and switching\nbranches are incompatible.\n"},{"id":"16164","messageId":"7vu0b1pntl.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"87d5hpvc8p.wl%cworth@cworth.org","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T22:39:34Z","receivedAt":"2006-02-14T22:39:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> You've pointed out that branches are free in terms of what git has to\n> do. I'm saying that they're not free for the user who bears the cost\n> of inventing a name. And in the case of any commit-while-seeking, it's\n> at the time of the commit itself that the user has enough information\n> to invent a useful name, not prior to seeking, (when the user is still\n> trying to figure things out).\n\nI think this is a very valid point and I am happy to accept a\nworkable proposal (does not have to be a working patch, but a\ngeneral semantics that covers most of if not all the corner\ncases).\n"},{"id":"16165","messageId":"43F26129.4040804@op5.se","threadId":"3334","inReplyTo":"7v7j7xr54u.fsf@assigned-by-dhcp.cox.net","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-14T23:00:57Z","receivedAt":"2006-02-14T23:00:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Josef Weidendorfer writes:\n> \n> \n>>Why not allow something like\n>>\n>>\tgit-checkout master~5\n>>\n>>which implicitly does create a read-only branch \"seek-point\"?\n> \n> \n> Now what does \"git-checkout branch\" mean? Does it switch to the\n> branch, or does it force tip of seek-point to be the tip of\n> branch and switch to seek-point branch? More interestingly,\n> what does \"git-checkout seek-point\" mean? \n> \n> If we _were_ to do something like cg-seek where an implicit\n> throw-away branch is used, you at least need a way to\n> disambiguate these cases, and \"git seek\" originally suggested is\n> far clearer than what you said above.\n> \n\nNah. What's the point of having another protected name. Just allow\n\n\t$ git checkout -b discard HEAD~15\n\nand we're good to go.\n\n> Having said that, I am not convinced in either way, though.\n> \n> \n>>A branch could be marked readonly by above command with\n>>\n>>\tchmod a-w .git/refs/heads/seek\n> \n> \n> I do not think that would work. Have you tried it?\n> \n\nIt wouldn't on cygwin, for one. I'm against having things work \ndifferently on different platforms. If nothing else it usually worsens \nthe bitrot that always happens to documentation.\n\n> \n>>And git-commit should refuse to commit on a readonly ref, telling\n>>the user to create a writable branch before with \"git-branch new\".\n> \n> \n> Now, read-only ref does not interest me, but \"do not commit on\n> top of this yourself, only fast-forward from somewhere else is\n> allowed\" may be useful, for the reason why you mentioned\n> \"origin\".\n> \n\nDo my suggestion and you wouldn't have to worry about read-only \nbranches, and although merging any changes from it might be more trouble \nthan its worth, it might be possible to cherry-pick the commit rather \nthan reverting and re-applying it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16168","messageId":"Pine.LNX.4.63.0602150022470.24570@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3334","inReplyTo":"43F26129.4040804@op5.se","subject":"Re: several quick questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-14T23:23:45Z","receivedAt":"2006-02-14T23:23:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 15 Feb 2006, Andreas Ericsson wrote:\n\n> What's the point of having another protected name. Just allow\n> \n> \t$ git checkout -b discard HEAD~15\n> \n> and we're good to go.\n\nLast time I checked (2 hours ago) it did exactly what you want it to.\n\nHth,\nDscho\n"},{"id":"16169","messageId":"43F270F5.7070804@op5.se","threadId":"3334","inReplyTo":"Pine.LNX.4.63.0602150022470.24570@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-15T00:08:21Z","receivedAt":"2006-02-15T00:08:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 15 Feb 2006, Andreas Ericsson wrote:\n> \n> \n>>What's the point of having another protected name. Just allow\n>>\n>>\t$ git checkout -b discard HEAD~15\n>>\n>>and we're good to go.\n> \n> \n> Last time I checked (2 hours ago) it did exactly what you want it to.\n> \n\nHeh. You're right. :) Didn't grok that from the man-page. I'm so used to \nseeing everywhere that when it says \" can be any \nobject that refers to a commit\" I get confused.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16171","messageId":"7vpslppii0.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"43F270F5.7070804@op5.se","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-15T00:34:31Z","receivedAt":"2006-02-15T00:34:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Heh. You're right. :) Didn't grok that from the man-page. I'm so used\n> to seeing everywhere that when it says \" can be\n> any object that refers to a commit\" I get confused.\n\nYou are right; the documentation is wrong. It says\n\n'git-checkout' [-f] [-b ] [-m] [] [...]\n\nIt should have said something like:\n\ngit-checkout [ -f | -m ] \t\tor\ngit-checkout [-b ] \tor\ngit-checkout [ | -- ] ...\n\nThe first form is to switch to a branch (with flag to say what\nto do when conflict can lose local modification); the second\nform is to create a new branch out of comittish and switch to\nit; and the third is not switching branches but just checking\nout named paths out of index or arbitrary comittish (I think any\nent should do but I have not verified it).\n"},{"id":"16174","messageId":"20060215011210.GG30316@pasky.or.cz","threadId":"3334","inReplyTo":"1139963183.4341.117.camel@evo.keithp.com","subject":"Cogito turbo-introduction","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2006-02-15T01:12:11Z","receivedAt":"2006-02-15T01:12:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"I suppose this might be interesting for others (and Google) as well, so\nI'm bringing it back to the mailing list...\n\nDear diary, on Wed, Feb 15, 2006 at 01:26:23AM CET, I got a letter\nwhere Keith Packard said that...\n> I will see about learning enough cogito to point appropriate people at\n> it in place of full-on git exposure.\n\nActually, everything should be really trivial, since Cogito is very\nsimilar to CVS or SVN in practice. A turbo introduction to Cogito, which\nactually proved to be enough to get started fast with the regular work,\nwas:\n\n\t* cg-clone URL to get the stuff\n\t* cg-commit just like in CVS (but cooler)\n\t* cg-update just like in CVS (or rather SVN)\n\t* cg-status to get the status letters produced by cvs update\n\t (just like in SVN)\n\t* cg-diff, cg-log, cg-add, cg-rm just like in CVS (but cooler)\n\n\t* After committing for a while, you need to run cg-push\n\t* Merge commits are perfectly ok, don't mind them; no really,\n\t you will get used; in reality, they are cool\n\t* If you hit conflicts during merge, the software will tell you\n\t how to proceed\n\t* If you need something different / more advanced, look it up\n\t in cg-help list (there is actually significantly less Cogito\n\t commands to go through than in CVS, yet in most areas Cogito\n\t is much more powerful)\n\t* If you are confused about the distributed concept or want to\n\t learn about branching, try Cogito README\n\nI've been trying to design Cogito's UI pretty carefully to really\nabsolutely minimize the learning curve from CVS/SVN, while also making\nit consistent on its own so that people who learn it as their first VCS\nwill get actually something nice. Well, the users shall judge. ;-)\n(At this stage I would probably design few bits of the UI slightly\ndifferently than how they have evolved, but the gripes are pretty\nminor.)\n\nIn this sense, the good UI goal has indeed higher priority than the\npowerfulness goal, but most of the time we hopefully manage to make it\ngo together well. The significant areas where Cogito is fundamentally\nless powerful than GIT itself are:\n\n\t* No git-whatchanged -p - this is huge deficiency, and I'm\n\t entirely at fault here\n\t* Consequently, no pickaxe and renames detection - same\n\t* Recursive merge strategy - not much of a UI problem, it just\n\t needs the time and work to get integrated\n\t* Remote branches handling - Cogito's handling is strictly 1:1\n\t while GIT's remotes are much more powerful and allow you to\n\t fetch/push many branches at once (and in fact do so by\n\t default); I did not invent a good UI for something similarly\n\t powerful yet, and it is no high priority for me so far;\n\t I think you actually want 1:1 in by far the most common usage\n\t pattern\n\t* No email interface - but you can trivially just fall back to\n\t GIT in this area\n\nNote that Cogito's goal is not to reproduce and wrap all GIT commands -\ne.g. I have currently no plans to wrap up git-bisect.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16176","messageId":"20060215013236.GN31278@pasky.or.cz","threadId":"3334","inReplyTo":"20060215011210.GG30316@pasky.or.cz","subject":"Re: Cogito turbo-introduction","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-15T01:32:36Z","receivedAt":"2006-02-15T01:32:36Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Feb 15, 2006 at 02:12:11AM CET, I got a letter\nwhere Petr Baudis said that...\n> In this sense, the good UI goal has indeed higher priority than the\n> powerfulness goal, but most of the time we hopefully manage to make it\n> go together well. The significant areas where Cogito is fundamentally\n> less powerful than GIT itself are:\n> \n> \t* No git-whatchanged -p - this is huge deficiency, and I'm\n> \t entirely at fault here\n> \t* Consequently, no pickaxe and renames detection - same\n> \t* Recursive merge strategy - not much of a UI problem, it just\n> \t needs the time and work to get integrated\n> \t* Remote branches handling - Cogito's handling is strictly 1:1\n> \t while GIT's remotes are much more powerful and allow you to\n> \t fetch/push many branches at once (and in fact do so by\n> \t default); I did not invent a good UI for something similarly\n> \t powerful yet, and it is no high priority for me so far;\n> \t I think you actually want 1:1 in by far the most common usage\n> \t pattern\n\n(And you can pretty easily script/alias multi-branch fetches, it just\nwon't be as super-efficient as if you would fetch/push at once.)\n\n\nThe above is though not to say that Cogito is strict subset of GIT!\nCogito has many cool things GIT doesn't have. ;-) To pick some random\nexamples:\n\n\t* cg-clean\n\t* cg-commit - packed with convenience stuff, from multiple -m's\n\t to --review\n\t* cg-init's initial commit\n\t* resumable cg-clone\n\t* cg-fetch's cute progressbars ;-)\n\t* things which are rather thin wrappers automating sequence of\n\t few commands, nevertheless providing much convenience\n\t (cg-admin-setuprepo, cg-admin-uncommit, cg-seek, cg-export...)\n\n(Perhaps some of this GIT can already do, I don't watch the core\nporcelain that closely.)\n\n> Note that Cogito's goal is not to reproduce and wrap all GIT commands -\n> e.g. I have currently no plans to wrap up git-bisect.\n\nTo explain, that's not because I consider git-bisect to be bad, but the\nvery opposite - because it is so cool and I couldn't really add much\nvalue by adding it to Cogito. When Cogito will have good tutorial\ndocumentation (I think it already has _very_ good reference\ndocumentation - please prove me wrong so that we can improve it\nfurther), I will just happily reference people to those GIT core\ncommands.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16184","messageId":"46a038f90602142011o36b975b7s1833953db3b6d376@mail.gmail.com","threadId":"3334","inReplyTo":"1139945967.4341.71.camel@evo.keithp.com","subject":"Re: several quick questions","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-02-15T04:11:08Z","receivedAt":"2006-02-15T04:11:08Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/15/06, Keith Packard wrote:\n> I was validating the cvs import by comparing every tagged version. Trust\n> me, the git tree-rewriting stage was somewhat faster than the CVS\n> checkout of the same content. And, as an egg, one often prefers BFI to\n> finesse.\n\nKeith,\n\nDid that lead to finding any problems with the import? Can I get my\nhands on that script you've written to run the comparison?\n\ncheers,\n\n\nmartin\n"},{"id":"16187","messageId":"1139981145.4341.137.camel@evo.keithp.com","threadId":"3334","inReplyTo":"46a038f90602142011o36b975b7s1833953db3b6d376@mail.gmail.com","subject":"Re: several quick questions","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-02-15T05:25:45Z","receivedAt":"2006-02-15T05:25:45Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Wed, 2006-02-15 at 17:11 +1300, Martin Langhoff wrote:\n\n> Did that lead to finding any problems with the import? Can I get my\n> hands on that script you've written to run the comparison?\n\nThe only issues we had were with manual changes to the repository; other\nthan that, we now has a usable git repository for cairo (visible at\ngit://git.cairographics.org/cairo). The comparison tool that I wrote was\na cheesy shell script; I think Carl has updated it to do something less\nsevere than rm -rf *; git-reset --hard; if he can share that, I think\nyou'll like it a lot better than mine.\n\nOur CVS import script has some magic ChangeLog-style mangling which\nwe've posted to the list before; that clearly needs to be encapsulated\nin an optional log-reformatting bit for it to be generally useful. \n \n-- \nkeith.packard@intel.com\n"},{"id":"16189","messageId":"7vwtfxm917.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"43F26129.4040804@op5.se","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-15T06:27:16Z","receivedAt":"2006-02-15T06:27:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Junio C Hamano wrote:\n>\n>> Now, read-only ref does not interest me, but \"do not commit on\n>> top of this yourself, only fast-forward from somewhere else is\n>> allowed\" may be useful, for the reason why you mentioned\n>> \"origin\".\n>\n> Do my suggestion and you wouldn't have to worry about read-only\n> branches, and although merging any changes from it might be more\n> trouble than its worth, it might be possible to cherry-pick the commit\n> rather than reverting and re-applying it.\n\nSorry, is this \"do my suggestion\" a solution to my \"do not\ncommit on top of this yourself, only fast-forward from somewhere\nelse is allowed -- e.g. to protect 'origin'\" issue, or is it\nsomething completely different?\n"},{"id":"16197","messageId":"87wtfxhw25.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"1139981145.4341.137.camel@evo.keithp.com","subject":"Re: several quick questions","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-15T08:21:06Z","receivedAt":"2006-02-15T08:21:06Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Feb 2006 21:25:45 -0800, Keith Packard wrote:\n> On Wed, 2006-02-15 at 17:11 +1300, Martin Langhoff wrote:\n> \n> > Did that lead to finding any problems with the import? Can I get my\n> > hands on that script you've written to run the comparison?\n> \n> The only issues we had were with manual changes to the repository;\n\nFor anyone interested, here are the problems our script found after\nimporting cairo with git-cvsimport:\n\n1) Some \"future\" files existed at old tags since we had copied ,v\n files to preserve per-file history. This one was no surprise.\n\n2) We had a couple tags in CVS that didn't tag the current head,\n (instead a file had been manually reverted before the tag). In the\n git checkout of the same tag name, we got the results as if HEAD\n had been tagged.\n\nThose two weren't too surprising. We remembered quite clearly what had\nhappened as soon as we saw the results. I've fixed these up\npost-import by making git commits to fix the problems and then moving\nthe tags.\n\n3) There are some sub-tree tags in cairo's CVS tree as\n well. Obviously, those aren't very interesting for direct\n comparison.\n\nAlso not surprising. For these, I just modified the script to\nwhitelist the tags I actually cared about checking.\n\n4) There was a branch that diverged from the main line two commits\n \"late\" in the git history.\n\nI'm not sure what caused this, but it's obviously happening in the\ncvsps output. I fixed the problem by capturing the cvsps output into a\nfile, reordering the branching patchset up two positions in the list,\nthen feeding the result into git-cvsimport with its -P option.\n\nI've attached the script I used to do the git and cvs comparisons. I\nwas getting perfect results with a local rsync of cairo's CVS\nrepository. The version here does a pserver checkout instead. When I\nrun this I'm apparently getting different substitution of some of\nthose annoying RCS $Id:...$ strings. Looks like the formatting of the\ndate is different. So your mileage may vary.\n\nBut here it is if its of any interest.\n\n\n\n\n"},{"id":"16200","messageId":"43F2EF09.5060603@op5.se","threadId":"3334","inReplyTo":"7vwtfxm917.fsf@assigned-by-dhcp.cox.net","subject":"Re: several quick questions","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-15T09:06:17Z","receivedAt":"2006-02-15T09:06:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n> \n>>Junio C Hamano wrote:\n>>\n>>\n>>>Now, read-only ref does not interest me, but \"do not commit on\n>>>top of this yourself, only fast-forward from somewhere else is\n>>>allowed\" may be useful, for the reason why you mentioned\n>>>\"origin\".\n>>\n>>Do my suggestion and you wouldn't have to worry about read-only\n>>branches, and although merging any changes from it might be more\n>>trouble than its worth, it might be possible to cherry-pick the commit\n>>rather than reverting and re-applying it.\n> \n> \n> Sorry, is this \"do my suggestion\" a solution to my \"do not\n> commit on top of this yourself, only fast-forward from somewhere\n> else is allowed -- e.g. to protect 'origin'\" issue, or is it\n> something completely different?\n> \n\nThe \"git checkout -b foo HEAD~15\", which was already supported, although \nI missed that. All programmers have names to use just for throwaway \nvariables (never heard \"frotz\" and \"nitfol\" before though), so adding \nthe burden of selecting a name for the throw-away search branch \nshouldn't be too hard on them. Then it would be possible to commit to \nit, and merge or cherry-pick from it later. It's usually preferrable to \namend to a broken patch than to revert it completely.\n\nIn essence, I claim that git-seek is superfluous and inferior to \"git \ncheckout -b foo \" and shouldn't be implemented. If anyone \nwants to distribute the source to non-scm people as per a given point in \nthe history I think \"git tar-tree\" works marvelously as is.\n\nThe good thing about being past 1.0 in a project is that it's \nfeature-complete, or close to. The bad thing is that bloat usually \nstarts to happen around 1.1.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16202","messageId":"7vwtfxkmf0.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"43F2EF09.5060603@op5.se","subject":"Re: several quick questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-15T09:21:07Z","receivedAt":"2006-02-15T09:21:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> The good thing about being past 1.0 in a project is that it's\n> feature-complete, or close to. The bad thing is that bloat usually\n> starts to happen around 1.1.\n\nThanks -- be kind and stop me whenever somebody else tempts me\nto add excess things to the core, please. Always good to have\nadult supervision ;-), eh, voice of sanity.\n"},{"id":"16226","messageId":"200602152022.11162.Josef.Weidendorfer@gmx.de","threadId":"3334","inReplyTo":"7v3bilr2zr.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] More useful/hinting error messages in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-02-15T19:22:11Z","receivedAt":"2006-02-15T19:22:11Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"\nSigned-off-by: Josef Weidendorfer \n---\n\nOn Tuesday 14 February 2006 23:26, you wrote:\n>\n> \t$ git checkout -b test v2.6.10\n> \n> The user wanted to create a new branch test based on tag\n> v2.6.10, alas that tag does not exist. We give quite confusing\n> error message because we are confused that the user meant to\n> checkout only \"./v2.6.10\" file and that operation and switching\n> branches are incompatible.\n\nDoes this patch clarify the error condition?\n\nJosef\n\n\n git-checkout.sh | 13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\nd15e024c0bd07a2f0dad6e2729e2681df374c8e6\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 6a87c71..b7d892d 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -22,7 +22,7 @@ while [ \"$#\" != \"0\" ]; do\n \t\t[ -e \"$GIT_DIR/refs/heads/$newbranch\" ] &&\n \t\t\tdie \"git checkout: branch $newbranch already exists\"\n \t\tgit-check-ref-format \"heads/$newbranch\" ||\n-\t\t\tdie \"we do not like '$newbranch' as a branch name.\"\n+\t\t\tdie \"git checkout: we do not like '$newbranch' as a branch name.\"\n \t\t;;\n \t\"-f\")\n \t\tforce=1\n@@ -75,9 +75,15 @@ done\n \n if test \"$#\" -ge 1\n then\n+\thint=\n+\tif test \"$#\" -eq 1\n+\tthen\n+\t\thint=\"\n+Did you intend to checkout '$@' which can not be resolved as commit?\"\n+\tfi\n \tif test '' != \"$newbranch$force$merge\"\n \tthen\n-\t\tdie \"updating paths and switching branches or forcing are incompatible.\"\n+\t\tdie \"git checkout: updating paths is incompatible with switching branches/forcing$hint\"\n \tfi\n \tif test '' != \"$new\"\n \tthen\n@@ -117,7 +123,8 @@ fi\n \n [ -z \"$branch$newbranch\" ] &&\n \t[ \"$new\" != \"$old\" ] &&\n-\tdie \"git checkout: you need to specify a new branch name\"\n+\tdie \"git checkout: to checkout the requested commit you need to specify \n+ a name for a new branch which is created and switched to\"\n \n if [ \"$force\" ]\n then\n-- \n1.2.0.g719b\n"},{"id":"16635","messageId":"87zmkhrf4y.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"7vu0b1pntl.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] New git-seek command with documentation and test.","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-23T20:31:25Z","receivedAt":"2006-02-23T20:31:25Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"Add git-seek which allows for temporary excursions through the\nrevision history. With \"git seek \" one gets a working tree\ncorresponding to . When done with the excursion \"git seek\"\nreturns back to the original branch from where the first seek began.\n\nSigned-off-by: Carl Worth \n\n---\n\n git-seek could be used as a new basis for git-bisect. This patch does\n not do that, but even so, git-bisect and git-seek should play nicely\n with each other, (in the sense that either will refuse to do anything\n if .git/head-name already exists).\n\n On Tue, 14 Feb 2006 14:39:34 -0800, Junio C Hamano wrote:\n > Carl Worth writes:\n > > [arguments in favor of a new git-seek] \n > \n > I think this is a very valid point and I am happy to accept a\n > workable proposal (does not have to be a working patch, but a\n > general semantics that covers most of if not all the corner\n > cases).\n \n I had planned to just let this drop as my original need was some\n historical exploration that I've already finished. But now I've found\n a common use case in my everyday workflow that could benefit from\n git-seek. Here it is:\n \n I receive a bug-fix patch that updates a test case to demonstrate the\n bug. I can apply both the fix and the test case and see it succeed.\n But what I really want to do is first commit the test case, see it\n fail, and only then commit the fix and see the test now succeed. I'd\n also like the history to reflect that order. So what I do is:\n \n \t$ git-am\n \t$ git update-index test.c ; git commit -m \"Update test\"\n \t$ git update-index buggy.c ; git commit -m \"Fix bug\"\n \n At that point, without git-seek I can get by with:\n \n \t$ git checkout -b tmp HEAD^\n \t$ make check # to see failure\n \t$ git checkout \n \t$ git branch -d tmp # easy to forget, but breaks the next time otherwise\n \t$ make check # to see success\n \n But what I'd really like to do, (and can with the attached patch), is:\n \n \t$ git seek HEAD^\n \t$ make check # to see failure\n \t$ git seek\n \t$ make check # to see success\n \n This avoids me having to: 1) invent a throwaway name, 2) remember the\n branch I started on, 3) remember to actually throwaway the temporary\n branch.\n\n I've documented git-seek quite carefully and added a test that tries\n to cover every documented failure mode.\n\n -Carl\n\n .gitignore | 1 \n Documentation/git-seek.txt | 44 +++++++++++++++++++++\n Makefile | 4 +-\n git-seek.sh | 94 ++++++++++++++++++++++++++++++++++++++++++++\n t/t3800-seek.sh | 82 ++++++++++++++++++++++++++++++++++++++\n 5 files changed, 223 insertions(+), 2 deletions(-)\n create mode 100644 Documentation/git-seek.txt\n create mode 100644 git-seek.sh\n create mode 100755 t/t3800-seek.sh\n\n2656ffb6e3fcbd9443c22b4675b13f23c031600e\ndiff --git a/.gitignore b/.gitignore\nindex 94f66d5..55484b0 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -85,6 +85,7 @@ git-rev-list\n git-rev-parse\n git-revert\n git-rm\n+git-seek\n git-send-email\n git-send-pack\n git-sh-setup\ndiff --git a/Documentation/git-seek.txt b/Documentation/git-seek.txt\nnew file mode 100644\nindex 0000000..cb5c13d\n--- /dev/null\n+++ b/Documentation/git-seek.txt\n@@ -0,0 +1,44 @@\n+git-bisect(1)\n+=============\n+\n+NAME\n+----\n+git-seek - Provide a temporary excursion through the revision history.\n+\n+\n+SYNOPSIS\n+--------\n+'git seek' []\n+\n+DESCRIPTION\n+-----------\n+When given a , git-seek updates the files in the working\n+tree to the state of the given revision. It will do this by performing\n+a checkout of to a new branch named \"seek\", or by resetting\n+the seek branch if it already exists.\n+\n+When run with with no argument, git-seek will return to the\n+original branch from which the initial git-seek operation was\n+performed, (this original branch name is saved in $GIT_DIR/head-name).\n+\n+git-seek refuses to do anything if the working tree or index are\n+modified with respect to HEAD. If you want to carry modifications\n+around, use git-checkout rather than git-seek.\n+\n+git-seek will also fail if GIT_DIR/head-name exists when a seek is not\n+already in progress, or if a seek branch already exists that is not a\n+subset of the current branch, (that is, if it has unmerged commits).\n+\n+Author\n+------\n+Written by Carl Worth , based on git-bisect by\n+Linus Torvalds \n+\n+Documentation\n+-------------\n+Documentation by Carl Worth and the git-list .\n+\n+GIT\n+---\n+Part of the gitlink:git[7] suite\n+\ndiff --git a/Makefile b/Makefile\nindex 8e6bbce..f3383d8 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -120,8 +120,8 @@ SCRIPT_SH = \\\n \tgit-merge-one-file.sh git-parse-remote.sh \\\n \tgit-prune.sh git-pull.sh git-push.sh git-rebase.sh \\\n \tgit-repack.sh git-request-pull.sh git-reset.sh \\\n-\tgit-resolve.sh git-revert.sh git-rm.sh git-sh-setup.sh \\\n-\tgit-tag.sh git-verify-tag.sh git-whatchanged.sh \\\n+\tgit-resolve.sh git-revert.sh git-rm.sh git-seek.sh \\\n+\tgit-sh-setup.sh git-tag.sh git-verify-tag.sh git-whatchanged.sh \\\n \tgit-applymbox.sh git-applypatch.sh git-am.sh \\\n \tgit-merge.sh git-merge-stupid.sh git-merge-octopus.sh \\\n \tgit-merge-resolve.sh git-merge-ours.sh git-grep.sh \\\ndiff --git a/git-seek.sh b/git-seek.sh\nnew file mode 100644\nindex 0000000..26f0b76\n--- /dev/null\n+++ b/git-seek.sh\n@@ -0,0 +1,94 @@\n+#!/bin/sh\n+\n+USAGE='[]'\n+LONG_USAGE='git-seek provides a temporary excursion through the revision history.\n+\n+When given a , git-seek updates the files in the working\n+tree to the state of the given revision. It will do this by performing\n+a checkout of to a new branch named \"seek\", or by resetting\n+the seek branch if it already exists.\n+\n+When run with with no argument, git-seek will return to the\n+original branch from which the initial git-seek operation was\n+performed, (this original branch name is saved in $GIT_DIR/head-name).\n+\n+git-seek refuses to do anything if the working tree or index are\n+modified with respect to HEAD. If you want to carry modifications\n+around, use git-checkout rather than git-seek.\n+\n+git-seek will also fail if GIT_DIR/head-name exists when a seek is not\n+already in progress, or if a seek branch already exists that is not a\n+subset of the current branch, (that is, if it has unmerged commits).'\n+\n+. git-sh-setup\n+\n+# Does $GIT_DIR/head-name contain the given revision\n+# We use git-rev-parse to correctly resolve any aliases through references.\n+head_name_contains() {\n+\told_head=$(git-rev-parse $(cat \"$GIT_DIR/head-name\"))\n+\tnew_head=$(git-rev-parse \"$1\")\n+\t[ \"$old_head\" = \"$new_head\" ]\n+}\n+\n+seek_to() {\n+\ttarget=\"$1\"\n+\thead=$(GIT_DIR=\"$GIT_DIR\" git-symbolic-ref HEAD) ||\n+\tdie \"Bad HEAD - I need a symbolic ref\"\n+\tcase \"$head\" in\n+\trefs/heads/seek)\n+\t\t# An explicit seek to head-name is treated as a reset\n+\t\tif head_name_contains \"$target\"; then\n+\t\t\tseek_reset\n+\t\telse\n+\t\t\tgit reset --hard $target\n+\t\tfi\n+\t\t;;\n+\trefs/heads/*)\n+\t\t[ -s \"$GIT_DIR/head-name\" ] && die \"Will not seek: $GIT_DIR/head-name is already in use\"\n+\t\techo \"$head\" | sed 's#^refs/heads/##' >\"$GIT_DIR/head-name\"\n+\t\tif git-rev-parse --verify seek >&/dev/null ; then\n+\t\t\tgit-branch -d seek || exit\n+\t\tfi\n+\t\tgit checkout -b seek $target\n+\t\t;;\n+\t*)\n+\t\tdie \"Bad HEAD - strange symbolic ref\"\n+\t\t;;\n+\tesac\n+}\n+\n+seek_reset() {\n+\tif [ -s \"$GIT_DIR/head-name\" ]; then\n+\t\tsource=$(cat \"$GIT_DIR/head-name\") || exit\n+\telse\n+\t\techo >&2 \"No seek is in progress: returning to master.\"\n+\t\tsource \n+\tfi\n+\tgit checkout \"$source\" &&\n+\t(git branch -d seek || err=$? ; git checkout seek ; exit $err) &&\n+\trm -f \"$GIT_DIR/head-name\"\n+}\n+\n+head=$(git-rev-parse --verify HEAD) || die \"You do not have a valid HEAD\"\n+\n+files_dirty=$(git-diff-index --name-only $head) || exit\n+index_dirty=$(git-diff-index --cached --name-only $head) || exit\n+if [ \"$files_dirty\" -o \"$index_dirty\" ]; then\n+\tdie \"Will not seek from a dirty state:\n+\t${index_dirty:+(dirty in index: $index_dirty)} ${files_dirty:+(dirty in working tree: $files_dirty)}\n+You may want to commit these changes first or perhaps use git-checkout\n+-m instead of git-seek.\"\n+fi\n+\n+case \"$#\" in\n+0)\n+\tseek_reset\n+\t;;\n+1)\n+\tseek_to \"$1\"\n+\t;;\n+*)\n+\tusage \n+\t;;\n+esac\n+\ndiff --git a/t/t3800-seek.sh b/t/t3800-seek.sh\nnew file mode 100755\nindex 0000000..e5d8f90\n--- /dev/null\n+++ b/t/t3800-seek.sh\n@@ -0,0 +1,82 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2006 Carl D. Worth\n+#\n+\n+test_description='Test of git-seek and all documented failure modes.'\n+\n+. ./test-lib.sh\n+\n+echo \"first\" > file\n+git-add file && git-commit -m \"add first revision of file\"\n+echo \"second\" > file\n+git-commit -a -m \"commit second revision\"\n+git tag second\n+echo \"third\" > file\n+git-commit -a -m \"commit third revision\"\n+\n+verify_revision() {\n+ contents=$(cat file) && [ \"$contents\" = \"$1\" ]\n+}\n+\n+test_expect_success \\\n+ 'Test of initial \"git-seek \"' \\\n+ 'git-seek HEAD~2 && verify_revision first'\n+\n+test_expect_success \\\n+ 'Test of \"git-seek \" during seek' \\\n+ 'git-seek second && verify_revision second'\n+\n+test_expect_success \\\n+ 'Test that \"git-seek\" returns to starting point and resets seek state' \\\n+ 'git-seek && verify_revision third &&\n+ [ ! -f .git/refs/seek ] &&\n+ [ ! -f .git/head-name ]'\n+\n+test_expect_success \\\n+ 'Test that \"git-seek master\" also resets seek state' \\\n+ 'git seek HEAD^1 &&\n+ git seek master && verify_revision third &&\n+ [ ! -f .git/refs/seek ] &&\n+ [ ! -f .git/head-name ]'\n+\n+test_expect_success \\\n+ 'Test that \"git-seek \" which aliases to master also resets seek state' \\\n+ 'source=$(git-rev-parse HEAD) &&\n+ git seek HEAD^1 &&\n+ git seek $source && verify_revision third &&\n+ [ ! -f .git/refs/seek ] &&\n+ [ ! -f .git/head-name ]'\n+\n+echo modified > file\n+test_expect_failure \\\n+ 'Test that git-seek fails with local file modification' \\\n+ 'git-seek HEAD^'\n+git-reset --hard master\n+\n+echo modified > file\n+git-update-index file\n+test_expect_failure \\\n+ 'Test that git-seek fails with a modified index' \\\n+ 'git-seek HEAD^'\n+git-reset --hard master\n+\n+echo master > .git/head-name\n+test_expect_failure \\\n+ 'Test that git-seek fails when .git/head-name exists and not seeking' \\\n+ 'git-seek HEAD^'\n+rm .git/head-name\n+\n+git-seek HEAD^\n+echo new > new; git-add new; git-commit -m \"Commit new file to seek branch\"\n+test_expect_failure \\\n+ 'Test that git-seek fails when there are unmerged commits on seek branch' \\\n+ 'git-seek'\n+\n+git checkout master\n+git-pull . seek >&/dev/null\n+test_expect_success \\\n+ 'Test that git-seek works again after merging in the seek branch' \\\n+ 'git-seek'\n+\n+test_done\n-- \n1.2.3.g207a-dirty\n\n\n\n\n"},{"id":"16646","messageId":"20060224001848.GB21094@fieldses.org","threadId":"3334","inReplyTo":"87zmkhrf4y.wl%cworth@cworth.org","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-02-24T00:18:48Z","receivedAt":"2006-02-24T00:18:48Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Feb 23, 2006 at 12:31:25PM -0800, Carl Worth wrote:\n> --- /dev/null\n> +++ b/Documentation/git-seek.txt\n> @@ -0,0 +1,44 @@\n> +git-bisect(1)\n> +=============\n\nOops.\n\n> +When given a , git-seek updates the files in the working\n> +tree to the state of the given revision. It will do this by performing\n> +a checkout of to a new branch named \"seek\", or by resetting\n> +the seek branch if it already exists.\n\nI wonder if its a good idea to silently reset a branch named with a\nshort common word?\n\n> +LONG_USAGE='git-seek provides a temporary excursion through the revision history.\n> +\n> +When given a , git-seek updates the files in the working\n> +tree to the state of the given revision. It will do this by performing\n> +a checkout of to a new branch named \"seek\", or by resetting\n> +the seek branch if it already exists.\n\nThese long usage texts with language duplicated from the man pages seem\nlike they'd be asking for bit-rot, when an update happens in one place\nbut not the other. I dunno.\n\n--b.\n"},{"id":"16650","messageId":"87vev5r2m4.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"20060224001848.GB21094@fieldses.org","subject":"[PATCH] git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs.","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-24T01:01:55Z","receivedAt":"2006-02-24T01:01:55Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"This fixed a bug that would cause \"git seek\" to mistakenly try to\ncheckout the seek branch just after deleting it. Of course, that would\nnever work, but fixing the bug does squelch the annoying error caused\nby the bug.\n\nAlso fix an errant title of \"git-bisect\" in the git-seek documentation.\n\n---\n\nOn Thu, 23 Feb 2006 19:18:48 -0500, \"J. Bruce Fields\" wrote:\n> On Thu, Feb 23, 2006 at 12:31:25PM -0800, Carl Worth wrote:\n> > +git-bisect(1)\n> > +=============\n> \n> Oops.\n\nThanks.\n\n> I wonder if its a good idea to silently reset a branch named with a\n> short common word?\n\nIt at least takes some care not to leave commits dangling when doing\nthis, (the seek branch must at least be a subset of the current\nHEAD). I was pretty much following the lead of git-bisect here,\n(though \"bisect\" is definitely a touch longer and less common than\n\"seek\").\n\nIf it would be preferred to hide such \"internal\" branch names behind\nsome unlikely symbol or such, that would obviously be easy to do.\n\nAs is, the seek branch is at least documented, and rather well\nadvertised in operation, (for example, returning with \"git seek\"\nreported \"Deleted branch seek.\").\n\n> These long usage texts with language duplicated from the man pages seem\n> like they'd be asking for bit-rot, when an update happens in one place\n> but not the other. I dunno.\n\nYeah, I don't know. Again, I was just imitating things I'd seen\nelsewhere.\n\n Documentation/git-seek.txt | 4 ++--\n git-seek.sh | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\n43f042982c26859b6b7f6055fc03dda8e89f4e70\ndiff --git a/Documentation/git-seek.txt b/Documentation/git-seek.txt\nindex cb5c13d..513dbc7 100644\n--- a/Documentation/git-seek.txt\n+++ b/Documentation/git-seek.txt\n@@ -1,5 +1,5 @@\n-git-bisect(1)\n-=============\n+git-seek(1)\n+===========\n \n NAME\n ----\ndiff --git a/git-seek.sh b/git-seek.sh\nindex 26f0b76..921c014 100644\n--- a/git-seek.sh\n+++ b/git-seek.sh\n@@ -65,7 +65,7 @@ seek_reset() {\n \t\tsource \n \tfi\n \tgit checkout \"$source\" &&\n-\t(git branch -d seek || err=$? ; git checkout seek ; exit $err) &&\n+\t(git branch -d seek || (err=$? ; git checkout seek ; exit $err)) &&\n \trm -f \"$GIT_DIR/head-name\"\n }\n \n-- \n1.2.3.g2656-dirty\n\n"},{"id":"16654","messageId":"7vslq9fg53.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"87vev5r2m4.wl%cworth@cworth.org","subject":"Re: [PATCH] git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-24T06:02:48Z","receivedAt":"2006-02-24T06:02:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n>> I wonder if its a good idea to silently reset a branch named with a\n>> short common word?\n>\n> It at least takes some care not to leave commits dangling when doing\n> this, (the seek branch must at least be a subset of the current\n> HEAD). I was pretty much following the lead of git-bisect here,\n> (though \"bisect\" is definitely a touch longer and less common than\n> \"seek\").\n\nIIUC Cogito seems to use cg-seek-point or something long and\nunusual like that...\n"},{"id":"16660","messageId":"43FED93D.1000601@op5.se","threadId":"3334","inReplyTo":"87zmkhrf4y.wl%cworth@cworth.org","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-24T10:00:29Z","receivedAt":"2006-02-24T10:00:29Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Carl Worth wrote:\n> Add git-seek which allows for temporary excursions through the\n> revision history. With \"git seek \" one gets a working tree\n> corresponding to . When done with the excursion \"git seek\"\n> returns back to the original branch from where the first seek began.\n> \n\nI've said it before, and I'll say it again. This tool provides less \nflexibility and much less power than \"git checkout -b branch \n\" (although it would be nice to have '-o' for 'overwrite \nexisting branch' as an argument to git checkout)\n\n> Signed-off-by: Carl Worth \n> \n> ---\n> \n> I had planned to just let this drop as my original need was some\n> historical exploration that I've already finished. But now I've found\n> a common use case in my everyday workflow that could benefit from\n> git-seek. Here it is:\n> \n> I receive a bug-fix patch that updates a test case to demonstrate the\n> bug. I can apply both the fix and the test case and see it succeed.\n> But what I really want to do is first commit the test case, see it\n> fail, and only then commit the fix and see the test now succeed. I'd\n> also like the history to reflect that order. So what I do is:\n> \n> \t$ git-am\n> \t$ git update-index test.c ; git commit -m \"Update test\"\n> \t$ git update-index buggy.c ; git commit -m \"Fix bug\"\n> \n> At that point, without git-seek I can get by with:\n> \n> \t$ git checkout -b tmp HEAD^\n> \t$ make check # to see failure\n> \t$ git checkout \n> \t$ git branch -d tmp # easy to forget, but breaks the next time otherwise\n> \t$ make check # to see success\n> \n> But what I'd really like to do, (and can with the attached patch), is:\n> \n> \t$ git seek HEAD^\n> \t$ make check # to see failure\n> \t$ git seek\n> \t$ make check # to see success\n> \n> This avoids me having to:\n> 1) invent a throwaway name,\n\nAll programmers have at least five throwaway names that are only ever \nused as such (mine are, in order of precedence, foo, bar, tmp, fnurg, \nsdf and asd).\n\n> 2) remember the branch I started on,\n\nWith topic branches, you need to pick more careful topic names. Without \ntopic branches you're always on \"master\". Surely you know what the \npatches touch, so you know what branch they should be in.\n\n> 3) remember to actually throwaway the temporary branch.\n> \n\nThis isn't always a bad thing, since you after applying some patch or \nother decide you want to go back to this point in history, or want to \nkeep the point so you can show the author some problem or other with the \npatch. With git-seek you'll then have to remember the hard-to-learn \nSHA1, or how far below HEAD or some other easily remembered point in \nhistory it is. In that case, you need to remember to add the \nbranch/tag/whatever to where you seeked rather than just go on with the \nwork. Removing a branch later is simple. Finding the right spot to \ncreate it later can be trouble-some.\n\nIf I had a vote, I'd say no to this patch, and to this tool entirely.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16665","messageId":"7vvev5aswm.fsf@assigned-by-dhcp.cox.net","threadId":"3334","inReplyTo":"43FED93D.1000601@op5.se","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-24T11:38:17Z","receivedAt":"2006-02-24T11:38:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> I've said it before, and I'll say it again. This tool provides less\n> flexibility and much less power than \"git checkout -b branch\n> \" (although it would be nice to have '-o' for 'overwrite\n> existing branch' as an argument to git checkout)\n\nTrue, but assembly provides more flexibility than higher level\nlanguages and you need to strike a balance between power and\nusability.\n\nThe real question is if the structure the tool enforces to your\nworkflow is simply being a straight-jacket or helping an average\nuser to avoid common mistakes.\n\nOne occasion I've felt the need for \"seek\" like feature was when\nstarting to bisect. You usually notice breakage, so you can\nstart with \"git bisect bad HEAD\", but then what next? You\nusually are not absolutely sure which one _was_ working the last\ntime.\n\nIf I had a seek, then I could go back to some randomly chosen\nversion to try it out, going back until I find a good one.\n\nMaybe \"git bisect try $committish\" would be a good addition. We\ncould live without it (we can just say \"git reset --hard\n$committish\"), but it can be a bit more than just that. If\ngiven committish is known to be good or bad, we could remind the\nuser what she said the last time, and offer a chance to take it\nback. That is, (1) if the given $committish is an ancestor of\nexisting good one, list those good ones and ask \"do you mean you\nare not sure if they are good anymore, and retry the\nbisection?\" If yes, delete those good-* refs; (2) if the given\n$committish is a descendant of a bad one, show it and ask \"do\nyou mean you are not sure if they are good anymore, and retry\nthe bisection?\" If yes, remove the existing bad ref. In any\ncase, \"reset --hard\" to it after user responds.\n\nOther than that, I haven't felt a need for seek-like feature;\ninstead, I make liberal use of throw-away branches.\n"},{"id":"16674","messageId":"87oe0wrg29.wl%cworth@cworth.org","threadId":"3334","inReplyTo":"43FED93D.1000601@op5.se","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-24T14:23:42Z","receivedAt":"2006-02-24T14:23:42Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:\n> \n> I've said it before, and I'll say it again. This tool provides less \n> flexibility and much less power than \"git checkout -b branch \n> \"\n\nYes, that's by design. It's not intended to be a replacement for git\ncheckout -b. It's intended to be easier to use than that when its\npurpose fits what you want to to.\n\n> > 1) invent a throwaway name,\n> \n> All programmers have at least five throwaway names that are only ever \n> used as such (mine are, in order of precedence, foo, bar, tmp, fnurg, \n> sdf and asd).\n\nSure, and when I use \"git checkout -b\" I have to keep trying these\nlinearly until I found one that is available. That's what I've been\ndoing, and it's painful enough that I wrote this. (Though yes,\nsomething like checkout -o would help here).\n\n> > 2) remember the branch I started on,\n> \n> With topic branches, you need to pick more careful topic names. Without \n> topic branches you're always on \"master\". Surely you know what the \n> patches touch, so you know what branch they should be in.\n\nI almost put \"remember\" in quotation marks. Obviously I know what I'm\nworking on. It's more a matter of just having to type the name, (I do\nuse very careful topic names so they tend to be longish). Having\ntab-completion for git-checkout would help here.\n\nSo (1) and (2) have potential workarounds, but neither exists, and\neven then they would still be harder to use than git-seek.\n\n> > 3) remember to actually throwaway the temporary branch.\n> \n> This isn't always a bad thing, since you after applying some patch or \n> other decide you want to go back to this point in history,\n\nThat assumes that I've made any change though. If you're going back in\nthe past to make changes, then \"git checkout -b\" is the right thing to\nuse. It's when you're not planning to make changes, but just exploring\nthe past that \"git seek\" is helpful.\n\nSo (3) is just extra pain when using git-seek for what its designed to\nbe good for, (exploring history when not planning on writing to it).\n\nBut note that the git-seek I've implemented *does* provide a writable\nbranch, so if you discover that you do want to commit something, then\nthat's always available. Linus gave compelling arguments for this.\n\n> In that case, you need to remember to add the \n> branch/tag/whatever to where you seeked rather than just go on with the \n> work. Removing a branch later is simple. Finding the right spot to \n> create it later can be trouble-some.\n\nYes. And that's why git-seek stops and warns you before it leaves\ndangling commits by moving the branch. (Though it might make sense to\nadd a -f option to force it to seek regardless of the things it\ncurrently balks at.)\n\n> If I had a vote, I'd say no to this patch, and to this tool entirely.\n\nOne argument in favor is that seeking already exists in git privately\nwithin git-bisect. Exposing git-seek makes it easier to code new\noperations along the lines of git-bisect. It's certainly consistent\nwith git's current implementation strategy to have the more primitive\npieces of complex operations exported and available.\n\n-Carl\n"},{"id":"16713","messageId":"Pine.LNX.4.63.0602242246430.11479@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3334","inReplyTo":"87oe0wrg29.wl%cworth@cworth.org","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-24T21:48:46Z","receivedAt":"2006-02-24T21:48:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Feb 2006, Carl Worth wrote:\n\n> On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:\n> > \n> > I've said it before, and I'll say it again. This tool provides less \n> > flexibility and much less power than \"git checkout -b branch \n> > \"\n> \n> Yes, that's by design. It's not intended to be a replacement for git\n> checkout -b.\n\nI do not really understand why.\n\ngit-seek shares so many characteristics with git-seek, you could make \ngit-seek just another command line option to checkout (like \"--temporary\" \nand \"--go-back\").\n\nHth,\nDscho\n"},{"id":"16714","messageId":"20060224215727.GL15970@fieldses.org","threadId":"3334","inReplyTo":"Pine.LNX.4.63.0602242246430.11479@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] New git-seek command with documentation and test.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-02-24T21:57:27Z","receivedAt":"2006-02-24T21:57:27Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Feb 24, 2006 at 10:48:46PM +0100, Johannes Schindelin wrote:\n> git-seek shares so many characteristics with git-seek, you could make \n> git-seek just another command line option to checkout (like \"--temporary\" \n> and \"--go-back\").\n\nWell, as a user interface, git-seek seems a bit simpler (e.g., easier to\nremember).--b.\n"}]}