{"thread":{"id":"18016","subject":"Files different for me","startedAt":"2009-02-25T16:11:39Z","lastAt":"2009-02-25T20:14:36Z","messageCount":17,"participants":["John Dlugosz","Feanil Patel","Brian Gernhardt","Junio C Hamano","Linus Torvalds","Matthieu Moy","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106229","messageId":"450196A1AAAE4B42A00A8B27A59278E709E047DE@EXCHANGE.trad.tradestation.com","threadId":"18016","inReplyTo":null,"subject":"Files different for me","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-25T16:11:39Z","receivedAt":"2009-02-25T16:11:39Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"I'm working with a group, and using git for source code.  I need to change a couple files temporarily and just for me.  I thought, \"that's easy\", just don't stage them when I check in changes.  But, what do I do when I pull changes from others?  I think it will complain that I have unsaved changes.\nWhat's the best way to do this?\n"},{"id":"106231","messageId":"16946e800902250842h3973efdoc902de38ac35562f@mail.gmail.com","threadId":"18016","inReplyTo":"16946e800902250840o677f8708x7c0bf8980e004b91@mail.gmail.com","subject":"Re: Files different for me","fromName":"Feanil Patel","fromEmail":"feanil@gmail.com","sentAt":"2009-02-25T16:42:52Z","receivedAt":"2009-02-25T16:42:52Z","isPatch":false,"sender":{"key":"feanil@gmail.com","avatar":"https://gravatar.com/avatar/699979df6ea477a4bef95fa8595768623598afc6f0ba7f939015c3cf5cfc700c?d=mp&s=160"},"body":"You could use 'git stash' to stash the changes away for later use.\nThen when you want them you can 'git stash apply' them later.\n\n-Feanil\n\nOn Wed, Feb 25, 2009 at 10:11 AM, John Dlugosz\n<JDlugosz@tradestation.com> wrote:\n>\n> I'm working with a group, and using git for source code.  I need to change a couple files temporarily and just for me.  I thought, \"that's easy\", just don't stage them when I check in changes.  But, what do I do when I pull changes from others?  I think it will complain that I have unsaved changes.\n> What's the best way to do this?\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"106232","messageId":"7E43550E-68B7-4B22-A83C-F840A7037CA9@silverinsanity.com","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E047DE@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-25T17:05:54Z","receivedAt":"2009-02-25T17:05:54Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 25, 2009, at 11:11 AM, John Dlugosz wrote:\n\n> I'm working with a group, and using git for source code.  I need to  \n> change a couple files temporarily and just for me.  I thought,  \n> \"that's easy\", just don't stage them when I check in changes.  But,  \n> what do I do when I pull changes from others?  I think it will  \n> complain that I have unsaved changes.\n> What's the best way to do this?\n\nGenerally when I keep changes like this, I make a commit called \"Local  \nChanges\" or similar and have branch.master.rebase set to true so that  \nmy changes get rebased on top of origin when I pull.\n\n~~ Brian\n"},{"id":"106235","messageId":"7vd4d62ygo.fsf@gitster.siamese.dyndns.org","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E047DE@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T17:55:19Z","receivedAt":"2009-02-25T17:55:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John Dlugosz\" <JDlugosz@TradeStation.com> writes:\n\n> I'm working with a group, and using git for source code.  I need to\n> change a couple files temporarily and just for me.  I thought, \"that's\n> easy\", just don't stage them when I check in changes.  But, what do I do\n> when I pull changes from others?  I think it will complain that I have\n> unsaved changes.  What's the best way to do this?\n\n[jc: Overlong lines wrapped]\n\nThis typically happens when a configuration file of some sort that *must*\nbe different in each work tree is tracked.\n\n\"git pull\" and \"git merge\" do not care when you have local changes to\npaths *and* the merge does not involve them, and errors out without\ntouching any files in your tree when the merge needs to touch them.  You\ncan safely deal with your local changes after seeing such an error.  This,\nand because such a file tend to be modified much less often than the real\ncontents, means that:\n\n (1) you do not usually have to worry about this issue, and can keep your\n     small local changes you do not mind losing around, and\n\n (2) when you have to recover, you can easily stash your changes away,\n     redo the pull and unstash them.\n\nIf you want an \"I do not have to think\" solution, an easiest recipe to\nfollow would be:\n\n    $ git stash\n    $ git pull\n    ... potentially resolve conflicts and make a merge commit ...\n    $ git stash pop\n\nBut as described above, stash/stash pop are superfluous for most of the\ntime.\n"},{"id":"106236","messageId":"450196A1AAAE4B42A00A8B27A59278E709E0486D@EXCHANGE.trad.tradestation.com","threadId":"18016","inReplyTo":"7E43550E-68B7-4B22-A83C-F840A7037CA9@silverinsanity.com","subject":"RE: Files different for me","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-25T18:02:12Z","receivedAt":"2009-02-25T18:02:12Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> Generally when I keep changes like this, I make a commit called \"Local\n\n> Changes\" or similar and have branch.master.rebase set to true so that\n\n> my changes get rebased on top of origin when I pull.\n\nThat sounds ideal.  However, I don't understand the specific steps you\nmention.  Looking in the help for git-config,\n\n\tbranch.<name>.rebase\n\n\t\tWhen true, rebase the branch <name> on top of the\nfetched branch, \n\t\tinstead of merging the default branch from the default\nremote when \n\t\t\"git pull\" is run. NOTE: this is a possibly dangerous\noperation; \n\t\tdo not use it unless you understand the implications \n\t\t(see git-rebase(1) for details).\n\nSo, assuming you are working on the \"master\" branch, this will rebase\nthe pulled content on top of the existing \"master\" rather than merging.\nIf my local changes are committed to \"master\" first, then this will take\nall the commits from other developers that I don't already have in my\nlocal copy and apply them on top of my existing (including Local\nChanges).  But since those will now be different commits, what happens\nnext time?  Ah, \"...which introduce the same textual changes...\" so\nthat's covered in how rebase works.\n\nBut this will have Local Changes present, and different commits (with\nthe same textual changes) in my branch.  So what happens when I \"push\"?\n\n\tOldstuff--A--B--C  remote\n\t       \\\n\t        LC--X--Y  mine\n\nLC is \"Local Changes\", X and Y are changes I made, and A, B, C are\nchanges from other developers.\n\nAfter a fetch, I have:\n\n\tOldstuff--LC--X--Y--A'--B'--C'  mine\n\nSo what happens when I \"push\"?\n\nIn any case, the whole point is that I don't want to publish LC.\n"},{"id":"106237","messageId":"alpine.LFD.2.00.0902250957260.3111@localhost.localdomain","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E047DE@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-02-25T18:04:22Z","receivedAt":"2009-02-25T18:04:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Feb 2009, John Dlugosz wrote:\n>\n> I'm working with a group, and using git for source code.  I need to \n> change a couple files temporarily and just for me.  I thought, \"that's \n> easy\", just don't stage them when I check in changes.  But, what do I do \n> when I pull changes from others?  I think it will complain that I have \n> unsaved changes.\n\nIf your changes do not touch any of the files that the \"git pull\" updates, \nthen everything is fine. The pull will just work, and your changes will \nstill exists in your tree. This is not an accident - git was very much \ndesigned to work that way, because it's a common usage case for me.\n\nI often have some trivial small changes in my tree (like a pending change \nto the top-level Makefile for the next version number that I just haven't \ncommitted yet - just a reminder to myself that I'm soon about to release \nanother -rc). And I still want to continue to do \"git pull\" to fetch \nstuff, or even \"git am -s\" to apply patches.\n\nHOWEVER. If the pull actually wants to modify a file that you have changed \n(ie that same file was changed in the remote), then \"git pull\" will fail \ngracefully after having done the fetch, saying something like\n\n\tEntry 'file-name' not uptodate. Cannot merge.\n\nand at that point you have to decide whethe you want to commit the change, \n\"stash\" it, or just undo it. Or whether you don't want to do the merge \nyet because you're still working on your own changes, and don't want the \ndistraction.\n\n\t\tLinus\n"},{"id":"106239","messageId":"013B8F55-FBCC-4D3B-9EA4-13C05FFE986B@silverinsanity.com","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E0486D@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-25T18:38:23Z","receivedAt":"2009-02-25T18:38:23Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 25, 2009, at 1:02 PM, John Dlugosz wrote:\n\n>> Generally when I keep changes like this, I make a commit called  \n>> \"Local\n>> Changes\" or similar and have branch.master.rebase set to true so that\n>> my changes get rebased on top of origin when I pull.\n>\n> That sounds ideal.  However, I don't understand the specific steps you\n> mention.  Looking in the help for git-config,\n\nAs Junio and Linus have pointed out, most pulls will ignore local  \nchanges,\nso this is likely overkill unless your changes are in commonly changed  \nfiles.\n\n> So, assuming you are working on the \"master\" branch, this will rebase\n> the pulled content on top of the existing \"master\" rather than  \n> merging.\n> If my local changes are committed to \"master\" first, then this will  \n> take\n> all the commits from other developers that I don't already have in my\n> local copy and apply them on top of my existing (including Local\n> Changes).  But since those will now be different commits, what happens\n> next time?  Ah, \"...which introduce the same textual changes...\" so\n> that's covered in how rebase works.\n\nYou can set branch.master.rebase with\n\n   git config branch.master.rebase true\n\nIt actually works the other way.  Your changes will be rebased on top of\nthe work from other developers.\n\nA--B--E--F  origin/master\n     \\\n      C--D master\n\nwill become\n\nA--B--E--F  origin/master\n           \\\n            C'--D' master\n\nI share most of my changes using format-patch and e-mail instead of\npushes, so I just don't generate patches for my unimportant changes.\nFor pushing, I'd suggest either working on new features in a different\nbranch (\"topic\" and \"local\" for example), or using \"rebase -i\" to move\nyour local changes to the top and using \"push HEAD^\".\n\n~~ Brian\n"},{"id":"106240","messageId":"vpqbpsq9x15.fsf@bauges.imag.fr","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E0486D@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-02-25T18:44:22Z","receivedAt":"2009-02-25T18:44:22Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"John Dlugosz\" <JDlugosz@TradeStation.com> writes:\n\n> \tOldstuff--A--B--C  remote\n> \t       \\\n> \t        LC--X--Y  mine\n>\n> LC is \"Local Changes\", X and Y are changes I made, and A, B, C are\n> changes from other developers.\n>\n> After a fetch, I have:\n>\n> \tOldstuff--LC--X--Y--A'--B'--C'  mine\n\nNo, your changes get rebased:\n\n \tOldstuff--A--B--C--LC'--X'--Y'   mine\n\nYou should just be carrefull not to push in this state, since you'd\npush LC too. But you can throw away LC later with \"git rebase -i\".\n\n-- \nMatthieu\n"},{"id":"106241","messageId":"7v4oyi2vvf.fsf@gitster.siamese.dyndns.org","threadId":"18016","inReplyTo":"alpine.LFD.2.00.0902250957260.3111@localhost.localdomain","subject":"Re: Files different for me","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T18:51:16Z","receivedAt":"2009-02-25T18:51:16Z","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> If your changes do not touch any of the files that the \"git pull\" updates, \n> then everything is fine. The pull will just work, and your changes will \n> still exists in your tree. This is not an accident - git was very much \n> designed to work that way, because it's a common usage case for me.\n>\n> I often have some trivial small changes in my tree (like a pending change \n> to the top-level Makefile for the next version number that I just haven't \n> committed yet - just a reminder to myself that I'm soon about to release \n> another -rc). And I still want to continue to do \"git pull\" to fetch \n> stuff, or even \"git am -s\" to apply patches.\n>\n> HOWEVER. If the pull actually wants to modify a file that you have changed \n> (ie that same file was changed in the remote), then \"git pull\" will fail \n> gracefully after having done the fetch, saying something like\n>\n> \tEntry 'file-name' not uptodate. Cannot merge.\n>\n> and at that point you have to decide whethe you want to commit the change, \n> \"stash\" it, or just undo it. Or whether you don't want to do the merge \n> yet because you're still working on your own changes, and don't want the \n> distraction.\n\nI've been repeating the above to new people to save you time, but recently\nI noticed one thing.\n\nThe handling of a case where a pull decides to go ahead (because it does\nnot have to touch the Makefile you have your codename updates in) but does\nnot complete with real conflicts, is not as graceful as the other two\ncases (merge refusing to run at all without touching anything, or merge\ncompletes cleanly and makes a commit).\n\nYou will be left with:\n\n - Paths that have local changes (index matches HEAD but work tree does\n   not match the index --- like your Makefile);\n\n - Paths cleanly merged (index and HEAD are different but work tree\n   already matches the index);\n\n - Unmerged paths (index has higher stage entries with <<</===/>>> files\n   in the work tree);\n\nYou, I and experienced users know what to do.  Deal *only* with the last\nkind, mark them with \"git add\" after you are done with each of them, and\nmake sure you do not say \"-a\" when committing the result, to exclude the\nfirst kind from the merge result.\n\nI've been wondering if we can make this safer for others.\n"},{"id":"106242","messageId":"450196A1AAAE4B42A00A8B27A59278E709E048A8@EXCHANGE.trad.tradestation.com","threadId":"18016","inReplyTo":"013B8F55-FBCC-4D3B-9EA4-13C05FFE986B@silverinsanity.com","subject":"RE: Files different for me","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-25T19:01:09Z","receivedAt":"2009-02-25T19:01:09Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"Thanks for the clarification, and thanks all on the thread for\nexplaining things to me.\nIt appears that fetching with my local changes is not a problem.  For\ngoing the other way, you suggest:\n\n\tFor pushing, I'd suggest either working on new features in a\ndifferent\n\tbranch (\"topic\" and \"local\" for example), or using \"rebase -i\"\nto move\n\tyour local changes to the top and using \"push HEAD^\".\n\nI get the idea of floating \"that\" change to the top and using \"push\nHEAD^\", though I've never tried --interactive so I'll have to play\naround with that on a backup first.\n\nI think if those changes are not committed, it won't be an issue.  \n\nSo, my plan at this point is to \"stash\" my Local Change, and then apply\nit.  Then just keep it out of the index.  If I do get a conflict, I can\nre-apply my change from the stashed copy.  \n\n\nOrdinarily, I'll all about working on a feature on a branch, exposing a\n\"task based\" system to other developers.  But, this particular change is\nnot isolated, and I'm adding parameter to functions and such (I'm\nchanging the way configuration works and making more things\nconfigurable) all over the place.  I want to push stable work frequently\nso other changes don't get too far away making a merge nightmare.\n\n<rant>\nLast time, I was careful to publish stable code frequently to the\nofficial \"dev\" branch, but when another major feature was finished, they\njust declared that branch to be the new main-line official branch.\n</rant>\n\n\n-----Original Message-----\nFrom: Brian Gernhardt [mailto:benji@silverinsanity.com] \n\nYou can set branch.master.rebase with\n\n   git config branch.master.rebase true\n\nIt actually works the other way.  Your changes will be rebased on top of\nthe work from other developers.\n\nA--B--E--F  origin/master\n     \\\n      C--D master\n\nwill become\n\nA--B--E--F  origin/master\n           \\\n            C'--D' master\n\nI share most of my changes using format-patch and e-mail instead of\npushes, so I just don't generate patches for my unimportant changes.\nFor pushing, I'd suggest either working on new features in a different\nbranch (\"topic\" and \"local\" for example), or using \"rebase -i\" to move\nyour local changes to the top and using \"push HEAD^\".\n\n~~ Brian\n"},{"id":"106243","messageId":"alpine.LFD.2.00.0902251106070.3111@localhost.localdomain","threadId":"18016","inReplyTo":"7v4oyi2vvf.fsf@gitster.siamese.dyndns.org","subject":"Re: Files different for me","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-02-25T19:12:47Z","receivedAt":"2009-02-25T19:12:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Feb 2009, Junio C Hamano wrote:\n>\n> I've been repeating the above to new people to save you time, but recently\n> I noticed one thing.\n> \n> The handling of a case where a pull decides to go ahead (because it does\n> not have to touch the Makefile you have your codename updates in) but does\n> not complete with real conflicts, is not as graceful as the other two\n> cases (merge refusing to run at all without touching anything, or merge\n> completes cleanly and makes a commit).\n\nI agree (although your phrasing was confusing - by \"does not complete with \nreal conflicts\" you made it sound like there were no real conflicts, but \nyou must have meant \"does not actually finish the merge commit _due_ to \nreal conflicts\").\n\nThat case is one large part of why I wanted to have that \"git reset \n--merge\" behavior - because it's a good way to get back to the \"pre-merge \nwith dirty state\" situation. Although I have to admit that I don't think \nI've had that happen since the feature got merged ;)\n\n> You will be left with:\n> \n>  - Paths that have local changes (index matches HEAD but work tree does\n>    not match the index --- like your Makefile);\n> \n>  - Paths cleanly merged (index and HEAD are different but work tree\n>    already matches the index);\n> \n>  - Unmerged paths (index has higher stage entries with <<</===/>>> files\n>    in the work tree);\n\nYes. The good news is that for people who know what they are doing, this \nis all unambiguous. Clean merges will be up-to-date in the index, unmgered \npaths will be marked as such in the index, and your own _real_ dirty state \nwill be unambioguously dirty in the working tree.\n\nBut I do agree that if you don't know what's up, you now are an in a \nreally good position for screwing up, and (for example) resolving the \nmerge conflict and then incorrectly committing your own unrelated changes \nwith the merge.\n\n> You, I and experienced users know what to do.  Deal *only* with the last\n> kind, mark them with \"git add\" after you are done with each of them, and\n> make sure you do not say \"-a\" when committing the result, to exclude the\n> first kind from the merge result.\n> \n> I've been wondering if we can make this safer for others.\n\nYou're right. We could decide to have a mode (maybe default to it, so that \npeople like me can just use a config option to enable \"expert\" mode) that\nsimply refuses to do the merge if it doesn't succeed cleanly if there were \ndirty files in the tree.\n\n\t\t\tLinus\n"},{"id":"106244","messageId":"76718490902251116l12e7d3c5jb42657cb0432ae40@mail.gmail.com","threadId":"18016","inReplyTo":"7v4oyi2vvf.fsf@gitster.siamese.dyndns.org","subject":"Re: Files different for me","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-25T19:16:25Z","receivedAt":"2009-02-25T19:16:25Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Feb 25, 2009 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> The handling of a case where a pull decides to go ahead (because it does\n> not have to touch the Makefile you have your codename updates in) but does\n> not complete with real conflicts, is not as graceful as the other two\n> cases (merge refusing to run at all without touching anything, or merge\n> completes cleanly and makes a commit).\n>\n> You will be left with:\n>\n>  - Paths that have local changes (index matches HEAD but work tree does\n>   not match the index --- like your Makefile);\n>\n>  - Paths cleanly merged (index and HEAD are different but work tree\n>   already matches the index);\n>\n>  - Unmerged paths (index has higher stage entries with <<</===/>>> files\n>   in the work tree);\n>\n> You, I and experienced users know what to do.  Deal *only* with the last\n> kind, mark them with \"git add\" after you are done with each of them, and\n> make sure you do not say \"-a\" when committing the result, to exclude the\n> first kind from the merge result.\n>\n> I've been wondering if we can make this safer for others.\n\nHave pull detect this case and stash if so, with a message to the user\nto pop the stash after they have committed the merge results? Or would\nit make more sense to do it in merge? Maybe a pre-merge hook?\n\nj.\n"},{"id":"106245","messageId":"450196A1AAAE4B42A00A8B27A59278E709E048CB@EXCHANGE.trad.tradestation.com","threadId":"18016","inReplyTo":"7v4oyi2vvf.fsf@gitster.siamese.dyndns.org","subject":"RE: Files different for me","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-25T19:23:29Z","receivedAt":"2009-02-25T19:23:29Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"\n=== re: ===\n\nThe handling of a case where a pull decides to go ahead (because it does\nnot have to touch the Makefile you have your codename updates in) but\ndoes\nnot complete with real conflicts, is not as graceful as the other two\ncases (merge refusing to run at all without touching anything, or merge\ncompletes cleanly and makes a commit).\n\nYou will be left with:\n\n - Paths that have local changes (index matches HEAD but work tree does\n   not match the index --- like your Makefile);\n\n - Paths cleanly merged (index and HEAD are different but work tree\n   already matches the index);\n\n - Unmerged paths (index has higher stage entries with <<</===/>>> files\n   in the work tree);\n\nYou, I and experienced users know what to do.  Deal *only* with the last\nkind, mark them with \"git add\" after you are done with each of them, and\nmake sure you do not say \"-a\" when committing the result, to exclude the\nfirst kind from the merge result.\n\nI've been wondering if we can make this safer for others.\n\n===end===\n\nI've gone over that carefully and I understand (I think) what you are\nsaying.  The first two are things that were not committed, and should\nstay that way (added or not) if they did not conflict.  But they can get\nin the way if a merge (on other files) is needed.\n\nIn an effort to \"wonder\" out loud, can you explain how to handle that\nwith \"mergetool\"?  For a dumb user like me, it just fixes some files\nitself (I guess kdiff is smarter than the normal merge logic) and\npresents me with a GUI for things I need to specify.  This should\nnaturally only go through files with conflicts because of those\n\"<<</===/>>>\" files present.\n\nSo, what should I know/do?  \"Don't use -a\"?  If the idea is to commit\nthe merged stuff but preserve the status of what I've added but don't\nwant to commit yet, I'm at a loss.  Using git GUI, it will be backwards:\nmy additions show, but the freshly merged files are noticed as changes\nthat could be staged.  I want to un-stage the original, stage the merged\nfiles, commit, then re-stage the original stuff?!\n\nLooking again and what you wrote, I think you are not doing that at all.\nYou would add the merged files to the index, carefully preserving the\nfirst kind.  Is it possible/easy to do what I thought you meant at\nfirst:  commit just the merged files, and leave the \"unaffected\" files\nstill in the index and not committed?\n\n--John\n"},{"id":"106246","messageId":"450196A1AAAE4B42A00A8B27A59278E709E048E4@EXCHANGE.trad.tradestation.com","threadId":"18016","inReplyTo":"76718490902251116l12e7d3c5jb42657cb0432ae40@mail.gmail.com","subject":"RE: Files different for me","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-02-25T19:38:43Z","receivedAt":"2009-02-25T19:38:43Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"=== re: ===\nHave pull detect this case and stash if so, with a message to the user\nto pop the stash after they have committed the merge results? Or would\nit make more sense to do it in merge? Maybe a pre-merge hook?\n===end===\n\nI've wondered a couple times how to abort a merge.  I ended up just deleting all the funny files.  Did I understand correctly that \"git reset --merge\" is a new feature?\n\nPerhaps best practice, if I have stuff I've added but don't want to commit yet (why? add the files as you touch them so you don't forget?  keep them from getting confused with the ones you intend to not add at all?), or changes I've not added yet,\nwould be to \"stash\" first, do the pull, then \"stash apply\".\n\nWith the existence of a clean way to abort the merge, I could just pull with the assumption that there will be no conflicts, then abort, stash, pull again if needed.  Without the ability to abort the merge, the stakes are high to risk the assumption that all will go well.  So, always stash first.  \n\nAssuming that is correct, it inspires this behavior:\nAutomatically stash and apply first, then merge.\nIf merge is clean, delete the stash.\nIf intervention is needed, I have the stash state to reset to if necessary, and to show me what was already changed if I need to know that.\n\nBut I'm still mixed up.  What is the requirement here?  I can understand the need to pull to keep current but not publish my own changes yet.  But why is it necessary to preserve the fact that _some_ (not all) of the changes are in the index?\n\n--John\n\n"},{"id":"106255","messageId":"7vocwq1dxe.fsf@gitster.siamese.dyndns.org","threadId":"18016","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E709E048CB@EXCHANGE.trad.tradestation.com","subject":"Re: Files different for me","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T20:04:13Z","receivedAt":"2009-02-25T20:04:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John Dlugosz\" <JDlugosz@TradeStation.com> writes:\n\n> You will be left with:\n>\n>  - Paths that have local changes (index matches HEAD but work tree does\n>    not match the index --- like your Makefile);\n>\n>  - Paths cleanly merged (index and HEAD are different but work tree\n>    already matches the index);\n>\n>  - Unmerged paths (index has higher stage entries with <<</===/>>> files\n>    in the work tree);\n>\n> You, I and experienced users know what to do.  Deal *only* with the last\n> kind, mark them with \"git add\" after you are done with each of them, and\n> make sure you do not say \"-a\" when committing the result, to exclude the\n> first kind from the merge result.\n>\n> I've been wondering if we can make this safer for others.\n>\n> ===end===\n>\n> I've gone over that carefully and I understand (I think) what you are\n> saying.  The first two are things that were not committed, and should\n> stay that way (added or not) if they did not conflict.  But they can get\n> in the way if a merge (on other files) is needed.\n\nNo, the latter two *should* be committed.  The first one *must* be\nexcluded.\n\n\"merge\" (and \"git am\" with or without \"-3\" for patch application) are\ncarefully written in such a way that:\n\n (1) They do not tolerate a dirty index.  They stop without touching\n     anything if you have *any* staged changes.\n\n (2) As long as your index is clean, i.e. matches HEAD, there are two\n     cases.\n\n     (2-a) They add cleanly merged paths to the index and write the result\n           out in the work tree.\n\n     (2-b) They leave unclean merges as unmerged entries in the index and\n           write the conflicted merge result in the work tree.\n\n     (2-c) If all paths cleanly merge, then the index is written out as a\n           tree and a merge commit is created.\n\n     However, neither of the above happens when you have local changes to\n     the paths they need to do so.\n\n     Your local changes to the paths that \"merge\" (and \"git am\") does not\n     have to touch are tolerated.\n\nUnlike CVS/SVN, you do not merge when you are in the middle of doing\nsomething, potentially risking a huge merge conflict that you are unable\nto resolve and redo, and (1) and \"However\" in (2) are both safety against\nsuch \"Merge conflicts between my HEAD and the other branch are intermixed\nwith my still uncommitted changes, and I am lost\" disaster.  You get a\nchance to finish what you started working with your index first before\ncontinuing with the merge.\n\nWe were discussing something very different.\n\nIn the case (2) where your local changes do not interact with the merge,\nthe merge as the whole can fail due to conflicts in some paths.  If you\nran \"git add\" before starting this merge, you wouldn't have come this far\nbut would have been dealt with by the safety of (1).\n\nNow, in such a case, you have:\n\n - Files you had modifications before starting this merge.  Because we are\n   talking about case (2), by definition, you haven't done \"git add\" to\n   them.  The index entries are at stage 0 and match HEAD for these paths.\n\n - Files cleanly merged.  In the index, they are at stage 0 and may be\n   different from HEAD.  The difference from HEAD comes from the changes\n   in the branch being merged (or in the case of \"am -3\", the change the\n   patch introduces).  It can never come from your local changes, because\n   we are talking about case (2), and you couldn't have done \"git add\"\n   them before you started this merge.\n\n - Files with conflicts.  These conflict come from changes committed to\n   your HEAD and the branch being merged (or in the case of \"am -3\", the\n   change the patch introduces).  You can never have had local changes to\n   these paths (see \"However\" in (2) above).\n\nThat means:\n\n - The paths at stage 0 in the index can and should be committed without\n   any further \"git add\" when recording this merge.  Doing \"git add\" for\n   paths in the first category among the three will include your unrelated\n   local changes in the result which is not what you want.  And doing \"git\n   add\" for the paths in the second category is unnecessary; \"merge\" (and\n   \"git am\") have already updated the index with the merge result.\n\n - The paths at higher stages (i.e. unmerged) come from the merge, and you\n   must resolve them (either in vi or mergetool) and \"git add\" them.\n\nSo the short rule is \"resolve and 'git add' to mark the resolution only\nfor paths with conflicts.  Never 'git add' anything else before making\nyour commit.  And do not say 'git commit -a' because that is part of the\nprevious rule.\"\n\n> In an effort to \"wonder\" out loud, can you explain how to handle that\n> with \"mergetool\"?  For a dumb user like me, it just fixes some files\n> itself (I guess kdiff is smarter than the normal merge logic) and\n> presents me with a GUI for things I need to specify.  This should\n> naturally only go through files with conflicts because of those\n> \"<<</===/>>>\" files present.\n>\n> So, what should I know/do?  \"Don't use -a\"?  If the idea is to commit\n> the merged stuff but preserve the status of what I've added but don't\n> want to commit yet,\n\nYou do not have to worry about that, because you don't \"merge\" (or \"am\")\nwhen you already have changes that are \"git add\"ed to the index.  These\ntools correctly detect this case that you are in the middle of something\nand refuse to touch neither your index nor your work tree(see (1) above).\n"},{"id":"106256","messageId":"7vk57e1du3.fsf@gitster.siamese.dyndns.org","threadId":"18016","inReplyTo":"alpine.LFD.2.00.0902251106070.3111@localhost.localdomain","subject":"Re: Files different for me","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T20:06:12Z","receivedAt":"2009-02-25T20:06:12Z","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>> You, I and experienced users know what to do.  Deal *only* with the last\n>> kind, mark them with \"git add\" after you are done with each of them, and\n>> make sure you do not say \"-a\" when committing the result, to exclude the\n>> first kind from the merge result.\n>> \n>> I've been wondering if we can make this safer for others.\n>\n> You're right. We could decide to have a mode (maybe default to it, so that \n> people like me can just use a config option to enable \"expert\" mode) that\n> simply refuses to do the merge if it doesn't succeed cleanly if there were \n> dirty files in the tree.\n\n\"git merge\" has always had this \"stash away local changes before starting,\nand unstash once done\" safety when we try to run multiple strategies.\nA patch to trigger it even for a single strategy case may be trivial.\n"},{"id":"106257","messageId":"alpine.LFD.2.00.0902251213350.3111@localhost.localdomain","threadId":"18016","inReplyTo":"7vk57e1du3.fsf@gitster.siamese.dyndns.org","subject":"Re: Files different for me","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-02-25T20:14:36Z","receivedAt":"2009-02-25T20:14:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Feb 2009, Junio C Hamano wrote:\n> \n> \"git merge\" has always had this \"stash away local changes before starting,\n> and unstash once done\" safety when we try to run multiple strategies.\n> A patch to trigger it even for a single strategy case may be trivial.\n\nWell, I'd feel better if it was actually in the low-level merge code, the \nway the current \"I refuse to merge if the file is dirty\" logic is.\n\n\t\t\tLinus\n"}]}