{"thread":{"id":"28199","subject":"Re: How to check out the repository at a particular point in time","startedAt":"2011-08-23T07:41:08Z","lastAt":"2011-08-23T20:30:58Z","messageCount":4,"participants":["R. Diez","Thomas Rast","PJ Weisberg","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174079","messageId":"1314085268.42103.YahooMailClassic@web25406.mail.ukl.yahoo.com","threadId":"28199","inReplyTo":null,"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-23T07:41:08Z","receivedAt":"2011-08-23T07:41:08Z","isPatch":false,"sender":{"key":"rdiezmail-temp2@yahoo.de","avatar":null},"body":"\n> \"master\" is nothing more than a pointer to a\n> particular commit.  The commit has references\n> to its parent(s), from which you can build a\n> whole history.  In general, Git doesn't\n> know the name of the branch a developer had\n> checked out when a commit was created.\n> In fact, in this example, both branches\n> could have been called \"master\" if they\n> lived in different developers' workspaces.\n\nI understand. However, let's see if git can cope with this pretty common scenario:\n\nSay I'm a developer with too many projects and little time. I don't really want to find the commit ID at each release and manually make a note on the project's web site. In fact, I have no \"official\" releases. The \"contract\" with my users (or co-developers in my team) is simple: check out HEAD, it should always work. If it doesn't, last week it worked well, check out at that point in time and wait until I fix the HEAD.\n\nNow you're saying I cannot reliably checkout last week's versions because yesterday I did a merge from an older branch? You mean that git stores everything with clean graphs and numeric pointers, so it cannot know what this repository looked like last week?\n\nAs the developer, I have full control, I can decide what the branches are called and how the public repository is updated/pushed/whatever. I can control the clock so there are no time skews.\n\nWhat do I have to do in order to be able to reliably checkout last week's versions without too much administrative work? I just want to get the same result today as if I had done a checkout last week from the public repository and had made a back-up copy of the working directory then.\n\nWith say CVS and Subversion, that's piece of cake, they already work that way, I don't need to manually keep track of revision IDs or visually inspect the merge tree.\n\nThanks for your answers,\n R. Diez\n"},{"id":"174081","messageId":"201108231117.00314.trast@student.ethz.ch","threadId":"28199","inReplyTo":"1314085268.42103.YahooMailClassic@web25406.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-23T09:17:00Z","receivedAt":"2011-08-23T09:17:00Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"R. Diez wrote:\n> \n> check out HEAD, it should always work\n\nPlease stop using HEAD like this, you'll just confuse your coworkers\n(and yourself). HEAD denotes the currently checked out commit.\n[Unlike SVN it is *not* the most recent version of anything.] Thus by\ndefinition, 'git checkout HEAD' is a no-op.\n\nThe newest commit on a branch is denoted by its branch name, because\nas Jens said, a branch is in fact a pointer to its tip[1] commit.\n\n> Now you're saying I cannot reliably checkout last week's versions\n> because yesterday I did a merge from an older branch? You mean that\n> git stores everything with clean graphs and numeric pointers, so it\n> cannot know what this repository looked like last week?\n\nIndeed. Especially if forced pushes are allowed, there is no way to\nknow what was in the repo at a given time unless you have (local)\nreflogs enabled on remote branches and going back until the time you\nwant.\n\n> As the developer, I have full control, I can decide what the\n> branches are called and how the public repository is\n> updated/pushed/whatever. I can control the clock so there are no\n> time skews.\n> \n> What do I have to do in order to be able to reliably checkout last\n> week's versions without too much administrative work? I just want to\n> get the same result today as if I had done a checkout last week from\n> the public repository and had made a back-up copy of the working\n> directory then.\n\nAssuming\n\n* you never do a non-fast-forward (i.e., forced) push\n* you never have any clock skew\n* you always merge features into master (not the other way around)\n* you always push immediately after committing on master\n\nyou can get there by using 'git log -1 --first-parent --until=...'\nas mentioned in my first email.\n\nI personally think that's crazy and -- if you want to avoid the work\nof \"really\" using submodules -- support Jens's suggestion of having\nthe buildbot automatically assemble an \"I tested this\" superproject.\n\n\n\n[1] or \"head\" in lowercase (thus \"branch head\"), but I prefer tip to\navoid confusion\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"174084","messageId":"CAJsNXTk0LaSDKCOzJgZRLYmGe8hauPbPOw4oKLKP0Xr0axZkwg@mail.gmail.com","threadId":"28199","inReplyTo":"201108231117.00314.trast@student.ethz.ch","subject":"Re: How to check out the repository at a particular point in time","fromName":"PJ Weisberg","fromEmail":"pjweisberg@gmail.com","sentAt":"2011-08-23T10:04:35Z","receivedAt":"2011-08-23T10:04:35Z","isPatch":false,"sender":{"key":"pjweisberg@gmail.com","avatar":"https://gravatar.com/avatar/e585568071f361126c42f73b11bee72fc6d4bdfea34be29faa52e621da3517eb?d=mp&s=160"},"body":"On Tue, Aug 23, 2011 at 2:17 AM, Thomas Rast wrote:\n\n> I personally think that's crazy and -- if you want to avoid the work\n> of \"really\" using submodules -- support Jens's suggestion of having\n> the buildbot automatically assemble an \"I tested this\" superproject.\n\nOr create a tag in each separate repository, using the same tag name\nto indicate versions that were tested together. Or you could do the\nsame with a branch, since a branch is basically a tag that moves. You\nwould just have to make sure only the buildbot updated that branch.\n\n-PJ\n"},{"id":"174119","messageId":"4E540E02.1060201@web.de","threadId":"28199","inReplyTo":"CAJsNXTk0LaSDKCOzJgZRLYmGe8hauPbPOw4oKLKP0Xr0axZkwg@mail.gmail.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-23T20:30:58Z","receivedAt":"2011-08-23T20:30:58Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 23.08.2011 12:04, schrieb PJ Weisberg:\n> On Tue, Aug 23, 2011 at 2:17 AM, Thomas Rast wrote:\n> \n>> I personally think that's crazy and -- if you want to avoid the work\n>> of \"really\" using submodules -- support Jens's suggestion of having\n>> the buildbot automatically assemble an \"I tested this\" superproject.\n> \n> Or create a tag in each separate repository, using the same tag name\n> to indicate versions that were tested together. Or you could do the\n> same with a branch, since a branch is basically a tag that moves. You\n> would just have to make sure only the buildbot updated that branch.\n\nThat would also work, but it might need some scripting. Probably having\nsome server side hooks to enforce the policy allowing no-one except the\nbuildbot to change those branches/tags would help here. Also submodules\nwould make it easier to see when they differ from the commits recorded\nin the superproject, so a script running something like \"git describe\"\nin all local repos and displaying the results might be a good idea to\nget that information.\n"}]}