[asdf-devel] announce: ASDF 1.359
Patch for system-source-file from Greg Pfeil * system-source-file now works for systems without their own .asd * moved defgenerics to their own section because I like it that way. Documentation improvements * added docstring to the method-combination standard-asdf-method- combination * added docstring to the generic-function traverse * added description of `test-op` to the manual * removed descriptions of test-system-version operation and feature- dependent-op thanks to all, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
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. Thanks, r
Hi Robert,
* 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?
Thats a good idea.
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.
I wish I could... :-(. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
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 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
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.
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:
* 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
Gary King wrote: ... 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 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
Robert Goldman wrote:
Would it be possible for us to add a short git briefing to the ASDF web page materials?
If you haven't already seen it, take a look at http://book.git-scm.com/ - Daniel
dherring@tentpost.com wrote:
Robert Goldman wrote:
Would it be possible for us to add a short git briefing to the ASDF web page materials?
If you haven't already seen it, take a look at http://book.git-scm.com/
I've looked at it, but I'm not sure that's what's needed. The problem is that git is so much more flexible than other version control systems (to the point where it has even been called a toolkit for building a version control system). So if I read the subversion redbook I pretty much know what to do with svn. But reading a book about git doesn't really get me all the way, because it doesn't provide the recommended use case. If you take a look at that email from the org-mode folks, it provides a pretty specific use case for git that matches the fundamentally centralized nature of org-mode development. That is, when you run a git clone of the org-mode code base, you do so in a way that optimizes the development and submission of patches to Carsten and his crew for incorporation in the main repository. My best guess is that this is going to be a good model for ASDF, with the possible exception that it might be nice to very clearly have a release and one or more experimental versions for us to be able to validate before new stuff makes the transition to release. I don't see a huge win to having a truly peer-to-peer revision control system for ASDF, although others' opinions might vary. best, r
participants (4)
-
dherring＠tentpost.com -
Gary King -
Robert Goldman -
Stelian Ionescu