{"thread":{"id":"8592","subject":"Re: pull into dirty working tree","startedAt":"2007-06-13T15:03:58Z","lastAt":"2007-06-13T23:32:13Z","messageCount":8,"participants":["MichaelTiloDressel@t-online.de","Bill Lear","Michael Dressel","Johannes Schindelin","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44944","messageId":"1HyUO6-04z4yG0@fwd28.aul.t-online.de","threadId":"8592","inReplyTo":null,"subject":"Re: pull into dirty working tree","fromName":"MichaelTiloDressel@t-online.de","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-06-13T15:03:58Z","receivedAt":"2007-06-13T15:03:58Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"Hi,\n\nwhy don't they just do a simple \ngit commit -a\nof their work before pulling?\n\nThat's different to cvs! Committing only affects the cloned repository.\n\nI think one of the biggest advantages of git is the concept of everyone\nworking on a clone. So developers are not prevented from actually using\nrevision control just because they are afraid of disturbing others. They\ndon't until they e.g. push!\n\n\nCheers,\nMichael\n"},{"id":"44950","messageId":"18032.3836.710438.73912@lisa.zopyra.com","threadId":"8592","inReplyTo":"1HyUO6-04z4yG0@fwd28.aul.t-online.de","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T15:36:28Z","receivedAt":"2007-06-13T15:36:28Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes:\n>Hi,\n>\n>why don't they just do a simple \n>git commit -a\n>of their work before pulling?\n\nBecause they are basically playing with some code and don't want to\ncommit it.\n\n>That's different to cvs! Committing only affects the cloned repository.\n\nYup, we realize that.\n\n>I think one of the biggest advantages of git is the concept of everyone\n>working on a clone. So developers are not prevented from actually using\n>revision control just because they are afraid of disturbing others. They\n>don't until they e.g. push!\n\nRight, but they just want updates to their working tree, as they could\ndo under CVS, without issuing five (or even one) other commands.\n\n\nBill\n"},{"id":"44976","messageId":"Pine.LNX.4.64.0706131916270.5241@castor.milkiway.cos","threadId":"8592","inReplyTo":"18032.3836.710438.73912@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-06-13T17:31:50Z","receivedAt":"2007-06-13T17:31:50Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"Hi,\n\nbut even if they just play with the code. Why not always commit?\nAs long as they don't push nobody else will be affected.\n\nEven if you play with the code it's useful to go back to earlier \nversions. Why would you not want to benefit from this possibility?\n\nSo this would really only be two commands the commit and the pull command.\n\nI hope I didn't miss your point completely.\n\nCheers\nMichael\n\nOn Wed, 13 Jun 2007, Bill Lear wrote:\n\n> On Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes:\n> >Hi,\n> >\n> >why don't they just do a simple \n> >git commit -a\n> >of their work before pulling?\n> \n> Because they are basically playing with some code and don't want to\n> commit it.\n> \n> >That's different to cvs! Committing only affects the cloned repository.\n> \n> Yup, we realize that.\n> \n> >I think one of the biggest advantages of git is the concept of everyone\n> >working on a clone. So developers are not prevented from actually using\n> >revision control just because they are afraid of disturbing others. They\n> >don't until they e.g. push!\n> \n> Right, but they just want updates to their working tree, as they could\n> do under CVS, without issuing five (or even one) other commands.\n> \n> \n> Bill\n> \n"},{"id":"44980","messageId":"18032.13176.649702.276044@lisa.zopyra.com","threadId":"8592","inReplyTo":"Pine.LNX.4.64.0706131916270.5241@castor.milkiway.cos","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T18:12:08Z","receivedAt":"2007-06-13T18:12:08Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, June 13, 2007 at 19:31:50 (+0200) Michael Dressel writes:\n>Hi,\n>\n>but even if they just play with the code. Why not always commit?\n>As long as they don't push nobody else will be affected.\n>\n>Even if you play with the code it's useful to go back to earlier \n>versions. Why would you not want to benefit from this possibility?\n>\n>So this would really only be two commands the commit and the pull command.\n>\n>I hope I didn't miss your point completely.\n\nNot completely: they don't want to commit, as this will then \"pollute\"\nthe history in their working repository (which is just temporarily\nbeing used to play with a new feature, idea, bug fix, optimization,\netc.).  This pollution with a handful of garbage would then have to be\nundone were they to say \"ok, that's really not a good idea\".  If a\npull into a dirty tree were possible, that last step could be just a\nsimple reset, or continuing to explore with the code, etc.\n\nTheir benchmark is CVS: CVS lets them do this easily (and yes, I\nunderstand that CVS sucks compared to git, so don't even start), and\nso even if they have to have 2 commands to do what they did in CVS\nwith 1, they complain.  My job is to either justify what git does to\nthem to shut them up, or to speak to the git community to see if their\ndesires are remotely rational.\n\nIt seems to me, based on several posts here, particularly Junio's,\nthat they are being remotely rational and it might be a reasonable\naddition to git to be able to say \"git pull --dirty\" or whatever...\n\n\nBill\n"},{"id":"44983","messageId":"Pine.LNX.4.64.0706131929020.4059@racer.site","threadId":"8592","inReplyTo":"18032.13176.649702.276044@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T18:30:23Z","receivedAt":"2007-06-13T18:30:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Jun 2007, Bill Lear wrote:\n\n> Not completely: they don't want to commit, as this will then \"pollute\"\n> the history in their working repository (which is just temporarily\n> being used to play with a new feature, idea, bug fix, optimization,\n> etc.).  This pollution with a handful of garbage would then have to be\n> undone were they to say \"ok, that's really not a good idea\".  If a\n> pull into a dirty tree were possible, that last step could be just a\n> simple reset, or continuing to explore with the code, etc.\n\nNotice that I am _not_ saying that CVS is bad. I am saying that their \nworkflow is likely bad (and yes, they should change that workflow, since \nthey now _can_).\n\nTwo things do they risk happily, which they should not do:\n\n- they test their new feature against different references. For example, \n  it might well be that they tested cases A, B, and C before pull, and D, \n  E and F after that. It is really easy to get lost in what you have, and \n  what not. Now, guess what. Merges are known to break things sometimes. \n  Even the best merge algorithm. Now your developers say \"we tested it, \n  and the merge broke it, it's not our fault\". But it is.\n\n- That new feature will have to be committed at some stage. Either your \n  devs commit at the end, which makes it a monster commit, which is bad. \n  Or they are _already_ using the suggested workflow \"commit && pull\", \n  which makes your whole complaint moot.\n\nCiao,\nDscho\n"},{"id":"44988","messageId":"18032.15862.835008.22589@lisa.zopyra.com","threadId":"8592","inReplyTo":"Pine.LNX.4.64.0706131929020.4059@racer.site","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T18:56:54Z","receivedAt":"2007-06-13T18:56:54Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Wed, 13 Jun 2007, Bill Lear wrote:\n>\n>> Not completely: they don't want to commit, as this will then \"pollute\"\n>> the history in their working repository (which is just temporarily\n>> being used to play with a new feature, idea, bug fix, optimization,\n>> etc.).  This pollution with a handful of garbage would then have to be\n>> undone were they to say \"ok, that's really not a good idea\".  If a\n>> pull into a dirty tree were possible, that last step could be just a\n>> simple reset, or continuing to explore with the code, etc.\n>\n>Notice that I am _not_ saying that CVS is bad. I am saying that their \n>workflow is likely bad (and yes, they should change that workflow, since \n>they now _can_).\n\nYes, I have urged this.  But, they are stubborn, smart people, and if\nthey see tool X allow something, they wonder why tool Y does not\nsupport it.\n\n>Two things do they risk happily, which they should not do:\n>\n>- they test their new feature against different references. For example, \n>  it might well be that they tested cases A, B, and C before pull, and D, \n>  E and F after that. It is really easy to get lost in what you have, and \n>  what not. Now, guess what. Merges are known to break things sometimes. \n>  Even the best merge algorithm. Now your developers say \"we tested it, \n>  and the merge broke it, it's not our fault\". But it is.\n\nWell, their testing is something along the line of \"I'm going to hack\nsomething here, and then I want to see if Joe's latest changes work\nwith it\".  Then, they want to pull in Joe's changes, run a test, and\nif their changes don't work, fix them, discard them, etc.\n\n>- That new feature will have to be committed at some stage. Either your \n>  devs commit at the end, which makes it a monster commit, which is bad. \n>  Or they are _already_ using the suggested workflow \"commit && pull\", \n>  which makes your whole complaint moot.\n\nPerhaps: again, they may just be taking stabs that they know are wild,\nand will likely not be committed.\n\nI'm not trying to argue for their point: I do most of my new work\non branches, very rarely on the master branch, and can handle\nthe git pull not working in a dirty tree with merge issues.\n\nSome of the people we work with are not developers per se: they are\nengineers who sometimes like to fiddle (say, with a compiler\noptimization setting) and who never push into our company repo.\nThey only see CVS and compare git to it.  When git prevents you\nfrom doing something they see as perfectly reasonable, they get\nannoyed and say \"git sucks\".  I'm battling in the git corner against\nthis, but there is only so much I can do.\n\n\nBill\n"},{"id":"44997","messageId":"200706132217.57075.robin.rosenberg.lists@dewire.com","threadId":"8592","inReplyTo":"18032.15862.835008.22589@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-06-13T20:17:56Z","receivedAt":"2007-06-13T20:17:56Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 13 juni 2007 skrev Bill Lear:\n> On Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes:\n> >Hi,\n> >\n> >On Wed, 13 Jun 2007, Bill Lear wrote:\n> >\n> >> Not completely: they don't want to commit, as this will then \"pollute\"\n> >> the history in their working repository (which is just temporarily\n> >> being used to play with a new feature, idea, bug fix, optimization,\n> >> etc.).  This pollution with a handful of garbage would then have to be\n> >> undone were they to say \"ok, that's really not a good idea\".  If a\n> >> pull into a dirty tree were possible, that last step could be just a\n> >> simple reset, or continuing to explore with the code, etc.\n> >\n> >Notice that I am _not_ saying that CVS is bad. I am saying that their \n> >workflow is likely bad (and yes, they should change that workflow, since \n> >they now _can_).\n> \n> Yes, I have urged this.  But, they are stubborn, smart people, and if\n> they see tool X allow something, they wonder why tool Y does not\n> support it.\n> \n> >Two things do they risk happily, which they should not do:\n> >\n> >- they test their new feature against different references. For example, \n> >  it might well be that they tested cases A, B, and C before pull, and D, \n> >  E and F after that. It is really easy to get lost in what you have, and \n> >  what not. Now, guess what. Merges are known to break things sometimes. \n> >  Even the best merge algorithm. Now your developers say \"we tested it, \n> >  and the merge broke it, it's not our fault\". But it is.\n> \n> Well, their testing is something along the line of \"I'm going to hack\n> something here, and then I want to see if Joe's latest changes work\n> with it\".  Then, they want to pull in Joe's changes, run a test, and\n> if their changes don't work, fix them, discard them, etc.\n> \n> >- That new feature will have to be committed at some stage. Either your \n> >  devs commit at the end, which makes it a monster commit, which is bad. \n> >  Or they are _already_ using the suggested workflow \"commit && pull\", \n> >  which makes your whole complaint moot.\n> \n> Perhaps: again, they may just be taking stabs that they know are wild,\n> and will likely not be committed.\n> \n> I'm not trying to argue for their point: I do most of my new work\n> on branches, very rarely on the master branch, and can handle\n> the git pull not working in a dirty tree with merge issues.\n> \n> Some of the people we work with are not developers per se: they are\n> engineers who sometimes like to fiddle (say, with a compiler\n> optimization setting) and who never push into our company repo.\n> They only see CVS and compare git to it.  When git prevents you\n> from doing something they see as perfectly reasonable, they get\n> annoyed and say \"git sucks\".  I'm battling in the git corner against\n> this, but there is only so much I can do.\n\nA typical case I recognize is a few printfs or disabling a feature that makes \nit harder to debug with no intentions whatsoever to commit them. What we see \nwhen the tools more or less forces people to \"temporarily\" commit stuff is \nthat that stuff is often left there. \"Oh, I forgot\". Gah.\n\nGit has this ability when checking out, so why not on pull or merge?\n\nWith stacked git I typically create a new patch, then I can push it whenever I \nwant to have some more tracing.\n\n-- robin\n"},{"id":"45020","messageId":"Pine.LNX.4.64.0706140030400.4059@racer.site","threadId":"8592","inReplyTo":"200706132217.57075.robin.rosenberg.lists@dewire.com","subject":"Re: pull into dirty working tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T23:32:13Z","receivedAt":"2007-06-13T23:32:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Ho,\n\nOn Wed, 13 Jun 2007, Robin Rosenberg wrote:\n\n> A typical case I recognize is a few printfs or disabling a feature that \n> makes it harder to debug with no intentions whatsoever to commit them. \n> What we see when the tools more or less forces people to \"temporarily\" \n> commit stuff is that that stuff is often left there. \"Oh, I forgot\". \n> Gah.\n> \n> Git has this ability when checking out, so why not on pull or merge?\n\nYou should hold your breath for git-stash. Now that Junio declared he'd \nwork on it.\n\n> With stacked git I typically create a new patch, then I can push it \n> whenever I want to have some more tracing.\n\nMy evil plan is to work git-stash into sort of a lightweight StGit. I \nnever liked that dependency to Python, and I always felt that it must be \nsimpler than that.\n\nCiao,\nDscho\n"}]}