{"thread":{"id":"22776","subject":"[PATCH] git checkout -b: unparent the new branch with -o","startedAt":"2010-02-23T21:20:07Z","lastAt":"2010-02-24T22:40:23Z","messageCount":7,"participants":["Erick Mattos","Junio C Hamano","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"135468","messageId":"1266960007-16127-1-git-send-email-erick.mattos@gmail.com","threadId":"22776","inReplyTo":null,"subject":"[PATCH] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-02-23T21:20:07Z","receivedAt":"2010-02-23T21:20:07Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Sometimes it is necessary to start up a new development branch of code\nintended to be merged in the near future to existing branches but which\nactually does not relate to them.\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 some files are\nadded to the index and committed, exactly as if it was an initial commit.\nA 'git clean -df' would delete everything from the work tree making it\nempty for new files.\n\nSigned-off-by: Erick Mattos <erick.mattos@gmail.com>\n---\n\nThis new option just make it easy to add orphan branches to git repositories.\n\nThere are a lot of hacks to do the same thing ( I had been using some!  :-) )\nbut this should be seen as a part of a normal work flow so just an option.\n\nA good example to show the need of this option is a Debian folder of control\nfiles.  Whenever a maintainer needs to debianize a source code to build\npackages he needs to add a folder called Debian with a lot of files inside it.\nThose files are connected to the source code of the program but they are not\nreally part of the program development.  On this situation using the new\noption, that maintainer would do:\n\n\tgit checkout -ob debian\n\tgit clean -df\n\tmkdir Debian\n\tadd all control files\n\t...hack it enough...\n\tgit add Debian\n\tgit commit\n\nAnd then when ready to build the packages from the master branch he would just\nneed to merge or cherry-pick the Debian branch on it.  On this work flow both\ndevelopments occur paralleled and fuse only at the moment of building the\nDebian's packages.\n\nI have some other examples to tell but I think you people already have figured\nthe needs and possible uses out.  :-)\n\nKind regards\n\n builtin-checkout.c             |   14 +++++++++-\n t/t2017-checkout-orphan.sh     |   50 ++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 72 insertions(+), 3 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..6534934 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -9,7 +9,7 @@ SYNOPSIS\n --------\n [verse]\n 'git checkout' [-q] [-f] [-m] [<branch>]\n-'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]\n+'git checkout' [-q] [-f] [-m] [-b <new_branch> [-o]] [<start_point>]\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...\n 'git checkout' --patch [<tree-ish>] [--] [<paths>...]\n \n@@ -25,6 +25,10 @@ linkgit:git-branch[1] were called; in this case you can\n 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+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 code will\n+be committed by using 'git add' and 'git commit' as if it was an initial\n+commit.\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@@ -86,6 +90,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 c5ab783..4882613 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@@ -509,8 +510,13 @@ 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\tdiscard_cache();\n+\t\t\tremove_path(get_index_file());\n+\t\t}\n+\t\telse\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@@ -647,6 +653,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@@ -695,6 +702,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..7170641\n--- /dev/null\n+++ b/t/t2017-checkout-orphan.sh\n@@ -0,0 +1,50 @@\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 branch | sed -n \"/*/s/\\* //p\")\" &&\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 -z \"$(git branch | grep \\*)\" &&\n+\ttest \"beta\" = \"$(git symbolic-ref HEAD | sed \"s,.*/,,\")\" &&\n+\ttest -z \"$(git ls-files)\" &&\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.84.g03684\n"},{"id":"135475","messageId":"7viq9nfwg8.fsf@alter.siamese.dyndns.org","threadId":"22776","inReplyTo":"1266960007-16127-1-git-send-email-erick.mattos@gmail.com","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-23T21:56:07Z","receivedAt":"2010-02-23T21:56:07Z","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> A good example to show the need of this option is a Debian folder of control\n> files.  Whenever a maintainer needs to debianize a source code to build\n> packages he needs to add a folder called Debian with a lot of files inside it.\n> Those files are connected to the source code of the program but they are not\n> really part of the program development.  On this situation using the new\n> option, that maintainer would do:\n>\n> \tgit checkout -ob debian\n> \tgit clean -df\n> \tmkdir Debian\n> \tadd all control files\n> \t...hack it enough...\n> \tgit add Debian\n> \tgit commit\n\nI do not think that is a good example.\n\nIf you have an extract of an upstream tarball, say frotz-1.42.tar.gz, and\nyou are not porting anything older than that version, why not have two\nbranches, frotz and master, and do things this way?\n\n - frotz (or \"vanilla\" or \"upstream\") that keeps track of the \"vendor\n   drop\" without debian/ directory;\n\n - master that forks from frotz and adds \"debian/\" and nothing else; and\n\n - any other topic branches that either fork from frotz if you are fixing\n   upstream bug (or enhancing the vanilla version), or fork from master if\n   you are fixing or enhancing the debianization.\n\nWhen you receive frotz-1.43.tar.gz, you will advance 'frotz' branch with\nit, and probably fork maint-1.42 branch from master so that you can keep\nsupporting older debianized frotz, while merging frotz into master so that\nyou can prepare a debianized version of newer package.\n\nYour debianization will _never_ be totally independent of the vendor\nversion, so there is no good reason to have it as a rootless branch.\n"},{"id":"135494","messageId":"m3ocjfmt60.fsf@localhost.localdomain","threadId":"22776","inReplyTo":"1266960007-16127-1-git-send-email-erick.mattos@gmail.com","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-02-23T23:26:01Z","receivedAt":"2010-02-23T23:26:01Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erick Mattos <erick.mattos@gmail.com> writes:\n\n> Subject: [PATCH] git checkout -b: unparent the new branch with -o\n\nI would say it is rather: \"git checkout -b: allow creating unrelated branch\",\nor something like that.\n\nBy the way, for the solution to be complete it should work not only for \n\"git checkout -b\" shortcut, but also for \"git branch\".\n\n>\n> Sometimes it is necessary to start up a new development branch of code\n> intended to be merged in the near future to existing branches but which\n> actually does not relate to them.\n\nI'm not sure if 'unrelated but _intended to merge_' is most common\nworkflow utilizing unrelated branches... and whether git should\npromote such workflow, even if only describing it in the commit\nmessage.\n\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\nI think that for example '--root', or '--rootless', or '--unrelated'\nwould be a better name than '--orphan'.  Besides I don't think that\nsuch rarely used option should squat on rare resource of single-letter\noption.\n\n> \n> After the 'checkout -o -b' the new branch is not saved until some files are\n> added to the index and committed, exactly as if it was an initial commit.\n> A 'git clean -df' would delete everything from the work tree making it\n> empty for new files.\n\nDoes it mean that the index is empty, but the working area is\nunchanged?  It is not clear from the commit message.\n\n> \n> Signed-off-by: Erick Mattos <erick.mattos@gmail.com>\n> ---\n[...]\n\n> --- a/Documentation/git-checkout.txt\n> +++ b/Documentation/git-checkout.txt\n> @@ -9,7 +9,7 @@ SYNOPSIS\n>  --------\n>  [verse]\n>  'git checkout' [-q] [-f] [-m] [<branch>]\n> -'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]\n> +'git checkout' [-q] [-f] [-m] [-b <new_branch> [-o]] [<start_point>]\n\nThis is not stricly correct, as you can use either '-o' OR '<start_point>',\nbut not both (but you can use '-o' only together with '-b <new_branch>').\n\n\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\nUnparented?  Perhaps \"set it up so first commit on this branch would\nbe root (parenless) commit\".  Hmmm... it is not easy to describe it\nwell...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"135620","messageId":"55bacdd31002241414p4428165asea22b71726afff68@mail.gmail.com","threadId":"22776","inReplyTo":"55bacdd31002241410h747ae221xd72dfcf269bdb84e@mail.gmail.com","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-02-24T22:14:24Z","receivedAt":"2010-02-24T22:14:24Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Hi,\n\n> > Subject: [PATCH] git checkout -b: unparent the new branch with -o\n>\n> I would say it is rather: \"git checkout -b: allow creating unrelated branch\",\n> or something like that.\n\nI don't see a point to change something specific to a general not yet\ndefined option.\n\n>\n> By the way, for the solution to be complete it should work not only for\n> \"git checkout -b\" shortcut, but also for \"git branch\".\n\nThat is not the idea.  The idea is to start coding a new orphan\nbranch.  Not to create an empty orphan branch for later.\n\nAlso it is not meant to clone a commit to a new orphan branch.  Even\nthough this could be done, using \"git checkout TARGET; git checkout\n-ob NEW_BRANCH; git add .; git commit -C/-c TARGET --reset-author\".\n\nIt is meant to start a parallel development which will be connected to\nexisting ones.  Of course there will be other possible uses (I always\ntrust in people inventiveness).\n\n>\n> >\n> > Sometimes it is necessary to start up a new development branch of code\n> > intended to be merged in the near future to existing branches but which\n> > actually does not relate to them.\n>\n> I'm not sure if 'unrelated but _intended to merge_' is most common\n> workflow utilizing unrelated branches... and whether git should\n> promote such workflow, even if only describing it in the commit\n> message.\n\nThis is dependent of point-of-view.  So thank you very much for sharing yours.\n\nAnyway all those unrelated branches uses you mentioned would be\nsatisfied by this new option.\n\n>\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> I think that for example '--root', or '--rootless', or '--unrelated'\n> would be a better name than '--orphan'.  Besides I don't think that\n> such rarely used option should squat on rare resource of single-letter\n> option.\n\nParent is the term employed even by the commits itself to describe the\ncommit of origin so I don't think those suggestions are nice.  I do\nagree about the importance of single-letters because we only have 26\nbut in this case it would be only the fifth used.\n\n> >\n> > Signed-off-by: Erick Mattos <erick.mattos@gmail.com>\n> > ---\n>\n> [...]\n>\n> > --- a/Documentation/git-checkout.txt\n> > +++ b/Documentation/git-checkout.txt\n> > @@ -9,7 +9,7 @@ SYNOPSIS\n> >  --------\n> >  [verse]\n> >  'git checkout' [-q] [-f] [-m] [<branch>]\n> > -'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]\n> > +'git checkout' [-q] [-f] [-m] [-b <new_branch> [-o]] [<start_point>]\n>\n> This is not stricly correct, as you can use either '-o' OR '<start_point>',\n> but not both (but you can use '-o' only together with '-b <new_branch>').\n\nYou are right on that because start_point would be useless.\n\n>\n>\n>\n> > +-o::\n> > +--orphan::\n> > +     When creating a new branch, set it up as unparented thus\n> > +     unrelated to the previous branch.\n> > +\n>\n> Unparented?  Perhaps \"set it up so first commit on this branch would\n> be root (parenless) commit\".  Hmmm... it is not easy to describe it\n> well...\n\nEverything we try do define with human language is incomplete.  So we\nnormally employ added layers of information to better describe things\nas much as requested.\n\nIn our case we start with a single word represented by a letter or not\nthat try to give an idea.  If not enough, by --help or when people use\nit incorrectly they will get a small message describing the intended\nuse better.  Then by a 'man' a paragraph.  Further text is added to\nthe 'man' if necessary. And then the help files, tutorials and other\npeople.\n\nI think all off those steps were taken correctly in this case and that\nwhat is written now is good enough.\n\nThank you very much for your comments.  I did appreciate it.\n\nBest regards.\n"},{"id":"135621","messageId":"55bacdd31002241423i10ee177cnda545c9aac071b39@mail.gmail.com","threadId":"22776","inReplyTo":"7viq9nfwg8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-02-24T22:23:16Z","receivedAt":"2010-02-24T22:23:16Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Erick Mattos <erick.mattos@gmail.com> writes:\n\n> A good example to show the need of this option is a Debian folder of control\n> files.  Whenever a maintainer needs to debianize a source code to build\n> packages he needs to add a folder called Debian with a lot of files inside it.\n> Those files are connected to the source code of the program but they are not\n> really part of the program development.  On this situation using the new\n> option, that maintainer would do:\n>\n>       git checkout -ob debian\n>       git clean -df\n>       mkdir Debian\n>       add all control files\n>       ...hack it enough...\n>       git add Debian\n>       git commit\n\nI do not think that is a good example.\n\nIf you have an extract of an upstream tarball, say frotz-1.42.tar.gz, and\nyou are not porting anything older than that version, why not have two\nbranches, frotz and master, and do things this way?\n\n - frotz (or \"vanilla\" or \"upstream\") that keeps track of the \"vendor\n  drop\" without debian/ directory;\n\n - master that forks from frotz and adds \"debian/\" and nothing else; and\n\n - any other topic branches that either fork from frotz if you are fixing\n  upstream bug (or enhancing the vanilla version), or fork from master if\n  you are fixing or enhancing the debianization.\n\nWhen you receive frotz-1.43.tar.gz, you will advance 'frotz' branch with\nit, and probably fork maint-1.42 branch from master so that you can keep\nsupporting older debianized frotz, while merging frotz into master so that\nyou can prepare a debianized version of newer package.\n\nYour debianization will _never_ be totally independent of the vendor\nversion, so there is no good reason to have it as a rootless branch.\n"},{"id":"135622","messageId":"55bacdd31002241427w2b160614vd1a5977d1820984b@mail.gmail.com","threadId":"22776","inReplyTo":"7viq9nfwg8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-02-24T22:27:06Z","receivedAt":"2010-02-24T22:27:06Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Thanks for the fast response.  Your level of commitment to this\nproject is awesome!\n\n2010/2/23 Junio C Hamano <gitster@pobox.com>\n>\n> >       git checkout -ob debian\n> >       git clean -df\n> >       mkdir Debian\n> >       add all control files\n> >       ...hack it enough...\n> >       git add Debian\n> >       git commit\n>\n> I do not think that is a good example.\n\nWell it is just an example. Its intention is to show some practical\ndata about this proposition.\n\n> If you have an extract of an upstream tarball, say frotz-1.42.tar.gz, and\n> you are not porting anything older than that version, why not have two\n> branches, frotz and master, and do things this way?\n>\n>  - frotz (or \"vanilla\" or \"upstream\") that keeps track of the \"vendor\n>   drop\" without debian/ directory;\n>\n>  - master that forks from frotz and adds \"debian/\" and nothing else; and\n>\n>  - any other topic branches that either fork from frotz if you are fixing\n>   upstream bug (or enhancing the vanilla version), or fork from master if\n>   you are fixing or enhancing the debianization.\n>\n> When you receive frotz-1.43.tar.gz, you will advance 'frotz' branch with\n> it, and probably fork maint-1.42 branch from master so that you can keep\n> supporting older debianized frotz, while merging frotz into master so that\n> you can prepare a debianized version of newer package.\n\nThe main point here is not the way one prefers to work.  It is to let\none works the way one wants.  In other words: give more versatility to\nwhat is already working fine.\n\n> Your debianization will _never_ be totally independent of the vendor\n> version, so there is no good reason to have it as a rootless branch.\n\nIn matter of fact, mine, personally, is.  Please follow:\nI normally hack software I want to add features I feel is lacking.  As\na Debian user when I compile it at last to install my version I always\ndo Debian packages so to let APT do its works.  As I like not to\nreinvent the wheel I normally extract the Debian folder from the\nnormal repository packages.\n\nSo after a while I just have in a separate Debian branch the commit\n1.5, 1.6, ....  In case I have to change the Debian files then I will\nhave my commits spread in the middle of this branch.\n\nBut as what I had pictured before was a general approach then or you\ncould be right on your example work flow or separating it could be\nbetter or whatever!  It was just an example.\n\nAll commits I post are stuff I use which, following free software\nideology, I just want to share so other people could use it too.  I\nknow how limited my efforts are to a project like git.  A project like\nthat needs people really involved and pro-active like you.  But even\nbeing a small contributor I really like to contribute because I think\nthe approach of free software community is the best for all and it\nshould be supported by everyone who cares.\n\nI hope some day we could find a way to spread this ideology to\neverything else in our society.  Working just to make things better\nfor no other direct reason; communitarian development; freedom and\ndemo/meritocracy; ...  :-)\n\nSorry for writing too much.\n\nRegards.\n"},{"id":"135623","messageId":"55bacdd31002241440n5266edcagbe0954127f072b5d@mail.gmail.com","threadId":"22776","inReplyTo":"55bacdd31002241423i10ee177cnda545c9aac071b39@mail.gmail.com","subject":"Re: [PATCH] git checkout -b: unparent the new branch with -o","fromName":"Erick Mattos","fromEmail":"erick.mattos@gmail.com","sentAt":"2010-02-24T22:40:23Z","receivedAt":"2010-02-24T22:40:23Z","isPatch":true,"sender":{"key":"erick.mattos@gmail.com","avatar":"https://avatars.githubusercontent.com/u/134001?v=4"},"body":"Sorry for the e-mail sent wrong (GMANE/140995).  The message was\nscrewed by gmail by sending it in HTML which git list blocked.  I had\nto forward another and mistakenly copied Junio's.\n\n2010/2/24 Erick Mattos <erick.mattos@gmail.com>:\n> Erick Mattos <erick.mattos@gmail.com> writes:\n>\n>> A good example to show the need of this option is a Debian folder of control\n>> files.  Whenever a maintainer needs to debianize a source code to build\n>> packages he needs to add a folder called Debian with a lot of files inside it.\n>> Those files are connected to the source code of the program but they are not\n>> really part of the program development.  On this situation using the new\n>> option, that maintainer would do:\n>>\n>>       git checkout -ob debian\n>>       git clean -df\n>>       mkdir Debian\n>>       add all control files\n>>       ...hack it enough...\n>>       git add Debian\n>>       git commit\n>\n> I do not think that is a good example.\n>\n> If you have an extract of an upstream tarball, say frotz-1.42.tar.gz, and\n> you are not porting anything older than that version, why not have two\n> branches, frotz and master, and do things this way?\n>\n>  - frotz (or \"vanilla\" or \"upstream\") that keeps track of the \"vendor\n>  drop\" without debian/ directory;\n>\n>  - master that forks from frotz and adds \"debian/\" and nothing else; and\n>\n>  - any other topic branches that either fork from frotz if you are fixing\n>  upstream bug (or enhancing the vanilla version), or fork from master if\n>  you are fixing or enhancing the debianization.\n>\n> When you receive frotz-1.43.tar.gz, you will advance 'frotz' branch with\n> it, and probably fork maint-1.42 branch from master so that you can keep\n> supporting older debianized frotz, while merging frotz into master so that\n> you can prepare a debianized version of newer package.\n>\n> Your debianization will _never_ be totally independent of the vendor\n> version, so there is no good reason to have it as a rootless branch.\n>\n"}]}