You only need to read this section if you are able to host a publicly accessible repo somewhere.
Getting everything set up is really very easy. I think you’ll be quite surprised if you haven’t done this sort of thing before. In the examples below I’m assuming that you have shell access to your remote host via ssh…
user@localhost ~ $ ssh email@example.com user@host ~ $ mkdir -v sxemacs user@host ~ $ cd !$ user@host ~/sxemacs $ git init --bare user@host ~/sxemacs $ echo Your Name's SXEmacs Repo > description user@host ~/sxemacs $ exit user@localhost ~ $ git clone http://git.sxemacs.org/sxemacs user@localhost ~ $ cd sxemacs user@localhost ~/sxemacs $ contrib/git-for-steve.sh
And that’s it! Told you it was easy, didn’t I? All you have to do now is push your local copy to your remote…
git push myremote master
The last two commands for patch submission listed in See Patch Submission,
send-email are fairly long
and hairy. You’d no doubt have trouble remembering them. But, never
fear, git has a few tricks up her sleeve to make your life easier.
If you are lucky enough to NOT be using github7 to host your publicly accessible repo you can set up a post-receive hook to automatically send your pull requests to the SXEmacs mailing list when you push to it.
Remember: This hook runs from your publicly accessible repo (your remote), and NOT from your local working directory. It is called after you push to your remote.
Jump over to your remote now and follow these steps
git config hooks.mailinglist \ "SXEmacs Patches <firstname.lastname@example.org>" git config hooks.envelopesender "Your Name <your@email>" git config hooks.emailprefix "[P-Req] " git config hooks.showrev "git show -C %s; echo"
echo "Your Name's SXEmacs Repo" > description
Take note that the SXEmacs mailing lists will funnel any post from non-subscribers into the moderation queue. So make sure that the address you set hooks.envelopesender to is subscribed to the patches list.
Also be aware that using this post-receive hook will mean that every time you push to your publicly accessible repo, a message will be sent to sxemacs-patches; this includes instances where you merely are pulling the latest from mainline and mirroring. Hence, the use of aliases as discussed below may be preferable. We are looking into ways of avoiding this sort of annoyance.
Git allows you to define aliases that will let you do all kinds of
funky things. Remember those hairy
git config alias.sxe-fp 'format-patch --add-header="X-Git-Repo: REPO-URL" \ --subject-prefix="P-Req" --numbered' git config alias.sxe-sm 'send-email \ --to="SXEmacs Patches <email@example.com>" \ --from="$(git config user.name) <$(git config user.email)>"'
With those 2 aliases set you can get your pull requests in by doing…
git sxe-fp -o DIR origin && git sxe-sm DIR
You can make your life even easier by having git store things in its
config. In this case, you can store those
send-email command line options in the repo’s config…
git config format.headers "X-Git-Repo: YOUR-REMOTE-URL" git config format.subjectprefix "P-Req" git config format.numbered true git config sendemail.to \ "SXEmacs Patches <firstname.lastname@example.org>" git config sendemail.from "Your Name <your@email>"
With those settings, the commands:
git format-patch -o DIR
git send-email DIR are now equivalent of the
original long hairy ones mentioned further up.
Be careful when setting up aliases and config settings that you only make them global if you absolutely have to. All the ones I’ve shown here have been repo-specific.
The git-for-steve.sh script in our contrib directory is an easy (and recommended) way to set up your git repo. It’ll make sure that you have everything set up correctly and in an optimal way.
github is great and may be the ideal solution for you to host your repo somewhere, but it is inflexible in that you get no shell access, you can’t set up custom hooks, and you are very limited in what git config settings you can tweak.