{"thread":{"id":"28143","subject":"Branches & directories","startedAt":"2011-08-17T18:35:55Z","lastAt":"2011-10-03T17:31:20Z","messageCount":52,"participants":["Hilco Wijbenga","Evan Shelhamer","Junio C Hamano","Jonathan Nieder","Michael Witten","Michael J Gruber","Kyle Moffett","Enrico Weigelt","Robin Rosenberg","Ronan Keryell","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173683","messageId":"CAE1pOi3Eg88i+1s+CcW3+W0WNZ-NYUQb1EV55oh+g1Od78AByQ@mail.gmail.com","threadId":"28143","inReplyTo":null,"subject":"Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-17T18:35:55Z","receivedAt":"2011-08-17T18:35:55Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi all,\n\nI have been noticing strange behaviour that I would like to be able to\nexplain or report as a bug as the case may be.\n\nWhat happens is that I create and commit a new directory in branch\n'next' and then when I checkout 'master' this new directory is still\nthere. I think this is wrong as this new directory does not exist yet\nin 'master'. Is my understanding correct?\n\nI tried recreating this scenario in a clean Git repo with a simple\nmkdir and commit but when I did a checkout of 'master' the new\ndirectory was removed. So the basic scenario seems to work the way I\nexpect it to.\n\nAssuming I ran into a bug, I would like some suggestions to properly\ninvestigate this. Clearly, I'm doing something else that triggers the\nbehaviour I'm seeing but I'm not sure what it is. What might trigger\nGit \"remembering\" a directory? Or what would prevent it from removing\na directory when checking out a different branch?\n\nExtra information: \"git status\" (in 'master') yields nothing. But\nafter adding a new file in the directory-that-should-not-be-there, Git\ntreats the entire directory as untracked and new (as one would\nexpect). I can also safely remove the directory with no (obvious) ill\neffects.\n\nCheers,\nHilco\n"},{"id":"173686","messageId":"CABNdCrCbSqup1=D2eEbGDhw3JzZGYHWLVqZFsB6GDO4Vk7HRxg@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi3Eg88i+1s+CcW3+W0WNZ-NYUQb1EV55oh+g1Od78AByQ@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Evan Shelhamer","fromEmail":"shelhamer@imaginarynumber.net","sentAt":"2011-08-17T18:47:02Z","receivedAt":"2011-08-17T18:47:02Z","isPatch":false,"sender":{"key":"shelhamer@imaginarynumber.net","avatar":null},"body":"Hey Hilco,\n\nI'm not sure exactly what you did because you didn't give a list of\ngit commands, but I'm guessing you ran into the fact that git doesn't\ntrack empty directories.\nFor instance if I do:\n\n(in repo on your branch)\nmkdir test_dir\ntouch test_file\ngit add *\ngit commit -m \"test commit\"\n\ntest_file will be tracked but test_dir will not (because it is empty).\nTo avoid this problem, a convention is to add an empty \".gitkeep\" file\nto directories. For example:\n\n(in repo on your branch)\nmkdir test_dir\ntouch test_dir/.gitkeep\ntouch test_file\ngit add *\ngit commit -m \"test commit (with directory)\"\n\nWill commit the directory as expected in your branch, and when you go\nto checkout another branch it will not exist.\n\nHope that helps. Sorry if you already know this and I misunderstood\nyour question.\nEvan Shelhamer\n\nOn Wed, Aug 17, 2011 at 2:35 PM, Hilco Wijbenga\n wrote:\n> Hi all,\n>\n> I have been noticing strange behaviour that I would like to be able to\n> explain or report as a bug as the case may be.\n>\n> What happens is that I create and commit a new directory in branch\n> 'next' and then when I checkout 'master' this new directory is still\n> there. I think this is wrong as this new directory does not exist yet\n> in 'master'. Is my understanding correct?\n>\n> I tried recreating this scenario in a clean Git repo with a simple\n> mkdir and commit but when I did a checkout of 'master' the new\n> directory was removed. So the basic scenario seems to work the way I\n> expect it to.\n>\n> Assuming I ran into a bug, I would like some suggestions to properly\n> investigate this. Clearly, I'm doing something else that triggers the\n> behaviour I'm seeing but I'm not sure what it is. What might trigger\n> Git \"remembering\" a directory? Or what would prevent it from removing\n> a directory when checking out a different branch?\n>\n> Extra information: \"git status\" (in 'master') yields nothing. But\n> after adding a new file in the directory-that-should-not-be-there, Git\n> treats the entire directory as untracked and new (as one would\n> expect). I can also safely remove the directory with no (obvious) ill\n> effects.\n>\n> Cheers,\n> Hilco\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"173688","messageId":"7vvctvdf5r.fsf@alter.siamese.dyndns.org","threadId":"28143","inReplyTo":"CABNdCrCbSqup1=D2eEbGDhw3JzZGYHWLVqZFsB6GDO4Vk7HRxg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-17T19:14:08Z","receivedAt":"2011-08-17T19:14:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Evan Shelhamer writes:\n\n> (in repo on your branch)\n> mkdir test_dir\n> touch test_dir/.gitkeep\n> touch test_file\n> git add *\n> git commit -m \"test commit (with directory)\"\n>\n> Will commit the directory as expected in your branch, and when you go\n> to checkout another branch it will not exist.\n\n... unless you have untracked files in test_dir/, that is.\n\nIf the branch you are switching to does not have anything at test_dir, you\nwill not lose the untracked file because git does not remove test_dir/ nor\nits untracked contents.\n\nDepending on what you have at the path \"test_dir\" in the branch you are\nswitching to, the actual rules are a bit more subtle than that, though.\n"},{"id":"173696","messageId":"CAE1pOi3rqqcz_6QxB8=g2jWOF-4SRZee7t8NXN1md2C4DL7wug@mail.gmail.com","threadId":"28143","inReplyTo":"7vvctvdf5r.fsf@alter.siamese.dyndns.org","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-17T21:23:51Z","receivedAt":"2011-08-17T21:23:51Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 17 August 2011 12:14, Junio C Hamano wrote:\n> Evan Shelhamer writes:\n>\n>> (in repo on your branch)\n>> mkdir test_dir\n>> touch test_dir/.gitkeep\n>> touch test_file\n>> git add *\n>> git commit -m \"test commit (with directory)\"\n>>\n>> Will commit the directory as expected in your branch, and when you go\n>> to checkout another branch it will not exist.\n>\n> ... unless you have untracked files in test_dir/, that is.\n>\n> If the branch you are switching to does not have anything at test_dir, you\n> will not lose the untracked file because git does not remove test_dir/ nor\n> its untracked contents.\n>\n> Depending on what you have at the path \"test_dir\" in the branch you are\n> switching to, the actual rules are a bit more subtle than that, though.\n\nYes, I should have thought of that. The problem is with .gitignore. I\nhave a number of files ignored that are important but can't be shared.\nSo when I switch to 'master' the directory is not removed because it\ncontains untracked, ignored files. And, of course, git status does not\ncomplain about them either because they are in .gitignore. :-)\n\nThis is still very annoying but hardly Git's fault (Git is working as\nintended). It would be really nice, though, if Git could somehow\n\"stash\" such files when checking out a different branch. In general, I\nwould prefer if uncommitted changes and untracked and/or ignored files\nstuck to the branch where they were created. If I want to take them\nwith me when I switch branches that should be possible but not the\ndefault behaviour. Is anything like that possible? Are there\nconfiguration options for this?\n"},{"id":"173715","messageId":"20110818044555.GA20752@elie.gateway.2wire.net","threadId":"28143","inReplyTo":"CAE1pOi3rqqcz_6QxB8=g2jWOF-4SRZee7t8NXN1md2C4DL7wug@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-18T04:45:55Z","receivedAt":"2011-08-18T04:45:55Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Hilco,\n\nHilco Wijbenga wrote:\n\n> It would be really nice, though, if Git could somehow\n> \"stash\" such files when checking out a different branch. In general, I\n> would prefer if uncommitted changes and untracked and/or ignored files\n> stuck to the branch where they were created.\n\nThis is just a random guess, but: wouldn't it be convenient in this\nworkflow to have a separate worktree for each branch you are working\non? That way, switching branches would not carry over unwanted state\nor throw away valuable state, clobber timestamps that \"make\" pays\nattention to, etc.\n\nIf I am understanding correctly, then the git-new-workdir script\nfrom contrib/workdir might help. (Note, though, that it comes with\nsome caveats. A quick mailing list search should find them.)\n"},{"id":"173727","messageId":"CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi3rqqcz_6QxB8=g2jWOF-4SRZee7t8NXN1md2C4DL7wug@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-18T05:52:02Z","receivedAt":"2011-08-18T05:52:02Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga wrote:\n> It would be really nice, though, if Git could somehow\n> \"stash\" such files when checking out a different branch. In general, I\n> would prefer if uncommitted changes and untracked and/or ignored files\n> stuck to the branch where they were created.\n\nAs an aside, the problem here is likely a manifestation of the fact\nthat nobody understands what a branch is; the word 'branch' is\nTERRIBLE, as everyone has a different idea for what that should mean.\nIn my opinion, `git branch' should become `git ref' or the like.\n\nOne of git's worst faults is that a complicated and imprecise\ninterface has been draped over a very simple and precise underlying\nstructure.\n"},{"id":"173747","messageId":"4E4CEFDA.9000703@drmicha.warpmail.net","threadId":"28143","inReplyTo":"CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-08-18T10:56:26Z","receivedAt":"2011-08-18T10:56:26Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael Witten venit, vidit, dixit 18.08.2011 07:52:\n> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga wrote:\n>> It would be really nice, though, if Git could somehow\n>> \"stash\" such files when checking out a different branch. In general, I\n>> would prefer if uncommitted changes and untracked and/or ignored files\n>> stuck to the branch where they were created.\n> \n> As an aside, the problem here is likely a manifestation of the fact\n> that nobody understands what a branch is; the word 'branch' is\n\nI would reject \"nobody\"...\n\n> TERRIBLE, as everyone has a different idea for what that should mean.\n\n... and insist that this statement is true either trivially true for all\nwords, or for none, depending on your understanding of \"everyone has a\ndifferent\".\n\n> In my opinion, `git branch' should become `git ref' or the like.\n\n\"branch\" and \"tag\" are boths refs. Their only essential difference is\nthat one \"moves\" and the other doesn't.\n\n> One of git's worst faults is that a complicated and imprecise\n> interface has been draped over a very simple and precise underlying\n> structure.\n\nA name is a name and just that. The use of any existing word may clash\nwith someone's expectations.\n\nI find the concepts \"file created on a branch\", \"commit created on a\nbranch\" silly, it's part of what drove me from hg to git early on. A git\n\"branch\" is an hg \"bookmark\" these days (a named \"head\"), and if that\nname triggers the right associations for some people, its best used in\nexplanations for those. git's branches do exactly what I (and many\nothers) expect branches to do and what I need daily, even coming from a\nsvn and hg background.\n\nMichael\n"},{"id":"173766","messageId":"CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com","threadId":"28143","inReplyTo":"4E4CEFDA.9000703@drmicha.warpmail.net","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-18T17:49:35Z","receivedAt":"2011-08-18T17:49:35Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Aug 18, 2011 at 10:56, Michael J Gruber\n wrote:\n> Michael Witten venit, vidit, dixit 18.08.2011 07:52:\n>> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga wrote:\n>>> It would be really nice, though, if Git could somehow\n>>> \"stash\" such files when checking out a different branch. In general, I\n>>> would prefer if uncommitted changes and untracked and/or ignored files\n>>> stuck to the branch where they were created.\n>>\n>> As an aside, the problem here is likely a manifestation of the fact\n>> that nobody understands what a branch is; the word 'branch' is\n>\n> I would reject \"nobody\"...\n\nIs it really necessary to attack something that is obviously\nhyperbolic rhetoric? The point is that a lot of people struggle with\ngit's concepts, and I think that the reason is largely two fold:\n\n * Terminology that is inaccurate by virtue of terminological baggage.\n * Terminology that is imprecisely used across the documentation.\n\n>> TERRIBLE, as everyone has a different idea for what that should mean.\n>\n> ... and insist that this statement is true either trivially true for all\n> words, or for none, depending on your understanding of \"everyone has a\n> different\".\n\nSo, precision is impossible?\n\nThe word 'branch' is clearly a sticking point, and you know it. You\ncan't deny that people have a hard time with what a branch really is\nin git.\n\n>> In my opinion, `git branch' should become `git ref' or the like.\n>\n> \"branch\" and \"tag\" are boths refs. Their only essential difference is\n> that one \"moves\" and the other doesn't.\n\nIndeed, and it seems like there's room for abstraction; a tool like\n`git ref' or `git pointer' or `git ptr' could probably handle both\nquite well.\n\nTerminology for references is a problem that was solved by the\nAncients, so it's a wonder we didn't use their work (pointers,\nconstant pointers, dereferencing, etc.).\n\n>> One of git's worst faults is that a complicated and imprecise\n>> interface has been draped over a very simple and precise underlying\n>> structure.\n>\n> A name is a name and just that. The use of any existing word may clash\n> with someone's expectations.\n\nYeah? So why wasn't the term 'foobar' used instead of 'branch'? Most\nterms are chosen for their associations (and only really novel\nconcepts receive an entirely new label), and I proffer that 'branch'\nhas too many associations to be considered accurate enough.\n\nThe idea was that one line of development can 'branch' off from\nanother, so it was called a 'branch'. But what is a line of\ndevelopment? (merges certainly make the concept fuzzy; tree branches\nusually don't join with the tree trunk again). The thing is, though,\nwhen you're working with what git calls a 'branch', you're really just\nworking with a pointer to a commit object; the term 'pointer' would\nhave been much more accurate.\n\nNow, I'm not saying we should be using 'pointer', but what I am saying\nis that it's necessary to choose words carefully, preferably in a way\nthat carries just enough associations to aid the user in remembering\nwhat a term describes.\n\n> I find the concepts \"file created on a branch\", \"commit created on a\n> branch\" silly, it's part of what drove me from hg to git early on.\n\nThere's no shortage of that kind of thinking in the git community,\nwhich is my point. The reason is a failure of both accurate\nterminology and precise usage.\n\n> git's branches do exactly what I (and many others) expect branches\n> to do and what I need daily, even coming from a svn and hg background.\n\nYes, well, many figure it out EVENTUALLY; it just requires them to\nignore most of the associations of 'branch', thereby tacitly\ntranslating the word 'branch' into 'pointer'.\n"},{"id":"173823","messageId":"20110819001301.GA32743@elie.gateway.2wire.net","threadId":"28143","inReplyTo":"CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-19T00:13:01Z","receivedAt":"2011-08-19T00:13:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Michael,\n\nMichael Witten wrote:\n\n> As an aside, the problem here is likely a manifestation of the fact\n> that nobody understands what a branch is\n\nI agree with Michael J Gruber that this is not the useful kind of\nhyperbole.\n\nIn olden times, there was more talk of the refs in the refs/heads/\nhierarchy as being branch heads which point to the tip of a particular\nbranch of history. That is still exactly what they are. By abuse of\nlanguage, people sometimes use the term \"branch\" as a synonym when\nthere is little risk of confusion.\n\nIf you have found tutorial documentation that is confusing on this\npoint, by all means, fix it. You are talking as though a\ndocumentation bug is a fundamental design flaw that cannot be fixed by\nthe likes of you and me.\n"},{"id":"173965","messageId":"CAE1pOi3F8SxJLhg5bzWNoH_3Bg4vHh7BEoJWW6Em9GvPaoxTVw@mail.gmail.com","threadId":"28143","inReplyTo":"20110818044555.GA20752@elie.gateway.2wire.net","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-21T19:48:32Z","receivedAt":"2011-08-21T19:48:32Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi Jonathan,\n\nOn 17 August 2011 21:45, Jonathan Nieder wrote:\n> Hi Hilco,\n>\n> Hilco Wijbenga wrote:\n>\n>> It would be really nice, though, if Git could somehow\n>> \"stash\" such files when checking out a different branch. In general, I\n>> would prefer if uncommitted changes and untracked and/or ignored files\n>> stuck to the branch where they were created.\n>\n> This is just a random guess, but: wouldn't it be convenient in this\n> workflow to have a separate worktree for each branch you are working\n> on?  That way, switching branches would not carry over unwanted state\n> or throw away valuable state, clobber timestamps that \"make\" pays\n> attention to, etc.\n>\n> If I am understanding correctly, then the git-new-workdir script\n> from contrib/workdir might help.  (Note, though, that it comes with\n> some caveats.  A quick mailing list search should find them.)\n\nYes, both a separate clone and git-new-workdir (which I've just\nstarted using) would work.\n\nI'm not entirely happy with this solution, though. It means having to\ncreate an Eclipse workspace per branch, this is a *lot* of work. (This\nis mostly Eclipse's fault but still.) One of the exceedingly\nattractive features of Git is the easy branching and merging.\nBranching is now no longer easy. :-(\n\nI assume it would be possible for Git to move untracked/ignored files\nout of the way when checking out a different branch? (And moving them\nback in when going back to that branch.) Are there any objections to\ndoing this? I.e. would it be a bad idea for some reason?\n\nSo, in essence, would it be possible (and desirable) to associate\nuntracked/ignored files with a particular branch? And only show them\nwhen that branch is checked out?\n"},{"id":"173966","messageId":"CAE1pOi2r9DT3Y-GxivTZRaNVi=qLOy5=QpQ-_YysOkgqy3iGRQ@mail.gmail.com","threadId":"28143","inReplyTo":"CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-21T20:25:38Z","receivedAt":"2011-08-21T20:25:38Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 17 August 2011 22:52, Michael Witten wrote:\n> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga wrote:\n>> It would be really nice, though, if Git could somehow\n>> \"stash\" such files when checking out a different branch. In general, I\n>> would prefer if uncommitted changes and untracked and/or ignored files\n>> stuck to the branch where they were created.\n>\n> As an aside, the problem here is likely a manifestation of the fact\n> that nobody understands what a branch is; the word 'branch' is\n> TERRIBLE, as everyone has a different idea for what that should mean.\n> In my opinion, `git branch' should become `git ref' or the like.\n\nAre you saying that Git's branches are different from branches in\nother SCMs? How does my understanding of \"branch\" hinder me in the\nabove scenario? Am I doing something wrong?\n\nIsn't a branch simply a way to track changes separately?\n"},{"id":"173968","messageId":"CAMOZ1BvpnP_729YOHrrPW3B8wa5c4cLyD_qAQ5rTuy0JqNiiXg@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi2r9DT3Y-GxivTZRaNVi=qLOy5=QpQ-_YysOkgqy3iGRQ@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-21T20:53:42Z","receivedAt":"2011-08-21T20:53:42Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n wrote:\n> Isn't a branch simply a way to track changes separately?\n\nWell, what does that mean, really? You can certainly use branches to\nhelp you achieve that goal.\n\nIn git usage, a `branch' is just a human-readable name for any given\ncommit object; it points to a commit object, and you can change to\nwhich commit it points. Furthermore, to help you work with commit\nlineages, some of the git machinery updates these branches (or\n`pointers', if you like) automatically (for instance, when you make a\nnew commit object with `git commit', then the `current branch' is\nupdated to point to the newly created commit object).\n\nOf course, 2 different branches may be used to point to the same commit object.\n\nYou should really think of your repository as a giant web of commit\nobjects (or, more technically, as a directed acyclic graph where each\nnode is a commit object); a commit object can point 'backwards'\ntowards its parent commit objects. A branch (like `master') just\npoints to one of these commit objects at any given time (that is, a\nbranch just gives a nice human-readable label by which to reference\none of these commit objects at any given time).\n\nSee here too:\n\n http://slashdot.org/comments.pl?sid=2350536&cid=36903136\n"},{"id":"173971","messageId":"CAE1pOi3OEFg7-OeQM0fvD69gf-5oPQ239CGy9nN0Waas8EM3Bg@mail.gmail.com","threadId":"28143","inReplyTo":"CAMOZ1BvpnP_729YOHrrPW3B8wa5c4cLyD_qAQ5rTuy0JqNiiXg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-21T21:37:47Z","receivedAt":"2011-08-21T21:37:47Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 13:53, Michael Witten wrote:\n> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n> wrote:\n>> Isn't a branch simply a way to track changes separately?\n>\n> Well, what does that mean, really? You can certainly use branches to\n> help you achieve that goal.\n\nIt means my commits are chained together separate from, say, master.\n\n> In git usage, a `branch' is just a human-readable name for any given\n> commit object; it points to a commit object, and you can change to\n> which commit it points. Furthermore, to help you work with commit\n> lineages, some of the git machinery updates these branches (or\n> `pointers', if you like) automatically (for instance, when you make a\n> new commit object with `git commit', then the `current branch' is\n> updated to point to the newly created commit object).\n>\n> Of course, 2 different branches may be used to point to the same commit object.\n>\n> You should really think of your repository as a giant web of commit\n> objects (or, more technically, as a directed acyclic graph where each\n> node is a commit object); a commit object can point 'backwards'\n> towards its parent commit objects. A branch (like `master') just\n> points to one of these commit objects at any given time (that is, a\n> branch just gives a nice human-readable label by which to reference\n> one of these commit objects at any given time).\n\nYes, I agree with all of that (especially the last sentence). I don't\nsee how it changes the concept of a branch is, though. You are, I\nthink, simply listing the technical implementation.\n\n> See here too:\n>\n>  http://slashdot.org/comments.pl?sid=2350536&cid=36903136\n\nBecause of the revision number you have to go \"the wrong way\". Any\nsingle commit can have many children but a branch only points to a\nsingle, unique commit (or at least that's how I understand it).\n\nI feel like we're talking in circles. I get (and even agree with) what\nyou're saying but I don't see how it changes the concept of a branch.\n\nIn any case, what I'm more interested in is knowing whether we can\n(optionally) add state (i.e. untracked/ignored files and unstaged\nchanges) to a branch.\n"},{"id":"173976","messageId":"CAMOZ1BvHKTPPmfB7Jx+y4OeRv-uwjmQkscXaRr-vEEy30G_Kdw@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi3OEFg7-OeQM0fvD69gf-5oPQ239CGy9nN0Waas8EM3Bg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-21T23:06:16Z","receivedAt":"2011-08-21T23:06:16Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n> On 21 August 2011 13:53, Michael Witten wrote:\n>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>> wrote:\n>>> Isn't a branch simply a way to track changes separately?\n>>\n>> Well, what does that mean, really? You can certainly use branches to\n>> help you achieve that goal.\n>\n> It means my commits are chained together separate from, say, master.\n\nWell, that's not what a git branch provides in general.\n\n>> In git usage, a `branch' is just a human-readable name for any given\n>> commit object; it points to a commit object, and you can change to\n>> which commit it points. Furthermore, to help you work with commit\n>> lineages, some of the git machinery updates these branches (or\n>> `pointers', if you like) automatically (for instance, when you make a\n>> new commit object with `git commit', then the `current branch' is\n>> updated to point to the newly created commit object).\n>>\n>> Of course, 2 different branches may be used to point to the same commit object.\n>>\n>> You should really think of your repository as a giant web of commit\n>> objects (or, more technically, as a directed acyclic graph where each\n>> node is a commit object); a commit object can point 'backwards'\n>> towards its parent commit objects. A branch (like `master') just\n>> points to one of these commit objects at any given time (that is, a\n>> branch just gives a nice human-readable label by which to reference\n>> one of these commit objects at any given time).\n>\n> Yes, I agree with all of that (especially the last sentence). I don't\n> see how it changes the concept of a branch is, though. You are, I\n> think, simply listing the technical implementation.\n\nNo, I'm simply listing the reality of what a branch is.\n\n> ...\n>\n> I feel like we're talking in circles. I get (and even agree with) what\n> you're saying but I don't see how it changes the concept of a branch.\n>\n> In any case, what I'm more interested in is knowing whether we can\n> (optionally) add state (i.e. untracked/ignored files and unstaged\n> changes) to a branch.\n\nNo, because a branch doesn't IN ANY WAY provide the structure for that\nkind of thing. Of course, you could use what git calls a 'branch' in\norder to implement what you imply is a 'branch', but git's concept of\na branch and your concept of a branch are not at all the same concept\n(which is why the term 'branch' is so unfortunate).\n"},{"id":"173977","messageId":"CAE1pOi0b2w8t53U7PSvVwVxZF9O0HTyfCR4vy+-baBjqCDeNJA@mail.gmail.com","threadId":"28143","inReplyTo":"CAMOZ1BvHKTPPmfB7Jx+y4OeRv-uwjmQkscXaRr-vEEy30G_Kdw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-21T23:35:44Z","receivedAt":"2011-08-21T23:35:44Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 16:06, Michael Witten wrote:\n> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n>> On 21 August 2011 13:53, Michael Witten wrote:\n>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>>> wrote:\n>>>> Isn't a branch simply a way to track changes separately?\n>>>\n>>> Well, what does that mean, really? You can certainly use branches to\n>>> help you achieve that goal.\n>>\n>> It means my commits are chained together separate from, say, master.\n>\n> Well, that's not what a git branch provides in general.\n\nEr, so what *does* a Git branch provide then?\n\n>> I feel like we're talking in circles. I get (and even agree with) what\n>> you're saying but I don't see how it changes the concept of a branch.\n>>\n>> In any case, what I'm more interested in is knowing whether we can\n>> (optionally) add state (i.e. untracked/ignored files and unstaged\n>> changes) to a branch.\n>\n> No, because a branch doesn't IN ANY WAY provide the structure for that\n> kind of thing.\n\nObviously, we'd need to expand that structure.\n\nI tried (ab)using git stash to get what I want but it ignores\nuntracked/ignored files (not a big surprise, of course). It seems the\nfunctionality is almost there. If I could just combine git checkout\nwith git stash (and have it work with untracked/ignored files) in a\nscript or alias, I'd be a happy camper. I'll have to give it some more\nthought.\n\n> Of course, you could use what git calls a 'branch' in\n> order to implement what you imply is a 'branch', but git's concept of\n> a branch and your concept of a branch are not at all the same concept\n> (which is why the term 'branch' is so unfortunate).\n\nYou've completely lost me. You may very well be right but all I see is\nthat you're pointing out how branches are implemented in Git.\n"},{"id":"173980","messageId":"CAMOZ1BtOkwVbC3RyJVQb7K1DRMnJf3_omn7zrkzoE48Ayu7HBg@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi0b2w8t53U7PSvVwVxZF9O0HTyfCR4vy+-baBjqCDeNJA@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-22T00:07:44Z","receivedAt":"2011-08-22T00:07:44Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga wrote:\n> On 21 August 2011 16:06, Michael Witten wrote:\n>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n>>> On 21 August 2011 13:53, Michael Witten wrote:\n>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>>>> wrote:\n>>>>> Isn't a branch simply a way to track changes separately?\n>>>>\n>>>> Well, what does that mean, really? You can certainly use branches to\n>>>> help you achieve that goal.\n>>>\n>>> It means my commits are chained together separate from, say, master.\n>>\n>> Well, that's not what a git branch provides in general.\n>\n> Er, so what *does* a Git branch provide then?\n\nI think my other replies (including the link) repeat myself quite enough.\n\nA branch is just a pointer. That's it.\n\nQuit saying `branch' to yourself. Start saying `pointer' or\n`reference' or `commit label' or even `special tag'.\n\n>>> I feel like we're talking in circles. I get (and even agree with) what\n>>> you're saying but I don't see how it changes the concept of a branch.\n>>>\n>>> In any case, what I'm more interested in is knowing whether we can\n>>> (optionally) add state (i.e. untracked/ignored files and unstaged\n>>> changes) to a branch.\n>>\n>> No, because a branch doesn't IN ANY WAY provide the structure for that\n>> kind of thing.\n>\n> Obviously, we'd need to expand that structure.\n>\n> I tried (ab)using git stash to get what I want but it ignores\n> untracked/ignored files (not a big surprise, of course). It seems the\n> functionality is almost there. If I could just combine git checkout\n> with git stash (and have it work with untracked/ignored files) in a\n> script or alias, I'd be a happy camper. I'll have to give it some more\n> thought.\n\nThis cobbling together of git's components for this purpose is\nactually a fairly frequent story on this list. Either git does indeed\nneed something more substantial as a `branch', or people (meaning you)\nneed to change the way they think (and I'm not sure which solution\nwould be best, honestly).\n\nIf there is a change, then what is currently called a `branch' should\nbe renamed explicitly to `pointer' or a `reference' or something like\nthat.\n\n>> Of course, you could use what git calls a 'branch' in\n>> order to implement what you imply is a 'branch', but git's concept of\n>> a branch and your concept of a branch are not at all the same concept\n>> (which is why the term 'branch' is so unfortunate).\n>\n> You've completely lost me. You may very well be right but all I see is\n> that you're pointing out how branches are implemented in Git.\n\nThat last sentence and your earlier sentence:\n\n> Obviously, we'd need to expand that structure.\n\nvindicate everything I've said about the choice of nomenclature. The\nterm `branch' is a TERRIBLE choice.\n"},{"id":"173984","messageId":"CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com","threadId":"28143","inReplyTo":"CAMOZ1BtOkwVbC3RyJVQb7K1DRMnJf3_omn7zrkzoE48Ayu7HBg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T00:47:12Z","receivedAt":"2011-08-22T00:47:12Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 17:07, Michael Witten wrote:\n> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga wrote:\n>> On 21 August 2011 16:06, Michael Witten wrote:\n>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n>>>> On 21 August 2011 13:53, Michael Witten wrote:\n>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>>>>> wrote:\n>>>>>> Isn't a branch simply a way to track changes separately?\n>>>>>\n>>>>> Well, what does that mean, really? You can certainly use branches to\n>>>>> help you achieve that goal.\n>>>>\n>>>> It means my commits are chained together separate from, say, master.\n>>>\n>>> Well, that's not what a git branch provides in general.\n>>\n>> Er, so what *does* a Git branch provide then?\n>\n> I think my other replies (including the link) repeat myself quite enough.\n>\n> A branch is just a pointer. That's it.\n>\n> Quit saying `branch' to yourself. Start saying `pointer' or\n> `reference' or `commit label' or even `special tag'.\n\n:-) Again, we are going in circles. I *know* a branch is just a\npointer. So what? To me, that's just the implementation. Why is that\nrelevant? What am I missing?\n\n>>>> I feel like we're talking in circles. I get (and even agree with) what\n>>>> you're saying but I don't see how it changes the concept of a branch.\n>>>>\n>>>> In any case, what I'm more interested in is knowing whether we can\n>>>> (optionally) add state (i.e. untracked/ignored files and unstaged\n>>>> changes) to a branch.\n>>>\n>>> No, because a branch doesn't IN ANY WAY provide the structure for that\n>>> kind of thing.\n>>\n>> Obviously, we'd need to expand that structure.\n>>\n>> I tried (ab)using git stash to get what I want but it ignores\n>> untracked/ignored files (not a big surprise, of course). It seems the\n>> functionality is almost there. If I could just combine git checkout\n>> with git stash (and have it work with untracked/ignored files) in a\n>> script or alias, I'd be a happy camper. I'll have to give it some more\n>> thought.\n>\n> This cobbling together of git's components for this purpose is\n> actually a fairly frequent story on this list. Either git does indeed\n> need something more substantial as a `branch', or people (meaning you)\n> need to change the way they think (and I'm not sure which solution\n> would be best, honestly).\n\nI don't think that changing the way I think would be very effective. I\nstill have to get my work done. And I don't want build artifacts from\none \"pointer\" ;-) leak into the working directory of another \"pointer\"\njust because I changed \"pointers\". (I'm sorry, \"pointer\" just doesn't\nwork for me.)\n\nHow is this normally resolved? What do the Linux kernel developers do\nwhen changing or creating a branch? Do they do some sort of \"clean\"\nfirst?\n\nAnd I'm getting quite close with \"git ls-files -io --exclude-standard\n--directory\". :-) The cobbling-together-of-components approach looks\npromising. ;-)\n\n> If there is a change, then what is currently called a `branch' should\n> be renamed explicitly to `pointer' or a `reference' or something like\n> that.\n\nQuite possibly but it seems to me that this is too low level. I think\nthere are already too many places where Git's implementation leaks\ninto its API. E.g., anything explicitly related to the index.\n\n>>> Of course, you could use what git calls a 'branch' in\n>>> order to implement what you imply is a 'branch', but git's concept of\n>>> a branch and your concept of a branch are not at all the same concept\n>>> (which is why the term 'branch' is so unfortunate).\n>>\n>> You've completely lost me. You may very well be right but all I see is\n>> that you're pointing out how branches are implemented in Git.\n>\n> That last sentence and your earlier sentence:\n>\n>> Obviously, we'd need to expand that structure.\n>\n> vindicate everything I've said about the choice of nomenclature. The\n> term `branch' is a TERRIBLE choice.\n"},{"id":"173985","messageId":"CAE1pOi1AnDLY6GUaDSK-YKbV=eRnusnOeOZK-BOb=PbYJMrSSg@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T01:53:57Z","receivedAt":"2011-08-22T01:53:57Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 17:47, Hilco Wijbenga wrote:\n> And I'm getting quite close with \"git ls-files -io --exclude-standard\n> --directory\". :-) The cobbling-together-of-components approach looks\n> promising. ;-)\n\nWow, it looks like this sort functionality is already available in\nGit. I just cloned the Git repo and git stash now has (in master) two\nnew options: -u|--include-untracked and -a|--all. It looks like my\nwish is about to come true. :-)\n"},{"id":"173986","messageId":"CAMOZ1Bu5pPeviyZD-e6aHbv-+tSaBDyyKb5vHA132K_3=1gD-g@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-22T02:05:25Z","receivedAt":"2011-08-22T02:05:25Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga wrote:\n> On 21 August 2011 17:07, Michael Witten wrote:\n>> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga wrote:\n>>> On 21 August 2011 16:06, Michael Witten wrote:\n>>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n>>>>> On 21 August 2011 13:53, Michael Witten wrote:\n>>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>>>>>> wrote:\n>>>>>>> Isn't a branch simply a way to track changes separately?\n>>>>>>\n>>>>>> Well, what does that mean, really? You can certainly use branches to\n>>>>>> help you achieve that goal.\n>>>>>\n>>>>> It means my commits are chained together separate from, say, master.\n>>>>\n>>>> Well, that's not what a git branch provides in general.\n>>>\n>>> Er, so what *does* a Git branch provide then?\n>>\n>> I think my other replies (including the link) repeat myself quite enough.\n>>\n>> A branch is just a pointer. That's it.\n>>\n>> Quit saying `branch' to yourself. Start saying `pointer' or\n>> `reference' or `commit label' or even `special tag'.\n>\n> :-) Again, we are going in circles. I *know* a branch is just a\n> pointer. So what? To me, that's just the implementation. Why is that\n> relevant? What am I missing?\n\nYou're missing (or, rather, ignoring) the fact that what is called a\n`branch' in git is exactly what is intended to be called a `branch' in\ngit; it is not merely an incomplete or weak implementation of\nsomething.\n\nYou're probably also missing the fact that I'm simply arguing the\npoint that the term `branch' was a TERRIBLE choice, and your remarks\nand confusion have confirmed that. Other than that, most of what I'm\nsaying has very little relevance to what you're trying to do; I was\nfollowing a philosophical tangent inspired by this thread.\n\n>>>>> I feel like we're talking in circles. I get (and even agree with) what\n>>>>> you're saying but I don't see how it changes the concept of a branch.\n>>>>>\n>>>>> In any case, what I'm more interested in is knowing whether we can\n>>>>> (optionally) add state (i.e. untracked/ignored files and unstaged\n>>>>> changes) to a branch.\n>>>>\n>>>> No, because a branch doesn't IN ANY WAY provide the structure for that\n>>>> kind of thing.\n>>>\n>>> Obviously, we'd need to expand that structure.\n>>>\n>>> I tried (ab)using git stash to get what I want but it ignores\n>>> untracked/ignored files (not a big surprise, of course). It seems the\n>>> functionality is almost there. If I could just combine git checkout\n>>> with git stash (and have it work with untracked/ignored files) in a\n>>> script or alias, I'd be a happy camper. I'll have to give it some more\n>>> thought.\n>>\n>> This cobbling together of git's components for this purpose is\n>> actually a fairly frequent story on this list. Either git does indeed\n>> need something more substantial as a `branch', or people (meaning you)\n>> need to change the way they think (and I'm not sure which solution\n>> would be best, honestly).\n>\n> I don't think that changing the way I think would be very effective. I\n> still have to get my work done. And I don't want build artifacts from\n> one \"pointer\" ;-) leak into the working directory of another \"pointer\"\n> just because I changed \"pointers\". (I'm sorry, \"pointer\" just doesn't\n> work for me.)\n\nIt doesn't make any sense to say `artifacts from one \"pointer\"'. You\nare now, unfortunately, just using the term `pointer' like the term\n`branch'; you are refusing to let go of the concept that the word\n`branch' alone has seared into your brain.\n\nAs has been my entire point: You have been corrupted by the wrong\nchoice of words.\n\n> How is this normally resolved? What do the Linux kernel developers do\n> when changing or creating a branch? Do they do some sort of \"clean\"\n> first?\n\nPerhaps `git clean' would be of use to you.\n\n> And I'm getting quite close with \"git ls-files -io --exclude-standard\n> --directory\". :-) The cobbling-together-of-components approach looks\n> promising. ;-)\n\nHence what I said earlier:\n\n Of course, you could use what git calls a 'branch' in order\n to implement what you imply is a 'branch', but git's concept\n of a branch and your concept of a branch are not at all the\n same concept (which is why the term 'branch' is so\n unfortunate).\n\nHowever, please note that your solution is not completing the\nimplementation of branches in git, but rather using git's branches to\nimplement something entirely different (and which you think should be\ncalled `branches'). The terminology is the key point in the confusion.\nI dare say, had git's branches been instead called `pointers' or the\nlike, then you would have just gone about the business of implementing\nyour `branches' on top of them without thinking twice.\n\n>> If there is a change, then what is currently called a `branch' should\n>> be renamed explicitly to `pointer' or a `reference' or something like\n>> that.\n>\n> Quite possibly but it seems to me that this is too low level. I think\n> there are already too many places where Git's implementation leaks\n> into its API. E.g., anything explicitly related to the index.\n\nGit's power is its simple conceptual basis, and what you are calling\nlow-level is in fact just the ability to deal within the language of\nthose simple concepts.\n\nGit's weakness is that the most public interface shoehorns that simple\nconceptual basis into not just a more automated system, but into a\nweaker model that works well most of the time, yet fails and even\ncorrupts the mind of the user when it comes to more interesting\nscenarios.\n\nWhat you call a leaky abstraction is not the `low-level' conceptual\nbasis peeking through innappropriately. Rather, it is the falling\napart of the shoddy `higher-level' facade.\n\n>>>> Of course, you could use what git calls a 'branch' in\n>>>> order to implement what you imply is a 'branch', but git's concept of\n>>>> a branch and your concept of a branch are not at all the same concept\n>>>> (which is why the term 'branch' is so unfortunate).\n>>>\n>>> You've completely lost me. You may very well be right but all I see is\n>>> that you're pointing out how branches are implemented in Git.\n>>\n>> That last sentence and your earlier sentence:\n>>\n>>> Obviously, we'd need to expand that structure.\n>>\n>> vindicate everything I've said about the choice of nomenclature. The\n>> term `branch' is a TERRIBLE choice.\n"},{"id":"173987","messageId":"CAE1pOi0dL2qNMksuY_=gyGSRsfr6e9AmzgJUNB=jEz85sjuiUw@mail.gmail.com","threadId":"28143","inReplyTo":"CAMOZ1Bu5pPeviyZD-e6aHbv-+tSaBDyyKb5vHA132K_3=1gD-g@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T02:13:26Z","receivedAt":"2011-08-22T02:13:26Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 19:05, Michael Witten wrote:\n> On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga wrote:\n>> On 21 August 2011 17:07, Michael Witten wrote:\n>>> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga wrote:\n>>>> On 21 August 2011 16:06, Michael Witten wrote:\n>>>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga wrote:\n>>>>>> On 21 August 2011 13:53, Michael Witten wrote:\n>>>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga\n>>>>>>> wrote:\n>>>>>>>> Isn't a branch simply a way to track changes separately?\n>>>>>>>\n>>>>>>> Well, what does that mean, really? You can certainly use branches to\n>>>>>>> help you achieve that goal.\n>>>>>>\n>>>>>> It means my commits are chained together separate from, say, master.\n>>>>>\n>>>>> Well, that's not what a git branch provides in general.\n>>>>\n>>>> Er, so what *does* a Git branch provide then?\n>>>\n>>> I think my other replies (including the link) repeat myself quite enough.\n>>>\n>>> A branch is just a pointer. That's it.\n>>>\n>>> Quit saying `branch' to yourself. Start saying `pointer' or\n>>> `reference' or `commit label' or even `special tag'.\n>>\n>> :-) Again, we are going in circles. I *know* a branch is just a\n>> pointer. So what? To me, that's just the implementation. Why is that\n>> relevant? What am I missing?\n>\n> You're missing (or, rather, ignoring) the fact that what is called a\n> `branch' in git is exactly what is intended to be called a `branch' in\n> git; it is not merely an incomplete or weak implementation of\n> something.\n>\n> You're probably also missing the fact that I'm simply arguing the\n> point that the term `branch' was a TERRIBLE choice, and your remarks\n> and confusion have confirmed that. Other than that, most of what I'm\n> saying has very little relevance to what you're trying to do; I was\n> following a philosophical tangent inspired by this thread.\n>\n>>>>>> I feel like we're talking in circles. I get (and even agree with) what\n>>>>>> you're saying but I don't see how it changes the concept of a branch.\n>>>>>>\n>>>>>> In any case, what I'm more interested in is knowing whether we can\n>>>>>> (optionally) add state (i.e. untracked/ignored files and unstaged\n>>>>>> changes) to a branch.\n>>>>>\n>>>>> No, because a branch doesn't IN ANY WAY provide the structure for that\n>>>>> kind of thing.\n>>>>\n>>>> Obviously, we'd need to expand that structure.\n>>>>\n>>>> I tried (ab)using git stash to get what I want but it ignores\n>>>> untracked/ignored files (not a big surprise, of course). It seems the\n>>>> functionality is almost there. If I could just combine git checkout\n>>>> with git stash (and have it work with untracked/ignored files) in a\n>>>> script or alias, I'd be a happy camper. I'll have to give it some more\n>>>> thought.\n>>>\n>>> This cobbling together of git's components for this purpose is\n>>> actually a fairly frequent story on this list. Either git does indeed\n>>> need something more substantial as a `branch', or people (meaning you)\n>>> need to change the way they think (and I'm not sure which solution\n>>> would be best, honestly).\n>>\n>> I don't think that changing the way I think would be very effective. I\n>> still have to get my work done. And I don't want build artifacts from\n>> one \"pointer\" ;-) leak into the working directory of another \"pointer\"\n>> just because I changed \"pointers\". (I'm sorry, \"pointer\" just doesn't\n>> work for me.)\n>\n> It doesn't make any sense to say `artifacts from one \"pointer\"'. You\n> are now, unfortunately, just using the term `pointer' like the term\n> `branch'; you are refusing to let go of the concept that the word\n> `branch' alone has seared into your brain.\n>\n> As has been my entire point: You have been corrupted by the wrong\n> choice of words.\n>\n>> How is this normally resolved? What do the Linux kernel developers do\n>> when changing or creating a branch? Do they do some sort of \"clean\"\n>> first?\n>\n> Perhaps `git clean' would be of use to you.\n>\n>> And I'm getting quite close with \"git ls-files -io --exclude-standard\n>> --directory\". :-) The cobbling-together-of-components approach looks\n>> promising. ;-)\n>\n> Hence what I said earlier:\n>\n>  Of course, you could use what git calls a 'branch' in order\n>  to implement what you imply is a 'branch', but git's concept\n>  of a branch and your concept of a branch are not at all the\n>  same concept (which is why the term 'branch' is so\n>  unfortunate).\n>\n> However, please note that your solution is not completing the\n> implementation of branches in git, but rather using git's branches to\n> implement something entirely different (and which you think should be\n> called `branches'). The terminology is the key point in the confusion.\n> I dare say, had git's branches been instead called `pointers' or the\n> like, then you would have just gone about the business of implementing\n> your `branches' on top of them without thinking twice.\n>\n>>> If there is a change, then what is currently called a `branch' should\n>>> be renamed explicitly to `pointer' or a `reference' or something like\n>>> that.\n>>\n>> Quite possibly but it seems to me that this is too low level. I think\n>> there are already too many places where Git's implementation leaks\n>> into its API. E.g., anything explicitly related to the index.\n>\n> Git's power is its simple conceptual basis, and what you are calling\n> low-level is in fact just the ability to deal within the language of\n> those simple concepts.\n>\n> Git's weakness is that the most public interface shoehorns that simple\n> conceptual basis into not just a more automated system, but into a\n> weaker model that works well most of the time, yet fails and even\n> corrupts the mind of the user when it comes to more interesting\n> scenarios.\n>\n> What you call a leaky abstraction is not the `low-level' conceptual\n> basis peeking through innappropriately. Rather, it is the falling\n> apart of the shoddy `higher-level' facade.\n>\n>>>>> Of course, you could use what git calls a 'branch' in\n>>>>> order to implement what you imply is a 'branch', but git's concept of\n>>>>> a branch and your concept of a branch are not at all the same concept\n>>>>> (which is why the term 'branch' is so unfortunate).\n>>>>\n>>>> You've completely lost me. You may very well be right but all I see is\n>>>> that you're pointing out how branches are implemented in Git.\n>>>\n>>> That last sentence and your earlier sentence:\n>>>\n>>>> Obviously, we'd need to expand that structure.\n>>>\n>>> vindicate everything I've said about the choice of nomenclature. The\n>>> term `branch' is a TERRIBLE choice.\n\nThanks for sticking it out. :-) That all makes sense. I think it's all\npretty clear now.\n"},{"id":"173991","messageId":"CAGZ=bqK7H3zc8LK7EP8+uV8DpWW+czK2POfceGtcBF8Vmkhkow@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi0dL2qNMksuY_=gyGSRsfr6e9AmzgJUNB=jEz85sjuiUw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2011-08-22T03:01:21Z","receivedAt":"2011-08-22T03:01:21Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga wrote:\n> Thanks for sticking it out. :-) That all makes sense. I think it's all\n> pretty clear now.\n\nIt's worth mentioning that in most cases you DON'T want to delete untracked and\nignored files when switching branches.\n\nFor example, when I'm doing kernel development, I will frequently do this:\n\n$ git checkout -b my-new-feature origin/master\n[...hack hack hack...]\n$ make -j16 && make install && reboot\n[...find unrelated bug...]\n$ git checkout -b my-new-bugfix origin/master\n[...fix the bug...]\n$ make -j16 && make install && reboot\n$ git commit -m 'I fixed this bug'\n$ git checkout my-new-feature\n$ git rebase my-new-bugfix\n$ make -j16 && make install && reboot\n\nTo avoid wasting time I don't want to completely rebuild the kernel each\nand every time I switch branches, I just want to rebuild the files that\nchanged when I switched. The way GIT works lets me do that quite\neasily, and the kernel Makefiles detect the changed files and rebuild\nthe minimum amount necessary.\n\nGIT's behavior when you switch between branches is effectively the\nsame as applying a patch generated by diffing between the two\nbranches. Any files which would not be changed are left alone, their\ntimestamps completely unchanged.\n\nIt sounds like Eclipse is simply not detecting changes to your working\ntree by outside programs, and as a result it's not rebuilding files and\nindexes the way that it should.\n\nObviously the easiest way to work around that issue is \"git clean\",\nwhich has options to select all untracked files or just ignored ones.\n\nCheers,\nKyle Moffett\n"},{"id":"173995","messageId":"CAE1pOi1J5DKtnyUQzu1K7G1+HLsWWCN7thCf6W8MwSzt4_vtOw@mail.gmail.com","threadId":"28143","inReplyTo":"CAGZ=bqK7H3zc8LK7EP8+uV8DpWW+czK2POfceGtcBF8Vmkhkow@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T05:36:18Z","receivedAt":"2011-08-22T05:36:18Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 21 August 2011 20:01, Kyle Moffett wrote:\n> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga wrote:\n>> Thanks for sticking it out. :-) That all makes sense. I think it's all\n>> pretty clear now.\n>\n> It's worth mentioning that in most cases you DON'T want to delete untracked and\n> ignored files when switching branches.\n\nFor the record, I don't want them deleted but replaced with the\nartifacts in the other branch. A bit wasteful but it saves a lot of\nbuild time.\n\n> For example, when I'm doing kernel development, I will frequently do this:\n>\n> $ git checkout -b my-new-feature origin/master\n> [...hack hack hack...]\n> $ make -j16 && make install && reboot\n> [...find unrelated bug...]\n> $ git checkout -b my-new-bugfix origin/master\n> [...fix the bug...]\n> $ make -j16 && make install && reboot\n> $ git commit -m 'I fixed this bug'\n> $ git checkout my-new-feature\n> $ git rebase my-new-bugfix\n> $ make -j16 && make install && reboot\n>\n> To avoid wasting time I don't want to completely rebuild the kernel each\n> and every time I switch branches, I just want to rebuild the files that\n> changed when I switched.  The way GIT works lets me do that quite\n> easily, and the kernel Makefiles detect the changed files and rebuild\n> the minimum amount necessary.\n>\n> GIT's behavior when you switch between branches is effectively the\n> same as applying a patch generated by diffing between the two\n> branches.  Any files which would not be changed are left alone, their\n> timestamps completely unchanged.\n\nFor small changes that makes perfect sense. I'm at a stage where APIs\nare still evolving and changing an API means rebuilding lots of code.\nI'd like to avoid that.\n\n> It sounds like Eclipse is simply not detecting changes to your working\n> tree by outside programs, and as a result it's not rebuilding files and\n> indexes the way that it should.\n\nWhile Eclipse isn't great at detecting such changes, this isn't really\nan Eclipse problem. It's just that lots of things are still changing\nand that leads to lots of building.\n\n> Obviously the easiest way to work around that issue is \"git clean\",\n> which has options to select all untracked files or just ignored ones.\n\nAs I mentioned above, I don't want to *delete* untracked/ignored\nfiles, I just want them to stick to the branch I was working on. So if\nI change to a different branch I get the appropriate build artifacts.\n\nSomething like: git stash --everything \"All artifacts for\nthis-branch.\" && git checkout other-branch && git stash apply\nstash-for-other-branch.\n"},{"id":"174016","messageId":"CAGZ=bqLZoLoyMcvnppg6SyFtJU8phSquQeBZ7uhwP=+ZL3DADw@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi1J5DKtnyUQzu1K7G1+HLsWWCN7thCf6W8MwSzt4_vtOw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2011-08-22T12:46:48Z","receivedAt":"2011-08-22T12:46:48Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote:\n> On 21 August 2011 20:01, Kyle Moffett wrote:\n>> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga wrote:\n>>> Thanks for sticking it out. :-) That all makes sense. I think it's all\n>>> pretty clear now.\n>>\n>> It's worth mentioning that in most cases you DON'T want to delete untracked and\n>> ignored files when switching branches.\n>\n> For the record, I don't want them deleted but replaced with the\n> artifacts in the other branch. A bit wasteful but it saves a lot of\n> build time.\n>\n>> For example, when I'm doing kernel development, I will frequently do this:\n>>\n>> $ git checkout -b my-new-feature origin/master\n>> [...hack hack hack...]\n>> $ make -j16 && make install && reboot\n>> [...find unrelated bug...]\n>> $ git checkout -b my-new-bugfix origin/master\n>> [...fix the bug...]\n>> $ make -j16 && make install && reboot\n>> $ git commit -m 'I fixed this bug'\n>> $ git checkout my-new-feature\n>> $ git rebase my-new-bugfix\n>> $ make -j16 && make install && reboot\n>>\n>> To avoid wasting time I don't want to completely rebuild the kernel each\n>> and every time I switch branches, I just want to rebuild the files that\n>> changed when I switched.  The way GIT works lets me do that quite\n>> easily, and the kernel Makefiles detect the changed files and rebuild\n>> the minimum amount necessary.\n>>\n>> GIT's behavior when you switch between branches is effectively the\n>> same as applying a patch generated by diffing between the two\n>> branches.  Any files which would not be changed are left alone, their\n>> timestamps completely unchanged.\n>\n> For small changes that makes perfect sense. I'm at a stage where APIs\n> are still evolving and changing an API means rebuilding lots of code.\n> I'd like to avoid that.\n>\n>> It sounds like Eclipse is simply not detecting changes to your working\n>> tree by outside programs, and as a result it's not rebuilding files and\n>> indexes the way that it should.\n>\n> While Eclipse isn't great at detecting such changes, this isn't really\n> an Eclipse problem. It's just that lots of things are still changing\n> and that leads to lots of building.\n>\n>> Obviously the easiest way to work around that issue is \"git clean\",\n>> which has options to select all untracked files or just ignored ones.\n>\n> As I mentioned above, I don't want to *delete* untracked/ignored\n> files, I just want them to stick to the branch I was working on. So if\n> I change to a different branch I get the appropriate build artifacts.\n>\n> Something like: git stash --everything \"All artifacts for\n> this-branch.\" && git checkout other-branch && git stash apply\n> stash-for-other-branch.\n\nWhen I am in those sorts of situations I generally just use separate\nworking directories or separate checkouts entirely; if you really prefer\nto have everything in one directory you would be better served by\nintegrating \"ccache\" into your workflow.\n\nIn particular, even \"git stash\" intentionally does not preserve file times,\nso you would end up rebuilding everything anyways because all of your\nsource files would be as new as your object files.\n\nIf you use \"ccache\" then it does not matter what branches you are\non; identical source files and compiler options will be looked up in the\ncache and the result (if found) copied to the output file.\n\nCheers,\nKyle Moffett\n"},{"id":"174033","messageId":"CAE1pOi0Er1ZgftpNeCr85Zu27xR2127V_KdAtvKc1NOKmDUvzQ@mail.gmail.com","threadId":"28143","inReplyTo":"CAGZ=bqLZoLoyMcvnppg6SyFtJU8phSquQeBZ7uhwP=+ZL3DADw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T18:49:07Z","receivedAt":"2011-08-22T18:49:07Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 22 August 2011 05:46, Kyle Moffett wrote:\n> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote:\n>> On 21 August 2011 20:01, Kyle Moffett wrote:\n>>> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga wrote:\n>>>> Thanks for sticking it out. :-) That all makes sense. I think it's all\n>>>> pretty clear now.\n>>>\n>>> It's worth mentioning that in most cases you DON'T want to delete untracked and\n>>> ignored files when switching branches.\n>>\n>> For the record, I don't want them deleted but replaced with the\n>> artifacts in the other branch. A bit wasteful but it saves a lot of\n>> build time.\n>>\n>>> For example, when I'm doing kernel development, I will frequently do this:\n>>>\n>>> $ git checkout -b my-new-feature origin/master\n>>> [...hack hack hack...]\n>>> $ make -j16 && make install && reboot\n>>> [...find unrelated bug...]\n>>> $ git checkout -b my-new-bugfix origin/master\n>>> [...fix the bug...]\n>>> $ make -j16 && make install && reboot\n>>> $ git commit -m 'I fixed this bug'\n>>> $ git checkout my-new-feature\n>>> $ git rebase my-new-bugfix\n>>> $ make -j16 && make install && reboot\n>>>\n>>> To avoid wasting time I don't want to completely rebuild the kernel each\n>>> and every time I switch branches, I just want to rebuild the files that\n>>> changed when I switched.  The way GIT works lets me do that quite\n>>> easily, and the kernel Makefiles detect the changed files and rebuild\n>>> the minimum amount necessary.\n>>>\n>>> GIT's behavior when you switch between branches is effectively the\n>>> same as applying a patch generated by diffing between the two\n>>> branches.  Any files which would not be changed are left alone, their\n>>> timestamps completely unchanged.\n>>\n>> For small changes that makes perfect sense. I'm at a stage where APIs\n>> are still evolving and changing an API means rebuilding lots of code.\n>> I'd like to avoid that.\n>>\n>>> It sounds like Eclipse is simply not detecting changes to your working\n>>> tree by outside programs, and as a result it's not rebuilding files and\n>>> indexes the way that it should.\n>>\n>> While Eclipse isn't great at detecting such changes, this isn't really\n>> an Eclipse problem. It's just that lots of things are still changing\n>> and that leads to lots of building.\n>>\n>>> Obviously the easiest way to work around that issue is \"git clean\",\n>>> which has options to select all untracked files or just ignored ones.\n>>\n>> As I mentioned above, I don't want to *delete* untracked/ignored\n>> files, I just want them to stick to the branch I was working on. So if\n>> I change to a different branch I get the appropriate build artifacts.\n>>\n>> Something like: git stash --everything \"All artifacts for\n>> this-branch.\" && git checkout other-branch && git stash apply\n>> stash-for-other-branch.\n>\n> When I am in those sorts of situations I generally just use separate\n> working directories or separate checkouts entirely; if you really prefer\n> to have everything in one directory you would be better served by\n> integrating \"ccache\" into your workflow.\n\nUnfortunately, that seems for C/C++ code only. I use Java. Besides,\nit's not the Java compilation that takes most of the time.\n\n> In particular, even \"git stash\" intentionally does not preserve file times,\n> so you would end up rebuilding everything anyways because all of your\n> source files would be as new as your object files.\n\nYes, I just noticed that. Why do you say \"intentionally\"? Is extra\nwork being done to make it so? If yes, then shouldn't that be\nconfigurable?\n\nCheers,\nHilco\n"},{"id":"174036","messageId":"CAGZ=bqLyS9tcpqztwGWFOXtDJRhugu+JYvz7wTnc0PTmECWX2g@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi0Er1ZgftpNeCr85Zu27xR2127V_KdAtvKc1NOKmDUvzQ@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2011-08-22T19:31:26Z","receivedAt":"2011-08-22T19:31:26Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga wrote:\n> On 22 August 2011 05:46, Kyle Moffett wrote:\n>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote:\n>>> On 21 August 2011 20:01, Kyle Moffett wrote:\n>>>> Obviously the easiest way to work around that issue is \"git clean\",\n>>>> which has options to select all untracked files or just ignored ones.\n>>>\n>>> As I mentioned above, I don't want to *delete* untracked/ignored\n>>> files, I just want them to stick to the branch I was working on. So if\n>>> I change to a different branch I get the appropriate build artifacts.\n>>>\n>>> Something like: git stash --everything \"All artifacts for\n>>> this-branch.\" && git checkout other-branch && git stash apply\n>>> stash-for-other-branch.\n>>\n>> When I am in those sorts of situations I generally just use separate\n>> working directories or separate checkouts entirely; if you really prefer\n>> to have everything in one directory you would be better served by\n>> integrating \"ccache\" into your workflow.\n>\n> Unfortunately, that seems for C/C++ code only. I use Java. Besides,\n> it's not the Java compilation that takes most of the time.\n\nHm, that sounds like a very serious Eclipse limitation with almost all forms\nof source control. What is done with other VCSes (IE: Subversion, etc)?\n\n>From this I believe the best option is to just make use of multiple separate\ncheckouts or worktrees.\n\n>> In particular, even \"git stash\" intentionally does not preserve file times,\n>> so you would end up rebuilding everything anyways because all of your\n>> source files would be as new as your object files.\n>\n> Yes, I just noticed that. Why do you say \"intentionally\"? Is extra\n> work being done to make it so? If yes, then shouldn't that be\n> configurable?\n\nWell, there's 2 reasons:\n\n(1) The GIT data-structures simply have no place for file timestamps, and\n\"git stash\" is simply a special way of dumping files into a temporary commit.\nThis is exactly the same as the\n\n(2) You almost always *don't* want to preserve timestamps. For example:\n\n$ git checkout -b my-feature origin/master\n$ vim some-file.c\n$ make\n$ git add some-file.c && git commit -m \"A new feature\"\n$ git checkout -b my-bugfix origin/master\n$ vim other-file.c\n$ make\n\nIf GIT preserved timestamps, the second \"make\" would fail to rebuild the\nproduct \"some-file.o\" because \"some-file.c\" is still older than it, even\nthough \"some-file.c\" has changed since the last build!!!\n\nReally, GIT is only intended for storing source code. If you want to store\nother kinds of things (like timestamps, permissions, etc), then you need to\nturn them into source code (IE: a text file and a \"make install\" target) and\nthen store them that way.\n\nCheers,\nKyle Moffett\n"},{"id":"174040","messageId":"CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com","threadId":"28143","inReplyTo":"CAGZ=bqLyS9tcpqztwGWFOXtDJRhugu+JYvz7wTnc0PTmECWX2g@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T20:10:18Z","receivedAt":"2011-08-22T20:10:18Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 22 August 2011 12:31, Kyle Moffett wrote:\n> On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga wrote:\n>> On 22 August 2011 05:46, Kyle Moffett wrote:\n>>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote:\n>>>> On 21 August 2011 20:01, Kyle Moffett wrote:\n>>>>> Obviously the easiest way to work around that issue is \"git clean\",\n>>>>> which has options to select all untracked files or just ignored ones.\n>>>>\n>>>> As I mentioned above, I don't want to *delete* untracked/ignored\n>>>> files, I just want them to stick to the branch I was working on. So if\n>>>> I change to a different branch I get the appropriate build artifacts.\n>>>>\n>>>> Something like: git stash --everything \"All artifacts for\n>>>> this-branch.\" && git checkout other-branch && git stash apply\n>>>> stash-for-other-branch.\n>>>\n>>> When I am in those sorts of situations I generally just use separate\n>>> working directories or separate checkouts entirely; if you really prefer\n>>> to have everything in one directory you would be better served by\n>>> integrating \"ccache\" into your workflow.\n>>\n>> Unfortunately, that seems for C/C++ code only. I use Java. Besides,\n>> it's not the Java compilation that takes most of the time.\n>\n> Hm, that sounds like a very serious Eclipse limitation with almost all forms\n> of source control.  What is done with other VCSes (IE: Subversion, etc)?\n\nIt has nothing to do with Eclipse. There is just a lot going on in the build.\n\n> From this I believe the best option is to just make use of multiple separate\n> checkouts or worktrees.\n\nSounds like it.\n\n>>> In particular, even \"git stash\" intentionally does not preserve file times,\n>>> so you would end up rebuilding everything anyways because all of your\n>>> source files would be as new as your object files.\n>>\n>> Yes, I just noticed that. Why do you say \"intentionally\"? Is extra\n>> work being done to make it so? If yes, then shouldn't that be\n>> configurable?\n>\n> Well, there's 2 reasons:\n>\n> (1) The GIT data-structures simply have no place for file timestamps, and\n> \"git stash\" is simply a special way of dumping files into a temporary commit.\n\nThat's what I thought. The \"intentionally\" threw me off. It's not\nintentional, it's just a side effect.\n\n> This is exactly the same as the\n\nThere seems to be some text missing here?\n\n> (2) You almost always *don't* want to preserve timestamps.  For example:\n>\n> $ git checkout -b my-feature origin/master\n> $ vim some-file.c\n> $ make\n> $ git add some-file.c && git commit -m \"A new feature\"\n> $ git checkout -b my-bugfix origin/master\n> $ vim other-file.c\n> $ make\n>\n> If GIT preserved timestamps, the second \"make\" would fail to rebuild the\n> product \"some-file.o\" because \"some-file.c\" is still older than it, even\n> though \"some-file.c\" has changed since the last build!!!\n>\n> Really, GIT is only intended for storing source code.  If you want to store\n> other kinds of things (like timestamps, permissions, etc), then you need to\n> turn them into source code (IE: a text file and a \"make install\" target) and\n> then store them that way.\n\nYep, that all makes sense. I just wish there was at least an option to\nkeep the timestamp (and possibly other such things). Even Subversion\ncan do that... ;-) After all, not everybody uses C & make.\n\nCheers,\nHilco\n"},{"id":"174045","messageId":"20110822210141.GA3880@elie.gateway.2wire.net","threadId":"28143","inReplyTo":"CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com","subject":"Restoring timestamps (Re: Branches & directories)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-22T21:01:41Z","receivedAt":"2011-08-22T21:01:41Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hilco Wijbenga wrote:\n> On 22 August 2011 12:31, Kyle Moffett wrote:\n\n>> (1) The GIT data-structures simply have no place for file timestamps, and\n>> \"git stash\" is simply a special way of dumping files into a temporary commit.\n>\n> That's what I thought. The \"intentionally\" threw me off. It's not\n> intentional, it's just a side effect.\n\nFor what it's worth: no, it's intentional. See, for example:\n\n http://thread.gmane.org/gmane.comp.version-control.git/1564/focus=1680\n https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F\n\nThat said, something being intentional does not necessarily mean it is\nalways _right_. So, for example, patches to allow a commit to store\nsome timestamps, with documentation explaining when this is\nappropriate, would probably be welcome. Maybe a good place to store\nsuch information would be a dotfile alongside the file (so old,\nunaware git versions could extract the same information without fuss).\n\nEven if this feature were implemented just for \"git stash\", personally\nI would turn it off so \"make\" could continue to behave as I expect it\nto. But in principle, I don't mind the idea of it existing. :)\n\nHope that helps,\nJonathan\n"},{"id":"174052","messageId":"CAE1pOi1+nnpnHAuhYsXcfFNUroW0JcDQKLu6D7YNrUwJg0tXPw@mail.gmail.com","threadId":"28143","inReplyTo":"20110822210141.GA3880@elie.gateway.2wire.net","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-22T22:33:03Z","receivedAt":"2011-08-22T22:33:03Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 22 August 2011 14:01, Jonathan Nieder wrote:\n> Hilco Wijbenga wrote:\n>> On 22 August 2011 12:31, Kyle Moffett wrote:\n>\n>>> (1) The GIT data-structures simply have no place for file timestamps, and\n>>> \"git stash\" is simply a special way of dumping files into a temporary commit.\n>>\n>> That's what I thought. The \"intentionally\" threw me off. It's not\n>> intentional, it's just a side effect.\n>\n> For what it's worth: no, it's intentional.  See, for example:\n>\n>  http://thread.gmane.org/gmane.comp.version-control.git/1564/focus=1680\n>  https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F\n\nAfter I had sent the above I realized it was worded a bit too strong.\n\n> That said, something being intentional does not necessarily mean it is\n> always _right_.  So, for example, patches to allow a commit to store\n> some timestamps, with documentation explaining when this is\n> appropriate, would probably be welcome.  Maybe a good place to store\n> such information would be a dotfile alongside the file (so old,\n> unaware git versions could extract the same information without fuss).\n\nYou mean an extra dotfile per file in the commit?\n\n> Even if this feature were implemented just for \"git stash\", personally\n> I would turn it off so \"make\" could continue to behave as I expect it\n> to.  But in principle, I don't mind the idea of it existing. :)\n\nGiven that apparently the majority of Git users don't want/need this,\nit should probably be off by default. So you would not even need to\nturn it off. :-)\n\nIn fact, I would not want it on by default either. It's really only\nuseful when switching branches when I want to keep the exact state of\nthe branch.\n"},{"id":"174056","messageId":"CAFzf2Xw6=BFsKauYTG-4cw0D_LzLSNb_wqz8dQJ83wJHNQXbdg@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi1+nnpnHAuhYsXcfFNUroW0JcDQKLu6D7YNrUwJg0tXPw@mail.gmail.com","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-22T23:21:16Z","receivedAt":"2011-08-22T23:21:16Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hilco Wijbenga wrote:\n\n> You mean an extra dotfile per file in the commit?\n\nLet me step back a moment.\n\nWhen you mentioned mtime, a switch went off and reminded me of the\nproblem of metadata in general, especially owner and permissions. That\nproblem is important for people keeping track of /etc or $HOME in\nversion control (always a little dangerous because of the effect of a\nstray \"git reset --hard\", but never mind). And the last time it came\nup, I convinced myself that a hook script setting up entries in\n.gitattributes, .gitmetadata, or .etckeepr with information like \"all\nfiles are owned by root:root unless otherwise specified\" could be a\ngood and not too invasive way to deal with that.\n\nNow that you remind me that the mtime of every file is likely to\ndiffer from every other file, it is harder to imagine what situation\nwould make this meaningful information that should be stored in the\nrepository and shared with other people. It seems more like something\nassociated to the worktree, which fits more closely with what you are\ntrying to do, anyway.\n\nRegarding the problem \"eclipse metadata is not carried over from one\nworktree to another\", isn't that going to be a problem regardless? In\nyour proposed setup, each time you stash everything and start work on\na different branch, the eclipse metadata before would be stashed along\nwith everything else, which doesn't make anything any easier (unless\ndisk space is very scarce or metadata stores the absolute path to the\ncwd).\n\nSorry for the lack of clarity.\nJonathan\n"},{"id":"174069","messageId":"CAE1pOi1J=TWUmJKZorotBsDoz3wozXsioN7fVO=7JBxdMD7Zqg@mail.gmail.com","threadId":"28143","inReplyTo":"CAFzf2Xw6=BFsKauYTG-4cw0D_LzLSNb_wqz8dQJ83wJHNQXbdg@mail.gmail.com","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-23T03:06:46Z","receivedAt":"2011-08-23T03:06:46Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 22 August 2011 16:21, Jonathan Nieder wrote:\n> Hilco Wijbenga wrote:\n>\n>> You mean an extra dotfile per file in the commit?\n>\n> Let me step back a moment.\n>\n> When you mentioned mtime, a switch went off and reminded me of the\n> problem of metadata in general, especially owner and permissions. That\n> problem is important for people keeping track of /etc or $HOME in\n> version control (always a little dangerous because of the effect of a\n> stray \"git reset --hard\", but never mind). And the last time it came\n> up, I convinced myself that a hook script setting up entries in\n> .gitattributes, .gitmetadata, or .etckeepr with information like \"all\n> files are owned by root:root unless otherwise specified\" could be a\n> good and not too invasive way to deal with that.\n>\n> Now that you remind me that the mtime of every file is likely to\n> differ from every other file, it is harder to imagine what situation\n> would make this meaningful information that should be stored in the\n> repository and shared with other people. It seems more like something\n> associated to the worktree, which fits more closely with what you are\n> trying to do, anyway.\n\nYes, indeed.\n\n> Regarding the problem \"eclipse metadata is not carried over from one\n> worktree to another\", isn't that going to be a problem regardless? In\n> your proposed setup, each time you stash everything and start work on\n> a different branch, the eclipse metadata before would be stashed along\n> with everything else, which doesn't make anything any easier (unless\n> disk space is very scarce or metadata stores the absolute path to the\n> cwd).\n\nEclipse is a wonderful IDE except for how it makes sharing workspaces\npractically impossible (where \"share\" means \"put in SCM\", not \"used my\nseveral developers at the same time\"). It's mostly (AFAICT) binary\ndata with lots of absolute paths. So it's a pain but it doesn't make\nmy scenario all that much more complicated.\n\nThe hard part is creating a new branch. Somehow I would need to\nduplicate the state in the parent branch in the child branch. It needs\nto be duplicated because I need to be able to do git stash in the\nchild branch *and* the parent branch. Is it possible to do git stash\npop without losing the stash? Or to \"copy\" a stash? Otherwise, it's\nprobably easier to simply write a separate script to do it. That\nshould not be very hard. I would not use git stash at all.\n\nFor a new branch, the script would\n1. in \"parent\", move workspace (i.e. the root working dir, where .git\nis) into .git/branches/parent/\n2. create and jump to \"child\"\n3. in \"child\", copy .git/branches/parent into workspace (so creating a\nnew branch is no longer a cheap operation)\n\nFor an existing branch, the script would\n1. in \"current-branch\", move workspace into .git/branches/current-branch\n2. jump to \"other-branch\"\n3. in \"other-branch\", move .git/branches/other-branch into workspace\n\nThe moves (assuming everything is on the same partition) should make\nswitching branches relatively cheap. Not very elegant (quite brute\nforce in fact) but it's simple and I think it would work. Or did I\noverlook something? Better/other ideas are certainly welcome. :-)\n"},{"id":"174070","messageId":"CAE1pOi1c2sKh671sFjHtHR3ux9Uv8Xinqg3RNpC2dBRXQnPc=Q@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi1J=TWUmJKZorotBsDoz3wozXsioN7fVO=7JBxdMD7Zqg@mail.gmail.com","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-23T03:20:29Z","receivedAt":"2011-08-23T03:20:29Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 22 August 2011 20:06, Hilco Wijbenga wrote:\n> On 22 August 2011 16:21, Jonathan Nieder wrote:\n>> Hilco Wijbenga wrote:\n>>\n>>> You mean an extra dotfile per file in the commit?\n>>\n>> Let me step back a moment.\n>>\n>> When you mentioned mtime, a switch went off and reminded me of the\n>> problem of metadata in general, especially owner and permissions. That\n>> problem is important for people keeping track of /etc or $HOME in\n>> version control (always a little dangerous because of the effect of a\n>> stray \"git reset --hard\", but never mind). And the last time it came\n>> up, I convinced myself that a hook script setting up entries in\n>> .gitattributes, .gitmetadata, or .etckeepr with information like \"all\n>> files are owned by root:root unless otherwise specified\" could be a\n>> good and not too invasive way to deal with that.\n>>\n>> Now that you remind me that the mtime of every file is likely to\n>> differ from every other file, it is harder to imagine what situation\n>> would make this meaningful information that should be stored in the\n>> repository and shared with other people. It seems more like something\n>> associated to the worktree, which fits more closely with what you are\n>> trying to do, anyway.\n>\n> Yes, indeed.\n>\n>> Regarding the problem \"eclipse metadata is not carried over from one\n>> worktree to another\", isn't that going to be a problem regardless? In\n>> your proposed setup, each time you stash everything and start work on\n>> a different branch, the eclipse metadata before would be stashed along\n>> with everything else, which doesn't make anything any easier (unless\n>> disk space is very scarce or metadata stores the absolute path to the\n>> cwd).\n>\n> Eclipse is a wonderful IDE except for how it makes sharing workspaces\n> practically impossible (where \"share\" means \"put in SCM\", not \"used my\n> several developers at the same time\"). It's mostly (AFAICT) binary\n> data with lots of absolute paths. So it's a pain but it doesn't make\n> my scenario all that much more complicated.\n>\n> The hard part is creating a new branch. Somehow I would need to\n> duplicate the state in the parent branch in the child branch. It needs\n> to be duplicated because I need to be able to do git stash in the\n> child branch *and* the parent branch. Is it possible to do git stash\n> pop without losing the stash? Or to \"copy\" a stash? Otherwise, it's\n> probably easier to simply write a separate script to do it. That\n> should not be very hard. I would not use git stash at all.\n>\n> For a new branch, the script would\n> 1. in \"parent\", move workspace (i.e. the root working dir, where .git\n> is)  into .git/branches/parent/\n> 2. create and jump to \"child\"\n> 3. in \"child\", copy .git/branches/parent into workspace (so creating a\n> new branch is no longer a cheap operation)\n>\n> For an existing branch, the script would\n> 1. in \"current-branch\", move workspace into .git/branches/current-branch\n> 2. jump to \"other-branch\"\n> 3. in \"other-branch\", move .git/branches/other-branch into workspace\n>\n> The moves (assuming everything is on the same partition) should make\n> switching branches relatively cheap. Not very elegant (quite brute\n> force in fact) but it's simple and I think it would work. Or did I\n> overlook something? Better/other ideas are certainly welcome. :-)\n\nP.S. I do not mean to imply that I have discounted simply using\ndifferent clones or git-new-workdir. Those are still valid options.\nThe script is probably a bit faster, though.\n"},{"id":"174089","messageId":"CAMOZ1BvM08FTODUbGhQMqAmVLWY1cQjTcDknGFp3ZGTsH=0fZw@mail.gmail.com","threadId":"28143","inReplyTo":"CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-08-23T14:46:04Z","receivedAt":"2011-08-23T14:46:04Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Mon, Aug 22, 2011 at 20:10, Hilco Wijbenga wrote:\n> On 22 August 2011 12:31, Kyle Moffett wrote:\n>> On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga wrote:\n>>> On 22 August 2011 05:46, Kyle Moffett wrote:\n>>>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote:\n>>>>> On 21 August 2011 20:01, Kyle Moffett wrote:\n>>>> In particular, even \"git stash\" intentionally does not preserve file times,\n>>>> so you would end up rebuilding everything anyways because all of your\n>>>> source files would be as new as your object files.\n>>>\n>>> Yes, I just noticed that. Why do you say \"intentionally\"? Is extra\n>>> work being done to make it so? If yes, then shouldn't that be\n>>> configurable?\n>>\n>> Well, there's 2 reasons:\n>>\n>> (1) The GIT data-structures simply have no place for file timestamps, and\n>> \"git stash\" is simply a special way of dumping files into a temporary commit.\n>\n> That's what I thought. The \"intentionally\" threw me off. It's not\n> intentional, it's just a side effect.\n\nNo, it's intentional.\n\nThis discussion about timestamps is not new; the mailing list is\nlittered with people wondering about it. The data structures are the\nway they are for intentional reasons, as suggested by Kyle's example.\n\n>> (2) You almost always *don't* want to preserve timestamps.  For example:\n>>\n>> $ git checkout -b my-feature origin/master\n>> $ vim some-file.c\n>> $ make\n>> $ git add some-file.c && git commit -m \"A new feature\"\n>> $ git checkout -b my-bugfix origin/master\n>> $ vim other-file.c\n>> $ make\n>>\n>> If GIT preserved timestamps, the second \"make\" would fail to rebuild the\n>> product \"some-file.o\" because \"some-file.c\" is still older than it, even\n>> though \"some-file.c\" has changed since the last build!!!\n>>\n>> Really, GIT is only intended for storing source code.  If you want to store\n>> other kinds of things (like timestamps, permissions, etc), then you need to\n>> turn them into source code (IE: a text file and a \"make install\" target) and\n>> then store them that way.\n>\n> Yep, that all makes sense. I just wish there was at least an option to\n> keep the timestamp (and possibly other such things). Even Subversion\n> can do that... ;-) After all, not everybody uses C & make.\n\nYes, well, the crux there is `(and possibly other such things)'. That\nis an open-ended specification because nobody can agree on what such\nthings should include.\n\nOne of git's major design goals has been efficiency, so it's natural\nthat git only handles what is necessary for its prime purpose of\nmanaging a history of line-oriented textual content.\n\nHowever, other tools have been built on top of git's infrastructure in\norder to store all manner of metadata (usually for the purposes of\nbacking up files with all of their special metadata).\n\nEssentially, only *you* know what `other such things' *you* need, so\nit's up to you to design a way of storing such information and\nretrieving it yourself. After all, not everybody (indeed, nearly\nnobody, I'd wager) has your specific difficulties.\n"},{"id":"176685","messageId":"20111002150601.GB15083@nibiru.local","threadId":"28143","inReplyTo":"CAE1pOi1J=TWUmJKZorotBsDoz3wozXsioN7fVO=7JBxdMD7Zqg@mail.gmail.com","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-10-02T15:06:01Z","receivedAt":"2011-10-02T15:06:01Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Hilco Wijbenga wrote:\n\n> Eclipse is a wonderful IDE except for how it makes sharing workspaces\n> practically impossible (where \"share\" means \"put in SCM\", not \"used my\n> several developers at the same time\"). \n\nThis is one the major points which render it rather useless for me ;-o\n\n> Is it possible to do git stash pop without losing the stash? \n\ngit cherry-pick stash{0}\n\n\nApropos IDEs:\n\nI've been thinking about how to properly integrate IDEs with VCS'es\nlike git. My conclusion is that it should be directly built ontop\nof it. Project metadata itself belongs into git, and the project\nmanagement tool should automatically create local working copies\non-demand. I would even delegate *all* the VCS handling to git\n(even when using other VCS'es in the back)\n\nMaybe I'll find some time to do some initial concepts.\nPerhaps anybody likes to join in ?\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"176688","messageId":"4E889813.8070205@gmail.com","threadId":"28143","inReplyTo":"CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@gmail.com","sentAt":"2011-10-02T16:57:55Z","receivedAt":"2011-10-02T16:57:55Z","isPatch":false,"sender":{"key":"robin.rosenberg@gmail.com","avatar":null},"body":"Hilco Wijbenga skrev 2011-08-22 22.10:\n> [...] I just wish there was at least an option to\n> keep the timestamp (and possibly other such things). Even Subversion\n> can do that... ;-) After all, not everybody uses C& make.\n>\nWhat tools do you use that need the benefits from retaining timestamps? \nThe only\none I can think of is clearmake, but then that tool goes with another \nSCM. Eclipse,\nfor example, will be just as confused by timestamps that travel \nbackwards in time, as\nmake is.\n\n-- robin\n"},{"id":"176689","messageId":"87botznvua.fsf@an-dro.info.enstb.org","threadId":"28143","inReplyTo":"4E889813.8070205@gmail.com","subject":"Re: Branches & directories","fromName":"Ronan Keryell","fromEmail":"ronan.keryell@hpc-project.com","sentAt":"2011-10-02T17:31:57Z","receivedAt":"2011-10-02T17:31:57Z","isPatch":false,"sender":{"key":"ronan.keryell@hpc-project.com","avatar":null},"body":">>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg said:\n\n Robin> Hilco Wijbenga skrev 2011-08-22 22.10:\n >> [...] I just wish there was at least an option to keep the\n >> timestamp (and possibly other such things). Even Subversion can\n >> do that... ;-) After all, not everybody uses C& make.\n\n Robin> What tools do you use that need the benefits from retaining\n Robin> timestamps? The only one I can think of is clearmake, but\n Robin> then that tool goes with another SCM. Eclipse, for example,\n Robin> will be just as confused by timestamps that travel backwards\n Robin> in time, as make is.\n\nI think of tools called \"humans\", very common indeed on Earth. :-)\n\nThe reward of git success is that it is not only used to develop the\nLinux kernel. :-)\n\nWe use also git as a very smart repositories to store administrative\ndocuments. It is very convenient to look at the real modification or\ncreation dates to figure out some historical aspects for example.\n\nmetastore is a nice tool providing a begin of this on top of git (or\nwhatever) but :\n- this is not very convenient, needing to deal manually with these\n aspects ;\n- the metadata is binary and not textual (à la YAML ?) so we loose the\n classical textual merging candies when conflict arises on metadata\n (ouch).\n\nIt is one of my future project to do a more textual version of\nmetastore, but I'm afraid it is an unbound future... :-/\n-- \n Ronan KERYELL |\\/ Phone: +1 408 844 HPC0\n HPC Project, Inc. |/) Cell: +33 613 143 766\n 5201 Great America Parkway #3241 K Ronan.Keryell@hpc-project.com\n Santa Clara, CA 95054 |\\ skype:keryell\n USA | \\ http://hpc-project.com\n"},{"id":"176690","messageId":"vpqehyvnrbj.fsf@bauges.imag.fr","threadId":"28143","inReplyTo":"87botznvua.fsf@an-dro.info.enstb.org","subject":"Re: Branches & directories","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-10-02T19:09:36Z","receivedAt":"2011-10-02T19:09:36Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ronan Keryell writes:\n\n>>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg said:\n>\n> Robin> Hilco Wijbenga skrev 2011-08-22 22.10:\n> >> [...] I just wish there was at least an option to keep the\n> >> timestamp (and possibly other such things). Even Subversion can\n> >> do that... ;-) After all, not everybody uses C& make.\n\nAFAIK, Subversion doesn't version timestamps. What it can do is to set\nthe timestamp to the commit date at the time the file is checked-out.\n\n> Robin> What tools do you use that need the benefits from retaining\n> Robin> timestamps? The only one I can think of is clearmake, but\n> Robin> then that tool goes with another SCM. Eclipse, for example,\n> Robin> will be just as confused by timestamps that travel backwards\n> Robin> in time, as make is.\n>\n> I think of tools called \"humans\", very common indeed on Earth. :-)\n\nFor human beings, it's not really harder to run\n\n git log -1 file\n\nthan to look at the on-disk timestamp. And it continues working after\nyou start modifying the file, so it's much less fragile than the\nfilesystem timestamp.\n\nBut if you insist in reproducing SVN's \"use-commit-times = yes\" setting,\nit should be doable with a post-checkout hook.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"176693","messageId":"CAE1pOi0HGCSXQL-=tVmOm-3p8BNd02h3MwyRMWRRANvQyovfUg@mail.gmail.com","threadId":"28143","inReplyTo":"CA+sFfMf=gi5CWyfZEt-Nmdr4J9g__maQTqy1WePr1x8D-AVr4A@mail.gmail.com","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-02T22:25:19Z","receivedAt":"2011-10-02T22:25:19Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 2 October 2011 08:47, Brandon Casey wrote:\n> On Aug 22, 2011 10:06 PM, \"Hilco Wijbenga\" wrote:\n>> Is it possible to do git stash\n>> pop without losing the stash?\n>\n> That's called 'git stash apply'.\n\n:-) Yeah, I had actually discovered that myself. I had been using\n\"pop\" and \"apply\" interchangeably until I noticed I had a number of\nstashes stored that I was not aware of. That's when I discovered they\ndid in fact *not* have exactly the same meaning. :-)\n"},{"id":"176694","messageId":"CAE1pOi1XmLzvuNtv1-cKETDK0UJdirK4ts-7L59dKqGWGxJ98Q@mail.gmail.com","threadId":"28143","inReplyTo":"20111002150601.GB15083@nibiru.local","subject":"Re: Restoring timestamps (Re: Branches & directories)","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-02T22:29:48Z","receivedAt":"2011-10-02T22:29:48Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 2 October 2011 08:06, Enrico Weigelt wrote:\n> * Hilco Wijbenga wrote:\n>\n>> Eclipse is a wonderful IDE except for how it makes sharing workspaces\n>> practically impossible (where \"share\" means \"put in SCM\", not \"used by\n>> several developers at the same time\").\n>\n> This is one the major points which render it rather useless for me ;-o\n\nAs long as Eclipse is the only IDE (AFAIK, of course) that has\nworkspaces (allowing you to easily group projects) and \"Clean Up\"\n(which helps clean up Java code), I'll stick with it despite its\ndeficiencies.\n"},{"id":"176696","messageId":"CAE1pOi3bm72Rk+UYygS_bC9eh0VTPr-VQSdtBGqjgDpEzkutZw@mail.gmail.com","threadId":"28143","inReplyTo":"4E889813.8070205@gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-02T23:40:14Z","receivedAt":"2011-10-02T23:40:14Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 2 October 2011 09:57, Robin Rosenberg wrote:\n> Hilco Wijbenga skrev 2011-08-22 22.10:\n>>\n>> [...] I just wish there was at least an option to\n>> keep the timestamp (and possibly other such things). Even Subversion\n>> can do that... ;-) After all, not everybody uses C&  make.\n>>\n> What tools do you use that need the benefits from retaining timestamps? The\n> only\n> one I can think of is clearmake, but then that tool goes with another SCM.\n> Eclipse,\n> for example, will be just as confused by timestamps that travel backwards in\n> time, as\n> make is.\n\nWhy would timestamps travel back in time? They simply would not change.\n\nAnyway, we're not really talking about the same thing. If there's an\nupdate (i.e. git pull or something similar) then changing the\ntimestamp to something (anything) newer is the right thing to do. In\nfact, it would be painful (as you already alluded to) if this were not\nthe case.\n\nThat's however not the scenario that I'm talking about. I'm talking about doing\n\ngit checkout branch\ngit checkout master\n\nor\n\ngit stash\ngit stash pop\n\nIn both cases all files (or at least all affected files, in case of\ngit stash) get the current time as their timestamp instead of the\ntimestamp they had before. This is forcing (completely unnecessary)\nrebuilds. *Nothing* has changed but I have to do a complete rebuild\n(well, I suppose I could \"touch\" all build artifacts and such but I'm\nsure you get the idea).\n\nI understand *why* it's happening (it's simply reusing the existing\nGit functionality) but in the scenarios above nothing has really\nchanged, I should be able to pick up from where I left off, shouldn't\nI?\n\n(Obviously, I moved the discussion off track when I started talking\nabout Subversion, commits, and commit times. That's really just an\nimplementation detail and I wish I had never brought it up.)\n\nP.S. I'm quite happy with git-new-workdir so I do believe I have a\ngood workaround.\n"},{"id":"176697","messageId":"CAE1pOi0ybQEANkLo-ie_41s5eeRKDZL=e2sP67Avnef5VUKMmQ@mail.gmail.com","threadId":"28143","inReplyTo":"vpqehyvnrbj.fsf@bauges.imag.fr","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-02T23:45:02Z","receivedAt":"2011-10-02T23:45:02Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 2 October 2011 12:09, Matthieu Moy wrote:\n> Ronan Keryell writes:\n>\n>>>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg said:\n>>\n>>     Robin> Hilco Wijbenga skrev 2011-08-22 22.10:\n>>     >> [...] I just wish there was at least an option to keep the\n>>     >> timestamp (and possibly other such things). Even Subversion can\n>>     >> do that... ;-) After all, not everybody uses C& make.\n>\n> AFAIK, Subversion doesn't version timestamps. What it can do is to set\n> the timestamp to the commit date at the time the file is checked-out.\n\nCorrect and this would fix my problem, I believe.\n\n>>     Robin> What tools do you use that need the benefits from retaining\n>>     Robin> timestamps?  The only one I can think of is clearmake, but\n>>     Robin> then that tool goes with another SCM. Eclipse, for example,\n>>     Robin> will be just as confused by timestamps that travel backwards\n>>     Robin> in time, as make is.\n>>\n>> I think of tools called \"humans\", very common indeed on Earth. :-)\n>\n> For human beings, it's not really harder to run\n>\n>  git log -1 file\n\nI think the idea is that computers do the work, not humans... :-)\n\n> than to look at the on-disk timestamp. And it continues working after\n> you start modifying the file, so it's much less fragile than the\n> filesystem timestamp.\n>\n> But if you insist in reproducing SVN's \"use-commit-times = yes\" setting,\n> it should be doable with a post-checkout hook.\n\nMmm, this post-checkout hook would get the commit time from the commit\nand \"touch\" all relevant files with that timestamp? Is that easily\ndone?\n"},{"id":"176699","messageId":"20111003030723.GA24523@sigill.intra.peff.net","threadId":"28143","inReplyTo":"CAE1pOi3bm72Rk+UYygS_bC9eh0VTPr-VQSdtBGqjgDpEzkutZw@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-03T03:07:23Z","receivedAt":"2011-10-03T03:07:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 02, 2011 at 04:40:14PM -0700, Hilco Wijbenga wrote:\n\n> That's however not the scenario that I'm talking about. I'm talking about doing\n> \n> git checkout branch\n> git checkout master\n> \n> or\n> \n> git stash\n> git stash pop\n> \n> In both cases all files (or at least all affected files, in case of\n> git stash) get the current time as their timestamp instead of the\n> timestamp they had before. This is forcing (completely unnecessary)\n> rebuilds. *Nothing* has changed but I have to do a complete rebuild\n> (well, I suppose I could \"touch\" all build artifacts and such but I'm\n> sure you get the idea).\n> \n> I understand *why* it's happening (it's simply reusing the existing\n> Git functionality) but in the scenarios above nothing has really\n> changed, I should be able to pick up from where I left off, shouldn't\n> I?\n\nNo. There are cases where that will fool timestamp-based tools. The\nproblem is that the build products are not tracked by git, and so they\nare not changed when you switch branches. But the timestamps of build\nproducts and branches are compared.\n\nSo let's imagine you have two branches, with two different versions of\nfoo.c, both of which use \"make\" to build them into foo.o. Their\ntimestamps are from an hour ago and two hours ago. And that git restores\nthose old timestamps. You do:\n\n git checkout master\n make\n\nNow foo.c is one hour old (from master). But foo.o is only a few seconds\nold (it was just created by make. Now you do:\n\n git checkout branch\n make\n\nNow foo.c is two hours old (from branch). But foo.o is still new, so\nmake doesn't rebuild it, which is an error.\n\nOr did you really mean your example literally, as in you run two\ncheckouts back to back, without running anything in between, and the\nsecond checkout restores the state before the first one. In that case,\nyes, it would be correct to keep the old timestamps. But this is an\noptimization that can only apply in a few very specific cases. And\nmoreoever, how can git know when it is OK to apply that optimization? It\nhas no idea what commands you might have run since the last time we were\nat \"master\".\n\n-Peff\n"},{"id":"176710","messageId":"CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com","threadId":"28143","inReplyTo":"20111003030723.GA24523@sigill.intra.peff.net","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-03T07:15:33Z","receivedAt":"2011-10-03T07:15:33Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 2 October 2011 20:07, Jeff King wrote:\n\n> Or did you really mean your example literally, as in you run two\n> checkouts back to back, without running anything in between, and the\n> second checkout restores the state before the first one. In that case,\n> yes, it would be correct to keep the old timestamps. But this is an\n> optimization that can only apply in a few very specific cases. And\n> moreoever, how can git know when it is OK to apply that optimization? It\n> has no idea what commands you might have run since the last time we were\n> at \"master\".\n\nYes, I meant it literally. And, no, Git could not possibly know so it\nwould have to be optional behaviour. But it's probably a lot of work\nfor (for most people) little gain.\n"},{"id":"176712","messageId":"20111003073059.GA9455@sigill.intra.peff.net","threadId":"28143","inReplyTo":"CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-03T07:30:59Z","receivedAt":"2011-10-03T07:30:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 03, 2011 at 12:15:33AM -0700, Hilco Wijbenga wrote:\n\n> On 2 October 2011 20:07, Jeff King wrote:\n> \n> > Or did you really mean your example literally, as in you run two\n> > checkouts back to back, without running anything in between, and the\n> > second checkout restores the state before the first one. In that case,\n> > yes, it would be correct to keep the old timestamps. But this is an\n> > optimization that can only apply in a few very specific cases. And\n> > moreoever, how can git know when it is OK to apply that optimization? It\n> > has no idea what commands you might have run since the last time we were\n> > at \"master\".\n> \n> Yes, I meant it literally. And, no, Git could not possibly know so it\n> would have to be optional behaviour. But it's probably a lot of work\n> for (for most people) little gain.\n\nIf you really want the human to trigger it, then you can do something\nlike this:\n\n cat >git-checkout-timestamp <<\\EOF\n #!/bin/sh\n\n old=`git rev-parse HEAD`\n git checkout \"$@\" || exit 1\n time=`git log -1 --format=%at`\n git diff-tree --name-only -z \"$old\" HEAD |\n perl -0ne \"utime($time, $time, \\$_)\";\n EOF\n\nDrop that somewhere in your $PATH, and use it instead of regular\ncheckout. It restores the timestamps on any changed files, but not on\nthose that were not touched. So your:\n\n git checkout branch\n git checkout master\n\nexample would end up with timestamps set for \"master\" on the changed\nfiles. Two caveats:\n\n 1. This can still break makefiles! For example, like this:\n\n make foo.o ;# now foo.o is recent\n vi foo.c ;# but foo.c is _more_ recent\n git checkout branch ;# now it's even newer\n git checkout-timestamp master ;# now we've restored it to some\n ;# old timestamp, and make will\n ;# think it's older than foo.o\n\n 2. In general, I'm not sure it makes any sense if there are local\n worktree modifications to the files in question. But I didn't think\n about it too hard. That ways madness lies.\n\n-Peff\n"},{"id":"176713","messageId":"vpqaa9ijzt4.fsf@bauges.imag.fr","threadId":"28143","inReplyTo":"CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-10-03T07:32:07Z","receivedAt":"2011-10-03T07:32:07Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hilco Wijbenga writes:\n\n> Yes, I meant it literally. And, no, Git could not possibly know so it\n> would have to be optional behaviour. But it's probably a lot of work\n> for (for most people) little gain.\n\nNot only little gain, but also important risk: users of this feature\nwould be likely to spend hours debugging something just because some\nfiles weren't recompiled at the right time.\n\nIf you want to optimize the number of files compiled by \"make\", then\nccache is your friend. This one is safe.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"176714","messageId":"20111003073456.GA10054@sigill.intra.peff.net","threadId":"28143","inReplyTo":"vpqaa9ijzt4.fsf@bauges.imag.fr","subject":"Re: Branches & directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-03T07:34:56Z","receivedAt":"2011-10-03T07:34:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 03, 2011 at 09:32:07AM +0200, Matthieu Moy wrote:\n\n> Hilco Wijbenga writes:\n> \n> > Yes, I meant it literally. And, no, Git could not possibly know so it\n> > would have to be optional behaviour. But it's probably a lot of work\n> > for (for most people) little gain.\n> \n> Not only little gain, but also important risk: users of this feature\n> would be likely to spend hours debugging something just because some\n> files weren't recompiled at the right time.\n> \n> If you want to optimize the number of files compiled by \"make\", then\n> ccache is your friend. This one is safe.\n\nYes. Despite my previous message showing what _could_ be done, I do\nthink it's crazy. You should just use ccache.\n\nSpeaking of which; does anybody know of a git-aware ccache-like tool?\nWe already have a nice index of the sha1 of each file in the repository\n(along with a stat cache showing us whether it's up-to-date or not).\nSomething like ccache could avoid even looking in the C files at all if\nit relied on git's index.\n\nI don't know how much speedup it would yield in practice, though.\n\n-Peff\n"},{"id":"176715","messageId":"vpqmxdiikt2.fsf@bauges.imag.fr","threadId":"28143","inReplyTo":"20111003073456.GA10054@sigill.intra.peff.net","subject":"Re: Branches & directories","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-10-03T07:41:29Z","receivedAt":"2011-10-03T07:41:29Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> Speaking of which; does anybody know of a git-aware ccache-like tool?\n> We already have a nice index of the sha1 of each file in the repository\n> (along with a stat cache showing us whether it's up-to-date or not).\n> Something like ccache could avoid even looking in the C files at all if\n> it relied on git's index.\n\nIt would be a bit harder than that I think. IIRC, ccache hashes the\npreprocessed file, hence it will notice if a .h file changed, even if\nit's outside the project.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"176717","messageId":"20111003074412.GC9455@sigill.intra.peff.net","threadId":"28143","inReplyTo":"vpqmxdiikt2.fsf@bauges.imag.fr","subject":"Re: Branches & directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-03T07:44:12Z","receivedAt":"2011-10-03T07:44:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 03, 2011 at 09:41:29AM +0200, Matthieu Moy wrote:\n\n> Jeff King writes:\n> \n> > Speaking of which; does anybody know of a git-aware ccache-like tool?\n> > We already have a nice index of the sha1 of each file in the repository\n> > (along with a stat cache showing us whether it's up-to-date or not).\n> > Something like ccache could avoid even looking in the C files at all if\n> > it relied on git's index.\n> \n> It would be a bit harder than that I think. IIRC, ccache hashes the\n> preprocessed file, hence it will notice if a .h file changed, even if\n> it's outside the project.\n\nYeah, you'd have to maintain your own dependency tree, then. Which is\nnasty (aside from the work involved), because I don't think you can\nportably get the header dependencies out of the C compiler.\n\nOh well.\n\n-Peff\n"},{"id":"176719","messageId":"7v4nzqikhg.fsf@alter.siamese.dyndns.org","threadId":"28143","inReplyTo":"20111003074412.GC9455@sigill.intra.peff.net","subject":"Re: Branches & directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-03T07:48:27Z","receivedAt":"2011-10-03T07:48:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, you'd have to maintain your own dependency tree, then. Which is\n> nasty (aside from the work involved), because I don't think you can\n> portably get the header dependencies out of the C compiler.\n\nHeh, but doesn't your Makefile know the header dependencies anyway?\n"},{"id":"176720","messageId":"20111003075158.GA10965@sigill.intra.peff.net","threadId":"28143","inReplyTo":"7v4nzqikhg.fsf@alter.siamese.dyndns.org","subject":"Re: Branches & directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-10-03T07:51:58Z","receivedAt":"2011-10-03T07:51:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 03, 2011 at 12:48:27AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yeah, you'd have to maintain your own dependency tree, then. Which is\n> > nasty (aside from the work involved), because I don't think you can\n> > portably get the header dependencies out of the C compiler.\n> \n> Heh, but doesn't your Makefile know the header dependencies anyway?\n\nSort of. It's often wrong (e.g., we are way over-inclusive in the git\nMakefile; one of the things I like about ccache is that even when our\nMakefile is overly conservative, ccache is fast. Or at least faster than\nactually recompiling).\n\nAnd of course it doesn't generally involve headers outside of your\nproject, whereas ccache does recompile if those change.\n\n-Peff\n"},{"id":"176747","messageId":"4E89CDCA.9030802@gmail.com","threadId":"28143","inReplyTo":"CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com","subject":"Re: Branches & directories","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@gmail.com","sentAt":"2011-10-03T14:59:22Z","receivedAt":"2011-10-03T14:59:22Z","isPatch":false,"sender":{"key":"robin.rosenberg@gmail.com","avatar":null},"body":"Hilco Wijbenga skrev 2011-10-03 09.15:\n> On 2 October 2011 20:07, Jeff King wrote:\n> \n>> Or did you really mean your example literally, as in you run two\n>> checkouts back to back, without running anything in between, and the\n>> second checkout restores the state before the first one. In that case,\n>> yes, it would be correct to keep the old timestamps. But this is an\n>> optimization that can only apply in a few very specific cases. And\n>> moreoever, how can git know when it is OK to apply that optimization? It\n>> has no idea what commands you might have run since the last time we were\n>> at \"master\".\n> Yes, I meant it literally. And, no, Git could not possibly know so it\n> would have to be optional behaviour. But it's probably a lot of work\n> for (for most people) little gain.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\nI wouldn't use stash for that. Just regular commit/amend and your\ntimestamps should be fine. Alternative submit a patch for either\nthe save or create subcommands of stash. That would not be very\nhard (technically) and no one needs to mess with the timestamps;\nthey will just survive.\n\n-- robin\n"},{"id":"176755","messageId":"CAE1pOi1QvcoO9GVwH4-z_gvNVNBQi78JP5mmmwNaRkJOH=W-SQ@mail.gmail.com","threadId":"28143","inReplyTo":"4E89CDCA.9030802@gmail.com","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-03T17:20:11Z","receivedAt":"2011-10-03T17:20:11Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 3 October 2011 07:59, Robin Rosenberg wrote:\n> Hilco Wijbenga skrev 2011-10-03 09.15:\n>>\n>> On 2 October 2011 20:07, Jeff King  wrote:\n>> \n>>>\n>>> Or did you really mean your example literally, as in you run two\n>>> checkouts back to back, without running anything in between, and the\n>>> second checkout restores the state before the first one. In that case,\n>>> yes, it would be correct to keep the old timestamps. But this is an\n>>> optimization that can only apply in a few very specific cases. And\n>>> moreoever, how can git know when it is OK to apply that optimization? It\n>>> has no idea what commands you might have run since the last time we were\n>>> at \"master\".\n>>\n>> Yes, I meant it literally. And, no, Git could not possibly know so it\n>> would have to be optional behaviour. But it's probably a lot of work\n>> for (for most people) little gain.\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>>\n> I wouldn't use stash for that. Just regular commit/amend and your\n> timestamps should be fine. Alternative submit a patch for either\n> the save or create subcommands of stash. That would not be very\n> hard (technically)  and no one needs to mess with the timestamps;\n> they will just survive.\n\nBy \"that\" you mean jump to another branch? I don't see how doing an\nexplicit commit changes anything. Stashing is essentially committing\n(i.e. a \"dummy\" commit is created to store the stash, IIUC), isn't it?\n\nAs I mentioned before, I'm quite happy with git-new-workdir. It allows\nme to work exactly the way I want. I may have some philosophical\nreservations about Git's timestamp handling but practically speaking\nI'm a happy little camper. :-)\n"},{"id":"176756","messageId":"CAE1pOi2Vzqp2X95AE6DHhPvCCUURS+H4rTqr53-kxCuRhzSS4g@mail.gmail.com","threadId":"28143","inReplyTo":"vpqaa9ijzt4.fsf@bauges.imag.fr","subject":"Re: Branches & directories","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-10-03T17:31:20Z","receivedAt":"2011-10-03T17:31:20Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 3 October 2011 00:32, Matthieu Moy wrote:\n> Hilco Wijbenga writes:\n>\n>> Yes, I meant it literally. And, no, Git could not possibly know so it\n>> would have to be optional behaviour. But it's probably a lot of work\n>> for (for most people) little gain.\n>\n> Not only little gain, but also important risk: users of this feature\n> would be likely to spend hours debugging something just because some\n> files weren't recompiled at the right time.\n\nPossibly. When I do a git pull or similar I do a full build\nregardless. I don't know of any build tool that triggers a build\nbecause of a deleted source file (that's an actual problem I ran into\nonly a couple of weeks ago). Of course, in that scenario the build was\nsucceeding where it should have been failing. :-)\n\n> If you want to optimize the number of files compiled by \"make\", then\n> ccache is your friend. This one is safe.\n\nThis is all C, right? I'm in Java land so I would assume ccache is of\nno use to me. And we certainly don't use make.\n"}]}