Are you in the right place? You cloned the SXEmacs sources with
git clone http://git.sxemacs.org/sxemacs, and you are able to
push your working copy to a remote repo that is accessible for git
read operations by other people (even if other people means only
Steve).
Yes? OK, great, read on.
Your workflow should run something along these lines...
git pull from your master branch to sync up with the main
SXEmacs repo.
git checkout -b mybugfix to create and checkout a new branch.
You can call it whatever you like, just as long as you know
what it's about. (Yeah, we recommend that you do all your work on
branches and keep your master branch as pristine as possible).
git commit -sam "Summary of changes" For use with small quick
changes that don't really warrant verbose logs to document them.
git commit -sa This form will fire up an editor for you to
write your change logs in1.
git commit -saF mylogfile Use this form for the times when you
have logged your changes as you went to the file mylogfile.
Please take note, that whichever commit command you use, to
always use the -s option to add a Signed-off-by
entry to the log. This will indicate that you played some role in
getting the patch into the code base, and, perhaps more importantly,
you had permission to do so2.
For patches that you're submitting to the main SXEmacs code base that have originated from somebody else (maybe you have a small team of sub-developers working for you), the Signed-off-by entry also indicates that you have reviewed, tested, and approved the patch. And also, the original author has permission to submit it.
git checkout master To flip back to your master branch.
git merge --no-ff mybugfix To merge the changes from the
mybugfix branch into master. The --no-ff forces git to
create a new commit object even if a fast-forward could have been used
to carry out the merge.
At this point everything that was in the mybugfix branch is now
in your master branch, so you no longer need it. You can safely delete
it with git branch -d mybugfix.
git push myremote master To push the changes to your publicly
accessible repo, myremote.
At this point, your changes are ready for Steve to pull into the main SXEmacs code base. All you need to do is let him know, and you can easily do that with the following 2 git commands:
git format-patch --add-header="X-Git-Repo: REPO-URL" \
--subject-prefix="P-Req" --numbered -o DIR origin
git send-email \
--to="SXEmacs Patches <sxemacs-patches@sxemacs.org>" \
--from="$(git config user.name) <$(git config user.email)>" DIR
Those last two commands, format-patch and 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 github3 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 <sxemacs-patches@sxemacs.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.
Git allows you to define aliases that will let you do all kinds of
funky things. Remember those hairy format-patch and
send-email commands?
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 <sxemacs-patches@sxemacs.org>" \
--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 format-patch and
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 <sxemacs-patches@sxemacs.org>"
git config sendemail.from "Your Name <your@email>"
With those settings, the commands: git format-patch -o DIR
origin, and 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.
[1] You can set which editor to use
with git config --global core.editor my_fav_editor. Steve has
his set to a shell function called edit which fires up gnuclient
if SXEmacs is running, or SXEmacs if not.
[2] There might be licencing/copyright things to be aware of, especially in the case of working on SXEmacs either for your employer, or during your employer's time.
[3] 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.