Re: [PATCH] git checkout -b: unparent the new branch with -o
- From
Erick Mattos <erick.mattos@gmail.com>
- Date
- Feb 24, 2010, 22:40 UTC
- Message-ID
- <55bacdd31002241440n5266edcagbe0954127f072b5d@mail.gmail.com>
- In-Reply-To
- <55bacdd31002241423i10ee177cnda545c9aac071b39@mail.gmail.com>
Sorry for the e-mail sent wrong (GMANE/140995). The message was screwed by gmail by sending it in HTML which git list blocked. I had to forward another and mistakenly copied Junio's.
2010/2/24 Erick Mattos <erick.mattos@gmail.com>:
Show 40 quoted lines
> Erick Mattos <erick.mattos@gmail.com> 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. >