Erick Mattos <erick.mattos@xxxxxxxxx> writes: > A good example to show the need of this option is a Debian folder of control > files. Whenever a maintainer needs to debianize a source code to build > packages he needs to add a folder called Debian with a lot of files inside it. > Those files are connected to the source code of the program but they are not > really part of the program development. On this situation using the new > option, that maintainer would do: > > git checkout -ob debian > git clean -df > mkdir Debian > add all control files > ...hack it enough... > git add Debian > git commit I do not think that is a good example. If you have an extract of an upstream tarball, say frotz-1.42.tar.gz, and you are not porting anything older than that version, why not have two branches, frotz and master, and do things this way? - frotz (or "vanilla" or "upstream") that keeps track of the "vendor drop" without debian/ directory; - master that forks from frotz and adds "debian/" and nothing else; and - any other topic branches that either fork from frotz if you are fixing upstream bug (or enhancing the vanilla version), or fork from master if you are fixing or enhancing the debianization. When you receive frotz-1.43.tar.gz, you will advance 'frotz' branch with it, and probably fork maint-1.42 branch from master so that you can keep supporting older debianized frotz, while merging frotz into master so that you can prepare a debianized version of newer package. Your debianization will _never_ be totally independent of the vendor version, so there is no good reason to have it as a rootless branch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html