Achim Gratz <
address@hidden> wrote:
> Lars Magne Ingebrigtsen writes:
>> Then we want to clone the repository. We normally want to have both
>> the current trunk and the emacs-24 branch.
>
> Trunk is now known as master.
>
>> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>
> Better to do the clone either with git: or http: public access and leave
> the ssh credentials strictly for pushing to upstream. You do this by
> adding a section like this to your global git config (you could add it
> to the repo config, but that doesn#t make much sense if you're having
> multiple clones around):
>
> [url "git+ssh://<membername>@
git.sv.gnu.org/srv/git/emacs.git"]
> pushInsteadOf = git://
git.sv.gnu.org/emacs.git>
> That should help the server load a bit.
>
>> mv emacs trunk
>
> If you're going to rename the directory, you'd be better off just
> telling git clone what you want it to be named:
>
> git clone -b master git://
git.sv.gnu.org/emacs.git master
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?