{"thread":{"id":"23039","subject":"[PATCH v3] git checkout -b: unparent the new branch with -o","startedAt":"2010-03-16T18:19:44Z","lastAt":"2010-03-17T18:55:45Z","messageCount":9,"participants":["Erick Mattos","Junio C Hamano","Jonathan Nieder"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"136968","messageId":"1268763584-14164-1-git-send-email-erick.mattos@gmail.com","threadId":"23039","inReplyTo":null,"subject":"[PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-03-16T18:19:44Z","receivedAt":"2010-03-16T18:19:44Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Sometimes it is interesting to start a new unparented branch in an\nexisting repository.\n\nThe new -o/--orphan is intended to solve this situation allowing the\ncreation of a new branch unparented to any other.\n\nAfter the 'checkout -o -b' the new branch is not saved until committed.\nBefore committing you should 'git rm -rf' anything which is not going to\ntake part in the new branch and change the work tree and index the way\nyou want it to be since they remain untouched as before checkout\ncommand.\n\nThere are two potential work flows where this feature is most useful:\n\n(1) \"mostly common paths\" work flow;\n(2) \"no common paths\" work flow;\n\nSigned-off-by: Erick Mattos <erick.mattos@gmail.com>\n---\n\nMajor rewrite to conform to Junio's demands.\n\nNow after checkout to the new unparented branch, the index and the work tree\nremain unchanged.\n\n Documentation/git-checkout.txt |   13 ++++++++++\n builtin/checkout.c             |   10 ++++++-\n t/t2017-checkout-orphan.sh     |   49 ++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 70 insertions(+), 2 deletions(-)\n create mode 100755 t/t2017-checkout-orphan.sh\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 37c1810..92562ce 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -9,6 +9,7 @@ SYNOPSIS\n --------\n [verse]\n 'git checkout' [-q] [-f] [-m] [<branch>]\n+'git checkout' [-q] [-f] [-m] [-b <new_branch> [-o]]\n 'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...\n 'git checkout' --patch [<tree-ish>] [--] [<paths>...]\n@@ -26,6 +27,13 @@ use the --track or --no-track options, which will be passed to `git\n branch`.  As a convenience, --track without `-b` implies branch\n creation; see the description of --track below.\n \n+When using -b, it is possible to use the option -o to set the new branch\n+as unparented thus unrelated to the previous branch.  The new branch is\n+not saved until committed.  But before committing you should first do\n+'git rm -rf' anything which is not going to take part in the new branch\n+and change the work tree and index the way you want it to be since they\n+remain untouched as before checkout command.\n+\n When <paths> or --patch are given, this command does *not* switch\n branches.  It updates the named paths in the working tree from\n the index file, or from a named <tree-ish> (most often a commit).  In\n@@ -86,6 +94,11 @@ explicitly give a name with '-b' in such a case.\n \tDo not set up \"upstream\" configuration, even if the\n \tbranch.autosetupmerge configuration variable is true.\n \n+-o::\n+--orphan::\n+\tWhen creating a new branch, set it up as unparented thus\n+\tunrelated to the previous branch.\n+\n -l::\n \tCreate the new branch's reflog; see linkgit:git-branch[1] for\n \tdetails.\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex acefaaf..405de7e 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -34,6 +34,7 @@ struct checkout_opts {\n \n \tconst char *new_branch;\n \tint new_branch_log;\n+\tint new_branch_orphan;\n \tenum branch_track track;\n };\n \n@@ -491,8 +492,9 @@ static void update_refs_for_switch(struct checkout_opts *opts,\n \tstruct strbuf msg = STRBUF_INIT;\n \tconst char *old_desc;\n \tif (opts->new_branch) {\n-\t\tcreate_branch(old->name, opts->new_branch, new->name, 0,\n-\t\t\t      opts->new_branch_log, opts->track);\n+\t\tif (!opts->new_branch_orphan)\n+\t\t\tcreate_branch(old->name, opts->new_branch, new->name, 0,\n+\t\t\t\t      opts->new_branch_log, opts->track);\n \t\tnew->name = opts->new_branch;\n \t\tsetup_branch_path(new);\n \t}\n@@ -629,6 +631,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tstruct option options[] = {\n \t\tOPT__QUIET(&opts.quiet),\n \t\tOPT_STRING('b', NULL, &opts.new_branch, \"new branch\", \"branch\"),\n+\t\tOPT_BOOLEAN('o', \"orphan\", &opts.new_branch_orphan, \"make the new branch unparented\"),\n \t\tOPT_BOOLEAN('l', NULL, &opts.new_branch_log, \"log for new branch\"),\n \t\tOPT_SET_INT('t', \"track\",  &opts.track, \"track\",\n \t\t\tBRANCH_TRACK_EXPLICIT),\n@@ -677,6 +680,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\topts.new_branch = argv0 + 1;\n \t}\n \n+\tif (opts.new_branch_orphan && !opts.new_branch)\n+\t\tdie(\"-o is used only with -b\");\n+\n \tif (conflict_style) {\n \t\topts.merge = 1; /* implied */\n \t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\ndiff --git a/t/t2017-checkout-orphan.sh b/t/t2017-checkout-orphan.sh\nnew file mode 100755\nindex 0000000..c1b77ac\n--- /dev/null\n+++ b/t/t2017-checkout-orphan.sh\n@@ -0,0 +1,49 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Erick Mattos\n+#\n+\n+test_description='git checkout -b\n+\n+Tests for -o functionality.'\n+\n+. ./test-lib.sh\n+\n+TEST_FILE=foo\n+\n+test_expect_success 'Setup' '\n+\techo \"initial\" >\"$TEST_FILE\" &&\n+\tgit add \"$TEST_FILE\" &&\n+\tgit commit -m \"First Commit\"\n+'\n+\n+test_expect_success '-b without -o checkout into a new clone branch' '\n+\ttest_tick &&\n+\techo \"Test 1\" >>\"$TEST_FILE\" &&\n+\tgit add \"$TEST_FILE\" &&\n+\tgit commit -m \"Second Commit\" &&\n+\tgit log --pretty=oneline >base &&\n+\tgit checkout -b alpha &&\n+\ttest \"alpha\" = \"$(git symbolic-ref HEAD | sed \"s,.*/,,\")\" &&\n+\tgit log --pretty=oneline >actual &&\n+\ttest_cmp base actual\n+'\n+\n+test_expect_success '-b with -o checkout into an orphan branch' '\n+\tgit checkout -ob beta &&\n+\ttest_must_fail PAGER= git log >/dev/null 2>/dev/null &&\n+\ttest \"beta\" = \"$(git symbolic-ref HEAD | sed \"s,.*/,,\")\" &&\n+\ttest_tick &&\n+\techo \"Test 2\" >>\"$TEST_FILE\" &&\n+\tgit add \"$TEST_FILE\" &&\n+\tgit commit -m \"Third Commit\" &&\n+\tgit log --pretty=oneline >actual &&\n+\ttest 1 -eq $(wc -l actual | sed \"s/ .*//\") &&\n+\t! test_cmp base actual\n+'\n+\n+test_expect_success '-o must be rejected without -b' '\n+\ttest_must_fail git checkout -o alpha\n+'\n+\n+test_done\n-- \n1.7.0.2.274.gc8f05\n"},{"id":"136980","messageId":"7v634v27vf.fsf@alter.siamese.dyndns.org","threadId":"23039","inReplyTo":"1268763584-14164-1-git-send-email-erick.mattos@gmail.com","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-16T22:56:36Z","receivedAt":"2010-03-16T22:56:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erick Mattos <erick.mattos@gmail.com> writes:\n\n> Sometimes it is interesting to start a new unparented branch in an\n> existing repository.\n>\n> The new -o/--orphan is intended to solve this situation allowing the\n> creation of a new branch unparented to any other.\n>\n> After the 'checkout -o -b' the new branch is not saved until committed.\n> Before committing you should 'git rm -rf' anything which is not going to\n> take part in the new branch and change the work tree and index the way\n> you want it to be since they remain untouched as before checkout\n> command.\n\nThis paragraph makes the patch incoherent.  It talks as if \"no common\npaths\" is the majority case, and everybody inconveniently has to perform\nan extra step that shouldn't be needed if the implementation were done\nright.  If \"no common paths\" is indeed the assumed primary target, why\ndoesn't the implementation empty both index and files in the working tree\nso that users don't have to do so themselves?\n\nMy _only_ complaint was that your version that _only_ emptied the index\nwithout touching the working tree made things difficult for everybody,\nboth \"no common paths\" people and \"mostly common paths\" people.\n\nYou need to at least qualify the above paragraph with something like \"if\nyou want to create an unrelated branch whose contents do not resemble the\noriginal branch at all, then you should ...\".\n\nBetter yet, try to advertise what you are giving your users in a positive\nway, instead of in a way that only scares users, perhaps like this:\n\n    After 'checkout --orphan', your HEAD will point at an unborn branch,\n    and the next commit will start a new history without any prior commit.\n    To help create such a new history that has contents mostly the same as\n    that of the original branch, the command does not touch the index nor\n    the working tree, and \"checkout --orphan\" immediately followed by\n    \"commit -a\" would record a tree very similar to what you had in the\n    original branch.  This is useful when you want to ... [insert a\n    summary of \"going open source\" example from my previous message if you\n    want here].\n\n    If on the other hand you want to start a new branch whose contents do\n    not resemble the original branch at all, you may want to start from an\n    empty index and the working tree, with \"git rm -rf .\" immediately\n    after running this command.\n\nThe same comment applies to the documentation part.\n\nBy the way, I wouldn't mind if you believe \"no common paths\" is the\nmajority case; if that is the case, then the code and behaviour would be\ndifferent, and the presentation would say something like this:\n\n    After 'checkout --orphan', your HEAD will point at an unborn branch,\n    and the next commit will start a new history without any prior commit.\n    To help create such a new history that has contents totally different\n    from the original branch, the command empties the index and removes\n    all tracked files from the working tree.  The command refuses to work\n    if you have uncommitted changes, so that you won't lose them.\n    Conclude the work in progress on your current branch first by first\n    recording the changes in commits (or \"git stash save\") before\n    re-running the command.\n\n    After \"checkout --orphan\" you can immediately start preparing the\n    files to be tracked in this new branch, without files unrelated to\n    this branch getting in the way.  This is useful when you want to\n    ... [I don't think any \"no commmon paths\" workflow makes sense to be\n    done in the same repository, but you seem to do do so, so give readers\n    such an example here].\n\n    If on the other hand you want to start a new branch whose contents\n    mostly match the original branch, you may need to start from an\n    index and the working tree files from the original branch, by running\n    \"git checkout <original-branch-name> .\"  after running this command.\n"},{"id":"136984","messageId":"55bacdd31003161810w1c824570lee1b7d5759568bc1@mail.gmail.com","threadId":"23039","inReplyTo":"7v634v27vf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-03-17T01:10:14Z","receivedAt":"2010-03-17T01:10:14Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Hi,\n\nJunio, you are the leader.  And I really don't want to bother you with\nmy opinions.\n\nI am just trying to make you satisfied so gitsters, I mean git users,\nwill have this feature as soon as possible.\n\n2010/3/16 Junio C Hamano <gitster@pobox.com>:\n>> After the 'checkout -o -b' the new branch is not saved until committed.\n>> Before committing you should 'git rm -rf' anything which is not going to\n>> take part in the new branch and change the work tree and index the way\n>> you want it to be since they remain untouched as before checkout\n>> command.\n>\n> This paragraph makes the patch incoherent.  It talks as if \"no common\n> paths\" is the majority case, and everybody inconveniently has to perform\n> an extra step that shouldn't be needed if the implementation were done\n> right.  If \"no common paths\" is indeed the assumed primary target, why\n> doesn't the implementation empty both index and files in the working tree\n> so that users don't have to do so themselves?\n\nI was NOT trying to scare with my message.  That paragraph was meant\nto let people who would need to do something (\"no common paths\") know\nwhat they will need to do.  I think it is good enough because \"mostly\ncommon paths\" people will be happy too by knowing that everything is\nunchanged as they want it to be.  So I haven't thought about scaring\nat all.  I thought it was good indeed!  :-)\n\n> My _only_ complaint was that your version that _only_ emptied the index\n> without touching the working tree made things difficult for everybody,\n> both \"no common paths\" people and \"mostly common paths\" people.\n\nJust to clarify my point-of-view about the design:\n\nI do prefer my first design mainly because it mimics the state of an\ninitial commit.  I think that is subjectively better.\n\nYou have been asking me to make one of the two possible work flow uses\nyou pictured as favored so things will be already set to them.  No\nfurther commands to them.\n\nI did it!  As a matter of fact the \"mostly common paths\" people were\nfavored as you have noticed your inclination to it before.\n\nAs I told you, I just want to make you happy so people that needs the\nfeature I am working on could have it as fast as possible.\n\nAnd if one of the possible work flows have to be favored then I do\nagree with you about \"mostly common paths\" as the best choice.\n\nBut the point is that the other group will need to do further commands\nanyway so I would keep my previous design because of the resemblance\nto an initial commit: work tree full and nothing added to the index.\n\nBut I mean it!  I really want to satisfy you.  So this was the last\ntime I talk about my preference.\n\nTherefore let's find out what you want me to do so we can finish this\nproduction cycle.  I don't want to bother you anymore.\n\n> You need to at least qualify the above paragraph with something like \"if\n> you want to create an unrelated branch whose contents do not resemble the\n> original branch at all, then you should ...\".\n>\n> Better yet, try to advertise what you are giving your users in a positive\n> way, instead of in a way that only scares users, perhaps like this:\n>\n>    After 'checkout --orphan', your HEAD will point at an unborn branch,\n>    and the next commit will start a new history without any prior commit.\n>    To help create such a new history that has contents mostly the same as\n>    that of the original branch, the command does not touch the index nor\n>    the working tree, and \"checkout --orphan\" immediately followed by\n>    \"commit -a\" would record a tree very similar to what you had in the\n>    original branch.  This is useful when you want to ... [insert a\n>    summary of \"going open source\" example from my previous message if you\n>    want here].\n>\n>    If on the other hand you want to start a new branch whose contents do\n>    not resemble the original branch at all, you may want to start from an\n>    empty index and the working tree, with \"git rm -rf .\" immediately\n>    after running this command.\n>\n> The same comment applies to the documentation part.\n\nI was trying to be concise on my message.  I realize you want it more explained.\n\nWhat about that:\n\nAfter the 'checkout -o -b' you are in an new unborn branch ready to be\ncommitted.  The next commit will start a new history without any\nancestry.  If this new branch was made to start from scratch, not\nresembling the previous one, then you should use 'git rm -rf' to get\nan empty work tree and index.  Otherwise with a 'git commit -a' you\nwill have a tree exactly as in the previous branch.  So just set\nthings as you want it to be and commit the new unparented branch.\n\n> By the way, I wouldn't mind if you believe \"no common paths\" is the\n> majority case; if that is the case, then the code and behaviour would be\n> different, and the presentation would say something like this:\n\nI agree with you in choosing \"mostly common paths\" as the target since\nyou have decided to target one.\n\nBefore I send another patch version could you please tell me your\nposition about my new explaining text up there.  I will wait for your\nreply before sending a new patch version.\n\nBest regards\n"},{"id":"136985","messageId":"20100317041307.GA26641@progeny.tock","threadId":"23039","inReplyTo":"55bacdd31003161810w1c824570lee1b7d5759568bc1@mail.gmail.com","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-17T04:13:08Z","receivedAt":"2010-03-17T04:13:08Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nErick Mattos wrote:\n\n> I am just trying to make you satisfied so gitsters, I mean git users,\n> will have this feature as soon as possible.\n\nWell, hopefully everyone wants it to make sense, too. :)\n\n> I do prefer my first design mainly because it mimics the state of an\n> initial commit.  I think that is subjectively better.\n> \n> You have been asking me to make one of the two possible work flow uses\n> you pictured as favored so things will be already set to them.  No\n> further commands to them.\n> \n> I did it!  As a matter of fact the \"mostly common paths\" people were\n> favored as you have noticed your inclination to it before.\n\nI guess I am confused because I am not sure what you are trying to do:\n\n A. on one hand, you might want a command to use as a building block.\n    In practice, people would use scripts or refer to known recipes to\n    make use of this building block in one of a few known combinations\n    with other commands.\n\n B. on the other hand, you might be trying to make it easier to get\n    some particular task done.\n\nJunio was discussing the case B.  Whoever has the itch is in a good\nposition to say what interface would be convenient.  Usually one command\ninvocation can be enough to accomplish most of what is needed on its\nown.  There were two examples of such commands he gave:\n\n 1.                                                    * [public]\n                                                        \\\n     * --- * --- * [private]   ===>    * --- * --- * --- * [private]\n\n   for the “we cannot publish the whole history” use,\n\nand\n\n 2.                                                 * [doc]\n\n    * --- * --- * [master]  ===>  * --- * --- * --- * [master]\n\n   for the “starting unrelated development but restrictive disk quotas\n   mean I have to use the same working directory” use.\n\nIn these examples (which are just examples for illustration of what a\nwell supported use case looks like), the content in the index and work\ntree after the command is run is tailored to what is expected to be\nneeded.\n\nI suspect you are aiming for case A instead.  For scripts and special\ncase recipes, it might be a good idea to have a command to use as an\ningredient in tasks like (1) and (2) above.  The recipe people\ncurrently use is usually something like the following:\n\n  git symbolic-ref HEAD refs/heads/newbranch\n  rm .git/index\n\nbut that indeed is not perfect: it does not check for a dirty index\nin case 1, it does not keep track of what files were not registered\nin the index so as not to delete them in case 2, and so on.\n\nAlso one might object to the knowledge of repository layout required;\ngitrepository-layout(5) is probably not the first place a person would\nlook in trying to figure out how to carry out this task.  That misses\nthe point, though, in my opinion, since\n\n git symbolic-ref HEAD refs/heads/newbranch\n git rm --cached '*'\n\naccomplishes the same thing.  Anyway, if your goal is to create\nplumbing, I would suggest modifying a plumbing command instead of\n‘git checkout’.  \n\nThank you for your efforts.  As hinted above, I would not mind seeing\nimprovement in this area at all.  Anyway, I hope this has provided some\nfood for thought (if not, don’t mind me; please carry on).\n\nKind regards,\nJonathan\n"},{"id":"136986","messageId":"7vfx3zjzf5.fsf@alter.siamese.dyndns.org","threadId":"23039","inReplyTo":"55bacdd31003161810w1c824570lee1b7d5759568bc1@mail.gmail.com","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-17T05:21:50Z","receivedAt":"2010-03-17T05:21:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erick Mattos <erick.mattos@gmail.com> writes:\n\n> I am just trying to make you satisfied so gitsters, I mean git users,\n> will have this feature as soon as possible.\n\nDon't try to satisfy _me_ personally.  It is not likely that I am going to\nuse \"checkout --orphan\" myself.  But I would not reject a new feature that\ndoes make sense to some people, even if it is not something I would use.\nI am here to help people like you help others (and to prevent people from\nharming others).\n\nI however am going to have to answer when people complain \"why was this\nsenseless new feature added to the system?  what it does makes no sense\nand does not help me.\"\n\n\"Nuke index but not working tree\" is not something I think I can defend\nand explain as sensible to these people, as I do not think it makes sense\nmyself.  So when Ispot a design that logically does not make sense to me,\nI would say so and ask clarifications.  A major part of the maintainer's\njob is to ask questions and say \"no\".\n\n> I do prefer my first design mainly because it mimics the state of an\n> initial commit.  I think that is subjectively better.\n\nYou keep saying that, but I think it is misguided.  And I do not think\nthere is anything subjective there.\n\nIf you are starting from scratch, you would:\n\n    $ git init newrepo\n    $ cd newrepo\n\nand that is how the state before the initial commit begins with.  You\nmight then do this to prepare for the commit:\n\n    $ tar xf ~/junk/frotz-2.43.tar.gz\n    $ git add .\n\nOr perhaps you would work the other way around:\n\n    $ tar xf ~/junk/frotz-2.43.tar.gz\n    $ cd frotz-2.43\n    $ git init\n    $ git add .\n\nWhichever way you work, notice that you wouldn't have any rubbish in the\nworking tree unrelated to the \"frotz\" project, when the tool (in this\ncase, \"git init\") prepares the repository with a dangling HEAD and the\nworking tree \"before the initial commit\".  You either have emptiness (to\nwhich you can untar into), or you already have files that you would want\nto have in the branch and no other cruft.\n\nIf you did \"nuke index, leaving files in the work tree around\", the result\ndoes not resemble \"state before the initial commit\" at all.  The leftover\nfiles will get in the way.\n\nThe leftover worktree files will not get in the way ONLY if the user wants\nto record a tree that is similar to the original branch, but even in that\ncase they have to do \"git add .\"; keeping the index intact would help them\neven better.\n\nAfter realizing all that, do you still think \"nuke only the index\" is\nsubjectively better?\n\n> I did it!\n\nSure, I am saying that then you should advertise the result as such,\nwithout being negative.\n\n>> Better yet, try to advertise what you are giving your users in a positive\n>> way, instead of in a way that only scares users, perhaps like this:\n>>\n>>    After 'checkout --orphan', your HEAD will point at an unborn branch,\n>>    and the next commit will start a new history without any prior commit.\n>>    To help create such a new history that has contents mostly the same as\n>>    that of the original branch, the command does not touch the index nor\n>>    the working tree, and \"checkout --orphan\" immediately followed by\n>>    \"commit -a\" would record a tree very similar to what you had in the\n>>    original branch.  This is useful when you want to ... [insert a\n>>    summary of \"going open source\" example from my previous message if you\n>>    want here].\n>>\n>>    If on the other hand you want to start a new branch whose contents do\n>>    not resemble the original branch at all, you may want to start from an\n>>    empty index and the working tree, with \"git rm -rf .\" immediately\n>>    after running this command.\n>>\n>> The same comment applies to the documentation part.\n>\n> I was trying to be concise on my message.  I realize you want it more explained.\n\nConcise is good.  Negative is not.\n\n> After the 'checkout -o -b' you are in an new unborn branch ready to be\n> committed.  The next commit will start a new history without any\n> ancestry.  If this new branch was made to start from scratch, not\n> resembling the previous one, then you should use 'git rm -rf' to get\n> an empty work tree and index.  Otherwise with a 'git commit -a' you\n> will have a tree exactly as in the previous branch.  So just set\n> things as you want it to be and commit the new unparented branch.\n\nI wouldn't start the description with\n\n    if you want 'no common paths', then it would be more cumbersome than\n    just this single command\n\nif the primary workflow your chose to support with your implementation is\n'mostly common paths'.\n\nLook at the example I gave you more carefully.  The primary use case we\nintend to support is described first.  Also it is written in much more\ninviting tone, in order to help readers understand the motivation behind\nthe feature.  IOW, \"Ah, that is something I may want to do in some cases,\nand the new feature indeed sounds useful.\" is what we want to hear from\nthe readers (the log message for reviewers, and the documentation for the\nend users) after they read the explanation.  The second paragraph then\nmentions the less common use case for completeness.  To the readers who\nunderstand why the behaviour of the command makes sense for its primary\nuse case (which is described first), it would be easier to accept that\nthey have to run an extra command (by the way, it is \"'git rm -rf .' from\nthe top-level of the working tree; do not forget the dot at the end) to\nclean up the working tree to a prestine state, because they would\nunderstand the reason why the clearing is not done by default.\n\nThe same comment applies to the documentation part of the patch.  Don't be\nnegative.  Positively explain why what you added is useful, and help the\nusers understand why they might want to use it and in what situation.\n"},{"id":"136987","messageId":"7v4okfiksh.fsf@alter.siamese.dyndns.org","threadId":"23039","inReplyTo":"20100317041307.GA26641@progeny.tock","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-17T05:23:10Z","receivedAt":"2010-03-17T05:23:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio was discussing the case B.\n\nWell, not really.  Even as an ingredient, \"nuke index, leaving files in\nthe work tree around\" is the most difficult-to-use mode of operation.\nEither \"try to run 'git rm -f .' from the toplevel and only if it succeeds\npoint HEAD to an unborn branch\" (aka \"remove both\"), or \"point HEAD to an\nunborn branch without doing anything else\" (aka \"keep both\") would be an\ningredient that is far easier to use.\n"},{"id":"136989","messageId":"20100317064034.GA31749@progeny.tock","threadId":"23039","inReplyTo":"7v4okfiksh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-17T06:40:34Z","receivedAt":"2010-03-17T06:40:34Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n> \n> > Junio was discussing the case B.\n> \n> Well, not really.  Even as an ingredient, \"nuke index, leaving files in\n> the work tree around\" is the most difficult-to-use mode of operation.\n> Either \"try to run 'git rm -f .' from the toplevel and only if it succeeds\n> point HEAD to an unborn branch\" (aka \"remove both\"), or \"point HEAD to an\n> unborn branch without doing anything else\" (aka \"keep both\") would be an\n> ingredient that is far easier to use.\n\nOkay, fair enough.  From the point of view of plumbing, what is there\nleft to do that\n\n\tgit rm -f . &&\n\tgit symbolic-ref HEAD refs/heads/new\n\nor\n\n\tgit symbolic-ref HEAD refs/heads/new\n\nor\n\n\tgit rm --cached . &&\n\tgit symbolic-ref HEAD refs/heads/new\n\ndoes not take care of?\n\nI guess I should have said that I would be happier to see something\ntailored to a use case or a class of use cases.\n\nI haven’t needed it for a while, but once upon a time I was making\nisolated branches like crazy for some abuse of git as a compression\ntool.\n\nJonathan\n"},{"id":"137040","messageId":"7v7hpauau1.fsf@alter.siamese.dyndns.org","threadId":"23039","inReplyTo":"20100317064034.GA31749@progeny.tock","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-17T17:17:26Z","receivedAt":"2010-03-17T17:17:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Okay, fair enough.  From the point of view of plumbing, what is there\n> left to do that\n>\n> \tgit rm -f . &&\n> \tgit symbolic-ref HEAD refs/heads/new\n>\n> or\n>\n> \tgit symbolic-ref HEAD refs/heads/new\n>\n> or\n>\n> \tgit rm --cached . &&\n> \tgit symbolic-ref HEAD refs/heads/new\n>\n> does not take care of?\n\nIf we have the \"just detach, don't touch index nor working tree\", which\nhappens to be the cheapest one in the middle (except that it probably\nwants to verify that \"new\" does not exist yet), the calling script of the\nPorcelain suite can use it in conjunction with various forms of \"git rm\"\nwithout incurring any additional overhead (other than a fork-and-exec),\nand I think that would be sufficient.\n\nYou could add\n\n\tgit ls-files |\n        while read path\n        do\n        \tcase $(choose-keep-drop-nuke \"$path\") in\n                keep) ;;\n                drop) git rm --cached -f \"$path\" ;;\n                nuke) git rm -f \"$path\" ;;\n        \tesac\n\tdone\n\tgit symbolic-ref HEAD refs/heads/new\n\nand have the caller supply a callback that intelligently choose what to\nkeep and what to drop, if you want to be really fancy, but at that level\nof complexity, I think it is something the Porcelain writer using the\nplumbing would want to write himself as part of the Porcelain program.\n\nWe might want to add \"git branch --switch <branchname>\" that is roughly\nlike this:\n\n    ref=\"refs/heads/$branch\"\n    git check-ref-format \"$ref\" || die \"malformed\"\n    if git rev-parse -q --verify \"$ref\" >/dev/null\n    then\n    \t# exists\n        exec git checkout \"$branch\"\n    else\n\t# create\n\texec git symbolic-ref HEAD \"$ref\"\n    fi\n"},{"id":"137051","messageId":"55bacdd31003171155l6cae5386m9f12ed72979f489f@mail.gmail.com","threadId":"23039","inReplyTo":"20100317041307.GA26641@progeny.tock","subject":"Re: [PATCH v3] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-03-17T18:55:45Z","receivedAt":"2010-03-17T18:55:45Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"2010/3/17 Jonathan Nieder <jrnieder@gmail.com>:\n> ...\n>\n> Thank you for your efforts.  As hinted above, I would not mind seeing\n> improvement in this area at all.  Anyway, I hope this has provided some\n> food for thought (if not, don’t mind me; please carry on).\n>\n> Kind regards,\n> Jonathan\n\nThanks for your kindness.\n\nWe are almost at the end of this new option creation cycle.  We are\nnow building the appropriated explaining messages.\n\nThis improvement is indeed targeted to let end users create orphan\nbranches.  I don't see a reason for changing focus because I see this\nneed as eventual really.\n\nKind regards\n"}]}