{"thread":{"id":"10674","subject":"git pull opinion","startedAt":"2007-11-05T21:52:12Z","lastAt":"2007-11-10T00:36:12Z","messageCount":43,"participants":["Aghiles","Jakub Narebski","Alex Riesen","Junio C Hamano","Miklos Vajna","Johannes Schindelin","Bill Lear","Steven Grimm","Pierre Habouzit","Andreas Ericsson","Benoit Sigoure","Ralf Wildenhues","Linus Torvalds","Pascal Obry","Brian Downing","Uwe Kleine-König","Johannes Sixt","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"58430","messageId":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","threadId":"10674","inReplyTo":null,"subject":"git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-05T21:52:12Z","receivedAt":"2007-11-05T21:52:12Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello,\n\nI am not sure this is the best place to write about this. Anyway,\nwe just switched a couple of repositories to git (from svn) here\nat work and one thing people find annoying is a pull into\na dirty directory. Before the \"stash\" feature it was even worse\nbut now we can type:\n\n git stash\n git pull\n git stash apply\n\nBut isn't that something we should be able to specify to the \"pull\"\ncommand ? Additionally and if I am not mistakn, those commands will\ncreate \"dangling\" commits and blobs. So one has to execute:\n\n git prune\n\nIs there an \"easier\" way to pull into a dirty directory ? I am\nasking this to make sure I understand the problem and not\nbecause I find it annoying to type those 4 commands to perform\na pull (although some of my colleagues do find that annoying :).\n\nFor now, I am recommanding to my colleagues to commit very often\n(even unfinished changes), pull, and then rebase the commits into\na more meaningful commit before pushing. Which seems to be a good\npractice anyway,\n\nThank you for git,\n\n- Aghiles.\n\nps; if someone is interested to hear what is the general opinion\non switching to git from svn in our company, I could elaborate.\n"},{"id":"58438","messageId":"fgo5dt$avh$1@ger.gmane.org","threadId":"10674","inReplyTo":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-05T22:28:16Z","receivedAt":"2007-11-05T22:28:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aghiles wrote:\n\n> I am not sure this is the best place to write about this. Anyway,\n> we just switched a couple of repositories to git (from svn) here\n> at work and one thing people find annoying is a pull into\n> a dirty directory. Before the \"stash\" feature it was even worse\n> but now we can type:\n> \n>     git stash\n>     git pull\n>     git stash apply\n> \n> But isn't that something we should be able to specify to the \"pull\"\n> command ?\n\nIf I remember correctly there is/was some preliminary work (at most 'pu'\nstages) about adding --dirty option to git-merge, git-pull and git-rebase.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"58442","messageId":"20071105224920.GB4208@steel.home","threadId":"10674","inReplyTo":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-05T22:49:20Z","receivedAt":"2007-11-05T22:49:20Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Aghiles, Mon, Nov 05, 2007 22:52:12 +0100:\n> ps; if someone is interested to hear what is the general opinion\n> on switching to git from svn in our company, I could elaborate.\n\nYes, please. And how did you manage to convince them to switch, if possible:\nthere are still some suckers here trying to do the same to their colleagues.\n"},{"id":"58450","messageId":"7vd4uomfn8.fsf@gitster.siamese.dyndns.org","threadId":"10674","inReplyTo":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-05T23:33:31Z","receivedAt":"2007-11-05T23:33:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aghiles writes:\n\n> Is there an \"easier\" way to pull into a dirty directory ? I am\n> asking this to make sure I understand the problem and not\n> because I find it annoying to type those 4 commands to perform\n> a pull (although some of my colleagues do find that annoying :).\n\nYou need to switch your mindset from centralized SVN workflow.\n\nThe beauty of distributedness is that it redefines the meaning\nof \"to commit\". In distributed systems, the act of committing\nis purely checkpointing and it is not associated with publishing\nthe result to others as centralized systems force you to.\n\nStop thinking like \"I need to integrate the changes from\nupstream into my WIP to keep up to date.\" You first finish what\nyou are currently doing, at least to the point that it is\nstable, make a commit to mark that state, and then start\nthinking about what other people did. You may most likely do a\n\"git fetch\" followed by \"git rebase\" to update your WIP on top\nof the updated work by others.\n\nOnce you get used to that, you would not have \"a dirty\ndirectory\" problem.\n"},{"id":"58451","messageId":"20071105234049.GA31277@genesis.frugalware.org","threadId":"10674","inReplyTo":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2007-11-05T23:40:49Z","receivedAt":"2007-11-05T23:40:49Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Nov 05, 2007 at 04:52:12PM -0500, Aghiles wrote:\n> git stash\n> git pull\n> git stash apply\n\nwho will run git stash clear? :)\n\n- VMiklos\n"},{"id":"58462","messageId":"Pine.LNX.4.64.0711060007010.4362@racer.site","threadId":"10674","inReplyTo":"fgo5dt$avh$1@ger.gmane.org","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T00:08:44Z","receivedAt":"2007-11-06T00:08:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Nov 2007, Jakub Narebski wrote:\n\n> Aghiles wrote:\n> \n> > I am not sure this is the best place to write about this. Anyway,\n> > we just switched a couple of repositories to git (from svn) here\n> > at work and one thing people find annoying is a pull into\n> > a dirty directory. Before the \"stash\" feature it was even worse\n> > but now we can type:\n> > \n> > ? ? git stash\n> > ? ? git pull\n> > ? ? git stash apply\n> > \n> > But isn't that something we should be able to specify to the \"pull\"\n> > command ?\n> \n> If I remember correctly there is/was some preliminary work (at most 'pu'\n> stages) about adding --dirty option to git-merge, git-pull and git-rebase.\n\nThere was, but AFAICT these are dead now.\n\nThe consense was that you are much better off committing first, then \npulling. And if the work you are doing really is not committable, but you \n_have_ to pull _now_, you use stash. Although you are quite likely to \nrevert the pull when it succeeds, and _then_ unstash.\n\nCiao,\nDscho\n"},{"id":"58464","messageId":"18223.46848.109961.552827@lisa.zopyra.com","threadId":"10674","inReplyTo":"7vd4uomfn8.fsf@gitster.siamese.dyndns.org","subject":"Re: git pull opinion","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-06T00:36:16Z","receivedAt":"2007-11-06T00:36:16Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n>Aghiles writes:\n>\n>> Is there an \"easier\" way to pull into a dirty directory ? I am\n>> asking this to make sure I understand the problem and not\n>> because I find it annoying to type those 4 commands to perform\n>> a pull (although some of my colleagues do find that annoying :).\n>\n>You need to switch your mindset from centralized SVN workflow.\n>\n>The beauty of distributedness is that it redefines the meaning\n>of \"to commit\". In distributed systems, the act of committing\n>is purely checkpointing and it is not associated with publishing\n>the result to others as centralized systems force you to.\n>\n>Stop thinking like \"I need to integrate the changes from\n>upstream into my WIP to keep up to date.\" You first finish what\n>you are currently doing, at least to the point that it is\n>stable, make a commit to mark that state, and then start\n>thinking about what other people did. You may most likely do a\n>\"git fetch\" followed by \"git rebase\" to update your WIP on top\n>of the updated work by others.\n>\n>Once you get used to that, you would not have \"a dirty\n>directory\" problem.\n\nI respectfully beg to differ. I think it is entirely reasonable, and\nnot a sign of \"centralized\" mindset, to want to pull changes others\nhave made into your dirty repository with a single command.\n\n\nBill\n"},{"id":"58466","messageId":"1922673A-C57E-4C10-BAB0-5853B8499164@midwinter.com","threadId":"10674","inReplyTo":"7vd4uomfn8.fsf@gitster.siamese.dyndns.org","subject":"Re: git pull opinion","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-06T00:37:50Z","receivedAt":"2007-11-06T00:37:50Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 5, 2007, at 3:33 PM, Junio C Hamano wrote:\n\n> Aghiles writes:\n>\n>> Is there an \"easier\" way to pull into a dirty directory ? I am\n>> asking this to make sure I understand the problem and not\n>> because I find it annoying to type those 4 commands to perform\n>> a pull (although some of my colleagues do find that annoying :).\n>\n> You need to switch your mindset from centralized SVN workflow.\n\nI don't think wanting to pull in the middle of one's work has anything \nto do with centralized vs. decentralized, actually, though I do agree \nthat it's a question of workflow.\n\nFor maybe 80% of my work, I do things \"the git way\" (lots of little \nlocal commits) and only sync up with other people when I've reached a \ngood stopping point. Those are cases where I'm working in isolation on \na new feature or a fix and will publish it as a whole unit when I'm \ndone.\n\nBut the other 20% of the time, I'm working closely with another \nperson. For example, I might be working with a front-end developer who \nis writing some nice snazzy JavaScript or Flash UI code to talk to my \nserver-side code. And in that case, I really do want to be able to \npull down his latest changes while I'm still in the middle of working \non my own stuff, not least because it's only by testing with the real \nclient -- where the button to invoke a particular piece of code on my \nside has just been added in the last 2 minutes -- that I can decide \nwhether my work in progress is actually functional or not. (Unit tests \nonly get you partway there.)\n\nIn other words, for traditional open-source-style distributed \ndevelopment where each repository is an isolated island that goes off \nand does its own thing, ignoring the outside world, the recommended \ngit workflow is totally appropriate. It's also appropriate for a lot \nof in-house non-distributed development.\n\nBut for some classes of collaboration, where two or more people are \nessentially editing the same code base to work on the same feature and \ntheir changes are highly interdependent, that workflow is next to \nuseless. There *is* no \"I've gotten my code working and am ready to \nlook at other people's changes now\" stage until pretty late in the \ngame. This kind of workflow happens a lot in commercial development in \nmy experience.\n\nBefore git-stash, I did a lot of \"commit; fetch; rebase; reset\" \nsequences to support this kind of tight collaboration. Now it's \n\"stash; fetch; rebase; unstash\" which is the same number of commands \nbut is semantically clearer. \"fetch; rebase --dirty\" or \"pull --dirty - \ns rebase\" will be nicer.\n\n-Steve\n"},{"id":"58467","messageId":"20071106004601.GS8939@artemis.corp","threadId":"10674","inReplyTo":"18223.46848.109961.552827@lisa.zopyra.com","subject":"Re: git pull opinion","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T00:46:01Z","receivedAt":"2007-11-06T00:46:01Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote:\n> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n> > Stop thinking like \"I need to integrate the changes from upstream\n> > into my WIP to keep up to date.\"\n> >\n> > [...]\n> >\n> > Once you get used to that, you would not have \"a dirty directory\"\n> > problem.\n> \n> I respectfully beg to differ. I think it is entirely reasonable, and\n> not a sign of \"centralized\" mindset, to want to pull changes others\n> have made into your dirty repository with a single command.\n\n I agree, I have such needs at work. Here is how we (very informally)\nwork: people push things that they believe could help other (a new\nhelper function, a new module, a bug fix) in our master ASAP, but\ndevelop big complex feature in their repository and merge into master\nwhen it's ready.\n\n Very often we discuss some bugfix that is impeding people, or a\nmost-wanted-API. Someone does the work, commits, I often want to merge\nmaster _directly_ into my current work-branch, because I want the\nfix/new-API/... whatever.\n\n I don't believe it's because we have a centralized repository that I\nhave those needs, I would have the very same if I pulled changes\ndirectly from my colleagues repository. The reason why I need it at work\nis because there are some very vivid kind of changes, that only takes a\ncouple of diff lines, and that you _need_ for your work to be completed.\nIt's not really a matter of being fully up-to-date.\n\n Though to my delight, with the current tip-of-next git, I noticed that\nmany rebase and pull work in a dirty tree now :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58468","messageId":"472FBB3F.8080307@op5.se","threadId":"10674","inReplyTo":"18223.46848.109961.552827@lisa.zopyra.com","subject":"Re: git pull opinion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-06T00:54:23Z","receivedAt":"2007-11-06T00:54:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Bill Lear wrote:\n> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n>> Aghiles writes:\n>>\n>>> Is there an \"easier\" way to pull into a dirty directory ? I am\n>>> asking this to make sure I understand the problem and not\n>>> because I find it annoying to type those 4 commands to perform\n>>> a pull (although some of my colleagues do find that annoying :).\n>> You need to switch your mindset from centralized SVN workflow.\n>>\n>> The beauty of distributedness is that it redefines the meaning\n>> of \"to commit\". In distributed systems, the act of committing\n>> is purely checkpointing and it is not associated with publishing\n>> the result to others as centralized systems force you to.\n>>\n>> Stop thinking like \"I need to integrate the changes from\n>> upstream into my WIP to keep up to date.\" You first finish what\n>> you are currently doing, at least to the point that it is\n>> stable, make a commit to mark that state, and then start\n>> thinking about what other people did. You may most likely do a\n>> \"git fetch\" followed by \"git rebase\" to update your WIP on top\n>> of the updated work by others.\n>>\n>> Once you get used to that, you would not have \"a dirty\n>> directory\" problem.\n> \n> I respectfully beg to differ. I think it is entirely reasonable, and\n> not a sign of \"centralized\" mindset, to want to pull changes others\n> have made into your dirty repository with a single command.\n> \n\nI find it much more convenient to just fetch them. I'd rather see\ngit-pull being given a --rebase option (which would ultimately mean\nteaching git-merge about it) to rebase already committed changes on\ntop of the newly fetched tracking branch. It's being worked on, but\nrather slowly.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"58471","messageId":"Pine.LNX.4.64.0711060115130.4362@racer.site","threadId":"10674","inReplyTo":"472FBB3F.8080307@op5.se","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T01:16:30Z","receivedAt":"2007-11-06T01:16:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Andreas Ericsson wrote:\n\n> Bill Lear wrote:\n> > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n> > > Aghiles writes:\n> > > \n> > > > Is there an \"easier\" way to pull into a dirty directory ? I am\n> > > > asking this to make sure I understand the problem and not\n> > > > because I find it annoying to type those 4 commands to perform\n> > > > a pull (although some of my colleagues do find that annoying :).\n> > > You need to switch your mindset from centralized SVN workflow.\n> > > \n> > > The beauty of distributedness is that it redefines the meaning\n> > > of \"to commit\". In distributed systems, the act of committing\n> > > is purely checkpointing and it is not associated with publishing\n> > > the result to others as centralized systems force you to.\n> > > \n> > > Stop thinking like \"I need to integrate the changes from\n> > > upstream into my WIP to keep up to date.\" You first finish what\n> > > you are currently doing, at least to the point that it is\n> > > stable, make a commit to mark that state, and then start\n> > > thinking about what other people did. You may most likely do a\n> > > \"git fetch\" followed by \"git rebase\" to update your WIP on top\n> > > of the updated work by others.\n> > > \n> > > Once you get used to that, you would not have \"a dirty\n> > > directory\" problem.\n> > \n> > I respectfully beg to differ. I think it is entirely reasonable, and\n> > not a sign of \"centralized\" mindset, to want to pull changes others\n> > have made into your dirty repository with a single command.\n> > \n> \n> I find it much more convenient to just fetch them. I'd rather see\n> git-pull being given a --rebase option (which would ultimately mean\n> teaching git-merge about it) to rebase already committed changes on\n> top of the newly fetched tracking branch. It's being worked on, but\n> rather slowly.\n\ngit-pull learning about --rebase does not mean teaching git-merge about \nit. See my patch, which you (and others) failed to enthusiastically \nembrace, which is the sole reason it is stalled.\n\nCiao,\nDscho\n"},{"id":"58485","messageId":"3abd05a90711052004v3de6d448s2d1d9a53323060be@mail.gmail.com","threadId":"10674","inReplyTo":"7vd4uomfn8.fsf@gitster.siamese.dyndns.org","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-06T04:04:28Z","receivedAt":"2007-11-06T04:04:28Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello Junio,\n\n> You need to switch your mindset from centralized SVN workflow.\n\nYes, we understood that and we are trying hard :)\n\n> The beauty of distributedness is that it redefines the meaning\n> of \"to commit\". In distributed systems, the act of committing\n> is purely checkpointing and it is not associated with publishing\n> the result to others as centralized systems force you to.\n>\n\nThis is very nice actually and we absolutely understand what a\ncommit means in the git world. Having the commit as a step\nbefore publishing is very helpful (although some concepts such\nas \"staging for a commit\" are still obscure as of now).\n\n> Stop thinking like \"I need to integrate the changes from\n> upstream into my WIP to keep up to date.\" You first finish what\n> you are currently doing, at least to the point that it is\n> stable, make a commit to mark that state, and then start\n> thinking about what other people did.\n\nOne particular situation in which this might not apply is when\ntwo people work very closely on the same feature (as mentioned\nby Steve Grimm in this thread) and one needs the changes\nmade by the other. This often happens when starting a new project,\nas it is our case now :)\n\nThank you,\n\n- Aghiles.\n"},{"id":"58486","messageId":"3abd05a90711052016s615cd66cy5a5f932900d89143@mail.gmail.com","threadId":"10674","inReplyTo":"20071105234049.GA31277@genesis.frugalware.org","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-06T04:16:06Z","receivedAt":"2007-11-06T04:16:06Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello,\n\n> who will run git stash clear? :)\n\nYes you are right. By the way, in the context of merging into a\ndirty tree, \"git stash clear\" seems to be a dangerous command:\nthere is a risk of loosing all your changes without a question\nasked!\n\nI know unix is a harsh world but ...\n\n- Aghiles.\n"},{"id":"58487","messageId":"3abd05a90711052022j590f1faesb85f4646afd9acec@mail.gmail.com","threadId":"10674","inReplyTo":"Pine.LNX.4.64.0711060007010.4362@racer.site","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-06T04:22:33Z","receivedAt":"2007-11-06T04:22:33Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello,\n\n> The consense was that you are much better off committing first, then\n> pulling. And if the work you are doing really is not committable, but you\n> _have_ to pull _now_, you use stash. Although you are quite likely to\n> revert the pull when it succeeds, and _then_ unstash.\n\nSorry but I don't really understand why one should \"revert the pull\" ? Could\nelaborate for a newbie ? :)\n\n- Aghiles.\n"},{"id":"58491","messageId":"176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr","threadId":"10674","inReplyTo":"3abd05a90711052016s615cd66cy5a5f932900d89143@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-06T05:29:58Z","receivedAt":"2007-11-06T05:29:58Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Nov 6, 2007, at 5:16 AM, Aghiles wrote:\n\n> Hello,\n>\n>> who will run git stash clear? :)\n>\n> Yes you are right. By the way, in the context of merging into a\n> dirty tree, \"git stash clear\" seems to be a dangerous command:\n> there is a risk of loosing all your changes without a question\n> asked!\n>\n> I know unix is a harsh world but ...\n\nBe *very* careful, because it's worse than that. If you run, say, \n`git stash clean', instead of `clear' (that's the sort of typo that \nquickly slips through), then it will stash all your changes in a new \nstash named \"clean\". Once you realize you made a typo, you will most \nprobably correct it and run `git stash clear' but... Oops, you just \nwiped your changes that were in the \"clean\" stash.\nThat happened to me and other people I know, so now I'm utterly \ncautious when I start a command with \"git stash\".\n\nAs far as I remember, a patch was proposed to change this mis- \nbehavior of \"git stash\" (one could argue that it's a PEBCAK issue, \nbut I really think this command is *way* too dangerous) but I don't \nthink it's been accepted at this time.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"58493","messageId":"3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com","threadId":"10674","inReplyTo":"18223.46848.109961.552827@lisa.zopyra.com","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-06T06:30:23Z","receivedAt":"2007-11-06T06:30:23Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"> I respectfully beg to differ. I think it is entirely reasonable, and\n> not a sign of \"centralized\" mindset, to want to pull changes others\n> have made into your dirty repository with a single command.\n\nBitKeeper, for example, does a merge with a \"dirty\" directory.\nI am not saying that git should behave the same way but I think\nthat this argument strengthens the point that it is not a\n\"centralized repository\" mindset.\n\n- Aghiles.\n"},{"id":"58496","messageId":"20071106073455.GA19106@ins.uni-bonn.de","threadId":"10674","inReplyTo":"176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr","subject":"Re: git pull opinion","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2007-11-06T07:34:55Z","receivedAt":"2007-11-06T07:34:55Z","isPatch":false,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"Hello,\n\n* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:\n> On Nov 6, 2007, at 5:16 AM, Aghiles wrote:\n>\n>>> who will run git stash clear? :)\n>>\n>> Yes you are right. By the way, in the context of merging into a\n>> dirty tree, \"git stash clear\" seems to be a dangerous command:\n>> there is a risk of loosing all your changes without a question\n>> asked!\n\nI would love it if for once in the git world, there were a pair of\ncommands that would do the exact opposite of each other and where the\nnaive newbie (me) would immediately recognize that from their names:\n git stash push\n git stash pop\n\nBoth applied in this order should be a no-op on both the working tree,\nthe index, and also the stash. There's room for extensions (pop\n--keep-stash to not remove the stashed information), explicit naming of\nstashes, doing multiple pops at once, and so on. Please don't add more\nof the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.\nEven if they're perfectly clear to git intimates, each one of them\ntakes precious extra time to learn due to this lack of symmetry.\n\nSince I simply don't have the time resources to just implement that,\nI'll thank you for your attention and go back to lurking mode now.\n\nThanks,\nRalf\n"},{"id":"58497","messageId":"20071106073841.GB3021@steel.home","threadId":"10674","inReplyTo":"20071106004601.GS8939@artemis.corp","subject":"Re: git pull opinion","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-06T07:38:41Z","receivedAt":"2007-11-06T07:38:41Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100:\n> On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote:\n> > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n> > > Stop thinking like \"I need to integrate the changes from upstream\n> > > into my WIP to keep up to date.\"\n> > >\n> > > [...]\n> > >\n> > > Once you get used to that, you would not have \"a dirty directory\"\n> > > problem.\n> > \n> > I respectfully beg to differ. I think it is entirely reasonable, and\n> > not a sign of \"centralized\" mindset, to want to pull changes others\n> > have made into your dirty repository with a single command.\n> \n> I agree, I have such needs at work. Here is how we (very informally)\n> work: people push things that they believe could help other (a new\n> helper function, a new module, a bug fix) in our master ASAP, but\n> develop big complex feature in their repository and merge into master\n> when it's ready.\n> \n> Very often we discuss some bugfix that is impeding people, or a\n> most-wanted-API. Someone does the work, commits, I often want to merge\n> master _directly_ into my current work-branch, because I want the\n> fix/new-API/... whatever.\n\nHow about merging just that \"fix/new-API/... whatever\" thing and not\nthe whole master, which should be a complete mess by now?\n\nThe way you explained it it looks like typical centralized workflow.\n"},{"id":"58498","messageId":"20071106074022.GC3021@steel.home","threadId":"10674","inReplyTo":"3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-06T07:40:22Z","receivedAt":"2007-11-06T07:40:22Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Aghiles, Tue, Nov 06, 2007 07:30:23 +0100:\n> > I respectfully beg to differ. I think it is entirely reasonable, and\n> > not a sign of \"centralized\" mindset, to want to pull changes others\n> > have made into your dirty repository with a single command.\n> \n> BitKeeper, for example, does a merge with a \"dirty\" directory.\n\nGit does merge with dirty working directory. It just wont touch the\nchanged files and stop merging if the merge requires it.\n"},{"id":"58499","messageId":"3abd05a90711052345v7cc74524g588e03c0c1a93c68@mail.gmail.com","threadId":"10674","inReplyTo":"176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-06T07:45:13Z","receivedAt":"2007-11-06T07:45:13Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello,\n\n> As far as I remember, a patch was proposed to change this mis-\n> behavior of \"git stash\" (one could argue that it's a PEBCAK issue,\n> but I really think this command is *way* too dangerous) but I don't\n> think it's been accepted at this time.\n\nI think that people will use this a lot with the pull command and some\naccidents will happen. I am of the opinion that the semantics of this\ncommand must be changed.\nAdditionally, having \"git stash [command]\" and \"git stash [argument]\"\nmixed together seems strange. One suggestion would be:\n\n git stash store/add/create [stash-name]\n git stash apply [stash-name]\n git stash clear (accepts wildcards but no empty args)\n ...\n\n- Aghiles.\n"},{"id":"58505","messageId":"20071106083144.GA4435@artemis.corp","threadId":"10674","inReplyTo":"20071106073841.GB3021@steel.home","subject":"Re: git pull opinion","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T08:31:44Z","receivedAt":"2007-11-06T08:31:44Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 07:38:41AM +0000, Alex Riesen wrote:\n> Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100:\n> > On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote:\n> > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n> > > > Stop thinking like \"I need to integrate the changes from upstream\n> > > > into my WIP to keep up to date.\"\n> > > >\n> > > > [...]\n> > > >\n> > > > Once you get used to that, you would not have \"a dirty directory\"\n> > > > problem.\n> > > \n> > > I respectfully beg to differ. I think it is entirely reasonable, and\n> > > not a sign of \"centralized\" mindset, to want to pull changes others\n> > > have made into your dirty repository with a single command.\n> > \n> > I agree, I have such needs at work. Here is how we (very informally)\n> > work: people push things that they believe could help other (a new\n> > helper function, a new module, a bug fix) in our master ASAP, but\n> > develop big complex feature in their repository and merge into master\n> > when it's ready.\n> > \n> > Very often we discuss some bugfix that is impeding people, or a\n> > most-wanted-API. Someone does the work, commits, I often want to merge\n> > master _directly_ into my current work-branch, because I want the\n> > fix/new-API/... whatever.\n> \n> How about merging just that \"fix/new-API/... whatever\" thing and not\n> the whole master, which should be a complete mess by now?\n\n No master only holds simple patches (few of them, typically half a\ndozen a day), or long-lived branches that are tested and ready to merge.\n\n> The way you explained it it looks like typical centralized workflow.\n\n Well I disagree, it's /part/ centralized. We have a two speed devel\nmethod, one that works the old-centralized way for quick fixes, and a\nmore decentralized approach for big changes. It's a rather nice and\nuseful middle ground for a company where all programmers are within\nearshot.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58509","messageId":"20071106085134.GD4435@artemis.corp","threadId":"10674","inReplyTo":"176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr","subject":"Re: git pull opinion","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T08:51:34Z","receivedAt":"2007-11-06T08:51:34Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 05:29:58AM +0000, Benoit Sigoure wrote:\n> On Nov 6, 2007, at 5:16 AM, Aghiles wrote:\n> \n> >Hello,\n> >\n> >>who will run git stash clear? :)\n> >\n> >Yes you are right. By the way, in the context of merging into a\n> >dirty tree, \"git stash clear\" seems to be a dangerous command:\n> >there is a risk of loosing all your changes without a question\n> >asked!\n> >\n> >I know unix is a harsh world but ...\n> \n> Be *very* careful, because it's worse than that. If you run, say, `git \n> stash clean', instead of `clear' (that's the sort of typo that quickly \n> slips through), then it will stash all your changes in a new stash named \n> \"clean\". Once you realize you made a typo, you will most probably \n> correct it and run `git stash clear' but... Oops, you just wiped your \n> changes that were in the \"clean\" stash.\n> That happened to me and other people I know, so now I'm utterly cautious \n> when I start a command with \"git stash\".\n> \n> As far as I remember, a patch was proposed to change this mis-behavior of \n> \"git stash\" (one could argue that it's a PEBCAK issue, but I really think \n> this command is *way* too dangerous) but I don't think it's been accepted \n> at this time.\n\n no it's a command issue. git stash should\n_NOT_ be an alias to git stash save . Either the command\nshould be mandatory _or_ it should be a long option to avoid such kind\nof conflicts.\n\n It's just a bad ui design.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58511","messageId":"47302D07.9030703@op5.se","threadId":"10674","inReplyTo":"Pine.LNX.4.64.0711060115130.4362@racer.site","subject":"Re: git pull opinion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-06T08:59:51Z","receivedAt":"2007-11-06T08:59:51Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 6 Nov 2007, Andreas Ericsson wrote:\n> \n>> Bill Lear wrote:\n>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n>>>> Aghiles writes:\n>>>>\n>>>>> Is there an \"easier\" way to pull into a dirty directory ? I am\n>>>>> asking this to make sure I understand the problem and not\n>>>>> because I find it annoying to type those 4 commands to perform\n>>>>> a pull (although some of my colleagues do find that annoying :).\n>>>> You need to switch your mindset from centralized SVN workflow.\n>>>>\n>>>> The beauty of distributedness is that it redefines the meaning\n>>>> of \"to commit\". In distributed systems, the act of committing\n>>>> is purely checkpointing and it is not associated with publishing\n>>>> the result to others as centralized systems force you to.\n>>>>\n>>>> Stop thinking like \"I need to integrate the changes from\n>>>> upstream into my WIP to keep up to date.\" You first finish what\n>>>> you are currently doing, at least to the point that it is\n>>>> stable, make a commit to mark that state, and then start\n>>>> thinking about what other people did. You may most likely do a\n>>>> \"git fetch\" followed by \"git rebase\" to update your WIP on top\n>>>> of the updated work by others.\n>>>>\n>>>> Once you get used to that, you would not have \"a dirty\n>>>> directory\" problem.\n>>> I respectfully beg to differ. I think it is entirely reasonable, and\n>>> not a sign of \"centralized\" mindset, to want to pull changes others\n>>> have made into your dirty repository with a single command.\n>>>\n>> I find it much more convenient to just fetch them. I'd rather see\n>> git-pull being given a --rebase option (which would ultimately mean\n>> teaching git-merge about it) to rebase already committed changes on\n>> top of the newly fetched tracking branch. It's being worked on, but\n>> rather slowly.\n> \n> git-pull learning about --rebase does not mean teaching git-merge about \n> it. See my patch, which you (and others) failed to enthusiastically \n> embrace, which is the sole reason it is stalled.\n> \n\nI must have missed it. Found the thread now though. Gonna try the patch in\nproduction for a while and see how it pans out.\n\nI'm curious about this hunk though. It seems unaffiliated with the --rebase\noption as such, but was still in the patch. Would you care to clarify?\n\n@@ -86,7 +95,6 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n \n case \"$merge_head\" in\n '')\n-\tcurr_branch=$(git symbolic-ref -q HEAD)\n \tcase $? in\n \t 0) ;;\n \t 1) echo >&2 \"You are not currently on a branch; you must explicitly\"\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"58527","messageId":"Pine.LNX.4.64.0711061154310.4362@racer.site","threadId":"10674","inReplyTo":"20071106073455.GA19106@ins.uni-bonn.de","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T11:59:07Z","receivedAt":"2007-11-06T11:59:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Ralf Wildenhues wrote:\n\n> * Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:\n> > On Nov 6, 2007, at 5:16 AM, Aghiles wrote:\n> >\n> >>> who will run git stash clear? :)\n> >>\n> >> Yes you are right. By the way, in the context of merging into a\n> >> dirty tree, \"git stash clear\" seems to be a dangerous command:\n> >> there is a risk of loosing all your changes without a question\n> >> asked!\n> \n> I would love it if for once in the git world, there were a pair of\n> commands that would do the exact opposite of each other and where the\n> naive newbie (me) would immediately recognize that from their names:\n> git stash push\n> git stash pop\n> \n> Both applied in this order should be a no-op on both the working tree,\n> the index, and also the stash. There's room for extensions (pop\n> --keep-stash to not remove the stashed information), explicit naming of\n> stashes, doing multiple pops at once, and so on. Please don't add more\n> of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.\n> Even if they're perfectly clear to git intimates, each one of them\n> takes precious extra time to learn due to this lack of symmetry.\n> \n> Since I simply don't have the time resources to just implement that, \n> I'll thank you for your attention and go back to lurking mode now.\n\nYou might as well be honest, and say that they are not time constraints, \nbut lack of motivation. There is -- still! -- the patch \"Teach \"git \nreflog\" a subcommand to delete single entries\" in \"pu\" to delete \nsingle reflogs (and being in \"pu\" means it is only a fetch and a \ncherry-pick away).\n\nImplementing that feature would be a piece of cake, but I will not do it, \nsince _you_ want it, not _I_. In spite of that, I implemented that reflog \ndeleting, which was the hardest part of the exercise.\n\nSo, out, out with you, out of lurking mode!\n\nCiao,\nDscho\n"},{"id":"58528","messageId":"Pine.LNX.4.64.0711061159240.4362@racer.site","threadId":"10674","inReplyTo":"3abd05a90711052022j590f1faesb85f4646afd9acec@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T12:02:25Z","receivedAt":"2007-11-06T12:02:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Nov 2007, Aghiles wrote:\n\n> > The consense was that you are much better off committing first, then \n> > pulling. And if the work you are doing really is not committable, but \n> > you _have_ to pull _now_, you use stash. Although you are quite \n> > likely to revert the pull when it succeeds, and _then_ unstash.\n> \n> Sorry but I don't really understand why one should \"revert the pull\" ? \n> Could elaborate for a newbie ? :)\n\nYes, no problem.\n\nA pull is just a fetch and a merge. And a merge is a commit with more \nthan one parent. So you can use the command \"git reset --hard HEAD^\" to \nundo a merge, just as you can undo any other commit.\n\nNOTE: if you pushed that commit (merge or not), do _not_ use reset. This \neffectively rewrites history, and _will_ upset people pulling from you. \nIf you really have to undo a commit you already published, use \"git revert \n\".\n\nHth,\nDscho\n"},{"id":"58529","messageId":"Pine.LNX.4.64.0711061204160.4362@racer.site","threadId":"10674","inReplyTo":"47302D07.9030703@op5.se","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T12:05:39Z","receivedAt":"2007-11-06T12:05:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Tue, 6 Nov 2007, Andreas Ericsson wrote:\n> > \n> > > Bill Lear wrote:\n> > > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n> > > > > Aghiles writes:\n> > > > > \n> > > > > > Is there an \"easier\" way to pull into a dirty directory ? I am\n> > > > > > asking this to make sure I understand the problem and not\n> > > > > > because I find it annoying to type those 4 commands to perform\n> > > > > > a pull (although some of my colleagues do find that annoying :).\n> > > > > You need to switch your mindset from centralized SVN workflow.\n> > > > > \n> > > > > The beauty of distributedness is that it redefines the meaning\n> > > > > of \"to commit\". In distributed systems, the act of committing\n> > > > > is purely checkpointing and it is not associated with publishing\n> > > > > the result to others as centralized systems force you to.\n> > > > > \n> > > > > Stop thinking like \"I need to integrate the changes from\n> > > > > upstream into my WIP to keep up to date.\" You first finish what\n> > > > > you are currently doing, at least to the point that it is\n> > > > > stable, make a commit to mark that state, and then start\n> > > > > thinking about what other people did. You may most likely do a\n> > > > > \"git fetch\" followed by \"git rebase\" to update your WIP on top\n> > > > > of the updated work by others.\n> > > > > \n> > > > > Once you get used to that, you would not have \"a dirty\n> > > > > directory\" problem.\n> > > > I respectfully beg to differ. I think it is entirely reasonable, and\n> > > > not a sign of \"centralized\" mindset, to want to pull changes others\n> > > > have made into your dirty repository with a single command.\n> > > > \n> > > I find it much more convenient to just fetch them. I'd rather see\n> > > git-pull being given a --rebase option (which would ultimately mean\n> > > teaching git-merge about it) to rebase already committed changes on\n> > > top of the newly fetched tracking branch. It's being worked on, but\n> > > rather slowly.\n> > \n> > git-pull learning about --rebase does not mean teaching git-merge about it.\n> > See my patch, which you (and others) failed to enthusiastically embrace,\n> > which is the sole reason it is stalled.\n> > \n> \n> I must have missed it. Found the thread now though. Gonna try the patch in\n> production for a while and see how it pans out.\n> \n> I'm curious about this hunk though. It seems unaffiliated with the --rebase\n> option as such, but was still in the patch. Would you care to clarify?\n> \n> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n> \n> case \"$merge_head\" in\n> '')\n> -\tcurr_branch=$(git symbolic-ref -q HEAD)\n> \tcase $? in\n> \t 0) ;;\n> \t 1) echo >&2 \"You are not currently on a branch; you must\n> explicitly\"\n> \n\nNo, it is not unaffiliated. If you go back to the patch, you will find \nthat this line was not deleted, but moved to the start of git-rebase.sh. \nWe need to know the branch name to get the config settings, and might just \nas well reuse the branch name for the merge_head case.\n\nHth,\nDscho\n"},{"id":"58530","messageId":"47305925.8020306@op5.se","threadId":"10674","inReplyTo":"Pine.LNX.4.64.0711061204160.4362@racer.site","subject":"Re: git pull opinion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-06T12:08:05Z","receivedAt":"2007-11-06T12:08:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 6 Nov 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Tue, 6 Nov 2007, Andreas Ericsson wrote:\n>>>\n>>>> Bill Lear wrote:\n>>>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:\n>>>>>> Aghiles writes:\n>>>>>>\n>>>>>>> Is there an \"easier\" way to pull into a dirty directory ? I am\n>>>>>>> asking this to make sure I understand the problem and not\n>>>>>>> because I find it annoying to type those 4 commands to perform\n>>>>>>> a pull (although some of my colleagues do find that annoying :).\n>>>>>> You need to switch your mindset from centralized SVN workflow.\n>>>>>>\n>>>>>> The beauty of distributedness is that it redefines the meaning\n>>>>>> of \"to commit\". In distributed systems, the act of committing\n>>>>>> is purely checkpointing and it is not associated with publishing\n>>>>>> the result to others as centralized systems force you to.\n>>>>>>\n>>>>>> Stop thinking like \"I need to integrate the changes from\n>>>>>> upstream into my WIP to keep up to date.\" You first finish what\n>>>>>> you are currently doing, at least to the point that it is\n>>>>>> stable, make a commit to mark that state, and then start\n>>>>>> thinking about what other people did. You may most likely do a\n>>>>>> \"git fetch\" followed by \"git rebase\" to update your WIP on top\n>>>>>> of the updated work by others.\n>>>>>>\n>>>>>> Once you get used to that, you would not have \"a dirty\n>>>>>> directory\" problem.\n>>>>> I respectfully beg to differ. I think it is entirely reasonable, and\n>>>>> not a sign of \"centralized\" mindset, to want to pull changes others\n>>>>> have made into your dirty repository with a single command.\n>>>>>\n>>>> I find it much more convenient to just fetch them. I'd rather see\n>>>> git-pull being given a --rebase option (which would ultimately mean\n>>>> teaching git-merge about it) to rebase already committed changes on\n>>>> top of the newly fetched tracking branch. It's being worked on, but\n>>>> rather slowly.\n>>> git-pull learning about --rebase does not mean teaching git-merge about it.\n>>> See my patch, which you (and others) failed to enthusiastically embrace,\n>>> which is the sole reason it is stalled.\n>>>\n>> I must have missed it. Found the thread now though. Gonna try the patch in\n>> production for a while and see how it pans out.\n>>\n>> I'm curious about this hunk though. It seems unaffiliated with the --rebase\n>> option as such, but was still in the patch. Would you care to clarify?\n>>\n>> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n>>\n>> case \"$merge_head\" in\n>> '')\n>> -\tcurr_branch=$(git symbolic-ref -q HEAD)\n>> \tcase $? in\n>> \t 0) ;;\n>> \t 1) echo >&2 \"You are not currently on a branch; you must\n>> explicitly\"\n>>\n> \n> No, it is not unaffiliated. If you go back to the patch, you will find \n> that this line was not deleted, but moved to the start of git-rebase.sh. \n> We need to know the branch name to get the config settings, and might just \n> as well reuse the branch name for the merge_head case.\n> \n\nRighto. I should learn to not write emails or read patches before 10am.\nThanks for clarifying.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"58548","messageId":"alpine.LFD.0.999.0711060812170.15101@woody.linux-foundation.org","threadId":"10674","inReplyTo":"3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-06T16:36:45Z","receivedAt":"2007-11-06T16:36:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 6 Nov 2007, Aghiles wrote:\n> \n> BitKeeper, for example, does a merge with a \"dirty\" directory.\n> I am not saying that git should behave the same way but I think\n> that this argument strengthens the point that it is not a\n> \"centralized repository\" mindset.\n\nGit does merge with a dirty directory too, but refuses to merge if it \nneeds to *change* any individual dirty *files*.\n\nAnd that actually comes from one of the great strengths of git: in git \n(unlike just about any other SCM out there) you can - and are indeed \nexpected to - resolve merges sanely in the working tree using normal \nfilesystem accesses (ie your basic normal editors and other tools).\n\nThat means that if there is a unresolved merge, you're actually expected \nto edit things in the same place where they are dirty. Which means that \nthe merge logic doesn't want to mix up your dirty state and whatever \nmerged state, because that is then not sanely resolvable.\n\nNow, I do think that we could relax the rule so that \"files that are \nmodified must be clean in the working tree\" could instead become \"files \nthat actually don't merge _trivially_ must be clean in the working tree\". \nBut basically, if it's not a trivial merge, then since it's done in the \nworking tree, the working tree has to be clean (or the merge would \noverwrite it).\n\nDoing a four-way merge is just going to confuse everybody.\n\nSo we *could* probably make unpack-trees.c: treeway_merge() allow this. \nIt's not totally trivial, because it requires that the CE_UPDATE be \nreplaced with something more (\"CE_THREEWAY\"): instead of just writing the \nnew result, it should do another three-way merge.\n\nSo it's within the range of possible, but it's actually pretty subtle. The \nreason: we cannot (and *must*not*!) actually do the three-way merge early. \nWe need to do the full tree merge in stage 1, and then only if all files \nare ok can we then check out the new tree. And we currently don't save the \nmerge information at all.\n\nSo to do this, we'd need to:\n\n - remove the \"verify_uptodate(old, o); invalidate_ce_path(old);\" in \n \"merged_entry()\", and actually *leave* the index with all three stages \n intact, but set CE_UPDATE *and* return success.\n\n - make check_updates() do the three-way merge of \"original index, working \n tree, new merged state\" instead of just doing a \"unlink_entry() + \n checkout_entry()\".\n\nIt doesn't actually look *hard*, but it's definitely subtle enough that \nI'd be nervous about doing it. We're probably talking less than 50 lines \nof actual diffs (this whole code uses good data structures, and we can \nfairly easily represent the problem, and we already have the ability to do \na three-way merge!), but we're talking some really quite core code and \nstuff that absolutely must not have any chance what-so-ever of ever \nbreaking!\n\nTo recap:\n - it's probably a fairly simple change to just two well-defined places \n (merge_entry() and check_updates())\n - but dang, those two places are critical and absolutely must not be \n screwed up, and while both of those functions are pretty simple, this \n is some seriously core functionality.\n\nIf somebody wants to do it, I'll happily look over the result and test it \nout, but it really needs to be really clean and obvious and rock solid. \nAnd in the absense of that, I'll take the current safe code that just \nsays: don't confuse the merge and make it any more complex than it needs \nto be.\n\n\t\tLinus\n"},{"id":"58558","messageId":"4730AD48.2050907@obry.net","threadId":"10674","inReplyTo":"3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-11-06T18:07:04Z","receivedAt":"2007-11-06T18:07:04Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Aghiles a écrit :\n> Hello,\n> \n> I am not sure this is the best place to write about this. Anyway,\n> we just switched a couple of repositories to git (from svn) here\n> at work and one thing people find annoying is a pull into\n> a dirty directory. Before the \"stash\" feature it was even worse\n> but now we can type:\n> \n> git stash\n> git pull\n> git stash apply\n> \n> But isn't that something we should be able to specify to the \"pull\"\n> command ? Additionally and if I am not mistakn, those commands will\n> create \"dangling\" commits and blobs. So one has to execute:\n> \n> git prune\n> \n> Is there an \"easier\" way to pull into a dirty directory ? \n\nI'm using:\n\n$ git config --global alias.update '!git stash && git pull && git stash\napply'\n\nThen in a git repository just do:\n\n$ git update\n\n> ps; if someone is interested to hear what is the general opinion\n> on switching to git from svn in our company, I could elaborate.\n\nWould be nice to hear about that indeed.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"58560","messageId":"7v1wb3i6nx.fsf@gitster.siamese.dyndns.org","threadId":"10674","inReplyTo":"Pine.LNX.4.64.0711061159240.4362@racer.site","subject":"Re: git pull opinion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T18:13:22Z","receivedAt":"2007-11-06T18:13:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> A pull is just a fetch and a merge. And a merge is a commit with more \n> than one parent. So you can use the command \"git reset --hard HEAD^\" to \n> undo a merge, just as you can undo any other commit.\n\n*DANGER*\n\nA pull is usually just a fetch and a merge, but sometimes it can\nfast forward. ORIG_HEAD, not HEAD^, points at the previous HEAD\nlocation in both cases.\n"},{"id":"58563","messageId":"Pine.LNX.4.64.0711061828380.4362@racer.site","threadId":"10674","inReplyTo":"7v1wb3i6nx.fsf@gitster.siamese.dyndns.org","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T18:28:52Z","receivedAt":"2007-11-06T18:28:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > A pull is just a fetch and a merge. And a merge is a commit with more \n> > than one parent. So you can use the command \"git reset --hard HEAD^\" to \n> > undo a merge, just as you can undo any other commit.\n> \n> *DANGER*\n> \n> A pull is usually just a fetch and a merge, but sometimes it can fast \n> forward. ORIG_HEAD, not HEAD^, points at the previous HEAD location in \n> both cases.\n\nOops. Right.\n\nThanks,\nDscho\n"},{"id":"58584","messageId":"20071106202209.GG6361@ins.uni-bonn.de","threadId":"10674","inReplyTo":"Pine.LNX.4.64.0711061154310.4362@racer.site","subject":"Re: git pull opinion","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2007-11-06T20:22:10Z","receivedAt":"2007-11-06T20:22:10Z","isPatch":false,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"* Johannes Schindelin wrote on Tue, Nov 06, 2007 at 12:59:07PM CET:\n> On Tue, 6 Nov 2007, Ralf Wildenhues wrote:\n> >\n> > Since I simply don't have the time resources to just implement that, \n> > I'll thank you for your attention and go back to lurking mode now.\n> \n> You might as well be honest, and say that they are not time constraints, \n> but lack of motivation.\n\nNo. I will not do it, because the marginal cost of getting to\nknow not only git but also its source is too high for my precious\ntime ATM. Maybe next year.\n\nWill you do it for me if I buy you some beer? If I promise to\n(continue to) proofread git documentation for a couple of months?\nIf I do more audit of git's shell code, searching for nonportable\nconstructs? Or if I promise to try to help you with any autotools\nissue you might have? Or would money be needed? This:\n\n> Implementing that feature would be a piece of cake [...]\n\ndoesn't sound like it, but I would understand very well if it\nneeded that.\n\nPlease consider that division of work really can be advantageous\nand that not all git users want to be or can be developers at all\ntimes.\n\nCheers,\nRalf\n"},{"id":"58628","messageId":"1194395205-27905-1-git-send-email-bdowning@lavos.net","threadId":"10674","inReplyTo":"20071106085134.GD4435@artemis.corp","subject":"[PATCH] Mark 'git stash [message...]' as deprecated","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-11-07T00:26:44Z","receivedAt":"2007-11-07T00:26:44Z","isPatch":true,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"Complain to STDERR unless 'git stash save' is explicitly used.\nThis is in preparation for completely disabling the \"default save\"\nbehavior of the command in the future.\n\nSigned-off-by: Brian Downing \n---\n Documentation/git-stash.txt | 9 ++++-----\n git-stash.sh | 8 +++++++-\n t/t3903-stash.sh | 14 +++++++++++++-\n 3 files changed, 24 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt\nindex c0147b9..61cf95d 100644\n--- a/Documentation/git-stash.txt\n+++ b/Documentation/git-stash.txt\n@@ -9,7 +9,7 @@ SYNOPSIS\n --------\n [verse]\n 'git-stash' (list | show [] | apply [] | clear)\n-'git-stash' [save] [message...]\n+'git-stash' save [message...]\n \n DESCRIPTION\n -----------\n@@ -39,8 +39,7 @@ OPTIONS\n save::\n \n \tSave your local modifications to a new 'stash', and run `git-reset\n-\t--hard` to revert them. This is the default action when no\n-\tsubcommand is given.\n+\t--hard` to revert them.\n \n list::\n \n@@ -119,7 +118,7 @@ perform a pull, and then unstash, like this:\n $ git pull\n ...\n file foobar not up to date, cannot merge.\n-$ git stash\n+$ git stash save\n $ git pull\n $ git stash apply\n ----------------------------------------------------------------\n@@ -147,7 +146,7 @@ You can use `git-stash` to simplify the above, like this:\n +\n ----------------------------------------------------------------\n ... hack hack hack ...\n-$ git stash\n+$ git stash save\n $ edit emergency fix\n $ git commit -a -m \"Fix in a hurry\"\n $ git stash apply\ndiff --git a/git-stash.sh b/git-stash.sh\nindex f39bd55..a8b854a 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -1,7 +1,7 @@\n #!/bin/sh\n # Copyright (c) 2007, Nanako Shiraishi\n \n-USAGE='[ | list | show | apply | clear]'\n+USAGE='[save | list | show | apply | clear]'\n \n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n@@ -223,6 +223,12 @@ help | usage)\n \tif test $# -gt 0 && test \"$1\" = save\n \tthen\n \t\tshift\n+\telse\n+\t\tcat >&2 < file &&\n \ttest_tick &&\n-\tgit stash &&\n+\tgit stash save &&\n \tgit diff-files --quiet &&\n \tgit diff-index --cached --quiet HEAD\n '\n@@ -73,4 +73,16 @@ test_expect_success 'unstashing in a subdirectory' '\n \tgit stash apply\n '\n \n+test_expect_success 'stash with no args' '\n+\techo 7 > file &&\n+\ttest_tick &&\n+\tgit stash\n+'\n+\n+test_expect_success 'stash with bare message' '\n+\techo 8 > file &&\n+\ttest_tick &&\n+\tgit stash \"a message\"\n+'\n+\n test_done\n-- \n1.5.3.5.1547.gf6d81-dirty\n"},{"id":"58629","messageId":"1194395205-27905-2-git-send-email-bdowning@lavos.net","threadId":"10674","inReplyTo":"1194395205-27905-1-git-send-email-bdowning@lavos.net","subject":"[PATCH] Disable implicit 'save' argument for 'git stash'","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-11-07T00:26:45Z","receivedAt":"2007-11-07T00:26:45Z","isPatch":true,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"Having 'git stash random stuff' actually stash changes is poor\nuser interface, due to the likelyhood of misspelling another legitimate\nargument. Require an explicit 'save' command instead.\n\nSigned-off-by: Brian Downing \n---\n This commit can be applied on top of the previous whenever it\n is decided \"enough time\" has passed for the hard behavior change\n of \"git stash\" to take place.\n\n git-stash.sh | 16 +++++-----------\n t/t3903-stash.sh | 4 ++--\n 2 files changed, 7 insertions(+), 13 deletions(-)\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex a8b854a..e900d40 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -219,17 +219,11 @@ create)\n help | usage)\n \tusage\n \t;;\n-*)\n-\tif test $# -gt 0 && test \"$1\" = save\n-\tthen\n-\t\tshift\n-\telse\n-\t\tcat >&2 < file &&\n \ttest_tick &&\n \tgit stash\n '\n \n-test_expect_success 'stash with bare message' '\n+test_expect_failure 'stash with bare message' '\n \techo 8 > file &&\n \ttest_tick &&\n \tgit stash \"a message\"\n-- \n1.5.3.5.1547.gf6d81-dirty\n"},{"id":"58639","messageId":"20071107070646.GA3417@informatik.uni-freiburg.de","threadId":"10674","inReplyTo":"4730AD48.2050907@obry.net","subject":"Re: git pull opinion","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-11-07T07:06:46Z","receivedAt":"2007-11-07T07:06:46Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\n> I'm using:\n> \n> $ git config --global alias.update '!git stash && git pull && git stash apply'\nI wonder how this works, if the merge produces conflicts...\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=1+year+in+days\n"},{"id":"58641","messageId":"47316BFF.4050505@obry.net","threadId":"10674","inReplyTo":"20071107070646.GA3417@informatik.uni-freiburg.de","subject":"Re: git pull opinion","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-11-07T07:40:47Z","receivedAt":"2007-11-07T07:40:47Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Uwe Kleine-König a écrit :\n> Hello,\n> \n>> I'm using:\n>>\n>> $ git config --global alias.update '!git stash && git pull && git stash apply'\n> I wonder how this works, if the merge produces conflicts...\n\nIf you have conflicts it will not do the \"git stash apply\" as git pull\nwill return with an error. So you'll need to fix the conflicts and do\nyou the final git stash manually.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"58644","messageId":"473170AB.7030104@viscovery.net","threadId":"10674","inReplyTo":"1194395205-27905-1-git-send-email-bdowning@lavos.net","subject":"Re: [PATCH] Mark 'git stash [message...]' as deprecated","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-07T08:00:43Z","receivedAt":"2007-11-07T08:00:43Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Brian Downing schrieb:\n> Complain to STDERR unless 'git stash save' is explicitly used.\n> This is in preparation for completely disabling the \"default save\"\n> behavior of the command in the future.\n> \n> ...\n> -'git-stash' [save] [message...]\n> +'git-stash' save [message...]\n\nCan't we have these two?\n\n\tgit-stash\n\tgit-stash save [message...]\n\n'git stash' without a message as an equivalent of 'git stash save' is still \nvery handy.\n\n-- Hannes\n"},{"id":"58645","messageId":"7vve8ecwl8.fsf@gitster.siamese.dyndns.org","threadId":"10674","inReplyTo":"1194395205-27905-1-git-send-email-bdowning@lavos.net","subject":"Re: [PATCH] Mark 'git stash [message...]' as deprecated","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-07T08:02:11Z","receivedAt":"2007-11-07T08:02:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Downing writes:\n\n> Complain to STDERR unless 'git stash save' is explicitly used.\n> This is in preparation for completely disabling the \"default save\"\n> behavior of the command in the future.\n\nOk, but I would prefer to see this made into at least a\nthree-step process to ease the migration on users. I do not\nhave any issue with a deprecation warning before the next big\nrelease (1.5.4?).\n\nThe next step after this patch should not be the removal of\n\"defalut save\". Instead, introduce a boolean configuration,\nstash.defaultsave, that defaults to false. Without the\nconfiguration, disable the \"default save\" (and do not even\nmention the configuration variable, but do give the usage\nmessage listing the commands). But allow people to use the\n\"default save\" behaviour with the configuration to help existing\nusers. You can do this in the same release as above if you\nwant.\n\nThen you would finally drop the \"default save\" in the next\nbig release after that \"deprecation release\". But not before\nthat.\n\nBTW, I've been quietly rewriting git-stash in C. Be warned ;-)\n"},{"id":"58648","messageId":"208BA68A-462D-4EDF-996B-65CFFC3BB5C3@wincent.com","threadId":"10674","inReplyTo":"473170AB.7030104@viscovery.net","subject":"Re: [PATCH] Mark 'git stash [message...]' as deprecated","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-07T08:12:15Z","receivedAt":"2007-11-07T08:12:15Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 7/11/2007, a las 9:00, Johannes Sixt escribió:\n\n> Brian Downing schrieb:\n>> Complain to STDERR unless 'git stash save' is explicitly used.\n>> This is in preparation for completely disabling the \"default save\"\n>> behavior of the command in the future.\n>> ...\n>> -'git-stash' [save] [message...]\n>> +'git-stash' save [message...]\n>\n> Can't we have these two?\n>\n> \tgit-stash\n> \tgit-stash save [message...]\n>\n> 'git stash' without a message as an equivalent of 'git stash save' \n> is still very handy.\n\nAgreed.\n\nWincent\n"},{"id":"58651","messageId":"20071107082345.GA18057@artemis.corp","threadId":"10674","inReplyTo":"1194395205-27905-1-git-send-email-bdowning@lavos.net","subject":"Re: [PATCH] Mark 'git stash [message...]' as deprecated","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-07T08:23:45Z","receivedAt":"2007-11-07T08:23:45Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Nov 07, 2007 at 12:26:44AM +0000, Brian Downing wrote:\n> Complain to STDERR unless 'git stash save' is explicitly used.\n> This is in preparation for completely disabling the \"default save\"\n> behavior of the command in the future.\n\n No arguments at all should not IMHO be deprecated, it's very useful,\nand is not ambiguous. The issue with git stash is that if you\nthought you typed a command that doesn't in fact exists, you stash which\nis not what you meant _at all_.\n\n When you type `git stash` you certainly want to stash, and it's what\nit does.\n\nHere is how it should work:\n\ngit-stash (list | show [] | apply [] | clear)\ngit-stash [save ]\n\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58726","messageId":"3abd05a90711071325y397434efq7d4e50cb7a1cf07e@mail.gmail.com","threadId":"10674","inReplyTo":"alpine.LFD.0.999.0711060812170.15101@woody.linux-foundation.org","subject":"Re: git pull opinion","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2007-11-07T21:25:10Z","receivedAt":"2007-11-07T21:25:10Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"On 11/6/07, Linus Torvalds wrote:\n> Git does merge with a dirty directory too, but refuses to merge if it\n> needs to *change* any individual dirty *files*.\n\nUnderstood.\n\n> [...]\n> Now, I do think that we could relax the rule so that \"files that are\n> modified must be clean in the working tree\" could instead become \"files\n> that actually don't merge _trivially_ must be clean in the working tree\".\n> But basically, if it's not a trivial merge, then since it's done in the\n> working tree, the working tree has to be clean (or the merge would\n> overwrite it).\n>[...]\n\nI really think this is a good idea. It seems to me that the first \"bad\"\nsurprise a svn/cvs/bk user will have is the result of a \"git pull\" command\non a dirty tree. With the proposed change, and if I understand correctly:\n - users that are used to commit often and fetch into clean trees\nwill never be bothered by this change.\n - users that are used to \"update\" often are expecting to resolve\nconflicts in their working copy anyway.\n\nIn both cases git does not get in your way and everyone is happy.\n\n- Aghiles\n"},{"id":"58906","messageId":"Pine.LNX.4.64.0711081525460.4362@racer.site","threadId":"10674","inReplyTo":"3abd05a90711071325y397434efq7d4e50cb7a1cf07e@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-08T15:27:15Z","receivedAt":"2007-11-08T15:27:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Nov 2007, Aghiles wrote:\n\n> On 11/6/07, Linus Torvalds wrote:\n>\n> > Now, I do think that we could relax the rule so that \"files that are \n> > modified must be clean in the working tree\" could instead become \n> > \"files that actually don't merge _trivially_ must be clean in the \n> > working tree\". But basically, if it's not a trivial merge, then since \n> > it's done in the working tree, the working tree has to be clean (or \n> > the merge would overwrite it).\n> \n> I really think this is a good idea. It seems to me that the first \"bad\"\n> surprise a svn/cvs/bk user will have is the result of a \"git pull\" command\n> on a dirty tree. With the proposed change, and if I understand correctly:\n> - users that are used to commit often and fetch into clean trees\n> will never be bothered by this change.\n> - users that are used to \"update\" often are expecting to resolve\n> conflicts in their working copy anyway.\n\nBut the latter ones will likely not understand why all of a sudden their \nworking tree has to be clean sometimes (when there was no trivial \nmerge possible).\n\nBesides, I think it is not trivial to implement.\n\nNot my itch,\nDscho\n"},{"id":"59151","messageId":"alpine.LFD.0.999.0711091633380.15101@woody.linux-foundation.org","threadId":"10674","inReplyTo":"3abd05a90711071325y397434efq7d4e50cb7a1cf07e@mail.gmail.com","subject":"Re: git pull opinion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-10T00:36:12Z","receivedAt":"2007-11-10T00:36:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 7 Nov 2007, Aghiles wrote:\n\n> > [...]\n> > Now, I do think that we could relax the rule so that \"files that are\n> > modified must be clean in the working tree\" could instead become \"files\n> > that actually don't merge _trivially_ must be clean in the working tree\".\n> > But basically, if it's not a trivial merge, then since it's done in the\n> > working tree, the working tree has to be clean (or the merge would\n> > overwrite it).\n> >[...]\n> \n> I really think this is a good idea. It seems to me that the first \"bad\"\n> surprise a svn/cvs/bk user will have is the result of a \"git pull\" command\n> on a dirty tree. With the proposed change, and if I understand correctly:\n> - users that are used to commit often and fetch into clean trees\n> will never be bothered by this change.\n> - users that are used to \"update\" often are expecting to resolve\n> conflicts in their working copy anyway.\n> \n> In both cases git does not get in your way and everyone is happy.\n\nWell, there will still be cases where people won't be happy.\n\nThat said, all fast-forward cases (which is, I guess, a fairly common way \nof operating for anybody who has ever just uses anoncvs to track others) \nwould be handled by the \"three-way-merge dirty data for trivial merges\". \n\nSo even if it would only handle that special case (and it handles a *lot* \nof other cases too!) it probably would be useful to some people.\n\nThat said, I still don't think I have the energy to actually try to do it. \nI do suspect it's not that hard, and I outlined where it would go, but \nit's really quite core and important code... IOW, this needs *lots* of \ndeep thought and care.\n\n\t\t\tLinus\n"}]}