{"thread":{"id":"8590","subject":"pull into dirty working tree","startedAt":"2007-06-13T14:14:32Z","lastAt":"2007-06-15T18:26:58Z","messageCount":35,"participants":["Bill Lear","Pierre Habouzit","Randal L. Schwartz","Johannes Schindelin","Andy Parkins","Junio C Hamano","Alex Riesen","Daniel Barkalow","Linus Torvalds","Raimund Bauer","Steven Grimm","Nicolas Pitre","Olivier Galibert","Martin Langhoff","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44933","messageId":"18031.64456.948230.375333@lisa.zopyra.com","threadId":"8590","inReplyTo":null,"subject":"pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T14:14:32Z","receivedAt":"2007-06-13T14:14:32Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"We have some CVS users who complain that they cannot do a pull\ninto a dirty working tree, as they could under CVS.  Here is\ntheir scenario: they make a few changes to their code and want\nto test it out; someone else pushes changes to the central repo\nthat they then want to add to their working tree to test also;\nthey then want to pull in these changes and test everything, as\nif they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n\nThey would like an option (perhaps a config option) to do a \"dirty\npull\".\n\nThe git-merge documentation states:\n\n  You may have local modifications in the working tree files. In other\n  words, git-diff is allowed to report changes. However, the merge uses\n  your working tree as the working area, and in order to prevent the\n  merge operation from losing such changes, it makes sure that they do\n  not interfere with the merge. Those complex tables in read-tree\n  documentation define what it means for a path to \"interfere with the\n  merge\". And if your local modifications interfere with the merge,\n  again, it stops before touching anything.\n\nBut my colleagues are still wondering: why can't git just do it as\nCVS does?\n\nI know there are workarounds: I myself documented a set of commands\nto \"put things on a shelf\", but they still are whining.\n\nI need a convincing argument: not a technical one, but one that is\npractical (e.g. where CVS would do harm that git is preventing).\n\nSo, any explanation that I can give them why we can't have a 'git pull\n--dirty' that moves things out of the way, then does the merge, then\nmoves thing back, aside from that it is stupid?\n\n\nBill\n"},{"id":"44934","messageId":"20070613143845.GD5311@artemis.intersec.eu","threadId":"8590","inReplyTo":"18031.64456.948230.375333@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-13T14:38:45Z","receivedAt":"2007-06-13T14:38:45Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 13, 2007 at 09:14:32AM -0500, Bill Lear wrote:\n> We have some CVS users who complain that they cannot do a pull\n> into a dirty working tree, as they could under CVS.  Here is\n> their scenario: they make a few changes to their code and want\n> to test it out; someone else pushes changes to the central repo\n> that they then want to add to their working tree to test also;\n> they then want to pull in these changes and test everything, as\n> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n> \n> They would like an option (perhaps a config option) to do a \"dirty\n> pull\".\n> \n> The git-merge documentation states:\n> \n>   You may have local modifications in the working tree files. In other\n>   words, git-diff is allowed to report changes. However, the merge uses\n>   your working tree as the working area, and in order to prevent the\n>   merge operation from losing such changes, it makes sure that they do\n>   not interfere with the merge. Those complex tables in read-tree\n>   documentation define what it means for a path to \"interfere with the\n>   merge\". And if your local modifications interfere with the merge,\n>   again, it stops before touching anything.\n> \n> But my colleagues are still wondering: why can't git just do it as\n> CVS does?\n> \n> I know there are workarounds: I myself documented a set of commands\n> to \"put things on a shelf\", but they still are whining.\n> \n> I need a convincing argument: not a technical one, but one that is\n> practical (e.g. where CVS would do harm that git is preventing).\n> \n> So, any explanation that I can give them why we can't have a 'git pull\n> --dirty' that moves things out of the way, then does the merge, then\n> moves thing back, aside from that it is stupid?\n\n  I suppose the following way would work:\n\n  $ git commit -a -m \"temporary commit\"  # save current work\n  $ git branch -f dirty                  # ..in a separate branch\n  $ git reset --hard HEAD~1              # unwind this commit\n  $ git pull                             # perform a clean pull\n  $ git rebase master dirty              # rewrite the work\n  <you may have to fix some conficts here>\n  $ git reset master                     # \"undo\" the commit\n\n  So that's definitely doable.\n\n  Though, in git, if you really work in a \"pure\" git environment, you\nnever pull until your work in your topic branch is ready for a merge.\nIt's a very bad habit to do otherwise: you don't _need_ to pull until\nyou have a clean slate.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44935","messageId":"20070613144311.GE5311@artemis.intersec.eu","threadId":"8590","inReplyTo":"20070613143845.GD5311@artemis.intersec.eu","subject":"Re: pull into dirty working tree","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-13T14:43:11Z","receivedAt":"2007-06-13T14:43:11Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 13, 2007 at 04:38:45PM +0200, Pierre Habouzit wrote:\n> On Wed, Jun 13, 2007 at 09:14:32AM -0500, Bill Lear wrote:\n> > We have some CVS users who complain that they cannot do a pull\n> > into a dirty working tree, as they could under CVS.  Here is\n> > their scenario: they make a few changes to their code and want\n> > to test it out; someone else pushes changes to the central repo\n> > that they then want to add to their working tree to test also;\n> > they then want to pull in these changes and test everything, as\n> > if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n> > \n> > They would like an option (perhaps a config option) to do a \"dirty\n> > pull\".\n> > \n> > The git-merge documentation states:\n> > \n> >   You may have local modifications in the working tree files. In other\n> >   words, git-diff is allowed to report changes. However, the merge uses\n> >   your working tree as the working area, and in order to prevent the\n> >   merge operation from losing such changes, it makes sure that they do\n> >   not interfere with the merge. Those complex tables in read-tree\n> >   documentation define what it means for a path to \"interfere with the\n> >   merge\". And if your local modifications interfere with the merge,\n> >   again, it stops before touching anything.\n> > \n> > But my colleagues are still wondering: why can't git just do it as\n> > CVS does?\n> > \n> > I know there are workarounds: I myself documented a set of commands\n> > to \"put things on a shelf\", but they still are whining.\n> > \n> > I need a convincing argument: not a technical one, but one that is\n> > practical (e.g. where CVS would do harm that git is preventing).\n> > \n> > So, any explanation that I can give them why we can't have a 'git pull\n> > --dirty' that moves things out of the way, then does the merge, then\n> > moves thing back, aside from that it is stupid?\n> \n>   I suppose the following way would work:\n> \n>   $ git commit -a -m \"temporary commit\"  # save current work\n>   $ git branch -f dirty                  # ..in a separate branch\n>   $ git reset --hard HEAD~1              # unwind this commit\n>   $ git pull                             # perform a clean pull\n>   $ git rebase master dirty              # rewrite the work\n>   <you may have to fix some conficts here>\n\n>   $ git reset master                     # \"undo\" the commit\n\n  okay this is wrong because you would then \"live\" in the `dirty`\nbranch. So you'd have to do sth like:\n\n   git checkout master\n   git diff master..dirty | git apply\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44936","messageId":"18032.776.784080.321044@lisa.zopyra.com","threadId":"8590","inReplyTo":"20070613143845.GD5311@artemis.intersec.eu","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T14:45:28Z","receivedAt":"2007-06-13T14:45:28Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"[Pierre writes:]\n>  I suppose the following way would work:\n>\n>  $ git commit -a -m \"temporary commit\"  # save current work\n>  $ git branch -f dirty                  # ..in a separate branch\n>  $ git reset --hard HEAD~1              # unwind this commit\n>  $ git pull                             # perform a clean pull\n>  $ git rebase master dirty              # rewrite the work\n>  <you may have to fix some conficts here>\n>  $ git reset master                     # \"undo\" the commit\n>\n>  So that's definitely doable.\n>\n>  Though, in git, if you really work in a \"pure\" git environment, you\n>never pull until your work in your topic branch is ready for a merge.\n>It's a very bad habit to do otherwise: you don't _need_ to pull until\n>you have a clean slate.\n\nI know, but I can't throw git purity at them as an explanation, they\nwon't understand.  And they would disagree about the \"need\" to pull.\nThat's for them to say: they WANT to pull without having to move aside\nthe makefile that they modified to add the '-wingit' option to the\ncompile line and just get on with their work without having to run 14\ndifferent git commands.\n\nI'm not trying to justify their habits, but to try to see if there is\nany clinching reason why this habit is not only \"bad\", but positively\nharmful.\n\n\nBill\n"},{"id":"44938","messageId":"20070613144743.GF5311@artemis.intersec.eu","threadId":"8590","inReplyTo":"20070613144311.GE5311@artemis.intersec.eu","subject":"Re: pull into dirty working tree","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-13T14:47:43Z","receivedAt":"2007-06-13T14:47:43Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 13, 2007 at 04:43:11PM +0200, Pierre Habouzit wrote:\n> On Wed, Jun 13, 2007 at 04:38:45PM +0200, Pierre Habouzit wrote:\n\n> >   I suppose the following way would work:\n> > \n> >   $ git commit -a -m \"temporary commit\"  # save current work\n> >   $ git branch -f dirty                  # ..in a separate branch\n> >   $ git reset --hard HEAD~1              # unwind this commit\n> >   $ git pull                             # perform a clean pull\n> >   $ git rebase master dirty              # rewrite the work\n> >   <you may have to fix some conficts here>\n> \n> >   $ git reset master                     # \"undo\" the commit\n> \n>   okay this is wrong because you would then \"live\" in the `dirty`\n> branch. So you'd have to do sth like:\n> \n>    git checkout master\n>    git diff master..dirty | git apply\n\n  Alternatively and definitely shorter:\n\n  $ git commit -a -m \"temporary commit\"        # save the current work\n  $ git checkout -f -b dirty HEAD~1            # have a dirty branch for the pull\n  $ git pull                                   # perform the pull\n  $ git rebase dirty master                    # rewrite the work\n  <you may have to fix some conficts here>\n  $ git reset HEAD~1                           # then unwind the commit\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44940","messageId":"20070613145342.GG5311@artemis.intersec.eu","threadId":"8590","inReplyTo":"18032.776.784080.321044@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-13T14:53:42Z","receivedAt":"2007-06-13T14:53:42Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 13, 2007 at 09:45:28AM -0500, Bill Lear wrote:\n> [Pierre writes:]\n> >  I suppose the following way would work:\n> >\n> >  $ git commit -a -m \"temporary commit\"  # save current work\n> >  $ git branch -f dirty                  # ..in a separate branch\n> >  $ git reset --hard HEAD~1              # unwind this commit\n> >  $ git pull                             # perform a clean pull\n> >  $ git rebase master dirty              # rewrite the work\n> >  <you may have to fix some conficts here>\n> >  $ git reset master                     # \"undo\" the commit\n> >\n> >  So that's definitely doable.\n> >\n> >  Though, in git, if you really work in a \"pure\" git environment, you\n> >never pull until your work in your topic branch is ready for a merge.\n> >It's a very bad habit to do otherwise: you don't _need_ to pull until\n> >you have a clean slate.\n> \n> I know, but I can't throw git purity at them as an explanation, they\n> won't understand.  And they would disagree about the \"need\" to pull.\n> That's for them to say: they WANT to pull without having to move aside\n> the makefile that they modified to add the '-wingit' option to the\n> compile line and just get on with their work without having to run 14\n> different git commands.\n> \n> I'm not trying to justify their habits, but to try to see if there is\n> any clinching reason why this habit is not only \"bad\", but positively\n> harmful.\n\n  If it's because they have local modifications that match their use and\nare not meant to be commited then I'd say that leaving it as \"unclean\"\nwork is a bad idea, because one day or the other they will have to\nmodify this Makefile to add a thing to commit for real. and then, 99\ntimes over 100 they will commit their local modification too. _that_ is\nharmful. And usually there is very soon a new commit to remove the local\nchange.\n\n  I have a project where we had .htaccess that people had to customize\nto have their local checkout work in the devel web server setup. It was\nalways commited (wrongly). We weren't using git.\n\n  To solve those issues, there is many ways, not all are very handy, but\nit works. The simplest way is to use a repository with a tool like\nguilt, and each time you commit, you:\n\n  guilt pop -a (remove your changes)\n  ... do the stuff ...\n  guilt push -a (push your changes again).\n\n  Maybe you can also have a local branch where you store those local\nchanges. But that's still a bit awkward to use. Maybe someone will come\nwith a better workflow for this.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44942","messageId":"86zm33291h.fsf@blue.stonehenge.com","threadId":"8590","inReplyTo":"18031.64456.948230.375333@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-06-13T15:01:14Z","receivedAt":"2007-06-13T15:01:14Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Bill\" == Bill Lear <rael@zopyra.com> writes:\n\nBill> We have some CVS users who complain that they cannot do a pull\nBill> into a dirty working tree, as they could under CVS.  Here is\nBill> their scenario: they make a few changes to their code and want\nBill> to test it out; someone else pushes changes to the central repo\nBill> that they then want to add to their working tree to test also;\nBill> they then want to pull in these changes and test everything, as\nBill> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n\nBill> They would like an option (perhaps a config option) to do a \"dirty\nBill> pull\".\n\nMaybe this will do it, presuming they haven't published any of their local\nwork, and they're on a topic branch \"topic\"\n\ngit-tag WIP # mark HEAD so we can come back\ngit-commit -a -m WIP # commit current work so we can replay it\ngit-fetch origin # grabs the upstream\ngit-rebase origin # rebase current work-in-progress onto new upstream\n# might need to resolve and commit conflicts repeatedly\ngit-reset --soft WIP # next commit will be on top of commit prior to rebase\ngit-reset # mark all files as uncommitted as yet\ngit-tag -d WIP # no more need for this tag\n\nThis effectively puts the upstream changes \"under\" (or \"prior to\") the current\ntopic branch.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"44945","messageId":"Pine.LNX.4.64.0706131559210.4059@racer.site","threadId":"8590","inReplyTo":"18031.64456.948230.375333@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T15:01:56Z","receivedAt":"2007-06-13T15:01:56Z","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> We have some CVS users who complain that they cannot do a pull\n> into a dirty working tree, as they could under CVS.\n\nTwo things you can do. First thing is: teach them to commit first. If they \ndecide later that they did not want that change, they still can go back \nwith \"git reset HEAD@{2}\".\n\nThe other thing, if you have to, is to put all dirty changes into the \nindex before pull. Something like \"git add $(git ls-files --modified)\". \nYou can even make that a global alias for your users. Although IIRC it \ndoes not work if the merge changes the same files as your dirty work tree \ntouches, but I could very well be wrong there.\n\nHth,\nDscho\n"},{"id":"44951","messageId":"200706131640.22588.andyparkins@gmail.com","threadId":"8590","inReplyTo":"Pine.LNX.4.64.0706131559210.4059@racer.site","subject":"Re: pull into dirty working tree","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-13T15:40:18Z","receivedAt":"2007-06-13T15:40:18Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 June 13, Johannes Schindelin wrote:\n\n> The other thing, if you have to, is to put all dirty changes into the\n> index before pull. Something like \"git add $(git ls-files --modified)\".\n\nOr the shiny new\n\n git add -u\n\nwhich works a treat :-)\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"44955","messageId":"Pine.LNX.4.64.0706131648070.4059@racer.site","threadId":"8590","inReplyTo":"200706131640.22588.andyparkins@gmail.com","subject":"Re: pull into dirty working tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T15:54:20Z","receivedAt":"2007-06-13T15:54:20Z","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, Andy Parkins wrote:\n\n> On Wednesday 2007 June 13, Johannes Schindelin wrote:\n> \n> > The other thing, if you have to, is to put all dirty changes into the\n> > index before pull. Something like \"git add $(git ls-files --modified)\".\n> \n> Or the shiny new\n> \n>  git add -u\n> \n> which works a treat :-)\n\nYeah, completely forgot about that.\n\nAnother idea just hit me: you could add this to your \"[alias]\" section:\n\n\tstash = !git add -u && \\\n\t\ttree=$(git-write-tree) && \\\n\t\tcommit=$(echo stash $(date) | \\\n\t\t\tgit-commit-tree $tree -p HEAD) && \\\n\t\tgit-update-ref refs/heads/stash $commit && \\\n\t\tgit-reset --hard\n\n\tup = !git stash && git pull && git cherry-pick -n stash\n\nOr something like that (untested!). Then, your users could use \"git up\" to \npull from origin, and reapply their changes on top, without committing.\n\nThis assumes that your users only have the remote \"origin\", but given \ntheir obvious \"objections\" to Git concepts, I think they do.\n\nCiao,\nDscho\n"},{"id":"44954","messageId":"18032.5016.716192.939675@lisa.zopyra.com","threadId":"8590","inReplyTo":"200706131640.22588.andyparkins@gmail.com","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T15:56:08Z","receivedAt":"2007-06-13T15:56: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 16:40:18 (+0100) Andy Parkins writes:\n>On Wednesday 2007 June 13, Johannes Schindelin wrote:\n>\n>> The other thing, if you have to, is to put all dirty changes into the\n>> index before pull. Something like \"git add $(git ls-files --modified)\".\n>\n>Or the shiny new\n>\n> git add -u\n>\n>which works a treat :-)\n\nBetter.\n\nI wonder, also, if there could be a way to alert users that their\nworking tree is dirty before all the git pull blather comes out,\nscaring their poor little souls?  So, instead of this:\n\n% git pull\nremote: Generating pack...\nremote: Done counting 122 objects.\nremote: Result has 90 objects.\nremote: Deltifying 90 objects.\nremote:  100% (90/90) done\nUnpacking 90 objects\nremote: Total 90 (delta 59), reused 41 (delta 10)\n 100% (90/90) done\n* refs/remotes/origin/master: fast forward to branch 'master' of\ngit://source/sc\n  old..new: 171b65f..0be3472\n* refs/remotes/origin/v1.0: fast forward to branch 'v1.0' of\ngit://source/sc\n  old..new: a9de9dd..efa3a73\nUpdating 717d9f6..0be3472\nsrc/fs/testsuite/fs.tst/gettest: needs update\nsrc/nl/EocCompiler.cc: needs update\nsrc/nl/EocCompiler.hh: needs update\nsrc/nl/Nl.cc: needs update\nfatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.\n\nwe could have:\n\n% git pull\nSorry, I can't pull, as you have a dirty working tree.  Please commit\nyour changes or move your files before you pull.  These are the\nfiles that are preventing this:\n\n    src/fs/testsuite/fs.tst/gettest\n    src/nl/EocCompiler.cc\n    src/nl/EocCompiler.hh\n    src/nl/Nl.cc\n\n\nBill\n"},{"id":"44957","messageId":"Pine.LNX.4.64.0706131702020.4059@racer.site","threadId":"8590","inReplyTo":"18032.5016.716192.939675@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T16:07:20Z","receivedAt":"2007-06-13T16:07:20Z","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> I wonder, also, if there could be a way to alert users that their \n> working tree is dirty before all the git pull blather comes out, scaring \n> their poor little souls?\n\nWell, it's their fault, isn't it?\n\n>  So, instead of this:\n> \n> % git pull\n> remote: Generating pack...\n> remote: Done counting 122 objects.\n> remote: Result has 90 objects.\n> remote: Deltifying 90 objects.\n> remote:  100% (90/90) done\n> Unpacking 90 objects\n> remote: Total 90 (delta 59), reused 41 (delta 10)\n>  100% (90/90) done\n> * refs/remotes/origin/master: fast forward to branch 'master' of\n> git://source/sc\n>   old..new: 171b65f..0be3472\n> * refs/remotes/origin/v1.0: fast forward to branch 'v1.0' of\n> git://source/sc\n>   old..new: a9de9dd..efa3a73\n> Updating 717d9f6..0be3472\n> src/fs/testsuite/fs.tst/gettest: needs update\n> src/nl/EocCompiler.cc: needs update\n> src/nl/EocCompiler.hh: needs update\n> src/nl/Nl.cc: needs update\n> fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.\n\nSorry, this is the first time Git can realize that the dirty working \ndirectory conflicts with the changes about to be applied.\n\nFor example, I run \"git pull\" very often with a modified Makefile. If the \nmerge would not touch the Makefile, it would succeed. No need to do \nanything fancy.\n\nIf you do have to shut the (otherwise useful) messages up, you can always \nhave an alias (using the advanced technique illustrated in another post in \nthis thread).\n\n> % git pull\n> Sorry, I can't pull, as you have a dirty working tree.  Please commit\n> your changes or move your files before you pull.  These are the\n> files that are preventing this:\n> \n>     src/fs/testsuite/fs.tst/gettest\n>     src/nl/EocCompiler.cc\n>     src/nl/EocCompiler.hh\n>     src/nl/Nl.cc\n\nAs far as I can see, gettest is not responsible, so this would be wrong.\n\nCiao,\nDscho\n"},{"id":"44963","messageId":"18032.7078.656285.877958@lisa.zopyra.com","threadId":"8590","inReplyTo":"Pine.LNX.4.64.0706131702020.4059@racer.site","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-13T16:30:30Z","receivedAt":"2007-06-13T16:30:30Z","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:07:20 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Wed, 13 Jun 2007, Bill Lear wrote:\n>\n>> I wonder, also, if there could be a way to alert users that their \n>> working tree is dirty before all the git pull blather comes out, scaring \n>> their poor little souls?\n>\n>Well, it's their fault, isn't it?\n\nYes, it is.  But that's no reason not to try to produce a nicer warning.\n\n>> fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.\n>\n>Sorry, this is the first time Git can realize that the dirty working \n>directory conflicts with the changes about to be applied.\n\nAh, this makes sense.  It has to do all the other stuff first and only\nwhen it comes across one that won't \"fit\" does it complain.  This makes\nmore sense now...\n\n\n\nBill\n"},{"id":"44972","messageId":"7vd4zzeq0s.fsf@assigned-by-dhcp.pobox.com","threadId":"8590","inReplyTo":"Pine.LNX.4.64.0706131559210.4059@racer.site","subject":"Re: pull into dirty working tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-13T17:13:39Z","receivedAt":"2007-06-13T17:13:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> The other thing, if you have to, is to put all dirty changes into the\n> index before pull. Something like \"git add $(git ls-files --modified)\".\n> You can even make that a global alias for your users. Although IIRC it\n> does not work if the merge changes the same files as your dirty work tree\n> touches, but I could very well be wrong there.\n\nI do not think that would change the issue in general, as the\nindex needs to be clean (wrt HEAD) during a conflicting merge.\n\nIncidentally, I was planning to start a \"stash dirty state and\nlater reapply on a different commit\" soon (if I survive an event\nplanned tomorrow, that is ;-).\n\nWhen you are in the middle of something (and when you are not in\nthe middle of a merge), you have two states you care about.\nWhat is in the index, and what is in the working tree.\nConceptually, even though you do _not_ have commits for these\ntwo extra states, your \"history\" would look like this:\n\n                 o <- working tree state = W\n                /\n               o <- index state = I\n              /\n      -------o <- HEAD\n\nA dirty merge (whether it is done as \"git checkout $another\",\n\"git merge $commit\", or \"git pull $somebodyelse\") is to first\nstash away I and W, perform the merge proper to advance HEAD,\nand after all that is done, recreate the index and working tree\nstate on top of the updated HEAD, to arrive at this:\n\n                 o  -->  * <- new working tree state = W'\n                /       /\n               o  -->  * <- new index state = I'\n              /       /\n      -------o-------* <- merge = new HEAD\n    old HEAD ^      /\n                   /\n      --------o---o <- other history\n\nThis can be internally done as four steps:\n\n * stash the dirty states (save I and W)\n\n   - record I by \"git commit\" (no parameters to commit the index).\n\n   - record W by \"git add . && git commit -a\".\n\n   - remember HEAD as $STASH.\n\n * match the working tree and the index to original HEAD by\n   \"reset HEAD^ && reset --hard HEAD\".  The first --mixed reset\n   is to forget about new files added with \"git add .\", so that\n   the second reset will not remove them from the working tree.\n\n * perform a merge in the resulting clean tree\n\n * unstash the dirty states\n\n   - I' is the three-way merge between $STASH~1 and the new HEAD\n     using $STASH~2 as the common ancestor.\n\n   - W' is the three-way merge between $STASH and I' using\n     $STASH~1 as the common ancestor.\n\nUnstashing operation can potentially require two merge conflict\nresolutions.  As we _care_ about distinction between the index\nstate and the working tree state, this is unavoidable.\n\n    Side note: as an implementation, it is a possibility not to\n    record I and record only W as the direct child of the HEAD\n    when stashing.  Unstashing would update only the working\n    tree (i.e. after unstashing, the index and the HEAD exactly\n    matches).  But it risks \"forgetting\" newly added files and I\n    would say it is unacceptable for that reason, even if we\n    declare that this feature is only for non-git people.\n\nCombined with the potential conflict resolution for the merge\nproper, you have to resolve up to three merges in a row.  One\nconflict resolution is something even CVS users must accept\nanyway, so we are talking about up to two _extra_ conflict\nresolutions here.\n"},{"id":"44990","messageId":"20070613192828.GB3412@steel.home","threadId":"8590","inReplyTo":"86zm33291h.fsf@blue.stonehenge.com","subject":"Re: pull into dirty working tree","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-13T19:28:28Z","receivedAt":"2007-06-13T19:28:28Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Randal L. Schwartz, Wed, Jun 13, 2007 17:01:14 +0200:\n> > We have some CVS users who complain that they cannot do a pull\n> > into a dirty working tree, as they could under CVS.  Here is\n> > their scenario: they make a few changes to their code and want\n> > to test it out; someone else pushes changes to the central repo\n> > that they then want to add to their working tree to test also;\n> > they then want to pull in these changes and test everything, as\n> > if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n> \n> > They would like an option (perhaps a config option) to do a \"dirty\n> > pull\".\n> \n> Maybe this will do it, presuming they haven't published any of their local\n> work, and they're on a topic branch \"topic\"\n> \n> git-tag WIP # mark HEAD so we can come back\n> git-commit -a -m WIP # commit current work so we can replay it\n> git-fetch origin # grabs the upstream\n> git-rebase origin # rebase current work-in-progress onto new upstream\n> # might need to resolve and commit conflicts repeatedly\n> git-reset --soft WIP # next commit will be on top of commit prior to rebase\n> git-reset # mark all files as uncommitted as yet\n> git-tag -d WIP # no more need for this tag\n> \n> This effectively puts the upstream changes \"under\" (or \"prior to\") the current\n> topic branch.\n> \n\nWont work for new files (not yet known to git) which conflict with the\nsame names from origin. Your method will not put them anywhere and\ntheir presence will break git-rebase. You _must_ do a merge.\n"},{"id":"44993","messageId":"86645r1wh8.fsf@blue.stonehenge.com","threadId":"8590","inReplyTo":"20070613192828.GB3412@steel.home","subject":"Re: pull into dirty working tree","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-06-13T19:32:35Z","receivedAt":"2007-06-13T19:32:35Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Alex\" == Alex Riesen <raa.lkml@gmail.com> writes:\n\nAlex> Wont work for new files (not yet known to git) which conflict with the\nAlex> same names from origin. Your method will not put them anywhere and\nAlex> their presence will break git-rebase. You _must_ do a merge.\n\nSo I missed git-add for those.  Then it'll work.  I guess I implied that the\ngit-commit initial step should capture all of the \"interesting\" state.\n\ngit-rebase *will* do the merge.  It must. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"45001","messageId":"20070613204711.GC3412@steel.home","threadId":"8590","inReplyTo":"86645r1wh8.fsf@blue.stonehenge.com","subject":"Re: pull into dirty working tree","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-13T20:47:11Z","receivedAt":"2007-06-13T20:47:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Randal L. Schwartz, Wed, Jun 13, 2007 21:32:35 +0200:\n> Alex> Wont work for new files (not yet known to git) which conflict with the\n> Alex> same names from origin. Your method will not put them anywhere and\n> Alex> their presence will break git-rebase. You _must_ do a merge.\n> \n> So I missed git-add for those.  Then it'll work.  I guess I implied that the\n> git-commit initial step should capture all of the \"interesting\" state.\n\nNo, it wont. What files are you going to add? All, but *.o? All, but\n*.log? What if user hasn't setup .gitignore yet? What if he meant to\nadd an ignored file anyway?\n\n> git-rebase *will* do the merge.  It must. :)\n\nIt won't merge anything which isn't known to git. Now, I come to think\nabout it, no existing merge method will help you here (and very likely\nit shouldn't).\n\nIt is actually much simplier doing things right: all this stashing\npeople keep talking about.\n"},{"id":"45002","messageId":"86odjjziek.fsf@blue.stonehenge.com","threadId":"8590","inReplyTo":"20070613204711.GC3412@steel.home","subject":"Re: pull into dirty working tree","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-06-13T20:52:35Z","receivedAt":"2007-06-13T20:52:35Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Alex\" == Alex Riesen <raa.lkml@gmail.com> writes:\n\nAlex> No, it wont. What files are you going to add?\n\nWhatever you are working on.  Whatever you want tracked.  It's a commit.\nI'm not sure why you're having trouble following me.  What did I leave out?\n\n>> git-rebase *will* do the merge.  It must. :)\n\nAlex> It won't merge anything which isn't known to git.\n\nAnd that's irrelevant, because my first step *did* a commit so they are\n*known* to git.\n\nAlex>  Now, I come to think\nAlex> about it, no existing merge method will help you here (and very likely\nAlex> it shouldn't).\n\nYes, it should.  You're merging your changes onto the upstream.  This\nhappens dozens of times a day with git repos all over the world. :)\n\nAlex> It is actually much simplier doing things right: all this stashing\nAlex> people keep talking about.\n\nYes, and that's what I said too.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"45006","messageId":"20070613213931.GD3412@steel.home","threadId":"8590","inReplyTo":"86odjjziek.fsf@blue.stonehenge.com","subject":"Re: pull into dirty working tree","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-13T21:39:31Z","receivedAt":"2007-06-13T21:39:31Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Randal L. Schwartz, Wed, Jun 13, 2007 22:52:35 +0200:\n> Alex> No, it wont. What files are you going to add?\n> \n> Whatever you are working on.  Whatever you want tracked.  It's a commit.\n> I'm not sure why you're having trouble following me.  What did I leave out?\n\nYou left the process of figuring out what files should be temporarily\nadded to the index. _Automatically_. Because that's what you need if\nyou want \"git pull\" to just work. Otherwise it just fails.\n\n> >> git-rebase *will* do the merge.  It must. :)\n> Alex> It won't merge anything which isn't known to git.\n> \n> And that's irrelevant, because my first step *did* a commit so they are\n> *known* to git.\n\nIt is not enough. It didn't add the \"other\" files to index, so the\nfiles are _not_ known to git.\n\nImagine you added a file to Makefile (which was known to git), wrote\nthe file, put some code in it, played with it. Never called \"git add\"\non it yet (you were just playing, as original poster suggested).\nNow someone from team calls and asks you to tests his changes (and\nimagine he added a file with exactly the same name as yours). You do a\npull from his repo and it breaks. With your method it will break too,\n\"git commit -a\" wont add your file to index.\n\n> Alex>  Now, I come to think\n> Alex> about it, no existing merge method will help you here (and very likely\n> Alex> it shouldn't).\n> \n> Yes, it should.  You're merging your changes onto the upstream.  This\n> happens dozens of times a day with git repos all over the world. :)\n\nOther way around. You merge upstream in your branch. And it conflicts\nwith work you haven't told git about just yet.\n\n> Alex> It is actually much simplier doing things right: all this stashing\n> Alex> people keep talking about.\n> \n> Yes, and that's what I said too.\n> \n\nYou (and others) just keep forgetting about this small detail with\n\"other\" files. Junio noticed it too. This \"small\" detail can make the\nwhole stashing bussiness impossible except for maybe a common case.\nWhich is not very helpful for a newbie who meets the uncommon, but his\ncase. He'll learn his way though, of course. After saying out loud:\n\"git sucks!\"; which what they already do.\n"},{"id":"45008","messageId":"86k5u7zf7x.fsf@blue.stonehenge.com","threadId":"8590","inReplyTo":"20070613213931.GD3412@steel.home","subject":"Re: pull into dirty working tree","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-06-13T22:01:22Z","receivedAt":"2007-06-13T22:01:22Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Alex\" == Alex Riesen <raa.lkml@gmail.com> writes:\n\nAlex> You left the process of figuring out what files should be temporarily\nAlex> added to the index. _Automatically_. Because that's what you need if\nAlex> you want \"git pull\" to just work. Otherwise it just fails.\n\nI'd just commit *all* of it in my scenerio.  There won't be any *other* files.\nAnd because of the final git-reset --soft and git-reset, it won't matter if I\ncommited more than I'd ever commit on the final hit.\n\nThe result of my sequence (I believe) is that my topic commits will appear\nrebased on top of the new upstream, and that I'll have a dirty working\ndirectory that represents things as they were, ready for the next commit.\n\nI *lose* the idea of what files were partially added before the last commit,\nbut I can always reconstruct that by hand, because I should already be\nthinking about that before the next commit.\n\nUsing those famous trees, if I start with:\n\nA--B--C--D origin\n         --E--F--G my_topic\n                 --(X) dirty tree\n\nand upstream commits P Q R, the result will be:\n\nA--B--C--D--P--Q--R origin\n                  --E'--F'--G' (E, F, G rebased and merged) my_topic\n                            --(X') dirty tree rebased\n\nThis works because I temporarily make H, which follows E, F, G\nand then rebase E-F-G-H onto origin,\nand then simply \"uncommit\" H'.\n\nOops.  I see the problem.  I don't need the \"WIP\" tag.  I want to uncommit to\nG' not to G.  Is that what you were referencing?\n\nIn which case, it's even simpler:\n\ngit-add . # add *everything* that's not .gitignored\ngit-commit -a -m WIP # save for replay (H above)\ngit-fetch origin # get upstream (P Q R)\ngit-rebase origin # creates E' F' G' H'\ngit-reset --soft HEAD^ # back up to G'\ngit-reset # mark everything un-added as of G'\n\nYeah, this is far easier.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"45010","messageId":"20070613222717.GA5513@steel.home","threadId":"8590","inReplyTo":"86k5u7zf7x.fsf@blue.stonehenge.com","subject":"Re: pull into dirty working tree","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-13T22:27:17Z","receivedAt":"2007-06-13T22:27:17Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Randal L. Schwartz, Thu, Jun 14, 2007 00:01:22 +0200:\n> In which case, it's even simpler:\n> \n> git-add . # add *everything* that's not .gitignored\n> git-commit -a -m WIP # save for replay (H above)\n> git-fetch origin # get upstream (P Q R)\n> git-rebase origin # creates E' F' G' H'\n> git-reset --soft HEAD^ # back up to G'\n> git-reset # mark everything un-added as of G'\n> \n> Yeah, this is far easier.\n> \n\nIt is also wrong. You either add a lot of junk (because it is not\nignored yet - who'll setup .gitignores just to check something?!) and\nspend a millenium hashing it (ever tried to add 4.7 DVD?) or it does\nnot add really important files which just happen to be in .gitignore.\n\nIOW, this recipe is dangerous. It'll only _mostly_ work.\n"},{"id":"45035","messageId":"Pine.LNX.4.64.0706132224580.5848@iabervon.org","threadId":"8590","inReplyTo":"18031.64456.948230.375333@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-14T04:22:05Z","receivedAt":"2007-06-14T04:22:05Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 13 Jun 2007, Bill Lear wrote:\n\n> We have some CVS users who complain that they cannot do a pull\n> into a dirty working tree, as they could under CVS.  Here is\n> their scenario: they make a few changes to their code and want\n> to test it out; someone else pushes changes to the central repo\n> that they then want to add to their working tree to test also;\n> they then want to pull in these changes and test everything, as\n> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.\n> \n> They would like an option (perhaps a config option) to do a \"dirty\n> pull\".\n> \n> The git-merge documentation states:\n> \n>   You may have local modifications in the working tree files. In other\n>   words, git-diff is allowed to report changes. However, the merge uses\n>   your working tree as the working area, and in order to prevent the\n>   merge operation from losing such changes, it makes sure that they do\n>   not interfere with the merge. Those complex tables in read-tree\n>   documentation define what it means for a path to \"interfere with the\n>   merge\". And if your local modifications interfere with the merge,\n>   again, it stops before touching anything.\n> \n> But my colleagues are still wondering: why can't git just do it as\n> CVS does?\n> \n> I know there are workarounds: I myself documented a set of commands\n> to \"put things on a shelf\", but they still are whining.\n> \n> I need a convincing argument: not a technical one, but one that is\n> practical (e.g. where CVS would do harm that git is preventing).\n\nWhere CVS would do harm that git is preventing is if they did something \nbrilliant, forgot how they did it, got other people's changes from the \ncentral repository, and got complicated merge conflicts, and lost their \nchange trying to resolve them. (Or, for that matter, if the merge \nalgorithm screwed up the file without reporting conflicts.)\n\nWhat git refuses to do is overwrite a file you've changed when you haven't \ncommitted it, because something could go wrong, and you'd lose the work.\n\nIt would be possible to tell git that you're okay with it accidentally \nlosing your work, but people tend not to like this idea quite so much when \nit's phrased like that.\n\nThe git sequence for this situation is:\n\n$ git commit -a\n$ git fetch\n$ git rebase origin\n\nThe operation they want to perform is \"rebase\", which puts the changes \nthey made on top of other people's changes instead of where they were \nwritten. It also wants the changes committed, so that it doesn't have to \nworry about losing your work, but afterward you can use \"git commit \n--amend\" to add fixes and the rest of your changes, because your work is \nthe top commit and hasn't been pushed out. Alternatively, \"git reset \nHEAD^\" at the end of the sequence will turn the commit into uncommitted \nchanges.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"45039","messageId":"alpine.LFD.0.98.0706132216300.14121@woody.linux-foundation.org","threadId":"8590","inReplyTo":"18031.64456.948230.375333@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-14T05:21:38Z","receivedAt":"2007-06-14T05:21:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 13 Jun 2007, Bill Lear wrote:\n>\n> We have some CVS users who complain that they cannot do a pull\n> into a dirty working tree, as they could under CVS.\n\nWell, a lot of people have told you that the answer is \"don't do that\", \nbut I actually somewhat disagree.\n\nI think it might be perfectly fine to allow for a *fast-forward* pull to \ndo a three-way merge on the working tree, assuming the index is clean in \nthe paths that got modified.\n\nFor a real merge (not just a fast-forward), we really *really* must not do \nit, for a very simple reason: we have no sane way to handle conflicts if \nwe have both a merge from the pull itself _and_ a merge from the working \ntree. Don't get me wrong: I'm sure it's possible in theory, I just think \nthat in practice it's such a total hairball that it's not worth it!\n\nSo I think we could actually try to allow \"git pull\" with a fast-forward \npull and a dirty working tree.\n\n(We obviously _already_ allow a working tree that is dirty in the paths \nthat don't actually get changed at all! I use that all the time. So this \nis strictly limited to the \"dirty state actually overlaps with what got \npulled!)\n\nIt might make it a bit easier for CVS people to get used to the git model: \nkeep your dirty working tree, and do \"git pull\" to update it, and fix up \nany conflicts in the working tree. That's how CVS works - it's a bad \nmodel, but it's a model that may be worth supporting just to get people \nmore easily into the _good_ model.\n\n\t\tLinus\n"},{"id":"45047","messageId":"7vps3zascu.fsf@assigned-by-dhcp.pobox.com","threadId":"8590","inReplyTo":"alpine.LFD.0.98.0706132216300.14121@woody.linux-foundation.org","subject":"Re: pull into dirty working tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-14T07:49:05Z","receivedAt":"2007-06-14T07:49:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> It might make it a bit easier for CVS people to get used to the git model: \n> keep your dirty working tree, and do \"git pull\" to update it, and fix up \n> any conflicts in the working tree. That's how CVS works - it's a bad \n> model, but it's a model that may be worth supporting just to get people \n> more easily into the _good_ model.\n\nIf a bad model _is_ supported, what incentive is there for these\npeople to move into the good model, I honestly wonder...\n"},{"id":"45049","messageId":"1181808114.6118.7.camel@localhost","threadId":"8590","inReplyTo":"7vps3zascu.fsf@assigned-by-dhcp.pobox.com","subject":"Re: pull into dirty working tree","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2007-06-14T08:01:54Z","receivedAt":"2007-06-14T08:01:54Z","isPatch":false,"sender":{"key":"ray007@gmx.net","avatar":null},"body":"On Thu, 2007-06-14 at 00:49 -0700, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n> \n> > It might make it a bit easier for CVS people to get used to the git model: \n> > keep your dirty working tree, and do \"git pull\" to update it, and fix up \n> > any conflicts in the working tree. That's how CVS works - it's a bad \n> > model, but it's a model that may be worth supporting just to get people \n> > more easily into the _good_ model.\n> \n> If a bad model _is_ supported, what incentive is there for these\n> people to move into the good model, I honestly wonder...\n\nIs it a bad model for the normal development process? Probably.\n\nWould it solve the problem of \"I want to keep my debug-statements that I\nwon't ever commit in the merged result\"? ... yes\n\nI think that's at least one valid usecase we should probably support.\nOne I'd also like to use ;-)\n\n-- \nbest regards\n\n  Ray\n"},{"id":"45050","messageId":"4670F6FD.4060704@midwinter.com","threadId":"8590","inReplyTo":"7vps3zascu.fsf@assigned-by-dhcp.pobox.com","subject":"Re: pull into dirty working tree","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-14T08:06:21Z","receivedAt":"2007-06-14T08:06:21Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> If a bad model _is_ supported, what incentive is there for these\n> people to move into the good model, I honestly wonder..\n\nPresumably it's a good model because it's easier, more productive, more \npredictable, more reliable, or some combination of those things; that's \nthe incentive. If it's none of those things for a given developer, then \nmaybe it's not in fact a better model for them.\n\nOf course, even if it is better for them, some people will never move -- \nbut those are the people who won't willingly move to git anyway unless \nthe bad model is supported. There are enough of them out there that \npeople who *do* want to use the good model, but have to work in an \nenvironment where they're outnumbered by those other folks, find they \ncan't sell the organization on git because it forces a change in work \nstyle on people who aren't interested in changing their work styles. \n(Not a purely hypothetical statement, sadly.)\n\nYou can view this in terms of being a leg up for people who *do* want to \nuse git, but are in environments where they are unable to convince or \nforce everyone else to adopt git-style workflows. I think it's telling \nthat almost all the discussions about this kind of feature are of the \nform, \"I'm trying to convince my team to use git, and they find it no \ngood because of X.\" It's the person trying to sell git to the group, \npresumably so they can use it themselves without having to go through a \nCVS or Subversion or p4 gateway, that this stuff really helps. That the \nrest of the team will benefit down the road too is nice but probably not \nthe immediate selfish personal goal of the people who are asking for \nthis kind of feature.\n\n-Steve\n"},{"id":"45061","messageId":"18033.14520.846510.640130@lisa.zopyra.com","threadId":"8590","inReplyTo":"alpine.LFD.0.98.0706132216300.14121@woody.linux-foundation.org","subject":"Re: pull into dirty working tree","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-06-14T12:46:48Z","receivedAt":"2007-06-14T12:46:48Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, June 13, 2007 at 22:21:38 (-0700) Linus Torvalds writes:\n>On Wed, 13 Jun 2007, Bill Lear wrote:\n>>\n>> We have some CVS users who complain that they cannot do a pull\n>> into a dirty working tree, as they could under CVS.\n>\n>Well, a lot of people have told you that the answer is \"don't do that\", \n>but I actually somewhat disagree.\n\nI have now officially fallen out of my chair.\n\n>I think it might be perfectly fine to allow for a *fast-forward* pull to \n>do a three-way merge on the working tree, assuming the index is clean in \n>the paths that got modified.\n>...\n>It might make it a bit easier for CVS people to get used to the git model: \n>keep your dirty working tree, and do \"git pull\" to update it, and fix up \n>any conflicts in the working tree. That's how CVS works - it's a bad \n>model, but it's a model that may be worth supporting just to get people \n>more easily into the _good_ model.\n\nExactly my desires.  I think it could work reliably, and as they\nmature into git users, they will come to appreciate branches.\n\n\nBill\n"},{"id":"45073","messageId":"alpine.LFD.0.99.0706141014320.5651@xanadu.home","threadId":"8590","inReplyTo":"4670F6FD.4060704@midwinter.com","subject":"Re: pull into dirty working tree","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-14T14:25:51Z","receivedAt":"2007-06-14T14:25:51Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Jun 2007, Steven Grimm wrote:\n\n> You can view this in terms of being a leg up for people who *do* want to use\n> git, but are in environments where they are unable to convince or force\n> everyone else to adopt git-style workflows. I think it's telling that almost\n> all the discussions about this kind of feature are of the form, \"I'm trying to\n> convince my team to use git, and they find it no good because of X.\" It's the\n> person trying to sell git to the group, presumably so they can use it\n> themselves without having to go through a CVS or Subversion or p4 gateway,\n> that this stuff really helps. That the rest of the team will benefit down the\n> road too is nice but probably not the immediate selfish personal goal of the\n> people who are asking for this kind of feature.\n\nPersonally, I think there is a point where it isn't worth trying to \nconvert the world.  If people consider GIT bad and unwilling to use it \nbecause of X or Z then they probably better stay with CVS.  There is a \nlimit to how backward bending should GIT do to accomodate everyone, \nespecially if it is about compromize in its usage model just to make \nlife easier for people who want to preserve their inferior work flow.\n\nThis being said, I don't claim to have a particular opinion about the \nissue discussed in this thread.  Simply that things should be decided on \na technical basis and be justified with good arguments.  Saying that \"I \ncan't convince my co-workers to use GIT if it doesn't do X\" is _not_ a \ngood argument.\n\n\nNicolas\n"},{"id":"45080","messageId":"alpine.LFD.0.98.0706140836450.14121@woody.linux-foundation.org","threadId":"8590","inReplyTo":"18033.14520.846510.640130@lisa.zopyra.com","subject":"Re: pull into dirty working tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-14T15:46:27Z","receivedAt":"2007-06-14T15:46:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 14 Jun 2007, Bill Lear wrote:\n\n> On Wednesday, June 13, 2007 at 22:21:38 (-0700) Linus Torvalds writes:\n> >On Wed, 13 Jun 2007, Bill Lear wrote:\n> >>\n> >> We have some CVS users who complain that they cannot do a pull\n> >> into a dirty working tree, as they could under CVS.\n> >\n> >Well, a lot of people have told you that the answer is \"don't do that\", \n> >but I actually somewhat disagree.\n> \n> I have now officially fallen out of my chair.\n\nWell, the thing is, I actually pull into dirty trees all the time. So I \ncan really see the point of wanting to have some dirty state (you're not \nready to commit it yet), but still wanting to update your tree to some \nnewer state..\n\nOf course, in the kernel (where I do this - I do it to a much lesser \ndegree in git too, but for the kernel it's \"normal\" for me to do it), we \nhave very good modularization of source code, so I can do the \"pull into a \ndirty tree\" with _current_ git, just because there is almost never a \nclash (and if there is, nothing bad happens: the pull won't succeed, and I \ncan decide to either stash away my diff or just undo it, and then re-pull \nafterwards).\n\nBut I can also well imagine that other projects aren't quite as modular as \nthe kernel is. In fact, I pretty much know that for a fact.. We've spent \nyears splitting things up, just because clashes are nasty.\n\nSo I don't think the \"pull into a dirty tree\" is necessarily a horribly \nbad workflow. It *can* be due to bad habits, but it can equally well be \ndue to perfectly fine habits like having added some debugging code that \nyou actually want to eventually throw away, but you haven't quite debugged \nit totally yet.\n\nFor example, maybe the reason you pull is because there's a potential fix \nin upstream - you want to keep your debugging code (to _verify_ the fix, \nor verify that it wasn't a fix at all).\n\nThe fact that some CVS users do it because they are used to it doesn't \n_automatically_ make it bad form. They probably have really bad reasons \nfor doing it (namely the fact that under CVS, you cannot commit to your \ntree as aggressively as you can under git, since committing affects \neverybody else too), and *those* reasons may not be true under git, but \nthe other ones (see above) are still what appear to be valid reasons for \nallowing this..\n\nSo the only reason I'm ambivalent is actually that I suspect it's just \nhard to do cleanly. For example, doing it for the fast-forward case is \nmuch easier, but then people will start *wanting* to do it for the more \ncomplex \"real merge\" case, and will complain when that doesn't work. And \nthat one really _is_ fundamentally harder.\n\nSo it might be easier to take a \"git stash ; git pull ; git unstash\" \napproach instead of making \"git pull\" handle working tree conflicts \nitseld.\n\n\t\tLinus\n"},{"id":"45090","messageId":"20070614202027.GA47039@dspnet.fr.eu.org","threadId":"8590","inReplyTo":"alpine.LFD.0.98.0706140836450.14121@woody.linux-foundation.org","subject":"Re: pull into dirty working tree","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2007-06-14T20:20:27Z","receivedAt":"2007-06-14T20:20:27Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Thu, Jun 14, 2007 at 08:46:27AM -0700, Linus Torvalds wrote:\n> So it might be easier to take a \"git stash ; git pull ; git unstash\" \n> approach instead of making \"git pull\" handle working tree conflicts \n> itseld.\n\nIsn't that \"git add .; git commit; git fetch; git rebase <something>;\ngit reset ^HEAD\"?  With the conflict resolution happening at rebase\ntime.\n\n  OG.\n"},{"id":"45091","messageId":"alpine.LFD.0.98.0706141328380.14121@woody.linux-foundation.org","threadId":"8590","inReplyTo":"20070614202027.GA47039@dspnet.fr.eu.org","subject":"Re: pull into dirty working tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-14T20:30:08Z","receivedAt":"2007-06-14T20:30:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 14 Jun 2007, Olivier Galibert wrote:\n\n> On Thu, Jun 14, 2007 at 08:46:27AM -0700, Linus Torvalds wrote:\n> > So it might be easier to take a \"git stash ; git pull ; git unstash\" \n> > approach instead of making \"git pull\" handle working tree conflicts \n> > itseld.\n> \n> Isn't that \"git add .; git commit; git fetch; git rebase <something>;\n> git reset ^HEAD\"?  With the conflict resolution happening at rebase\n> time.\n\nNo.\n\nThe two workflows happen to co-incide *if* the \"git pull\" is a \nfast-forward, but not if you actually had previous commits that you \nwanted the \"git pull\" to merge.\n\nSo if you want things to actually work as a \"git pull with dirty state \nmerge\", you really do need to do \"git stash + git pull + git unstash\".\n\n\t\tLinus\n"},{"id":"45100","messageId":"46a038f90706141746n1cb69258r23ba676bbcf7c425@mail.gmail.com","threadId":"8590","inReplyTo":"alpine.LFD.0.98.0706140836450.14121@woody.linux-foundation.org","subject":"Re: pull into dirty working tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-15T00:46:22Z","receivedAt":"2007-06-15T00:46:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> Well, the thing is, I actually pull into dirty trees all the time. So I\n> can really see the point of wanting to have some dirty state (you're not\n> ready to commit it yet), but still wanting to update your tree to some\n> newer state..\n\nRight now git merges/fforwards well with dirty state as long as the\nsame path is not touched on both sides. But there are several\nsituations where it could do better allowing those ops to go through\nif they don't result in any conflict.\n\n- For Fast Forwards on a dirty path - attempt the merge on a temp file\nand refuse to complete the FF there is a conflict.\n- For merges on a dirty path, attempt the merge. If both the tree\nmerge _and_ the subsequent with the dirty state are clean, then there\nis no problem updating the checkout.\n\nIn both cases, we can still go ahead in the case of a conflict against\nthe local state and give the user the normal conflict markers (or\nseparate files of the patch doesn't apply at all. The situation where\nI think it is valid to refuse to go ahead is in the \"merge on dirty\npath\" where the tree merge results in a conflict. Too many states to\nkeep track of -- not for git but for the user.\n\ncheers,\n\n\nmartin\n"},{"id":"45103","messageId":"alpine.LFD.0.98.0706141801030.14121@woody.linux-foundation.org","threadId":"8590","inReplyTo":"46a038f90706141746n1cb69258r23ba676bbcf7c425@mail.gmail.com","subject":"Re: pull into dirty working tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-15T01:07:01Z","receivedAt":"2007-06-15T01:07:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 15 Jun 2007, Martin Langhoff wrote:\n> \n> Right now git merges/fforwards well with dirty state as long as the\n> same path is not touched on both sides. But there are several\n> situations where it could do better allowing those ops to go through\n> if they don't result in any conflict.\n> \n> - For Fast Forwards on a dirty path - attempt the merge on a temp file\n>   and refuse to complete the FF there is a conflict.\n> - For merges on a dirty path, attempt the merge. If both the tree\n>   merge _and_ the subsequent with the dirty state are clean, then there\n>   is no problem updating the checkout.\n> \n> In both cases, we can still go ahead in the case of a conflict against\n> the local state and give the user the normal conflict markers (or\n> separate files of the patch doesn't apply at all. The situation where\n> I think it is valid to refuse to go ahead is in the \"merge on dirty\n> path\" where the tree merge results in a conflict. Too many states to\n> keep track of -- not for git but for the user.\n\nI agree, but there is actually a practical implementation problem with \ndoing that:\n\n - currently, we can decide *ahead* of time (by just looking at the index, \n   whether the index entry is clean, and the two branches) whether the \n   merge can go ahead or not.\n\n - so we actually do two passes: the first pass checks that we can do what \n   we want to do cleanly, and the second pass actually starts changing the \n   working tree!\n\nNow, if you actually start doing the *merge* thing, the biggest practical \nproblem ends up being that the natural place where you find out that \n\"oops, we can't get a clean result\" is in phase 2 - *after* you have \npotentially already done earlier merges in the working directory!\n\nAnd that's unacceptable. A \"git pull\" needs to either fail early without \nmaking any modifications at all (telling people that the tree is dirty and \ncannot be merged), or it needs to complete but leave conflict markers.\n\nBut yeah, if you can check in stage 1 (_without_ changing the working \ntree) whether the merge will work, then everything is fine.\n\n\t\tLinus\n"},{"id":"45107","messageId":"46a038f90706142033p1b7f5b49uc5b4af72b0419c8e@mail.gmail.com","threadId":"8590","inReplyTo":"alpine.LFD.0.98.0706141801030.14121@woody.linux-foundation.org","subject":"Re: pull into dirty working tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-15T03:33:27Z","receivedAt":"2007-06-15T03:33:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> But yeah, if you can check in stage 1 (_without_ changing the working\n> tree) whether the merge will work, then everything is fine.\n\nAha- so at phase 1 we know\n - what paths are dirty in the checkout\n - what paths of the merge need an actuall diff3 merge\n\nperhaps we can do those diff3 merges elsewhere (tempfiles). If they\nare trivial diff3 merges, then we can complete the merge operation\nwithout touching the checkout. After this is complete, we can then\nupdate the checkout...\n\ncheers,\n\n\n\nm\n"},{"id":"45146","messageId":"200706152026.58609.robin.rosenberg.lists@dewire.com","threadId":"8590","inReplyTo":"46a038f90706142033p1b7f5b49uc5b4af72b0419c8e@mail.gmail.com","subject":"Re: pull into dirty working tree","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-06-15T18:26:58Z","receivedAt":"2007-06-15T18:26:58Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 15 juni 2007 skrev Martin Langhoff:\n> On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> > But yeah, if you can check in stage 1 (_without_ changing the working\n> > tree) whether the merge will work, then everything is fine.\n> \n> Aha- so at phase 1 we know\n>  - what paths are dirty in the checkout\n>  - what paths of the merge need an actuall diff3 merge\n> \n> perhaps we can do those diff3 merges elsewhere (tempfiles). If they\n> are trivial diff3 merges, then we can complete the merge operation\n> without touching the checkout. After this is complete, we can then\n> update the checkout...\n\nCan't you treat this like git-am or git-rabase. Save the diff to .dottest. Then\npeform the pull just like you do normally involving the user if necessary. After\nthat either automatically or after a --continue/--abort you apply the diff with it's own\nconflicts.\n\n-- robin\n"}]}