Robert,
Including git stuff on the website is a definite win. I'll work on pulling what you've sent onto the site soon.
thanks,
On Aug 19, 2009, at 1:52 PM, Robert Goldman wrote:
Stelian Ionescu wrote:
On Wed, 2009-08-19 at 10:25 -0500, Robert Goldman wrote:
Gary King wrote: ...
- moved defgenerics to their own section because I like it that
way.
... I think that this is a fine thing to do, but it makes for a miserable merge. The next time you are going to do this, would you mind pushing a version with all the normal patches, then push a second version with the code blocks moved?
Alternatively, would someone please provide simple recipes for dealing with git? It's really far more complex than CVS, and I don't see obvious patterns of interaction to do simple things like restore synchronization with the central repo.
git fetch origin downloads latest commits git reset --hard origin/master nukes all local changes, synchronizing with the remote repo
Would it be possible for us to add a short git briefing to the ASDF web page materials?
At the bottom of the message is what I have from the org-mode folks (now very old), which I've found helpful.
Note that they suggest, for simplicity, putting all your local changes for a particular topic on a branch, and keeping your local master as a clean reflection of the remote origin. Each time you want to make a single change, you just make a new branch. Is this a reasonable
One of the things these instructions aren't great about is filling in how to pull changes from remote into your local development branch (through the master). They also don't touch on resolving conflicts. I have read about this on the web, and find the advice there conflicting and confusing.
Also, is git diff the best way to generate patches? I know that there are ways to generate patch emails from git, but don't know how to make them work if (like me) you don't run sendmail, procmail, etc. on your local machine.
Thanks,
R
get the latest changes
git pull
create a branch for you to do your changes
git checkout -b my-doc-fixed
Edit the file you want to change
$ emacs .... $ emacs ....
Commit the changes when you feel like it
git add doc/org.texi git commit
Create a patch
git diff master > send-to-carsten.patch
Go back t the master branch for normal use of Org-mode. Do this only after committing all changes.
git checkout master
This all works fine when you don't pull new changes while working on your patch. If Org changes while you do your work, you can do this:
commit your changes as described above.
switch back to master
git checkout master
get new changes
git pull
return to your branch
git checkout my-doc-fixes
make sure your changes are made relative to the current, new master:
git rebase master
continue working on your patches.
The only problem here is that git rebase can fail if there is overlap, so my recommendation for he beginner is to just use the workflow shown above.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter