On Wed, Jul 1, 2009 at 8:51 PM, David Given<[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Dennison wrote: > [...] >> If you like you can push this to a public git tree, so others can >> benefit immediately. However I fixed this last November in my local >> tree, so I won't need to pull in this change. > > Well, I've committed it, but I can't push it because I don't have write > access to the repository. (Also, github has really stupid username rules.)
David, There are several ways to attack this. Some examples below but other people have written far better tutorials than I can: 1) You can setup your own github source tree, push to that, then advise that your change is available 2) I can selectively add "collaborators" to my repository. This way I could give interested individuals the ability to write to their own named branch 3) You can use git to extract your commits as patches and email them through. I can the use git tools to apply the patches and recreate your branch locally. All these methods work. 3) is probably best if someone has questions about their changes - makes it easy to reply with inline comments in an email. > > Also, unless you know something cunning I'll probably have to regenerate > my git tree based on [email protected]:AndrewD/prex.git rather than > git://github.com/AndrewD/prex.git, for simplicity. You can add another "remote" to target pushing to this location, or just do something like: git push [email protected]:AndrewD/prex.git master:users/dg This would push your local master branch up to the server as a branch named users/dg Git has no problems communicating with multiple repositories from your local copy. > (Also also, trying to rebase complains that I have changed files in my > working tree. Yes, I know. Is there a way of proceeding and then letting > me resolve any conflicts later, a la SVN?) Several ways to attack this: with git stash: 1) git stash <- saves your working changes in a temp location 2) rebase / whatever 3) git stash apply <- reapply your working changes with a temp branch: 1) git checkout -b wip <- create a branch named wip 2) git commit -am "hacking on prex" <- commit all changes to the wip branch 3) git rebase origin/master master <- move your master branch changes onto origin/master (for example) 4) git rebase master wip Also note that in many cases you do not need to commit your changes - your working copy can stay "dirty", as long as the branch you are switching to hasn't changed the files you are editing. "git checkout -b wip" above is an example of this - it created a new branch and switched to it while having uncommitted changes > >> Are there any arm specific fixes I should have before I try to test >> changes with qemu? I've never run Prex on arm... > > The only one I know of is that modern libgccs require a symbol called > 'raise'. I hacked it in the three places needed to make things build, > but it then won't boot --- I get a load error from prexboot. Thanks - I'll see how I go. Andrew ------------------------------------------------------------------------------ _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
