why not just...
that's if you still want to refer to it as trunk and not master
without renaming the branch to... wait, why are you proposing to
rename the branch to master with -b when it's master by default?
>> ./trunk/admin/git-new-workdir
>
> This doesn't exist and whether or not git-workdir or even separate
> working trees is what you'll want is debatable. Personally I just
> switch branches and build out-of-tree, but for something as large as
> Emac I can see the utility of having separate workdirs. If the
> directories are side-by side anyway, then
git-new-workdir is part of git/contrib which falls under the same GPL, correct?
If so, no harm in copying it for distribution AFAIK.
> git clone -b emacs-24 --reference emacs git://
git.sv.gnu.org/emacs.git emacs-24
>
> is just as good.
>
>> You edit the files in either branch, `M-x vc-dir', and check in your
>> changes. Then you need to push the data to the main repository. This
>> will usually fail, since somebody else has pushed other changes in the
>> meantime. To fix this, say
>>
>> git pull --rebase
> When working with upstream this is good practrice, but if you're going
> to do that anyway, just configure your branch with "rebase = true". Or
> configure "autosetuprebase = true" on a repo-wide or global basis so Git
> will do that by default (you can always change that later of course).
This does no good in feature branches, so you should always `bzr update' first
...or in this case `git pull --rebase'. am I missing something here?