Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Achim Gratz <address@hidden> writes:

> 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.

We can call the trunk the trunk if we want to.

>> 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.

TLS is not a major CPU hog these days.  And we're not 10K developers
accessing the repository, so this just seems like make-work.

>> 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

I don't see how that's shorter or easier to remember.

>> ./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.

If this is the work flow we're going with, it will exist.

> 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.

Well, that's nice for you, but that's not how many of us prefer to
work.  We want both branches at the same time.

> If the directories are side-by side anyway, then
>
> git clone -b emacs-24 --reference emacs git://git.sv.gnu.org/emacs.git 
> emacs-24
>
> is just as good.

Somebody else will have to weigh in on that.  I have no idea.

>> 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).

Ditto.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no