{"thread":{"id":"20793","subject":"A note from the maintainer: Follow-up questions (MaintNotes)","startedAt":"2009-08-30T22:19:22Z","lastAt":"2009-09-01T19:09:48Z","messageCount":6,"participants":["David Chanters","Andreas Ericsson","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"122146","messageId":"ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com","threadId":"20793","inReplyTo":null,"subject":"A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"David Chanters","fromEmail":"david.chanters@googlemail.com","sentAt":"2009-08-30T22:19:22Z","receivedAt":"2009-08-30T22:19:22Z","isPatch":false,"sender":{"key":"david.chanters@googlemail.com","avatar":null},"body":"Hi,\n\n[Please retain a Cc back to me as I am not currently subscribed to the\nmailing list.]\n\nI've recently been intrigued with workflows, and have read quite a bit\nabout them, including various references on git-scm.com,\ngitworkflows(7), and the email \"A note from the maintainer\" which I\nhave some questions on.  I'll paste random quotes from that and just\nask my question, I think, so apologies up front of it reads a little\ndisjointed.\n\nI'd often wondered when I have read various posts of the git mailing\nlist on gmane, just how it is I am supposed to track:\n\ndc/some-topic-feature\n\n... Junio, are these topic branches ones you actively have somewhere\nin your own private checkout?  Yes, I appreciate that when I read a\ngiven post to the mailing list, you or other people will sometimes\nmake reference to these topic branches, but what do I do if I am\ninterested in finding out about one of them?  Indeed, perhaps even\nbefore getting to that question, how do you go about creating and\nmaintaining these topic branches -- are you making heavy use of \"git\nam\"?\n\nI ask because of the following snippet from \"MaintNotes\":\n\n    The two branches \"master\" and \"maint\" are never rewound, and\n    \"next\" usually will not be either (this automatically means the\n    topics that have been merged into \"next\" are usually not\n    rebased, and you can find the tip of topic branches you are\n    interested in from the output of \"git log next\"). You should be\n    able to safely track them.\n\nI am not sure if there's any real use-case for this, but I will ask\nanyway:  is the above saying that I am able to *checkout* one of these\ntopic-branches just from their presence in \"next\" alone?  I appreciate\nthat the point is somewhat moot since the topic branch has already\nbeen merged into \"next\", but I can surely see this as a really useful\nway for people to manage topic-branches in a shared environment:\npeople can simply pick a topic branch out from the integrated one --\nin this case \"next\".  Or is this idea a complete waste of time?\n\nTo continue:\n\n    The \"pu\" (proposed updates) branch bundles all the remainder of\n    topic branches.  The \"pu\" branch, and topic branches that are\n    only in \"pu\", are subject to rebasing in general.  By the above\n    definition of how \"next\" works, you can tell that this branch\n    will contain quite experimental and obviously broken stuff.\n\nI'm obviously missing something here -- but why is rebasing these\nexisting topic branches (I assume on top of \"pu\") more useful than\njust merging them into \"pu\" -- like you do with \"next\"?\n\n    When a topic that was in \"pu\" proves to be in testable shape, it\n    graduates to \"next\".  I do this with:\n\n            git checkout next\n            git merge that-topic-branch\n\n    Sometimes, an idea that looked promising turns out to be not so\n    good and the topic can be dropped from \"pu\" in such a case.\n\nAh -- so if I have this straight in my head -- you continually form\nthe local topic-branch on its own branch, and then just merge it into\n\"next\" only when you know that topic branch is satisfactory?  That\nbeing the case -- again, I assume the use of \"git am\" for the topic\nbranch?  If regular readers of the git mailing list wish to track this\ntopic branch, can they do so from you only until it's merged into\n\"next\"?\n\nAnd a related question:  If you decide a given topic in pu is declared\nto \"be dropped\", is this done by rebasing (as you mentioned earlier)\nso as to remove any trace of the topic branch ever having been in\n\"pu\", or am I reading too much into \"dropping\" here?  :)\n\nI hope these aren't too idiotic.\n\nThanks all in advance.\n\nDavid\n"},{"id":"122173","messageId":"4A9B845F.3030302@op5.se","threadId":"20793","inReplyTo":"ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com","subject":"Re: A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-08-31T08:05:51Z","receivedAt":"2009-08-31T08:05:51Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Chanters wrote:\n> Hi,\n> \n> [Please retain a Cc back to me as I am not currently subscribed to the\n> mailing list.]\n> \n> I've recently been intrigued with workflows, and have read quite a bit\n> about them, including various references on git-scm.com,\n> gitworkflows(7), and the email \"A note from the maintainer\" which I\n> have some questions on.  I'll paste random quotes from that and just\n> ask my question, I think, so apologies up front of it reads a little\n> disjointed.\n> \n> I'd often wondered when I have read various posts of the git mailing\n> list on gmane, just how it is I am supposed to track:\n> \n> dc/some-topic-feature\n> \n> ... Junio, are these topic branches ones you actively have somewhere\n> in your own private checkout?  Yes, I appreciate that when I read a\n> given post to the mailing list, you or other people will sometimes\n> make reference to these topic branches, but what do I do if I am\n> interested in finding out about one of them?  Indeed, perhaps even\n> before getting to that question, how do you go about creating and\n> maintaining these topic branches -- are you making heavy use of \"git\n> am\"?\n> \n> I ask because of the following snippet from \"MaintNotes\":\n> \n>     The two branches \"master\" and \"maint\" are never rewound, and\n>     \"next\" usually will not be either (this automatically means the\n>     topics that have been merged into \"next\" are usually not\n>     rebased, and you can find the tip of topic branches you are\n>     interested in from the output of \"git log next\"). You should be\n>     able to safely track them.\n> \n> I am not sure if there's any real use-case for this, but I will ask\n> anyway:  is the above saying that I am able to *checkout* one of these\n> topic-branches just from their presence in \"next\" alone?\n\nYes. \"git log --grep=dc/some-topic-feature next\" would point you to\nthe merge commit where it gets merged to 'next'. Then you can simply\ndo \"git checkout -b dc/some-topic-feature (the-located-commit)^2\" to\ncreate the branch \"dc/some-topic-feature\" as it was when Junio merged\nit. This relies on Junio not tampering with the commit messages git\ncreates when merging, but since there's no real need for that anyway,\nit's a fairly safe practice.\n\n> \n> To continue:\n> \n>     The \"pu\" (proposed updates) branch bundles all the remainder of\n>     topic branches.  The \"pu\" branch, and topic branches that are\n>     only in \"pu\", are subject to rebasing in general.  By the above\n>     definition of how \"next\" works, you can tell that this branch\n>     will contain quite experimental and obviously broken stuff.\n> \n> I'm obviously missing something here -- but why is rebasing these\n> existing topic branches (I assume on top of \"pu\") more useful than\n> just merging them into \"pu\" -- like you do with \"next\"?\n> \n\nBecause topics in 'pu' can be dropped on the floor, and are worked\non quite a lot more than the ones in next. Undoing a merge is quite\na lot of work as opposed to just rebuilding the history without that\nmerge. It's also a lot nicer to have a cleaner history in 'next',\nsince that makes it easier to merge things to 'master' in such a way\nthat bisection works nicely.\n\n>     When a topic that was in \"pu\" proves to be in testable shape, it\n>     graduates to \"next\".  I do this with:\n> \n>             git checkout next\n>             git merge that-topic-branch\n> \n>     Sometimes, an idea that looked promising turns out to be not so\n>     good and the topic can be dropped from \"pu\" in such a case.\n> \n> Ah -- so if I have this straight in my head -- you continually form\n> the local topic-branch on its own branch, and then just merge it into\n> \"next\" only when you know that topic branch is satisfactory?\n\nI *think* the topic branches live until they're merged to master, or\nuntil they're dropped (although I could well imagine them staying\nbehind quite some time after being dropped). I haven't heard Junio\ntalk about this afair, but that's how I would do it anyways.\n\n>  That\n> being the case -- again, I assume the use of \"git am\" for the topic\n> branch?\n\nI should think so, although once a patch is applied in its final\nform it'll no longer be necessary to use \"git am\". It'll be easier\nto just use rebase on the topic branch(es), or cherry-pick individual\ncommits from them in order to get only certain benefits of them.\nThis isn't *very* usual, but it does happen from time to time that\ntopic branches refactor something first and then adds a feature on\ntop of that.\n\n>  If regular readers of the git mailing list wish to track this\n> topic branch, can they do so from you only until it's merged into\n> \"next\"?\n> \n\nTopics that make it to master can be tracked indefinitely. 'next'\nis never merged directly to master, since the topics brewing on\nnext get different amounts of testing and feedback. Junio just\nmerges the topics to master as they go through all the review and\ntesting they're thought to need. Try\n\n  git log --grep=\"Merge branch '\" master\n\nand you'll see what I mean, or have a look using gitk.\n\n> And a related question:  If you decide a given topic in pu is declared\n> to \"be dropped\", is this done by rebasing (as you mentioned earlier)\n> so as to remove any trace of the topic branch ever having been in\n> \"pu\", or am I reading too much into \"dropping\" here?  :)\n> \n\nAFAIU, 'pu' is dropped in its entirety and re-built from the top of 'next'\nby the rather simple expedient of \"git reset --hard next\" and then merging,\none by one, all branches that aren't already merged to maint, master or\nnext. Git can list such branches so it's no great chore. Naturally, Junio\nknows his way fairly well around git and has scripts to do much of this\nwork for him.\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":"122217","messageId":"7v8wgzla02.fsf@alter.siamese.dyndns.org","threadId":"20793","inReplyTo":"ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com","subject":"Re: A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-01T01:38:37Z","receivedAt":"2009-09-01T01:38:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Chanters <david.chanters@googlemail.com> writes:\n\n> I'd often wondered when I have read various posts of the git mailing\n> list on gmane, just how it is I am supposed to track:\n>\n> dc/some-topic-feature\n>\n> ... Junio, are these topic branches ones you actively have somewhere\n> in your own private checkout?  Yes, I appreciate that when I read a\n> given post to the mailing list, you or other people will sometimes\n> make reference to these topic branches, but what do I do if I am\n> interested in finding out about one of them?\n\n    $ git log --oneline --first-parent origin/master..origin/pu\n\nwould be a handy way to view where the tip of each branch is.\n\n    a71f64a Merge branch 'pk/import-dirs' into pu\n    ce6cd39 Merge branch 'jh/cvs-helper' into pu\n    ...\n    2178d02 Merge branch 'jc/log-tz' into pu\n    ...\n    927d129 Merge branch 'lt/approxidate' into jch\n    35ada54 Merge branch 'tr/reset-checkout-patch' into jch\n    d82f86c Merge branch 'db/vcs-helper' (early part) into jch\n\nSo if you for example happen to be interested in jc/log-tz topic,\nyou would do something like:\n\n    $ git checkout -b jc/log-tz 2178d02^2\n    $ git log -p master..\n\nto check out, and view what changes the topic introduces. \n\nSome hawk-eyed people may have already noticed this, but I recently\nupdated the script I used to maintain the \"What's cooking\" messages, and\nthe entries come with when and at what commit each part of the series has\nbeen merged to 'next'.  For example, the lt/approxidate topic reads like\nthis:\n\n  * lt/approxidate (2009-08-30) 6 commits\n    (merged to 'next' on 2009-08-30 at e016e3d)\n   + fix approxidate parsing of relative months and years\n   + tests: add date printing and parsing tests\n   + refactor test-date interface\n   + Add date formatting and parsing functions relative to a given time\n    (merged to 'next' on 2009-08-26 at 62853f9)\n   + Further 'approxidate' improvements\n   + Improve on 'approxidate'\n\nTime flows from bottom to top in this output, so this tells us that the\nfirst two patches in the series has been in 'next' for five days or so,\nand the tests and a fix in 4 follow-up patches came later, merged to\n'next' yesterday.  You can use\n\n    $ git checkout -b lt/approxidate e016e3d^2\n\nto get at its tip.\n\n> ..., how do you go about creating and\n> maintaining these topic branches -- are you making heavy use of \"git\n> am\"\n\nSave patches from the list in mbox, review them in the mbox while fixing\ntrivial breakages, and finally:\n\n    $ git checkout -b ai/topic-name master\n    $ git am -s that.mbox\n\nwhere \"ai\" is typically the author's initial, and topic-name names the\ntopic just like you would name a function.  A topic typically forks from\nthe tip of master if it is a new feature, or a much older commit in maint\nif it is a fix (and in such a case, topic-name typically begins with\na string \"maint-\").\n\n> I ask because of the following snippet from \"MaintNotes\":\n>\n>     The two branches \"master\" and \"maint\" are never rewound, and\n>     \"next\" usually will not be either (this automatically means the\n>     topics that have been merged into \"next\" are usually not\n>     rebased, and you can find the tip of topic branches you are\n>     interested in from the output of \"git log next\"). You should be\n>     able to safely track them.\n>\n> I am not sure if there's any real use-case for this, but I will ask\n> anyway:  is the above saying that I am able to *checkout* one of these\n> topic-branches just from their presence in \"next\" alone?  I appreciate\n> that the point is somewhat moot since the topic branch has already\n> been merged into \"next\", but I can surely see this as a really useful\n> way for people to manage topic-branches in a shared environment:\n> people can simply pick a topic branch out from the integrated one --\n> in this case \"next\".\n\nSurely, see above.  And by checking out the topic alone, you can test and\nenhance it in isolation.\n\nIf you come up with a follow-up patch based on one particular topic, in\nother words, building on ai/topic-name created like the above example, as\nopposed to building on 'next', it would be easier for me to integrate it,\ntoo, because the way I accept a follow-up patch to a particular topic is\nby doing this:\n\n    $ git checkout ai/topic-name\n    $ git am -s followup-mail.mbox\n\nThe result will be tested in isolation and if it is good it would be\nmerged to 'next' again.\n\n    $ git merge ai/topic-name\n\n> I'm obviously missing something here -- but why is rebasing these\n> existing topic branches (I assume on top of \"pu\") more useful than\n> just merging them into \"pu\" -- like you do with \"next\"?\n\nSomebody may send a few patches [PATCH 1/3] thru [PATCH 3/3] whose\nquality is sub-par but tries to tackle a good problem.  I'd queue it in\n'pu'.\n\n    $ git checkout -b dc/cool-feature\n    $ git am -s david-chanters.mbox\n    $ git checkout pu\n    $ git merge dc/cool-feature\n\nIn a few days, people would notice that the series has a lot of room for\nimprovement, and offer suggestions.  You would send replacement patches\nbased on the review.  Perhaps you squashed the first two patches from the\noriginal into one, and added another patch for test suite, and the new\nseries is marked as [PATCH v2 1/3] thru [PATCH v2 3/3].\n\nIn general, the early attempts of a topic that have never been merged to\n'next' are not worth keeping in the public history.  The original author\nis free to keep them in his private tree, but there is no point in forever\nkeeping earlier mistakes, bugs, typos and implementation based on a flawed\ndesign, all of which later were corrected in _my_ history.\n\nSo I would replace the whole topic with the new series.\n\n    $ git checkout dc/cool-feature\n    $ git reset --hard HEAD~3\n    $ git am -s david-chanters-v2.mbox\n\nThe whole point of replacing the contents of this topic was to get rid of\nthe mistakes in your earlier round, so it does not make much sense to\nmerge this to 'pu' without rewinding 'pu' first.\n\nAfter the topic is merged to 'next', obviously I cannot sanely rewind and\nrebuild it.  Everything goes incremental from then on (see the earlier\nexample of applying followup-mail.mbox).\n\n> If regular readers of the git mailing list wish to track this topic\n> branch, can they do so from you only until it's merged into \"next\"?\n\nSorry, but I am not sure if I understand the question.\n\n> And a related question:  If you decide a given topic in pu is declared\n> to \"be dropped\", is this done by rebasing (as you mentioned earlier)\n> so as to remove any trace of the topic branch ever having been in\n> \"pu\", or am I reading too much into \"dropping\" here?  :)\n\nEssentially, I keep a list of branches that are in 'next' and another list\nof branches that are in 'pu'.  At the end of each integration cycle, I do\na rough equivalent of:\n\n    $ git checkout next\n    $ git merge ..a good topic that is not fully in next..\n    $ git merge ..another good topic that is not fully in next..\n    $ make test ;# make sure next is ok\n    $ git branch -f pu ;# get rid of everything in pu\n    $ git checkout pu\n    $ for branch in ..the list of branches to be in pu..\n      do\n          git merge $branch || break\n      done\n\nDiscarding a topic from 'pu' simply means I do not merge the topic in the\nlast loop.\n"},{"id":"122220","messageId":"20090901025504.GA23589@coredump.intra.peff.net","threadId":"20793","inReplyTo":"7v8wgzla02.fsf@alter.siamese.dyndns.org","subject":"Re: A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-01T02:55:04Z","receivedAt":"2009-09-01T02:55:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 31, 2009 at 06:38:37PM -0700, Junio C Hamano wrote:\n\n>     a71f64a Merge branch 'pk/import-dirs' into pu\n>     ce6cd39 Merge branch 'jh/cvs-helper' into pu\n>     ...\n>     2178d02 Merge branch 'jc/log-tz' into pu\n>     ...\n>     927d129 Merge branch 'lt/approxidate' into jch\n>     35ada54 Merge branch 'tr/reset-checkout-patch' into jch\n>     d82f86c Merge branch 'db/vcs-helper' (early part) into jch\n> \n> So if you for example happen to be interested in jc/log-tz topic,\n> you would do something like:\n> \n>     $ git checkout -b jc/log-tz 2178d02^2\n>     $ git log -p master..\n> \n> to check out, and view what changes the topic introduces.\n\nAnother alternative: Thomas Rast wrote a handy script called\n'git-resurrect' which does this for you. It's carried in the contrib/\nsection right now. I used it just the other day to pull out the\nlt/approxidate topic branch, which I then built some follow-up patches\nfor. Usage is something like:\n\n  # contrib scripts aren't installed by \"make install\",\n  # so put it somewhere in your PATH\n  $ cp contrib/git-resurrect.sh ~/bin/git-resurrect\n\n  $ git resurrect -m lt/approxidate\n  ** Candidates for lt/approxidate **\n  931e8e2 [22 hours ago] fix approxidate parsing of relative months and years\n  ** Restoring lt/approxidate to 931e8e2 fix approxidate parsing of relative months and years\n\n-Peff\n"},{"id":"122250","messageId":"ac3d41850909010958l890bf2fyda6e61e3cb082c2a@mail.gmail.com","threadId":"20793","inReplyTo":"7v8wgzla02.fsf@alter.siamese.dyndns.org","subject":"Re: A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"David Chanters","fromEmail":"david.chanters@googlemail.com","sentAt":"2009-09-01T16:58:36Z","receivedAt":"2009-09-01T16:58:36Z","isPatch":false,"sender":{"key":"david.chanters@googlemail.com","avatar":null},"body":"2009/9/1 Junio C Hamano <gitster@pobox.com>:\n>    $ git log --oneline --first-parent origin/master..origin/pu\n>\n> would be a handy way to view where the tip of each branch is.\n\nYes it is - thanks for that!  I presume that (in other workflows --\nnot necessarily git,git's) that using git-resurrect.sh would be\npreferable to the git-log suggestion above if the topic branch wanting\nto be \"resurrected\" had several merge points?\n\n> So if you for example happen to be interested in jc/log-tz topic,\n> you would do something like:\n>\n>    $ git checkout -b jc/log-tz 2178d02^2\n>    $ git log -p master..\n>\n> to check out, and view what changes the topic introduces.\n\nThis is really useful - thank you - it's solving a missing piece of a\npuzzle for me.  :)\n\n> where \"ai\" is typically the author's initial, and topic-name names the\n> topic just like you would name a function.  A topic typically forks from\n> the tip of master if it is a new feature, or a much older commit in maint\n> if it is a fix (and in such a case, topic-name typically begins with\n> a string \"maint-\").\n\nMakes sense - and on that note - in our current workflow of using Git,\nwe have a feature branch, call it \"featureA\" which is forked from\n\"master\" (where our stable code lives) -- but obviously over time, if\nbugfixes happen and get released, what do we do about then ensuring\nthat featureA also benefits from these bug-fixes?  Since invariably\npeople will want to develop using the bug-fixes, but \"featureA\" long\nsince branched from \"master\" at a point in the past, before the\nbug-fixes?\n\nWhat do you do, about this when handling topic branches merged into\nnext, or doesn't it really matter by that point?\n\n[...snip really useful explanation...]\n\nI can't thank you enough, Junio for this -- you've effectively ironed\nout a workflow here I think I can now go away and start using -\nthanks.  :)\n\nDavid\n"},{"id":"122253","messageId":"7vmy5eiirn.fsf@alter.siamese.dyndns.org","threadId":"20793","inReplyTo":"ac3d41850909010958l890bf2fyda6e61e3cb082c2a@mail.gmail.com","subject":"Re: A note from the maintainer: Follow-up questions (MaintNotes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-01T19:09:48Z","receivedAt":"2009-09-01T19:09:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Chanters <david.chanters@googlemail.com> writes:\n\n> 2009/9/1 Junio C Hamano <gitster@pobox.com>:\n>>    $ git log --oneline --first-parent origin/master..origin/pu\n>>\n>> would be a handy way to view where the tip of each branch is.\n>\n> Yes it is - thanks for that!  I presume that (in other workflows --\n> not necessarily git,git's) that using git-resurrect.sh would be\n> preferable to the git-log suggestion above if the topic branch wanting\n> to be \"resurrected\" had several merge points?\n\nAFAIK the script is an (attempt of) automating the inspecting of the above\noutput and manually choosing which one to use.  As automation, it may be\nhandy, and as automation, it may have bugs ;-).\n\n> Makes sense - and on that note - in our current workflow of using Git,\n> we have a feature branch, call it \"featureA\" which is forked from\n> \"master\" (where our stable code lives) -- but obviously over time, if\n> bugfixes happen and get released, what do we do about then ensuring\n> that featureA also benefits from these bug-fixes?  Since invariably\n> people will want to develop using the bug-fixes, but \"featureA\" long\n> since branched from \"master\" at a point in the past, before the\n> bug-fixes?\n\nThat is one of the most common misconception people new to the topic\nbranch workflow have [*1*].\n\nIn general, you do not want to merge fixes or other changes from\nintegration branches back into a topic branch such as featureA.  The\npurpose of a topic branch is to brew the topic and the topic alone in\nisolation to perfection.  Once you start merging 'maint' or 'master' into\n'featureA', the output from \"git log featureA\" ceases to be \"the work I\ndid to polish the feature A\".  The branch becomes \"this contains the work\nrelated to feature A, but overwhelmingly consists of other unrelated\nrandom stuff\".  It would be useless as a topic branch, because you cannot\ntell which ones are the changes to achieve the goal of the topic anymore.\n\nWhen you test featureA, you would test the topic branch itself, and while\ndoing so, you will of course see bugs that have been fixed since you\nforked from the mainline.  Do not get distracted by them; you did not fork\nthe featureA topic in order to fix them in the first place!\n\nOf course, when you test the whole system including the addition of\nfeatureA, you would want to make sure that fixes and enhancements that\nhappened on the mainline since you forked the topic branch work well with\nwhat you did on the topic.\n\nFor that kind of integration testing, either use a temporary branch to\ntest trial integration:\n\n\n    $ git checkout -b test master ;# start with everything else they did\n    $ git merge featureA ;# ... and try my topic with that\n    $ test..test..test\n\nand once you are done, you can get rid of the test branch\n\n    $ git checkout master\n    $ git branch -D test\n\nYou can alternatively have a dedicated branch for early integration\ntesting.  That is what 'next' branch is used for in git.git project.\n\n    $ git checkout next\n    $ git merge featureA ;# ... merge the update\n    $ test..test..test\n    ... yeek, my changes were buggy ...\n    $ git reset --hard HEAD^ ;# get rid of the change\n    $ git checkout featureA\n    $ fix..fix..fix\n    $ git checkout next\n    $ git merge featureA ;# ... try again\n    $ test..test..test\n    ... this time it is good and I am happy ...\n\n\n[Footnote]\n\n*1* I think I have had a chance to answer this question in a lot more\ndetail at least twice in the past couple of weeks on this list, and both\ntimes it was very frustrating for me, not because I did not want to answer\nthem, but because I've written it in length in my upcoming book but\npointing to it would not help people who asked the question because it is\nin Japanese.  I've been writing on a handful of topics I thought were\nworthy of general consumption on my blog while writing the book, but this\nis one of the topics that I haven't \"backported\" there yet X-<.\n"}]}