{"thread":{"id":"28191","subject":"How to check out the repository at a particular point in time","startedAt":"2011-08-22T12:25:02Z","lastAt":"2011-08-24T16:18:55Z","messageCount":12,"participants":["R. Diez","Thomas Rast","Jens Lehmann","Michael Witten","Jonathan Nieder","Matthieu Moy","Andreas Ericsson","Randal L. Schwartz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174014","messageId":"1314015902.48377.YahooMailClassic@web25403.mail.ukl.yahoo.com","threadId":"28191","inReplyTo":null,"subject":"How to check out the repository at a particular point in time","fromName":"R. Diez","fromEmail":"rdiezmail-temp2@yahoo.de","sentAt":"2011-08-22T12:25:02Z","receivedAt":"2011-08-22T12:25:02Z","isPatch":false,"sender":{"key":"rdiezmail-temp2@yahoo.de","avatar":null},"body":"Hi all:\n\nI'm writing a daily build script for all the OpenRISC components, so every day I need to check out several git repositories with the source code of many tools that depend on each other.\n\nThe hole process takes hours. In order to minimize the risk of repository skew, I thought I could just take the current date and time, clone all repositories to my local PC and check them all out at that particular timestamp.\n\nI figured out that something like git \"checkout HEAD@{2011-08-21 10:00:00}\" does not really cut it. I'm getting this warning:\n\n  warning: Log for 'HEAD' only goes back to Sun, 21 Aug 2011 10:00:02 +0200.\n\nThe reason is, the timestamp was taken at 10:00, and the repository was cloned 2 seconds later, which means that 10:00 is earlier than the repository. That was totally unexpected, but then I found this in the documentation for \"gitrevisions\":\n\n  Note that this looks up the state of your local ref at\n  a given time; e.g., what was in your local master branch last week.\n  If you want to look at commits made during certain times,\n  see --since and --until. \n\nI guess that means the HEAD@{date} syntax does not do what I expected. But hey, it's not the first time I find the git docs hard to follow... }8-)\n\nBy the way, it would be nice if the gitrevisions documentation could be improved, as I still don't understand what that really means. Say, for example, an hour ago I had temporarily checked out last year's versions, but half an hour ago I went back to this year's versions. If I check out at HEAD@{1 hour ago}, will I get then last year's version, or this year's?\n\nAnyway, my real problem is with the mentioned --until option. \"git checkout\" does not understand that option, so I guess I need to feed the date to some other git command in order to get the commit ID for \"git checkout\", right? Can someone help me here?\n\nOr even better, can someone add this kind of explanation to the \"git checkout\" documentation? If you are used to other version control systems, and wish to checkout the versions at a particular date, that's the documentation page you first look at.\n\nFor extra karma points, git checkout could understand the --until option itself.\n\nMany thanks in advance,\n  R. Diez\n"},{"id":"174017","messageId":"201108221525.32982.trast@student.ethz.ch","threadId":"28191","inReplyTo":"1314015902.48377.YahooMailClassic@web25403.mail.ukl.yahoo.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-08-22T13:25:31Z","receivedAt":"2011-08-22T13:25:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"I'll basically reply from bottom up so you can see the motivation and\nthen my suggestions for the solution.\n\nR. Diez wrote:\n> \n>   Note that this looks up the state of your local ref at\n>   a given time; e.g., what was in your local master branch last week.\n>   If you want to look at commits made during certain times,\n>   see --since and --until. \n[...]\n> Say, for example, an hour ago I had temporarily checked out last\n> year's versions, but half an hour ago I went back to this year's\n> versions. If I check out at HEAD@{1 hour ago}, will I get then last\n> year's version, or this year's?\n\nThe @{date} and @{n} syntax refers to the reflog, which as the name\ntries to imply, is a log of where *your local ref* was at that\ntime/step.  Since the HEAD ref is by definition what you have checked\nout at the moment, HEAD@{1 hour ago} indeed refers to last year's\nversion.\n\n> Anyway, my real problem is with the mentioned --until option. \"git\n> checkout\" does not understand that option, so I guess I need to feed\n> the date to some other git command in order to get the commit ID for\n> \"git checkout\", right? Can someone help me here?\n\nIt is a git-log option (or more precisely, revision walker option).\nThe main problem is that your request is not very well-defined: in\nnonlinear history there will in general be more than one commit at the\ntime requested.\n\n    ---a----b----c----M----       (M is a merge)\n        \\            /\n         d-----e----f\n\n             ^---- April 1st\n\nSuppose you ask git for \"the newest commit as of April 1st\" in this\nhistory.  Is it supposed to give you b or d?  [If you think nonlinear\nhistory is easy, try to figure out a good rule in the presence of time\nskew, where misconfigured clocks/timezones resulted in parents being\nyounger than children.]\n\nHence:\n\n> For extra karma points, git checkout could understand the --until option itself.\n\nIt probably never will, because that is an ill-defined request.\n\nYou can indeed say\n\n  git log -1 --until=\"april 1\"\n\nto get *one* commit that happened before April 1st, but which one is\nup to the order internally used by git.  You can also say\n\n  git log -1 --first-parent --until=\"april 1\"\n\nto get the first such commit along the first-parent ancestry, which\nmight suit the ticket.\n\nBut there is a more fundamental issue.  Let me explain.\n\n> I'm writing a daily build script for all the OpenRISC components, so\n> every day I need to check out several git repositories with the\n> source code of many tools that depend on each other.\n> \n> The hole process takes hours. In order to minimize the risk of\n> repository skew\n\nStep back and consider the real problem here.  In the simplest case\nyou are getting two components A and B which depend on each other,\ne.g., A depends on B.  But there is a race condition in the case where\na user updates an API between them in a backward-incompatible way: she\nhas to update both A and B, and an unfortunate coworker/buildbot may\npull old-A and new-B (or vice versa) and get a broken build.\n[Incidentally this seems to be a frequent problem with SVN externals.]\n\nYou might say: if only we had a way to record the fact that the\n\"blessed\" version of B to go with old-A is old-B, and for new-A it's\nnew-B.\n\nAnd indeed we do.  Submodules were invented to allow B to be \"linked\"\ninto A's repository, such that a checkout of any commit of A \"knows\"\nthe correct corresponding version of B.  A user who updates the API\ncan record the update to B inside the API-changing commit in A.\n\nSo while you can kludge your way around the problem with clever use of\n'git log --until', submodules would be the \"correct\" solution.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"174020","messageId":"1314026326.37332.YahooMailClassic@web25408.mail.ukl.yahoo.com","threadId":"28191","inReplyTo":"201108221525.32982.trast@student.ethz.ch","subject":"Re: How to check out the repository at a particular point in time","fromName":"R. Diez","fromEmail":"rdiezmail-temp2@yahoo.de","sentAt":"2011-08-22T15:18:46Z","receivedAt":"2011-08-22T15:18:46Z","isPatch":false,"sender":{"key":"rdiezmail-temp2@yahoo.de","avatar":null},"body":"Hallo Thomas Rast:\n\nThanks for your quick answer. Please see mine below.\n\n> The @{date} and @{n} syntax refers to the reflog, which as\n> the name\n> tries to imply, is a log of where *your local ref* was at\n> that\n> time/step.  Since the HEAD ref is by definition what\n> you have checked\n> out at the moment, HEAD@{1 hour ago} indeed refers to last\n> year's version.\n\nOK, thanks. That kind of example would be nice to have in the \"git checkout\" documentation page. In the meantime, I've seen on the Internet that other people also got caught by this... let's say... 'unintuitive' behaviour or documentation. 8-)\n\n\n> It is a git-log option (or more precisely, revision walker\n> option).\n\nIn the meantime, I've seen this done with \"git rev-list\" instead, like this:\n\n  git rev-list -n 1 --before=\"2010-11-01 11:45:16 +0000\" master\n\nIs that the same as with git-log ?\n\n\n> The main problem is that your request is not very\n> well-defined: in\n> nonlinear history there will in general be more than one\n> commit at the\n> time requested.\n> \n>     ---a----b----c----M----  (M is a merge)\n>         \\            /\n>          d-----e----f\n> \n>             ^----\n> April 1st\n> \n> Suppose you ask git for \"the newest commit as of April 1st\"\n> in this history.  Is it supposed to give you b or d?\n\nI still don't quite understand how git works, but let me risk a naive statement here. If \"a-b-c-M\" were 'master', and \"d-e-f\" were 'new-feature', then on April 1st the current version on 'master' is 'b', because I merged the 'new-feature' branch at a later point in time. Does that make sense?\n\n\n> Step back and consider the real problem here.  In the\n\nYou're right in saying there is a race condition here between developers, and the right solution would be of course to tag which versions work well with each other.\n\nBut that problem the daily build is trying to solve is precisely that it's too hard to keep track of all component versions in all repositories. Things just move too fast, and as far as I understand it, git submodules require manual intervention. If I ever tag anything manually, it must have already passed the daily build!\n\nThe development model looks like this: the latest HEAD versions of all components should always work well with each other. If something breaks, the daily build will let the developer know by the next day. If two developers make incompatible changes, they'll speak to each other and commit their changes within a few hours. During that time, they will be trouble, but that's quite alright (at least for the moment).\n\nI just didn't want the daily build to add to the uncertainty of what went wrong by introducing a few hours' worth of random time skew to the mix.\n\nThe daily build server needs to check out from git the head status at say 02:00 am on all repositories, as if the server had so many CPUs that it had ran a \"git pull\" for all of them simultaneously. That's close enough for my purposes. Like stated above, if someone merges some old branch at 02:01 am, a user that did a \"git pull\" on master at 02:00 am would not have seen that merge, that's the effect I would like to achieve.\n\nIn the future there will probably be a stable HEAD branch and a development branch with the same name across all git repositories, and the daily build can do both every day. Or maybe the stable versions will not come from git any more, but from .tar.gz files. Another solution to automate releases without so much human intervention would be as follows: if the automated build and automated testing succeeded 3 hours ago, then that timestamp can be entered in the database of \"pretty sure it works\" versions. The timestamp becomes effectively the version number. Manually coordinating all participants is hard if you don't have so many human resources.\n\nThanks again,\n  R. Diez\n"},{"id":"174026","messageId":"4E528A3E.2070505@web.de","threadId":"28191","inReplyTo":"1314026326.37332.YahooMailClassic@web25408.mail.ukl.yahoo.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-22T16:56:30Z","receivedAt":"2011-08-22T16:56:30Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 22.08.2011 17:18, schrieb R. Diez:\n> But that problem the daily build is trying to solve is precisely that it's\n> too hard to keep track of all component versions in all repositories. Things\n> just move too fast, and as far as I understand it, git submodules require\n> manual intervention. If I ever tag anything manually, it must have already\n> passed the daily build!\n\nSubmodules can easily be scripted too. Why don't you let your buildsystem\nautomatically create a commit with the current HEADs in the superproject\nwhen building and testing all repositories was successful? Then each\ndeveloper can use one of those superproject commits as starting point and\nhappily hack away on a repository. And as a bonus he can see in the\nsuperproject how many changes he did from the nightly build he started\nwith. And if he doesn't care, he can forget about the superproject until\nhe needs to sync again.\n\n> The development model looks like this: the latest HEAD versions of all\n> components should always work well with each other. If something breaks,\n> the daily build will let the developer know by the next day. If two\n> developers make incompatible changes, they'll speak to each other and\n> commit their changes within a few hours. During that time, they will be\n> trouble, but that's quite alright (at least for the moment).\n\nYou can decide later if you want to use the superproject to coordinate\nsuch possibly conflicting changes, but that would mean your developers\nwould have to commit their changes in the superproject too.\n"},{"id":"174093","messageId":"CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com","threadId":"28191","inReplyTo":"1314026326.37332.YahooMailClassic@web25408.mail.ukl.yahoo.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-23T15:54:57Z","receivedAt":"2011-08-23T15:54:57Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:\n>> The main problem is that your request is not very\n>> well-defined: in\n>> nonlinear history there will in general be more than one\n>> commit at the\n>> time requested.\n>>\n>>     ---a----b----c----M----  (M is a merge)\n>>         \\            /\n>>          d-----e----f\n>>\n>>              ^----April 1st\n>>\n>> Suppose you ask git for \"the newest commit as of April 1st\"\n>> in this history.  Is it supposed to give you b or d?\n>\n> I still don't quite understand how git works, but let me\n> risk a naive statement here. If \"a-b-c-M\" were 'master',\n> and \"d-e-f\" were 'new-feature', then on April 1st the\n> current version on 'master' is 'b', because I merged the\n> 'new-feature' branch at a later point in time. Does that\n> make sense?\n\nO! for the love all that is Holy!\n\nYou see, guys? The term `branch' was a TERRIBLE choice.\n\nWhat git calls `branch master' in your example is just a pointer to\nthe commit object `M'; it has nothing to do with particular lineages\nlike `a-b-c-M'.\n\nPlease see my discussion with Hilco, starting here:\n\n  http://marc.info/?l=git&m=131364675708355&w=2\n  Message-ID: CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com\n\nand this email in particular:\n\n  http://marc.info/?l=git&m=131396006222173&w=2\n  Message-ID: CAMOZ1BvpnP_729YOHrrPW3B8wa5c4cLyD_qAQ5rTuy0JqNiiXg@mail.gmail.com\n\nwhich also includes the following very germane link:\n\n  http://slashdot.org/comments.pl?sid=2350536&cid=36903136\n"},{"id":"174094","messageId":"20110823160525.GB3545@elie.gateway.2wire.net","threadId":"28191","inReplyTo":"CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-23T16:05:25Z","receivedAt":"2011-08-23T16:05:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael Witten wrote:\n> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:\n\n>> I still don't quite understand how git works, but let me\n>> risk a naive statement here. If \"a-b-c-M\" were 'master',\n>> and \"d-e-f\" were 'new-feature', then on April 1st the\n>> current version on 'master' is 'b', because I merged the\n>> 'new-feature' branch at a later point in time. Does that\n>> make sense?\n>\n> O! for the love all that is Holy!\n\nWait, what's wrong with what R. Diez said?  It's exactly what\n--first-parent gives you.\n"},{"id":"174095","messageId":"vpqliuk85ze.fsf@bauges.imag.fr","threadId":"28191","inReplyTo":"20110823160525.GB3545@elie.gateway.2wire.net","subject":"Re: How to check out the repository at a particular point in time","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-08-23T16:09:25Z","receivedAt":"2011-08-23T16:09:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Michael Witten wrote:\n>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:\n>\n>>> I still don't quite understand how git works, but let me\n>>> risk a naive statement here. If \"a-b-c-M\" were 'master',\n>>> and \"d-e-f\" were 'new-feature', then on April 1st the\n>>> current version on 'master' is 'b', because I merged the\n>>> 'new-feature' branch at a later point in time. Does that\n>>> make sense?\n>>\n>> O! for the love all that is Holy!\n>\n> Wait, what's wrong with what R. Diez said?  It's exactly what\n> --first-parent gives you.\n\nNot really. Suppose, on April 1st, I have\n\nA--B--C <-master\n    \\\n     D--E <-new-feature\n\nThen, I merge from upstream\n\nA--B-----C <-master\n    \\     \\\n     D--E--F <-new-feature\n\nand then I push to master, or master fast-forward-pulls from me:\n\nA--B-----C\n    \\     \\\n     D--E--F <-new-feature, master\n\nThen, what used to be in master on April 1st is C, but --first-parent\nwill give you E instead.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"174096","messageId":"CAMOZ1BuMfUT4D_UasLXsjDrXRKDw4EF_U-CV8tsS9W7AP+f8ow@mail.gmail.com","threadId":"28191","inReplyTo":"vpqliuk85ze.fsf@bauges.imag.fr","subject":"Re: How to check out the repository at a particular point in time","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-23T16:23:15Z","receivedAt":"2011-08-23T16:23:15Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, Aug 23, 2011 at 16:09, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> Michael Witten wrote:\n>>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:\n>>\n>>>> I still don't quite understand how git works, but let me\n>>>> risk a naive statement here. If \"a-b-c-M\" were 'master',\n>>>> and \"d-e-f\" were 'new-feature', then on April 1st the\n>>>> current version on 'master' is 'b', because I merged the\n>>>> 'new-feature' branch at a later point in time. Does that\n>>>> make sense?\n>>>\n>>> O! for the love all that is Holy!\n>>\n>> Wait, what's wrong with what R. Diez said?  It's exactly what\n>> --first-parent gives you.\n>\n> Not really. Suppose, on April 1st, I have\n>\n> A--B--C <-master\n>    \\\n>     D--E <-new-feature\n>\n> Then, I merge from upstream\n>\n> A--B-----C <-master\n>    \\     \\\n>     D--E--F <-new-feature\n>\n> and then I push to master, or master fast-forward-pulls from me:\n>\n> A--B-----C\n>    \\     \\\n>     D--E--F <-new-feature, master\n>\n> Then, what used to be in master on April 1st is C, but --first-parent\n> will give you E instead.\n\nIndeed. That example makes perfect sense when so-called `branches'\nmaster and new-feature are rightfully thought of as the `pointers'\n(or, `references') that they are.\n\nMoreover, Jonathan, can't you see that your more knowledgeable mind\nhas automatically smoothed over the inaccuracies presented by R.\nDiez's description? In particular, a `branch' has nothing to do with\nwalking a commit object's ancestry.\n"},{"id":"174100","messageId":"20110823165359.GD3545@elie.gateway.2wire.net","threadId":"28191","inReplyTo":"CAMOZ1BuMfUT4D_UasLXsjDrXRKDw4EF_U-CV8tsS9W7AP+f8ow@mail.gmail.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-23T16:53:59Z","receivedAt":"2011-08-23T16:53:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael Witten wrote:\n\n> Indeed. That example makes perfect sense when so-called `branches'\n> master and new-feature are rightfully thought of as the `pointers'\n> (or, `references') that they are.\n\nYou are right to point out there is potential for confusion, because\ndifferent VCSes model the practice of branching and merging in so many\ndifferent ways:\n\n - a single text field in each commit, as in Mercurial\n - a list of \"sticky\" keywords attached to each commit, as in CVS\n - special revision numbers, as in CVS\n - special directory names, as in Subversion\n - pointers to the tip of a line of history, as in Git\n\nEach model has its strengths and weaknesses in terms of supporting\ndifferent operations one might to perform on a branch:\n\n - creating a branch\n - advancing a branch\n - studying the history of development on a single branch\n - fetching and pushing\n - renaming a branch\n - deleting\n - comparing the history of two branches\n - merging and deleting the now-merged-in branch\n - merging and not deleting the now-merged-in branch\n - \"context switch\" from working on one branch to another\n\nIn particular, you are right to emphasize that in git's model, \"what\nwas on the foo branch at 12:00pm on Saturday\" is just not a well\ndefined question.  The foo branch tip might have been at commit A on\nmy machine, commit B on a server we share, and commit C on your\nmachine, so Git doesn't even bother --- branch refs are pointers into\nhistory rather than participating in the history themselves.\n\nInstead, we can content ourselves with the answers to questions like\n\"what was in the foo branch at 12pm on Saturday on the server used as\na rendezvous point\", by logging in and examining the reflog on the\nserver.\n\nA nice side-benefit is that branch refs are considered to be _private_\nunless they are pushed or mentioned in a commit message.  So there is\nno pressure to come up with good names for them.\n\nHope that helps,\nJonathan\n"},{"id":"174161","messageId":"4E551BC3.8080701@op5.se","threadId":"28191","inReplyTo":"CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-08-24T15:41:55Z","receivedAt":"2011-08-24T15:41:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 08/23/2011 05:54 PM, Michael Witten wrote:\n> On Mon, Aug 22, 2011 at 15:18, R. Diez<rdiezmail-temp2@yahoo.de>  wrote:\n>>> The main problem is that your request is not very\n>>> well-defined: in\n>>> nonlinear history there will in general be more than one\n>>> commit at the\n>>> time requested.\n>>>\n>>>      ---a----b----c----M----  (M is a merge)\n>>>          \\            /\n>>>           d-----e----f\n>>>\n>>>               ^----April 1st\n>>>\n>>> Suppose you ask git for \"the newest commit as of April 1st\"\n>>> in this history.  Is it supposed to give you b or d?\n>>\n>> I still don't quite understand how git works, but let me\n>> risk a naive statement here. If \"a-b-c-M\" were 'master',\n>> and \"d-e-f\" were 'new-feature', then on April 1st the\n>> current version on 'master' is 'b', because I merged the\n>> 'new-feature' branch at a later point in time. Does that\n>> make sense?\n> \n> O! for the love all that is Holy!\n> \n> You see, guys? The term `branch' was a TERRIBLE choice.\n> \n> What git calls `branch master' in your example is just a pointer to\n> the commit object `M'; it has nothing to do with particular lineages\n> like `a-b-c-M'.\n> \n\nBack in 2005 when git was young and fresh, there was a discussion about\nwhat to call things. If memory serves (which it might not), I think\nthe consensus was that \"branch\" works just fine, and when someone who\ndoesn't like it comes along we can just tell them that it's short for\n\"tip-of-branch pointer\", which is far more accurate. A \"ref\" is always\nlocal though, which is why the reflog (which is used for such date\nresolving problems) is never even considered to work on remote refs.\nThey *can* work on remotes' refs though, which is a slightly different\nthing.\n\nWhatever, really. The fact that pretty much everyone seems to know\nwhat a branch is and how it works in git after a (very) brief intro\nto it means it's either right on target or that people are so used to\nthe fact that branch means something different in every scm that they\ndon't even bother loading the word with some preconceived notion that\nused to be right in cvs.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"174162","messageId":"86vctm24le.fsf@red.stonehenge.com","threadId":"28191","inReplyTo":"4E551BC3.8080701@op5.se","subject":"Re: How to check out the repository at a particular point in time","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2011-08-24T15:48:13Z","receivedAt":"2011-08-24T15:48:13Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Andreas\" == Andreas Ericsson <ae@op5.se> writes:\n\nAndreas> Whatever, really. The fact that pretty much everyone seems to know\nAndreas> what a branch is and how it works in git after a (very) brief intro\nAndreas> to it means it's either right on target or that people are so used to\nAndreas> the fact that branch means something different in every scm that they\nAndreas> don't even bother loading the word with some preconceived notion that\nAndreas> used to be right in cvs.\n\nIt does lead to confusion though, and once you *really* understand that\na branch is a point, not a line, you can do a lot more cool things with\ngit, and rebase and stash make a lot more sense.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"174165","messageId":"CAMOZ1Bs59Hqoi3d0uxg1bey=_6cYu5+U5gWmz14V97_YFteSuA@mail.gmail.com","threadId":"28191","inReplyTo":"86vctm24le.fsf@red.stonehenge.com","subject":"Re: How to check out the repository at a particular point in time","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-24T16:18:55Z","receivedAt":"2011-08-24T16:18:55Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Aug 24, 2011 at 15:48, Randal L. Schwartz <merlyn@stonehenge.com> wrote:\n>>>>>> \"Andreas\" == Andreas Ericsson <ae@op5.se> writes:\n>\n> Andreas> Whatever, really. The fact that pretty much everyone seems to know\n> Andreas> what a branch is and how it works in git after a (very) brief intro\n> Andreas> to it means it's either right on target or that people are so used to\n> Andreas> the fact that branch means something different in every scm that they\n> Andreas> don't even bother loading the word with some preconceived notion that\n> Andreas> used to be right in cvs.\n>\n> It does lead to confusion though, and once you *really* understand that\n> a branch is a point, not a line, you can do a lot more cool things with\n> git, and rebase and stash make a lot more sense.\n\nIndeed. I don't think Andreas is correct in the assertion that\n\"everyone seems to know what a branch is and how it works in git after\na (very) brief intro\". Rather, I think it is just the case that\neveryone seems to know how to use the basic public interface for\nbranches after a (very) brief intro, and that many tasks allow\neveryone to get away with having wrongheaded ideas.\n"}]}