{"thread":{"id":"9855","subject":"Re: Data Integrity & un-Commited Branches","startedAt":"2007-09-15T00:40:56Z","lastAt":"2007-09-15T17:33:00Z","messageCount":12,"participants":["Brian Scott Dobrovodsky","Shawn O. Pearce","Junio C Hamano","Jan Hudec","Nikodemus Siivola","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53085","messageId":"2a8a071a0709141740l144b60aevdfec2b6cdab8bb60@mail.gmail.com","threadId":"9855","inReplyTo":"7vk5qtd3le.fsf@gitster.siamese.dyndns.org","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Brian Scott Dobrovodsky","fromEmail":"brian@pontech.com","sentAt":"2007-09-15T00:40:56Z","receivedAt":"2007-09-15T00:40:56Z","isPatch":false,"sender":{"key":"brian@pontech.com","avatar":null},"body":"It was a misunderstanding of Git's work flow. By switching from 'an\nun-committed demo' to a previously committed master: I was expecting\nGit to give me the content last commited to master while at the same\ntime preserving(without having to commit) the changes made in demo.\nIntuitively, this is how I expected Git to function.\n\nIndeed, I read through the Crash Courses: 'Git for everyone' & 'Git\nfor SVN users'.\n-- \nBrian Scott Dobrovodsky\n"},{"id":"53088","messageId":"20070915025129.GY3099@spearce.org","threadId":"9855","inReplyTo":"2a8a071a0709141740l144b60aevdfec2b6cdab8bb60@mail.gmail.com","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-15T02:51:29Z","receivedAt":"2007-09-15T02:51:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Scott Dobrovodsky wrote:\n> It was a misunderstanding of Git's work flow. By switching from 'an\n> un-committed demo' to a previously committed master: I was expecting\n> Git to give me the content last commited to master while at the same\n> time preserving(without having to commit) the changes made in demo.\n> Intuitively, this is how I expected Git to function.\n\nYou aren't the only one.\n\nSeveral of my day-job coworkers have also thought the same thing.\nOnly they use git-gui, and have never read any of the Git docs.\nBecause nobody ever reads the docs. Nope, not if you can just dial\nmy extension and browbeat me into giving you an answer to your most\nurgent question. :-\\\n\nMy point is just that some people actually assume that work done\nwhile having one branch checked out is related to that branch and\nthat branch alone and that switching a branch should put that work\non hold. Unfortunately for me some of these people at day-job have\nalso just assumed Git can read their mind and forget to switch\nbranches at the proper times, resulting in unrelated work mashed\ntogether for days straight (and criss-crossed merge to hell and back)\nbefore they call me and say \"MAKEITWORKNOW\".\n\n\nIt isn't unreasonable to want Git to save uncommitted work for the\ncurrent branch and then you switch to another, ending up with a\nclean working directory when you finally get there. Today we have\ngit-stash to help you with this, but I'm thinking maybe we want to\nconnect git-checkout with it?\n\nI see `-s` isn't used as an option yet. What about:\n\n\t$ git init\n\t$ echo master >file\n\t$ git add file && git commit -m initial\n\n\t$ git checkout -b demo ; # switch to demo\n $ echo demo >file ; # dirty the tree\n\n\t$ git checkout -s master ; # stash and switch to master\n\tUncommitted changes stashed on branch 'demo'.\n\t$ cat file\n\tmaster\n\n\t$ git checkout demo ; # return to demo\n\tUncommitted changes were stashed for 'demo'.\n\tTo recover them now run:\n\n\t git stash apply -s\n\n $ cat file\n\tmaster\n\t$ git stash apply -s\n\t$ cat file\n\tdemo\n\nThe new `git stash apply -s` here is defined to find the most\nrecent stash for the current branch (which may not be the top of\nthe stash!) and apply it.\n\nIf you know you want to just reapply the stash when you switch back\nwe could define `git checkout -a` (also unused) to automatically\nexecute `git stash apply -s` if a stash is available for the\ndestination branch.\n\nJust thinking out loud. I probably won't code up a patch that\nimplements this but I don't think it would be too difficult for\nsomeone else who wants to get their feet wet.\n\n-- \nShawn.\n"},{"id":"53090","messageId":"2a8a071a0709142324i29a863b7x8c164a589c1f1f9a@mail.gmail.com","threadId":"9855","inReplyTo":"20070915025129.GY3099@spearce.org","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Brian Scott Dobrovodsky","fromEmail":"brian@pontech.com","sentAt":"2007-09-15T06:24:42Z","receivedAt":"2007-09-15T06:24:42Z","isPatch":false,"sender":{"key":"brian@pontech.com","avatar":null},"body":"> My point is just that some people actually assume that work done\n> while having one branch checked out is related to that branch and\n> that branch alone and that switching a branch should put that work\n> on hold. Unfortunately for me some of these people at day-job have\n> also just assumed Git can read their mind and forget to switch\n> branches at the proper times, resulting in unrelated work mashed\n> together for days straight (and criss-crossed merge to hell and back)\n> before they call me and say \"MAKEITWORKNOW\".\n> \n\nAs I have learned over the years, assumptions can be fatal. I can not\nuse something until I wrap my head around it and test it. Especially\nfor managing something in production! So far, this has been the only\nproblem/mis-understanding.\n\n> It isn't unreasonable to want Git to save uncommitted work for the\n> current branch and then you switch to another, ending up with a\n> clean working directory when you finally get there. Today we have\n> git-stash to help you with this, but I'm thinking maybe we want to\n> connect git-checkout with it?\n\nThat would be great as a default action when using checkout!\n+Switching branches without having to commit improves work flow.\n+Fewer commits = cleaner logs.\n+More Intuitive!\n\nI am currently using git-1.5.1.6, which apparently does not have\ngit-stash. I will upgrade and check it out.\n\nCheers,\n-- \nBrian Scott Dobrovodsky\n"},{"id":"53091","messageId":"20070915063257.GZ3099@spearce.org","threadId":"9855","inReplyTo":"2a8a071a0709142324i29a863b7x8c164a589c1f1f9a@mail.gmail.com","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-15T06:32:57Z","receivedAt":"2007-09-15T06:32:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Scott Dobrovodsky wrote:\n> > It isn't unreasonable to want Git to save uncommitted work for the\n> > current branch and then you switch to another, ending up with a\n> > clean working directory when you finally get there. Today we have\n> > git-stash to help you with this, but I'm thinking maybe we want to\n> > connect git-checkout with it?\n> \n> That would be great as a default action when using checkout!\n\nWell, a lot of \"Git old timers\" like the current action of keeping\nthe tree dirty during a switch. But maybe we could also teach `git\ncheckout` that a user specified configuration option can cause it\nto automatically stash/unstash unless -m is supplied. Or something.\n\nPatches are always welcome. ;-)\n\n> +Switching branches without having to commit improves work flow.\n> +Fewer commits = cleaner logs.\n\nWell, I'm not sure that matters here. Typically Git users will make\nheavy use of commit rewriting features (e.g. `git commit --amend`\nor `git rebase -i`) to cleanup changes on a side branch before they\nsubmit them to the mainline. This makes it easy to commit all of\nthe time and not worry about how the resulting logs will look.\nPlus they can have look like they have some serious code-fu and\nalways write things perfectly the first time. :)\n\nIndeed, before git-stash came about I parked changes on a branch\nusing the following technique:\n\n\t$ git commit -a -m PARK ; # stash on \"demo\"\n\t$ git checkout master ; # tree is now clean\n\t$ git checkout demo ; # back on demo\n\t$ git reset --soft HEAD^ ; # undo the stash\n\nNo messy history, nice neat per-branch stash. Oh, you can do that\nin Git 1.3. And even earlier probably. I actually still use this\ntrick from time to time as I find it flowing out of my fingers far\neasier than git-stash.\n\n-- \nShawn.\n"},{"id":"53092","messageId":"7vk5qs8me5.fsf@gitster.siamese.dyndns.org","threadId":"9855","inReplyTo":"2a8a071a0709142324i29a863b7x8c164a589c1f1f9a@mail.gmail.com","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-15T06:37:22Z","receivedAt":"2007-09-15T06:37:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Scott Dobrovodsky\" writes:\n\n>> It isn't unreasonable to want Git to save uncommitted work for the\n>> current branch and then you switch to another, ending up with a\n>> clean working directory when you finally get there. Today we have\n>> git-stash to help you with this, but I'm thinking maybe we want to\n>> connect git-checkout with it?\n>\n> That would be great as a default action when using checkout!\n\nI would not bet you will stay feeling that way as you gain\nexperience. With \"git stash create\" (will be in 'next' this\nweekend), we could start using stashes more transparently from\nother commands, but I do not think this will ever become the\ndefault for branch switching, while I do not oppose to have such\nan option.\n"},{"id":"53093","messageId":"2a8a071a0709150014g3edd08edgb4b63d6130f9db97@mail.gmail.com","threadId":"9855","inReplyTo":"7vk5qs8me5.fsf@gitster.siamese.dyndns.org","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Brian Scott Dobrovodsky","fromEmail":"brian@pontech.com","sentAt":"2007-09-15T07:14:26Z","receivedAt":"2007-09-15T07:14:26Z","isPatch":false,"sender":{"key":"brian@pontech.com","avatar":null},"body":"> I would not bet you will stay feeling that way as you gain\n> experience. With \"git stash create\" (will be in 'next' this\n> weekend), we could start using stashes more transparently from\n> other commands, but I do not think this will ever become the\n> default for branch switching, while I do not oppose to have such\n> an option.\n\nStashing as the core default may have been over zealous..\n\nCheers,\n-- \nBrian Scott Dobrovodsky\n"},{"id":"53099","messageId":"20070915073845.GB3782@efreet.light.src","threadId":"9855","inReplyTo":"20070915025129.GY3099@spearce.org","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-15T07:38:45Z","receivedAt":"2007-09-15T07:38:45Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce wrote:\n> It isn't unreasonable to want Git to save uncommitted work for the\n> current branch and then you switch to another, ending up with a\n> clean working directory when you finally get there. Today we have\n> git-stash to help you with this, but I'm thinking maybe we want to\n> connect git-checkout with it?\n\nI think it would be reasonable if it just forced you to decide about it. That\nis reading the documentation, checkout only switches branches if the merge of\neach modified file is trivial and only does 3-way merge if it got -m option.\n\nIt might be reasonable to requre that option for all cases, where there are\nlocal changes and the branches don't point to the same commit and without it,\ncheckout should say something like:\n\n Cannot switch branches, because the tree is modified. You can apply the\n modifications to the target branch by using -m option, or commit them\n before switching branches (you can undo or amend that commit later if it's\n not finished yet).\n\nThe case with branches pointing to the same commit is for checkout -b,\nreverting that command if you do it too early/by mistake/wanted branch\ninstead and for doing it with branch + checkout.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"53101","messageId":"20070915075144.GB3099@spearce.org","threadId":"9855","inReplyTo":"20070915073845.GB3782@efreet.light.src","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-15T07:51:44Z","receivedAt":"2007-09-15T07:51:44Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jan Hudec wrote:\n> On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce wrote:\n> > It isn't unreasonable to want Git to save uncommitted work for the\n> > current branch and then you switch to another, ending up with a\n> > clean working directory when you finally get there. Today we have\n> > git-stash to help you with this, but I'm thinking maybe we want to\n> > connect git-checkout with it?\n> \n> I think it would be reasonable if it just forced you to decide about it. That\n> is reading the documentation, checkout only switches branches if the merge of\n> each modified file is trivial and only does 3-way merge if it got -m option.\n> \n> It might be reasonable to requre that option for all cases, where there are\n> local changes and the branches don't point to the same commit and without it,\n> checkout should say something like:\n> \n> Cannot switch branches, because the tree is modified. You can apply the\n> modifications to the target branch by using -m option\n\nThe thing there is `git checkout` by default does a switch only\nif the merge is really trivial. In such cases its probably sane\nto carry the changes with you to the new branch/parent commit.\nAt worst you can safely carry them right back. Or stash them.\nBut -m does a three-way file merge, which isn't trivial, and can\nresult in conflicts.\n\nSo I know that myself and Junio both rely on the default behavior\nto tell us if a switch is even a good idea right now, or if we\nshould stash the changes and *then* do the switch. Because if you\ndo the switch with -m and there are conflicts you are up a creek\nwith no paddle... and there's a mighty big water fall coming up\nin 3 feet... 2 feet... oh crap!\n\nMaking -m the only way to switch with dirty state is not a feature.\nIts a regression.\n\n-- \nShawn.\n"},{"id":"53111","messageId":"6bcc356f0709150611i97d31f0yb91016e53c4f5e9f@mail.gmail.com","threadId":"9855","inReplyTo":"20070915075144.GB3099@spearce.org","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Nikodemus Siivola","fromEmail":"nikodemus@random-state.net","sentAt":"2007-09-15T13:11:55Z","receivedAt":"2007-09-15T13:11:55Z","isPatch":false,"sender":{"key":"nikodemus@random-state.net","avatar":null},"body":"One thing that I've been bitten a couple of times is that\nI think I'm on branch X, which should be clean, whereas\nI'm really on branch Y with uncommitted changes. Then I\ncheckout another branch, and see the uncommitted work -- and\ngiven that I have a couple of dozen related feature branches\nin my tree it may take a while to figure which branch the\nuncommitted work came from.\n\nIt would be nice if the \"uncommitted changes\" message when\nswithching branches told you which branch you came from...\n\nCheers,\n\n -- Nikodemus\n"},{"id":"53113","messageId":"85myvoav1g.fsf@lola.goethe.zz","threadId":"9855","inReplyTo":"6bcc356f0709150611i97d31f0yb91016e53c4f5e9f@mail.gmail.com","subject":"Re: Data Integrity & un-Commited Branches","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-15T13:59:55Z","receivedAt":"2007-09-15T13:59:55Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Nikodemus Siivola\" writes:\n\n> One thing that I've been bitten a couple of times is that\n> I think I'm on branch X, which should be clean, whereas\n> I'm really on branch Y with uncommitted changes. Then I\n> checkout another branch, and see the uncommitted work -- and\n> given that I have a couple of dozen related feature branches\n> in my tree it may take a while to figure which branch the\n> uncommitted work came from.\n\n\"Take a while\"? What's wrong with git-reflog?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53135","messageId":"6bcc356f0709151014j9606a3ape6b62770304560ba@mail.gmail.com","threadId":"9855","inReplyTo":"85myvoav1g.fsf@lola.goethe.zz","subject":"Re: Data Integrity & un-Commited Branches","fromName":"Nikodemus Siivola","fromEmail":"nikodemus@random-state.net","sentAt":"2007-09-15T17:14:51Z","receivedAt":"2007-09-15T17:14:51Z","isPatch":false,"sender":{"key":"nikodemus@random-state.net","avatar":null},"body":"On 9/15/07, David Kastrup wrote:\n\n> \"Take a while\"? What's wrong with git-reflog?\n\nNot needing it as a part of my regular workflow, and therefore\nnot thinking about it. *blush*\n\nCheers,\n\n -- Nikodemus\n"},{"id":"53137","messageId":"85tzpval6b.fsf@lola.goethe.zz","threadId":"9855","inReplyTo":"6bcc356f0709151014j9606a3ape6b62770304560ba@mail.gmail.com","subject":"Re: Data Integrity & un-Commited Branches","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-15T17:33:00Z","receivedAt":"2007-09-15T17:33:00Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Nikodemus Siivola\" writes:\n\n> On 9/15/07, David Kastrup wrote:\n>\n>> \"Take a while\"? What's wrong with git-reflog?\n>\n> Not needing it as a part of my regular workflow, and therefore\n> not thinking about it. *blush*\n\n\"Oh no, what have I done now?\"\n\nI am afraid that working with git still exposes me to this question\ntime and again. And git-reflog usually provides the answer, as well\nas what I need to recover.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}