{"thread":{"id":"8477","subject":"pull/merge --no-commit","startedAt":"2007-06-07T04:26:49Z","lastAt":"2007-06-07T20:51:17Z","messageCount":10,"participants":["kurt_p_lloyd","Junio C Hamano","Kevin Green","Keith Duthie","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44223","messageId":"46678909.10608@alcatel-lucent.com","threadId":"8477","inReplyTo":null,"subject":"pull/merge --no-commit","fromName":"kurt_p_lloyd","fromEmail":"kplloyd@alcatel-lucent.com","sentAt":"2007-06-07T04:26:49Z","receivedAt":"2007-06-07T04:26:49Z","isPatch":false,"sender":{"key":"kplloyd@alcatel-lucent.com","avatar":null},"body":"Hello,\nI'm new to git, thought I'd take it for a spin.\nFound what seems to me to be a problem,\nhoping someone can shed light on it.\n\nI /really/ want --no-commit to work, bit it doesn't seem to:\n\nI run:      git pull --no-commit ssh://<blah blah blah>\n\nthen I run: git status\n\nit says:    nothing to commit (working directory clean)\n\nthen I run: git log\n\nit shows the commit message from the other user below a\ncommit sha1, and the change I pulled was indeed merged to\nmy file.\n\nDoes this seem to be a bug, or am I doing something wrong?\nBTW, merge --no-commit gives me the same problem.  It merges\nfine but does the commit.\n\nI put a 'set -x' in the git-merge shell script (which gets\ncalled by pull) from one of my 'pull' runs, I have the output\nif anyone wants it.\n\n-Kurt\n"},{"id":"44225","messageId":"46678C04.1030507@alcatel-lucent.com","threadId":"8477","inReplyTo":"46678909.10608@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"kurt_p_lloyd","fromEmail":"kplloyd@alcatel-lucent.com","sentAt":"2007-06-07T04:39:32Z","receivedAt":"2007-06-07T04:39:32Z","isPatch":false,"sender":{"key":"kplloyd@alcatel-lucent.com","avatar":null},"body":"PS - Sorry, I should have mentioned the git version: 1.5.2.1\n\nkurt_p_lloyd wrote:\n> Hello,\n> I'm new to git, thought I'd take it for a spin.\n> Found what seems to me to be a problem,\n> hoping someone can shed light on it.\n> \n> I /really/ want --no-commit to work, bit it doesn't seem to:\n> \n> I run:      git pull --no-commit ssh://<blah blah blah>\n> \n> then I run: git status\n> \n> it says:    nothing to commit (working directory clean)\n> \n> then I run: git log\n> \n> it shows the commit message from the other user below a\n> commit sha1, and the change I pulled was indeed merged to\n> my file.\n> \n> Does this seem to be a bug, or am I doing something wrong?\n> BTW, merge --no-commit gives me the same problem.  It merges\n> fine but does the commit.\n> \n> I put a 'set -x' in the git-merge shell script (which gets\n> called by pull) from one of my 'pull' runs, I have the output\n> if anyone wants it.\n> \n> -Kurt\n"},{"id":"44229","messageId":"7vfy54qqu8.fsf@assigned-by-dhcp.cox.net","threadId":"8477","inReplyTo":"46678909.10608@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-07T05:24:47Z","receivedAt":"2007-06-07T05:24:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:\n\n> I run:      git pull --no-commit ssh://<blah blah blah>\n>\n> then I run: git status\n>\n> it says:    nothing to commit (working directory clean)\n>\n> then I run: git log\n>\n> it shows the commit message from the other user below a\n> commit sha1, and the change I pulled was indeed merged to\n> my file.\n>\n> Does this seem to be a bug, or am I doing something wrong?\n\nNo bug, no user error.\n\nI suspect you did not have _ANY_ of your own development.  If\nthat is the case, then it worked as you told it to.  You asked\nno merge commit to be made, and it did not create a new merge\ncommit.\n\nIllustration.  Earlier you had (probably your git-clone created\nthis) this history:\n\n ---A---B---C---D\n                ^ HEAD\n\nand your tip of the branch (and HEAD) was at commit D.  You did\nnot do any of your own development yourself, and then you\npulled.\n\nIn the meantime, the other repository had been busily working\nand has a few more commits:\n\n ---A---B---C---D---E---F---G---H\n                ^               ^\n                Your HEAD       The tip of the branch you\n                was here.       pulled is here.\n\nIn this case, because you do not have anything new to add to the\nhistory (remember, git history is a global DAG -- you and the\nother repository are building it by pushing and pulling), we\nmove your HEAD to H (the tip of the branch you are pulling).\nThere is no need to create a new merge commit, with or without\nthe --no-commit option.  This is called \"fast forward\".\n\nIn a more interesting case, you will see a different behaviour.\nLet's suppose you started from the same state (i.e. cloned up to\nD), and built your own changes on top of it:\n\n                          Your HEAD\n                          v\n                  X---Y---Z\n                 / \n ---A---B---C---D\n\nwhile the other repository had the same E...H development line.\nYou pull from them.  Remember, pull is a fetch followed by a\nmerge.  After the fetch, you get this:\n\n                          Your HEAD\n                          v\n                  X---Y---Z\n                 /\n ---A---B---C---D---E---F---G---H\n                                ^\n                                The tip of the branch you\n                                pulled is here.\n\nThis is not a \"fast forward\" situation and \"git pull\" would need\na new merge commit, like this:\n\n                          Your HEAD used to be here\n                          v\n                  X---Y---Z-------M <- A new merge commit\n                 /               /     becomes HEAD\n ---A---B---C---D---E---F---G---H\n                                ^\n                                The tip of the branch you\n                                pulled is here.\n\nWhat --no-commit does is to prepare a tree to be used to create\nthe merge commit \"M\", without actually creating a commit.  So if\nyou did \"git pull --no-commit\", your HEAD would stay at Z and\nyour index and working tree is prepared to create the tree\nsuitable to be committed as \"M\".  After that, you have a chance\nto make further changes to your working tree before creating a\ncommit with \"git commit\", to affect what is recorded in the\nresulting merge commit \"M\".\n\nIn the case of \"fast forward\", --no-commit still moves the HEAD,\nand this is deliberate.  Imagine if we did not move the head.\nBecause the merge is \"fast forward\" in reality, what is left in\nthe index and the working tree to be committed should exactly\nmatch what is in H.  You may futz with the working tree further\nbefore actually creating the commit, and the next \"git commit\"\nwould give you this graph:\n\n                  .---------------M\n                 /               / \n ---A---B---C---D---E---F---G---H\n                ^               ^\n                Your HEAD       The tip of the branch you\n                is still here.  pulled is here.\n\nThe difference between H and M is strictly what you did to the\nindex and the working tree between \"pull --no-commit\" and\n\"commit\".\n\nThat is insane.  Why?  Because what you really did was to start\nfrom the tree of H, did your own development (i.e. \"diff H M\"),\nand made a commit.  This is the reason why --no-commit does not\ndo anything special when the pull is a fast forward.\n\nThe resulting history should not be the above merge, but just\nlike this:\n\n ---A---B---C---D---E---F---G---H---M\n\nYou did a \"fast forward\", and did your own development to make a\nsingle commit, which is what this history should look like.\nThere was no merge performed.  Just a straight line of\ndevelopment on top of what you got from the other side.\n"},{"id":"44252","messageId":"46684EFD.1080804@alcatel-lucent.com","threadId":"8477","inReplyTo":"7vfy54qqu8.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull/merge --no-commit","fromName":"kurt_p_lloyd","fromEmail":"kplloyd@alcatel-lucent.com","sentAt":"2007-06-07T18:31:25Z","receivedAt":"2007-06-07T18:31:25Z","isPatch":false,"sender":{"key":"kplloyd@alcatel-lucent.com","avatar":null},"body":"comments intermixed below\n\nJunio C Hamano wrote:\n > kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:\n >\n >> I run:      git pull --no-commit ssh://<blah blah blah>\n >>\n >> then I run: git status\n >>\n >> it says:    nothing to commit (working directory clean)\n >>\n >> then I run: git log\n >>\n >> it shows the commit message from the other user below a\n >> commit sha1, and the change I pulled was indeed merged to\n >> my file.\n >>\n >> Does this seem to be a bug, or am I doing something wrong?\n >\n > No bug, no user error.\n >\n > I suspect you did not have _ANY_ of your own development.\n\nSpot on :)\n\n > If that is the case, then it worked as you told it to.  You asked\n > no merge commit to be made, and it did not create a new merge\n > commit.\n\nAh, the difference in terminology biting me here .... I'm used to\nClearCase, where the term \"merge\" includes so-called \"trivial merges\",\nwhere a change is merely copied from one branch to another,\nwith no parallel changes on the receiving branch.\n\n > Illustration.  Earlier you had (probably your git-clone created\n > this) this history:\n >\n >  ---A---B---C---D\n >                 ^ HEAD\n >\n > and your tip of the branch (and HEAD) was at commit D.  You did\n > not do any of your own development yourself, and then you pulled.\n >\n > In the meantime, the other repository had been busily working\n > and has a few more commits:\n >\n >  ---A---B---C---D---E---F---G---H\n >                 ^               ^\n >                 Your HEAD       The tip of the branch you\n >                 was here.       pulled is here.\n >\n > In this case, because you do not have anything new to add to the\n > history (remember, git history is a global DAG -- you and the\n > other repository are building it by pushing and pulling), we\n > move your HEAD to H (the tip of the branch you are pulling).\n > There is no need to create a new merge commit, with or without\n > the --no-commit option.  This is called \"fast forward\".\n\nExcept here's the model that I am trying to follow....\nIt seems that 'pull' can be partitioned into 3 separate responsibilities:\n\n   1. Retrieve changes from the remote user's replica (without modifying\n      any /local/ branches).\n   2. Bring changes from \"remote\" into a local branch (without commit).\n   3. Commit.\n\nMy thoughts are that if I could have these be 3 different, sequential steps,\nafter step 1 I could peruse the \"database\" to see what \"remote\" changed, and\nwhether or not I may like such changes, and would want to /consider/ \"taking\"\nthem.  If no then I do nothing.  If yes then I do step 2.\nAfter step 2 I may find that I don't really like those changes after all.\nI only commit if I really do like those changes.\n\nI don't want to overdo it here on the ClearCase stuff, but this\nscenario is one which is very natural in that system:\n\n   1. multisite syncreplica\n   2. cleartool merge  # even for \"trivial merges\"\n   3. cleartool checkin (or cleartool uncheckout if I don't like the changes)\n\nmore way below\n\n > In a more interesting case, you will see a different behaviour.\n > Let's suppose you started from the same state (i.e. cloned up to\n > D), and built your own changes on top of it:\n >\n >                           Your HEAD\n >                           v\n >                   X---Y---Z\n >                  /\n >  ---A---B---C---D\n >\n > while the other repository had the same E...H development line.\n > You pull from them.  Remember, pull is a fetch followed by a\n > merge.  After the fetch, you get this:\n >\n >                           Your HEAD\n >                           v\n >                   X---Y---Z\n >                  /\n >  ---A---B---C---D---E---F---G---H\n >                                 ^\n >                                 The tip of the branch you\n >                                 pulled is here.\n >\n > This is not a \"fast forward\" situation and \"git pull\" would need\n > a new merge commit, like this:\n >\n >                           Your HEAD used to be here\n >                           v\n >                   X---Y---Z-------M <- A new merge commit\n >                  /               /     becomes HEAD\n >  ---A---B---C---D---E---F---G---H\n >                                 ^\n >                                 The tip of the branch you\n >                                 pulled is here.\n >\n > What --no-commit does is to prepare a tree to be used to create\n > the merge commit \"M\", without actually creating a commit.  So if\n > you did \"git pull --no-commit\", your HEAD would stay at Z and\n > your index and working tree is prepared to create the tree\n > suitable to be committed as \"M\".  After that, you have a chance\n > to make further changes to your working tree before creating a\n > commit with \"git commit\", to affect what is recorded in the\n > resulting merge commit \"M\".\n >\n > In the case of \"fast forward\", --no-commit still moves the HEAD,\n > and this is deliberate.  Imagine if we did not move the head.\n > Because the merge is \"fast forward\" in reality, what is left in\n > the index and the working tree to be committed should exactly\n > match what is in H.  You may futz with the working tree further\n > before actually creating the commit, and the next \"git commit\"\n > would give you this graph:\n >\n >                   .---------------M\n >                  /               /\n >  ---A---B---C---D---E---F---G---H\n >                 ^               ^\n >                 Your HEAD       The tip of the branch you\n >                 is still here.  pulled is here.\n >\n > The difference between H and M is strictly what you did to the\n > index and the working tree between \"pull --no-commit\" and\n > \"commit\".\n >\n > That is insane.  Why?  Because what you really did was to start\n > from the tree of H, did your own development (i.e. \"diff H M\"),\n > and made a commit.  This is the reason why --no-commit does not\n > do anything special when the pull is a fast forward.\n >\n > The resulting history should not be the above merge, but just\n > like this:\n >\n >  ---A---B---C---D---E---F---G---H---M\n >\n > You did a \"fast forward\", and did your own development to make a\n > single commit, which is what this history should look like.\n > There was no merge performed.  Just a straight line of\n > development on top of what you got from the other side.\n\nI must compliment you on your excellent communication.\nMaybe there is a different workflow to effectively achieve what\nI want via steps 1, 2, and 3 (way above).  In other words, OK I do\na 'pull', and all 3 steps occur together.  Then suppose that I\ncontemplate the changes that got committed, and that I disapprove\nof either a majority or all of those changes.  I'd like to be able\nto cleanly and easily recover from this with no related commits and\n\"revert commits\" in git log.  I'll add my own deliberate commits if\nand when I decide that I really /would/ like some or all of those\nchanges eventually, in which case I would still like the proper\ncontext to exist in the \"database\" for me to bring the selective\nremote changes into my local branch in a natural way.\nAre there git commands to best cover this scenario?\n\nKind regards,\n-Kurt\n"},{"id":"44253","messageId":"7vvedzpp69.fsf@assigned-by-dhcp.cox.net","threadId":"8477","inReplyTo":"46684EFD.1080804@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-07T18:58:22Z","receivedAt":"2007-06-07T18:58:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:\n\n> Maybe there is a different workflow to effectively achieve what\n> I want via steps 1, 2, and 3 (way above).  In other words, OK I do\n> a 'pull', and all 3 steps occur together.  Then suppose that I\n> contemplate the changes that got committed, and that I disapprove\n> of either a majority or all of those changes.  I'd like to be able\n> to cleanly and easily recover from this with no related commits and\n> \"revert commits\" in git log.\n\nLet's say you did this:\n\n $ git pull $other_party\n\nA \"pull\" is a \"fetch\" (download their history and objects)\nfollowed by a \"merge\" (integrate that history with your\nhistory).  When it goes without merge conflicts you need to\nresolve by hand, the above will move your HEAD to reflect the\nnew histroy of your project, including the fact that you merged\nwith the $other_party, at this point.  The above command gives\nyou the overview of the change in the form of diffstat.\n\nYou would naturally want to inspect and convince yourself that\nyou did not pull crap from the $other_party.  A special symbol\nORIG_HEAD is set up after a \"merge\" (be it a \"fast forward\" or a\ntrue merge) that lets you easily access where the tip of your\nbranch was before the merge.\n\nTo view the damage the $other_party inflicted on you as a whole:\n\n $ git diff ORIG_HEAD..\n\nOr to inspect individual patches:\n\n $ git log -p ORIG_HEAD..\n\nSome people seem to prefer \"git log --reverse -p ORIG_HEAD..\",\nwhich would give their changes in chronological order.\n\nIf it turns out that you pulled crap from the $other_party, you\ncan get rid of that away from the history of your branch with:\n\n $ git reset --hard ORIG_HEAD\n\n> I'll add my own deliberate commits if\n> and when I decide that I really /would/ like some or all of those\n> changes eventually, in which case I would still like the proper\n> context to exist in the \"database\" for me to bring the selective\n> remote changes into my local branch in a natural way.\n\nIn git managed projects that care about the readability of\nglobal history, this often is done by asking $other_party to\nredo the branch, discarding broken/undesirable bits.\n\nBut if you do not have the clout to do so over the $other_party,\nthen you could, after the above sequence, cherry pick good bits\nfrom what the $other_party has and you don't.  This however will\nmake your history and their history to have different commits\nthat record the result of the same patch application; if you\nlater pull from the $other_party again, you will end up having\ntwo copies of the (logically) same commit in your history.\n"},{"id":"44254","messageId":"20070607185918.GJ25093@menevado.ms.com","threadId":"8477","inReplyTo":"46684EFD.1080804@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"Kevin Green","fromEmail":"kevin.t.green@morganstanley.com","sentAt":"2007-06-07T18:59:18Z","receivedAt":"2007-06-07T18:59:18Z","isPatch":false,"sender":{"key":"kevin.t.green@morganstanley.com","avatar":null},"body":"On 06/07/07 14:31:25, kurt_p_lloyd wrote:\n> Junio C Hamano wrote:\n> >\n> >\n> > In this case, because you do not have anything new to add to the\n> > history (remember, git history is a global DAG -- you and the\n> > other repository are building it by pushing and pulling), we\n> > move your HEAD to H (the tip of the branch you are pulling).\n> > There is no need to create a new merge commit, with or without\n> > the --no-commit option.  This is called \"fast forward\".\n> \n> Except here's the model that I am trying to follow....\n> It seems that 'pull' can be partitioned into 3 separate responsibilities:\n> \n>   1. Retrieve changes from the remote user's replica (without modifying\n>      any /local/ branches).\n>   2. Bring changes from \"remote\" into a local branch (without commit).\n>   3. Commit.\n> \n\nI'm new to git and trying to pick it up and learn this week!! :)\n\nI think what you want is:\n\n$ git fetch\n$ git merge origin/master\n\nYou want to fetch the remote changes into a separate branch and then probably\ncheck the log to see what's changed...  Once you're happy, merge the branches.\nGit will still fast-forward because you haven't made any local changes.\n\n\n--Kevin\n"},{"id":"44256","messageId":"alpine.DEB.0.99.0706080658070.6319@sleipnir.no.net.nz","threadId":"8477","inReplyTo":"46684EFD.1080804@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"Keith Duthie","fromEmail":"keith@no.net.nz","sentAt":"2007-06-07T19:12:14Z","receivedAt":"2007-06-07T19:12:14Z","isPatch":false,"sender":{"key":"keith@no.net.nz","avatar":null},"body":"On Thu, 7 Jun 2007, kurt_p_lloyd wrote:\n\n> Except here's the model that I am trying to follow....\n> It seems that 'pull' can be partitioned into 3 separate responsibilities:\n>\n>   1. Retrieve changes from the remote user's replica (without modifying\n>      any /local/ branches).\n>   2. Bring changes from \"remote\" into a local branch (without commit).\n>   3. Commit.\n\nI believe you can accomplish step one with a remote tracking branch\n(\"git-remote add localname git://whereever/project.git\" to add the branch\nto the repository, then \"git-remote update localname\" to update it to the\ncurrent remote state).\n\n-- \nThe universe hates you, but don't worry - it's nothing personal.\n"},{"id":"44259","messageId":"46686B63.6080808@alcatel-lucent.com","threadId":"8477","inReplyTo":"alpine.DEB.0.99.0706080658070.6319@sleipnir.no.net.nz","subject":"Re: pull/merge --no-commit","fromName":"kurt_p_lloyd","fromEmail":"kplloyd@alcatel-lucent.com","sentAt":"2007-06-07T20:32:35Z","receivedAt":"2007-06-07T20:32:35Z","isPatch":false,"sender":{"key":"kplloyd@alcatel-lucent.com","avatar":null},"body":"Many thanks to Junio, Kevin, and Keith for the helpful comments.\nI'll give some play time to all of these suggestions :)\n\nOne thing I was thinking might be useful would be a command to make\n(just) my repository unavailable for 'fetch' or 'pull' from others,\ntemporarily.  And then a command to make it available again,\nafter I finish things that could end up needing \"database\" surgery,\nlike maybe something that could result in having to do a git reset.\nI was thinking maybe something like:\n\n   $ git config maintenance true\n   .... do something that may end up needing \"database\" surgery\n   $ git config maintenance false\n\nJust an idea.  Of course, if something like this already exists ....\n(I'd rather not shut down sshd, nor have to create a separate \"public\"\n  repository (for certain types of \"projects\" anyway).)\n\n-Kurt\n\nKeith Duthie wrote:\n> On Thu, 7 Jun 2007, kurt_p_lloyd wrote:\n> \n>> Except here's the model that I am trying to follow....\n>> It seems that 'pull' can be partitioned into 3 separate responsibilities:\n>>\n>>   1. Retrieve changes from the remote user's replica (without modifying\n>>      any /local/ branches).\n>>   2. Bring changes from \"remote\" into a local branch (without commit).\n>>   3. Commit.\n> \n> I believe you can accomplish step one with a remote tracking branch\n> (\"git-remote add localname git://whereever/project.git\" to add the branch\n> to the repository, then \"git-remote update localname\" to update it to the\n> current remote state).\n"},{"id":"44260","messageId":"20070607204333.GC14463@fieldses.org","threadId":"8477","inReplyTo":"46686B63.6080808@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-06-07T20:43:33Z","receivedAt":"2007-06-07T20:43:33Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jun 07, 2007 at 04:32:35PM -0400, kurt_p_lloyd wrote:\n> One thing I was thinking might be useful would be a command to make\n> (just) my repository unavailable for 'fetch' or 'pull' from others,\n> temporarily.  And then a command to make it available again,\n> after I finish things that could end up needing \"database\" surgery,\n> like maybe something that could result in having to do a git reset.\n> I was thinking maybe something like:\n> \n>   $ git config maintenance true\n>   .... do something that may end up needing \"database\" surgery\n>   $ git config maintenance false\n\nYou could probably do that with file permissions, but...\n\n> Just an idea.  Of course, if something like this already exists ....\n> (I'd rather not shut down sshd, nor have to create a separate \"public\"\n>  repository (for certain types of \"projects\" anyway).)\n\n... why not?  Having a separate public repository also allows you to do\nthis and much more.  And it should be cheap and easy--if you're worried\nabout the space, clone with --shared or something.\n\n--b.\n"},{"id":"44263","messageId":"alpine.DEB.0.99.0706080841030.6319@sleipnir.no.net.nz","threadId":"8477","inReplyTo":"46686B63.6080808@alcatel-lucent.com","subject":"Re: pull/merge --no-commit","fromName":"Keith Duthie","fromEmail":"keith@no.net.nz","sentAt":"2007-06-07T20:51:17Z","receivedAt":"2007-06-07T20:51:17Z","isPatch":false,"sender":{"key":"keith@no.net.nz","avatar":null},"body":"On Thu, 7 Jun 2007, kurt_p_lloyd wrote:\n\n> Just an idea.  Of course, if something like this already exists ....\n> (I'd rather not shut down sshd, nor have to create a separate \"public\"\n>  repository (for certain types of \"projects\" anyway).)\n\nActually, a separate public repository is probably exactly what you want\nhere. If you clone the repository with the local and shared flags you'll\nonly need to have one copy of the objects on disk (if I understand things\ncorrectly), and you can just push your development branch to the public\nrepository whenever you're happy with the state of your code.\n\nAnd if you're going to give other people access to your development\nrepository then you're probably best off having a branch (or branches)\nthat are there specifically for other people to pull from, and make sure\nyou don't merge anything into those branches without it being ready for\nrelease. And then tell people it's their own fault if they grab one of\nyour work-in-progress branches instead ;-)\n\n-- \nThe universe hates you, but don't worry - it's nothing personal.\n"}]}