{"thread":{"id":"20666","subject":"question concerning branches","startedAt":"2009-08-19T17:33:00Z","lastAt":"2009-08-20T17:37:14Z","messageCount":21,"participants":["Ingo Brueckl","Bruce Stephens","Avery Pennarun","Junio C Hamano","Jakub Narebski","Jacob Helwig","Theodore Tso","Linus Torvalds","Randal L. Schwartz","Andreas Ericsson","Matthieu Moy","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121274","messageId":"4a8c373f@wupperonline.de","threadId":"20666","inReplyTo":null,"subject":"question concerning branches","fromName":"Ingo Brueckl","fromEmail":"ib@wupperonline.de","sentAt":"2009-08-19T17:33:00Z","receivedAt":"2009-08-19T17:33:00Z","isPatch":false,"sender":{"key":"ib@wupperonline.de","avatar":"https://avatars.githubusercontent.com/u/123327?v=4"},"body":"I'm a git novice and have a comprehension question concerning branches.\n\nWithin a git repository, I do:\n\n git branch test\n git checkout test\n # edit foo.bar\n git checkout master\n\nI'd expect that master is in the exactly same unchanged state it was at\nbranching time, but what a surprise, foo.bar is modified here, too!\n\nIf I continue now working in the master branch (applying patches and such) I\nwill use a changed foo.bar with testing branch content. I can't even apply\npatches to foo.bar without conflict.\n\nOf what use are branches if the files aren't totally separated from each\nother?\n\nWhat must I do to get a test branch I can't work without affecting master?\n\nIngo\n"},{"id":"121275","messageId":"80skfn4r04.fsf@tiny.isode.net","threadId":"20666","inReplyTo":"4a8c373f@wupperonline.de","subject":"Re: question concerning branches","fromName":"Bruce Stephens","fromEmail":"bruce.stephens@isode.com","sentAt":"2009-08-19T18:07:07Z","receivedAt":"2009-08-19T18:07:07Z","isPatch":false,"sender":{"key":"bruce.stephens@isode.com","avatar":null},"body":"ib@wupperonline.de (Ingo Brueckl) writes:\n\n> I'm a git novice and have a comprehension question concerning branches.\n>\n> Within a git repository, I do:\n>\n> git branch test\n> git checkout test\n> # edit foo.bar\n> git checkout master\n>\n> I'd expect that master is in the exactly same unchanged state it was at\n> branching time, but what a surprise, foo.bar is modified here, too!\n\nYou didn't commit your change to foo.bar.\n\n[...]\n\n> What must I do to get a test branch I can't work without affecting master?\n\ncommit changes.\n"},{"id":"121276","messageId":"32541b130908191107v2ab6752awb43f521f805b5f1a@mail.gmail.com","threadId":"20666","inReplyTo":"4a8c373f@wupperonline.de","subject":"Re: question concerning branches","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-19T18:07:14Z","receivedAt":"2009-08-19T18:07:14Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Aug 19, 2009 at 5:33 PM, Ingo Brueckl wrote:\n> Within a git repository, I do:\n>\n>  git branch test\n>  git checkout test\n>  # edit foo.bar\n>  git checkout master\n>\n> I'd expect that master is in the exactly same unchanged state it was at\n> branching time, but what a surprise, foo.bar is modified here, too!\n\nYou seem to have forgotten the \"git commit\" step before switching back\nto master. You have a modified file in your repository; what did you\n*want* to happen when you switched branches? (Many people find the\ncurrent behaviour very convenient.)\n\nYou might also want to look at the \"git stash\" command.\n\nAvery\n"},{"id":"121278","messageId":"4a8c4425@wupperonline.de","threadId":"20666","inReplyTo":"32541b130908191107v2ab6752awb43f521f805b5f1a@mail.gmail.com","subject":"question concerning branches","fromName":"Ingo Brueckl","fromEmail":"ib@wupperonline.de","sentAt":"2009-08-19T18:31:00Z","receivedAt":"2009-08-19T18:31:00Z","isPatch":false,"sender":{"key":"ib@wupperonline.de","avatar":"https://avatars.githubusercontent.com/u/123327?v=4"},"body":"Avery Pennarun writes:\n\n> You seem to have forgotten the \"git commit\" step before switching back\n> to master.\n\nNo, I passed over the commit in my example. I know that after the commit the\nthings are as they ought to be, but what if I can't do a commit because I am\nin the middle of coding and have to have a break?\n\n> You have a modified file in your repository; what did you *want* to happen\n> when you switched branches?\n\nI want an unchanged file in master if I switch there (because I worked in a\ndifferent branch) and a changed version in the test branch.\n\nWhy is the *master* different depending on whether my work in test in still\ngoing on or committed?!\n\nActually, I cannot image how branches are practicable if I always have to\nhave in mind possibly still uncommitted work. Shouldn't it be git's work\nto ensure that master will remain it was when branching?\n\nWithout git I'd make a copy for testing new features. With git, it seems that\nI have to do the same (a clone). This is what I don't understand.\n\n> (Many people find the current behaviour very convenient.)\n\nI find it highly confusing. I understood a branch as something I can do in\nwhatever I want without affecting master. But now a learn that everything I\ndo in the branch will happen in master, too, until I commit. Strange. Very\nstrange.\n\n> You might also want to look at the \"git stash\" command.\n\nYes, but isn't it annoying to leave the test branch always either with stash\nor commit in order to have an unchanged master?!\n\nIngo\n"},{"id":"121277","messageId":"7vr5v7vehj.fsf@alter.siamese.dyndns.org","threadId":"20666","inReplyTo":"4a8c373f@wupperonline.de","subject":"Re: question concerning branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-19T18:35:20Z","receivedAt":"2009-08-19T18:35:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ib@wupperonline.de (Ingo Brueckl) writes:\n\n> I'm a git novice and have a comprehension question concerning branches.\n>\n> Within a git repository, I do:\n>\n> git branch test\n> git checkout test\n> # edit foo.bar\n> git checkout master\n>\n> I'd expect that master is in the exactly same unchanged state it was at\n> branching time, but what a surprise, foo.bar is modified here, too!\n\nNo. Local modification that are not committed do not belong to any\nbranch. Rather it belongs to your work tree and the index, and follow you\nwhen you switch branches.\n\nThis is one of the most useful features. For example, it is an essential\npart of supporting the workflow described here:\n\n http://gitster.livejournal.com/25892.html\n\nOn the other hand, there are cases that you do not want to see your local\nchanges to foo.bar appear when you switch back to master, and the most\nobvious case is \"I started working on something, and I used a separate\nbranch 'test' because the change will be involved. I am in the middle of\nthe work, the changes so far I made to foo.bar is far from ready, but I\nhave to handle emergency fix on the master branch\". For that kind of\nsituation, you can use \"git stash\", like:\n\n http://gitster.livejournal.com/29577.html\n"},{"id":"121280","messageId":"m33a7noc3u.fsf@localhost.localdomain","threadId":"20666","inReplyTo":"4a8c4425@wupperonline.de","subject":"Re: question concerning branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-19T19:08:39Z","receivedAt":"2009-08-19T19:08:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"ib@wupperonline.de (Ingo Brueckl) writes:\n\n> Avery Pennarun writes:\n> \n> > You seem to have forgotten the \"git commit\" step before switching back\n> > to master.\n> \n> No, I passed over the commit in my example. I know that after the commit the\n> things are as they ought to be, but what if I can't do a commit because I am\n> in the middle of coding and have to have a break?\n\nThen you use git-stash. It was invented for that.\n \n> > You have a modified file in your repository; what did you *want* to happen\n> > when you switched branches?\n> \n> I want an unchanged file in master if I switch there (because I worked in a\n> different branch) and a changed version in the test branch.\n> \n> Why is the *master* different depending on whether my work in test in still\n> going on or committed?!\n\nBranches are about commits. State of a working directory doesn't\nbelong to a branch (in Git). Learning concepts behind Git would help\nyou in understanding it (Git is very consistent), which in turn would\nhelp in using it.\n\nWhat about untracked files? Do you want to lose them when you switch\nbranches?\n\n> \n> Actually, I cannot image how branches are practicable if I always have to\n> have in mind possibly still uncommitted work. Shouldn't it be git's work\n> to ensure that master will remain it was when branching?\n> \n> Without git I'd make a copy for testing new features. With git, it seems that\n> I have to do the same (a clone). This is what I don't understand.\n\nYou finish old work (or stash it away), _then_ you begin new work.\n\n> \n> > (Many people find the current behaviour very convenient.)\n\nTake the following example. You started coding some feature on\n'master' branch, then you realized that this feature is more\ncomplicated than you thought at first, so it should be developed in\nseparate topic branch. You do \"git checkout -b featureA\", and voila\nyou are now coding on feature branch 'featureA'.\n\n> > You might also want to look at the \"git stash\" command.\n> \n> Yes, but isn't it annoying to leave the test branch always either with stash\n> or commit in order to have an unchanged master?!\n\nNo, it isn't.\n\n-- \nJakub Narebski\n\nGit User's Survey 2009: http://tinyurl.com/GitSurvey2009\n"},{"id":"121281","messageId":"4a8c4ece@wupperonline.de","threadId":"20666","inReplyTo":"7vr5v7vehj.fsf@alter.siamese.dyndns.org","subject":"question concerning branches","fromName":"Ingo Brueckl","fromEmail":"ib@wupperonline.de","sentAt":"2009-08-19T19:21:00Z","receivedAt":"2009-08-19T19:21:00Z","isPatch":false,"sender":{"key":"ib@wupperonline.de","avatar":"https://avatars.githubusercontent.com/u/123327?v=4"},"body":"Junio C Hamano writes:\n\n> This is one of the most useful features.\n\nWow. I'm sursprised to hear that, because I consider it at the moment as a\nvery strange one.\n\n> For example, it is an essential\n> part of supporting the workflow described here:\n> http://gitster.livejournal.com/25892.html\n\nHere is what I'd expect to do with git (described with my own words, not in\ngit commands):\n\n1. commit the quick fix to the release branch\n2. push this single commit to origin and master\n\nNow that all branches have the commit a later push and pull should notice\nthis and \"skip\" it.\n\nThis leads to a second question I have. Assuming I have three patches in my\nrepo (#1, #2 and #3), is it possible to push only #2 (because it is a\nquick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and\n#4?\n\nIngo\n"},{"id":"121283","messageId":"4a8c51f5@wupperonline.de","threadId":"20666","inReplyTo":"m33a7noc3u.fsf@localhost.localdomain","subject":"question concerning branches","fromName":"Ingo Brueckl","fromEmail":"ib@wupperonline.de","sentAt":"2009-08-19T19:45:00Z","receivedAt":"2009-08-19T19:45:00Z","isPatch":false,"sender":{"key":"ib@wupperonline.de","avatar":"https://avatars.githubusercontent.com/u/123327?v=4"},"body":"Jakub Narebski writes:\n\n> You finish old work (or stash it away), _then_ you begin new work.\n\nOk, this helps me a little bit to understand.\n\nThe branches aren't designed to split my work, but rather something to\ncollect the different parts of my work.\n\nBut as software development often is something where you are coding on\nseveral issues at the same time which can't be committed immediately, it\nsounds that 'stash' is the developer's best friend.\n\nIngo\n"},{"id":"121284","messageId":"32541b130908191250w79461592vf1bed7874aa4138b@mail.gmail.com","threadId":"20666","inReplyTo":"4a8c51f5@wupperonline.de","subject":"Re: question concerning branches","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-19T19:50:31Z","receivedAt":"2009-08-19T19:50:31Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Aug 19, 2009 at 7:45 PM, Ingo Brueckl wrote:\n> Jakub Narebski writes:\n>\n>> You finish old work (or stash it away), _then_ you begin new work.\n>\n> Ok, this helps me a little bit to understand.\n>\n> The branches aren't designed to split my work, but rather something to\n> collect the different parts of my work.\n>\n> But as software development often is something where you are coding on\n> several issues at the same time which can't be committed immediately, it\n> sounds that 'stash' is the developer's best friend.\n\nOr you could just 'commit' more frequently, but don't 'push' so you're\nnot disturbing anyone else until you're done.\n\nThis is a big difference from how centralized VCSs work: there, a\ncommit is a major operation that you're afraid to do in case you make\nsomeone else mad. In git, commits are cheap, you just need to be\ncareful about pushing.\n\n(You can also clean up your series of commits before pushing by using\n'git rebase')\n\nHave fun,\n\nAvery\n"},{"id":"121285","messageId":"8c9a060908191253q2ad30056vc26227cfe7bb438@mail.gmail.com","threadId":"20666","inReplyTo":"4a8c51f5@wupperonline.de","subject":"Re: question concerning branches","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2009-08-19T19:53:42Z","receivedAt":"2009-08-19T19:53:42Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Wed, Aug 19, 2009 at 12:45, Ingo Brueckl wrote:\n>\n> But as software development often is something where you are coding on\n> several issues at the same time which can't be committed immediately, it\n> sounds that 'stash' is the developer's best friend.\n>\n> Ingo\n>\n\nThere is no problem with having temporary commits on local branches,\nhowever.\n\nQuite frequently, I'll \"git commit -a -m 'Temp commit'; git checkout\nother-branch\". As long as you don't make these temporary commits\npublic, it's very easy to munge them (See: \"git rebase --interactive\n\", and \"git reset --soft \").\n\n-Jacob\n"},{"id":"121286","messageId":"200908192201.36383.jnareb@gmail.com","threadId":"20666","inReplyTo":"4a8c51f5@wupperonline.de","subject":"Re: question concerning branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-19T20:01:35Z","receivedAt":"2009-08-19T20:01:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 19 Aug 2009, Ingo Brueckl wrote:\n> Jakub Narebski writes:\n> \n> > You finish old work (or stash it away), _then_ you begin new work.\n> \n> Ok, this helps me a little bit to understand.\n> \n> The branches aren't designed to split my work, but rather something to\n> collect the different parts of my work.\n\nWell, git is flexible enough that it can support also the workflow you \ntried to use. \n\nNamely you can have many working directories tied to single repository \n(each of those checkouts should be of different branch). You can use \ngit-new-workdir script from contrib/worktree for that. Then to switch \nbranches you would just cd to appropriate directory (and keep unsaved \nchanges and untracked files). That said it is [much] less used \nworkflow.\n \n> But as software development often is something where you are coding on\n> several issues at the same time which can't be committed immediately,\n> it sounds that 'stash' is the developer's best friend.\n\nWell, you can also commit and then clean up history with interactive \nrebase (or patch management interface such as StGit or Guilt). In \ndistributed version control systems like Git the act of publishing \nchanges is separate from the act of committing them (you should not \nrewrite published history, though).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"121287","messageId":"20090819203917.GH27206@mit.edu","threadId":"20666","inReplyTo":"4a8c51f5@wupperonline.de","subject":"Re: question concerning branches","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-08-19T20:39:17Z","receivedAt":"2009-08-19T20:39:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Aug 19, 2009 at 09:45:00PM +0200, Ingo Brueckl wrote:\n> Jakub Narebski writes:\n> \n> > You finish old work (or stash it away), _then_ you begin new work.\n> \n> Ok, this helps me a little bit to understand.\n> \n> The branches aren't designed to split my work, but rather something to\n> collect the different parts of my work.\n> \n> But as software development often is something where you are coding on\n> several issues at the same time which can't be committed immediately, it\n> sounds that 'stash' is the developer's best friend.\n\nContext switching has overhead; so it's usually better to try to\ncomplete one task before switching to another. Granted, sometimes it\ncan't be done, but it's something you should really try to do.\n\nAlso, commits are easier to review if they are kept small; if you\nlocalize changes into separate commits, it's often easier to detet\nproblems when doing \"git bisect\", for example. So if you are often\nneeding to switch while leaving something that isn't ready to be\ncommitted, you might want to ask yourself if you are putting too many\nchanges into a single ocmmit.\n\nPersonally, in the cases where I can't finish a commit before I need\nto switch away to another branch, my preference is to not use \"git\nstash\", but instead to create a topic branch, and then check in a\npartially completed change on the topic branch, which I can later\nammend using \"git commit --amend\" (or if I have multiple commits on\nthe topic branch, \"git rebase --interactive\"). This is because I can\nuse the commit description to leave myself some notes about what still\nneeds to be done before the commit can be finalized.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"121288","messageId":"200908192257.23347.jnareb@gmail.com","threadId":"20666","inReplyTo":"20090819203917.GH27206@mit.edu","subject":"Re: question concerning branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-19T20:57:21Z","receivedAt":"2009-08-19T20:57:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso wrote:\n\n> Personally, in the cases where I can't finish a commit before I need\n> to switch away to another branch, my preference is to not use \"git\n> stash\", but instead to create a topic branch, and then check in a\n> partially completed change on the topic branch, which I can later\n> ammend using \"git commit --amend\" (or if I have multiple commits on\n> the topic branch, \"git rebase --interactive\"). This is because I can\n> use the commit description to leave myself some notes about what still\n> needs to be done before the commit can be finalized.\n\nErrr... you are aware that you can use \"git stash save \" (i.e. \nspecify commit message for stash; well, the subject), don't you?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"121290","messageId":"alpine.LFD.2.01.0908191441070.3158@localhost.localdomain","threadId":"20666","inReplyTo":"4a8c51f5@wupperonline.de","subject":"Re: question concerning branches","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-08-19T21:51:17Z","receivedAt":"2009-08-19T21:51:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Aug 2009, Ingo Brueckl wrote:\n\n> Jakub Narebski writes:\n> \n> > You finish old work (or stash it away), _then_ you begin new work.\n> \n> Ok, this helps me a little bit to understand.\n> \n> The branches aren't designed to split my work, but rather something to\n> collect the different parts of my work.\n\nHmm. Yes. That's one way of looking at it.\n\nAt the same time, thinking about it another way may explain the git \nchoices in this area. There's two issues:\n\n - if we _don't_ carry the edits around across branch switches, then what \n would we do?\n\n Basically, since you haven't committed things, it's kind of floating \n around. You switch to another branch, what should we do? There are \n really only two choices: either we'd need to 'stash' the state with the \n branch we switch away from (which is apparently what you expected), or \n we need to just move the changes to the new branch (which is what git \n does, or complains if it cannot).\n\n Now, 'stashing' the changes is actually very much against the whole git \n philosophy. Git was built up around the index and the database, and \n branches have always been pointers to the top-of-commit, so there \n literally isn't any way to stash things that makes sense. Sure, later \n on we ended up having the 'stash' command, but that's totally separate \n from branches, and is an independently useful thing.\n\n - One of the big reasons to act like git does is that the way at least \n _I_ work is to actually create a new branch with the explicit intention \n of committing work I have already done!\n\n IOW, your example was\n\n\tgit branch test\n\tgit checkout test\n\t# edit foo.bar\n\tgit checkout master\n\n and you were surprised that the edit followed you back to the \"master\" \n branch, but what is actualyl a much more natural way of working is\n\n\t# edit foo.bar\n\t# realize that this was actually the start of a new feature\n\tgit branch new-feature\n\tgit checkout new-feature\n\t# maybe continue to edit foo.bar until it's all good\n\tgit commit -a\n\n ie the git behavior explicitly _encourages_ you to not have to decide \n before-the-fact to create a branch - it may be that only after you've \n done the changes do you realize that \"oops, these changes were _way_ \n more intrusive than I originally anticipated, and I don't want to \n commit them on the master branch, I want to commit them on an \n experimental topic branch instead\"\n\nSo there are two different reasons why git works the way it does: a pure \nimplementation reason (\"working any other way would not fit the git \nmodel\") and a practical workflow reason (\"you are _expected_ to move dirty \nstate around with your branches, because one common case is to create a \nbranch _for_ that dirty state\").\n\n\t\t\tLinus\n"},{"id":"121313","messageId":"86y6pfyyrd.fsf@blue.stonehenge.com","threadId":"20666","inReplyTo":"alpine.LFD.2.01.0908191441070.3158@localhost.localdomain","subject":"Re: question concerning branches","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2009-08-20T03:01:26Z","receivedAt":"2009-08-20T03:01:26Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> \tgit branch new-feature\nLinus> \tgit checkout new-feature\n\nOr my favorite: \"git checkout -b new-feature\".\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"121316","messageId":"4A8CFC44.8050707@op5.se","threadId":"20666","inReplyTo":"4a8c4ece@wupperonline.de","subject":"Re: question concerning branches","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-08-20T07:33:24Z","receivedAt":"2009-08-20T07:33:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ingo Brueckl wrote:\n> Junio C Hamano writes:\n> \n>> This is one of the most useful features.\n> \n> Wow. I'm sursprised to hear that, because I consider it at the moment as a\n> very strange one.\n> \n>> For example, it is an essential\n>> part of supporting the workflow described here:\n>> http://gitster.livejournal.com/25892.html\n> \n> Here is what I'd expect to do with git (described with my own words, not in\n> git commands):\n> \n> 1. commit the quick fix to the release branch\n> 2. push this single commit to origin and master\n> \n> Now that all branches have the commit a later push and pull should notice\n> this and \"skip\" it.\n> \n> This leads to a second question I have. Assuming I have three patches in my\n> repo (#1, #2 and #3), is it possible to push only #2 (because it is a\n> quick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and\n> #4?\n> \n\nIf they're on different branches, yes. If they're on the same branch, no.\nThis is because a commit in git is named uniquely not only by its contents,\nbut also by its ancestry.\n\nYou can, however, run \"git rebase --interactive\" and re-order the commits\nbefore you push them, so that #2 becomes #1 and vice versa. Then you can\npush only #1 (the old #2) while leaving #2 (the old #1), #3 and #4 on\nyour machine only. This involves knowing the commit identifier of #1\nthough. Assuming it's \"deadbeef\", you can update the remote branch \"foo\"\nto hold your new commit by running the following command:\n\n git push deadbeef:refs/heads/foo\n\nHTH\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"121320","messageId":"vpqzl9urk6y.fsf@bauges.imag.fr","threadId":"20666","inReplyTo":"32541b130908191250w79461592vf1bed7874aa4138b@mail.gmail.com","subject":"Re: question concerning branches","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-20T07:57:57Z","receivedAt":"2009-08-20T07:57:57Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Avery Pennarun writes:\n\n> This is a big difference from how centralized VCSs work: there, a\n> commit is a major operation that you're afraid to do in case you make\n> someone else mad. In git, commits are cheap, you just need to be\n> careful about pushing.\n\nI second this. \"commit\" is indeed a bad name in decentralized VCSs.\nThere's no commitment from the developer, you don't commit to swear\nthe code is good, but you commit just to record a set of changes, and\nattach a descriptive message to it.\n\nIn Git, a commit takes usually a fraction of a second, and can be\nmodified later easily until it's pushed.\n\n'git commit --amend' will allow you to change either the changes or\nthe message associated to a commit.\n\n'git reset HEAD^' will just undo the commit, turning your commited\nchanges into uncommited ones.\n\n'git rebase --interactive' will allow you another bunch of cool\nthings.\n\nSo, keeping your changes uncommited has very few advantage, and indeed\nhas one big drawback: uncommited changes have no descriptive message\nassociated, so if you leave a branch for some time, it makes it more\ndifficult for you to remember what you were doing on it when you\nswitch back to it:\n\ngit checkout -b topic-branch\n# edit foo.bar\ngit checkout master\n# hack\ngit commit\n# go on holiday\n# come back\ngit checkout topic-branch\ngit status\n# err, what is this all about?\n\nOTOH:\n\ngit checkout -b topic-branch\n# edit foo.bar\ngit commit -m \"started feature foo, but bar is still to be done\"\ngit checkout master\n# hack\ngit commit\n# go on holiday\n# come back\ngit checkout topic-branch\ngit show\n# Ah, I remember!\n\nActually, all the VCSs I know about (Mercurial, Bazaar, Subversion,\nand IIRC GNU Arch) deal with this the way Git does. Hey! there must be\na reason ;-).\n\n-- \nMatthieu\n"},{"id":"121324","messageId":"4a8d4583@wupperonline.de","threadId":"20666","inReplyTo":"alpine.LFD.2.01.0908191441070.3158@localhost.localdomain","subject":"question concerning branches","fromName":"Ingo Brueckl","fromEmail":"ib@wupperonline.de","sentAt":"2009-08-20T12:46:00Z","receivedAt":"2009-08-20T12:46:00Z","isPatch":false,"sender":{"key":"ib@wupperonline.de","avatar":"https://avatars.githubusercontent.com/u/123327?v=4"},"body":"Linus Torvalds writes:\n\n> branches have always been pointers to the top-of-commit\n\nObviously I expected them to be pointers on trees.\n\nA kind of automatical starting commit in a newly created branch would at\nleast warn if one has begun changing files and wants to checkout back.\n(Is this a feature worth of discussion?)\n\n> the git behavior explicitly _encourages_ you to not have to decide\n> before-the-fact to create a branch\n\nThanks for the explanation which help me to understand why git works like it\ndoes.\n\nI'm able to follow your examples, but what I had it mind when I started the\ntopic and my example was:\n\nAssume a project is released (i.e. no more open bugs we know about) - I know\nwe're drifting towards fantasy now. ;-)\n\nOn the one hand, I want to add single new features (such as other developers\ndo) which will be written, tested and committed. I want to push/pull\nfrequently to be up to date all the time. (master branch)\n\nOn the other hand, I want to completely rewrite the core of the program.\n(test or rewrite branch)\n\nWhat is the git way to do this in a the right (and clever) manner?\n\nIn a branch, I learned, I have to commit or stash before I return to master\nfor push/pull to follow the project. If I forget, I'm screwed, because files\nhave changed due to the rewrite (in that branch), I won't get a warning until\nmy first commit (in that branch) and commits (in master) will conflict.\n\nIngo\n"},{"id":"121331","messageId":"4A8D53F3.3050500@viscovery.net","threadId":"20666","inReplyTo":"4a8d4583@wupperonline.de","subject":"Re: question concerning branches","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-08-20T13:47:31Z","receivedAt":"2009-08-20T13:47:31Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"[Please don't cull the Cc list.]\n\nIngo Brueckl schrieb:\n> On the one hand, I want to add single new features (such as other developers\n> do) which will be written, tested and committed. I want to push/pull\n> frequently to be up to date all the time. (master branch)\n\nIf you want to stay up-to-date while you are creating a new feature, then\nyour workflow is sub-optimal. This message by Linus is good to read:\n\nhttp://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html\n\nThe important rule is \"Don't merge upstream code at random points\".\n\nOnce you learnt this rule, then you also see that it is not important to\nalways stay up-to-date. It is important to complete (test, debug) your\nfeature on a stable base. During that time, you don't care about upstream;\nyou care about your feature.\n\n> In a branch, I learned, I have to commit or stash before I return to master\n> for push/pull to follow the project. If I forget, I'm screwed, because files\n> have changed due to the rewrite (in that branch), I won't get a warning until\n> my first commit (in that branch) and commits (in master) will conflict.\n\nYou are obviously of a CVS or SVN mindset, where making a commit is such\nan important operation that you don't dare to make it until your work is\n*completed*.\n\nWith a git mindset, it won't happen that you \"forget\" whether you have\nanything uncommitted; you simply never have because committing half-baked\nstuff is the rule, not the exception. That is, before you get a cup of\ncoffee, you commit; before you answer a phone call, you commit; before you\nturn your attention away, you commit. (That may be exaggerated, perhaps it\neven isn't, but you get the point.)\n\nWhen you have completed your work, you go back to make your commit history\nlook nice, comprehensible, and bisectable.\n\nAnd only then comes the heavy operation: You publish your work for\nconsumption by interested parties. This may be even only you yourself:\n\"Consumption\" would be to merge the work into your release branch. This is\nthe right time to care about upstream again.\n\n-- Hannes\n"},{"id":"121350","messageId":"m3y6pemsyl.fsf@localhost.localdomain","threadId":"20666","inReplyTo":"4A8D53F3.3050500@viscovery.net","subject":"Re: question concerning branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-20T14:59:50Z","receivedAt":"2009-08-20T14:59:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Sixt writes:\n\n> Ingo Brueckl schrieb:\n\n> > In a branch, I learned, I have to commit or stash before I return to master\n> > for push/pull to follow the project. If I forget, I'm screwed, because files\n> > have changed due to the rewrite (in that branch), I won't get a warning until\n> > my first commit (in that branch) and commits (in master) will conflict.\n\nErrr... if having unknown files in status info when comitting doesn't\nclue you in that you have spurious uncomitted changes, \n\n # On branch master\n # Changes to be committed:\n # (use \"git reset HEAD ...\" to unstage)\n #\n # modified: somefile\n\nand neither commit diff summary\n\n n files changed, kk insertions(+), ll deletions(-)\n\ndoesn't clue you in, then you have more serous problems!\n\n\nSecond, you can use git-aware prompt to tell you if you have\nuncomitted changes, so you will know when switching branches that you\nhave some changes that don't belong to branch you switch from.\n\n> \n> You are obviously of a CVS or SVN mindset, where making a commit is such\n> an important operation that you don't dare to make it until your work is\n> *completed*.\n> \n> With a git mindset, it won't happen that you \"forget\" whether you have\n> anything uncommitted; you simply never have because committing half-baked\n> stuff is the rule, not the exception. That is, before you get a cup of\n> coffee, you commit; before you answer a phone call, you commit; before you\n> turn your attention away, you commit. (That may be exaggerated, perhaps it\n> even isn't, but you get the point.)\n> \n> When you have completed your work, you go back to make your commit history\n> look nice, comprehensible, and bisectable.\n\n...with \"git rebase --interactive\" or patch management interface\n(StGit, Guilt), or topic branch management interface (TopGit).\n\n> \n> And only then comes the heavy operation: You publish your work for\n> consumption by interested parties. This may be even only you yourself:\n> \"Consumption\" would be to merge the work into your release branch. This is\n> the right time to care about upstream again.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"121355","messageId":"20090820173714.GD7076@mit.edu","threadId":"20666","inReplyTo":"200908192257.23347.jnareb@gmail.com","subject":"Re: question concerning branches","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-08-20T17:37:14Z","receivedAt":"2009-08-20T17:37:14Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Aug 19, 2009 at 10:57:21PM +0200, Jakub Narebski wrote:\n> Errr... you are aware that you can use \"git stash save \" (i.e. \n> specify commit message for stash; well, the subject), don't you?\n\nI wasn't aware, but usually I like leaving more notes to myself than\njust a single lines' worth of state. I should probably take another\nlook at \"git stash\" and see if it's a handy tool for me to use; but so\nfar I've been happy enough with \"git checkout -b topic-name; git\ncommit\".\n\n\t\t\t\t\t\t- Ted\n"}]}