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 > > > ------------------------------------------------------------- > > 1. get the latest changes > > git pull > > 2. create a branch for you to do your changes > > git checkout -b my-doc-fixed > > 3. Edit the file you want to change > > $ emacs .... > $ emacs .... > > 4. Commit the changes when you feel like it > > git add doc/org.texi > git commit > > 5. Create a patch > > git diff master > send-to-carsten.patch > > 6. 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 > [email protected] > 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
