Re: [Chicken-hackers] small patch
On Tue, May 26, 2015 at 04:40:03PM +0200, "Jörg F. Wittenberger" wrote: > Am 23.05.2015 um 16:45 schrieb Peter Bex: > > It looks like you forgot to configure your username and e-mail address > > in git. It says "From: Benutzer ". You can > > configure this through: > > > > git config --global user.name "blabla" > > git config --global user.email bla...@example.com > > Thanks a lot! These are the kind of things I expected to miss. > > Helpful and smart as git is, it does somehow not really obey the "name" > given in .gitconfig. I'll have to figure out. This time I manually > edited the patch... It wants the option under a heading, like an .ini file: [user] name = blabla This translates to "user.name" in the syntax "git config" accepts. > > Please make a new commit using the correct author and send it, so that > > we get the attribution right. > > attached Thanks, I've pushed this to master and cherry picked it onto chicken-5. > I tried now to to have my own branch. Funny: I expected the branch name > to appear somehow in the patch(headers), but that's not the case. Indeed, it will only show the parent commit. If you apply it on a branch, it will create a new commit and make the current branch point to the newly created head. > Since that's not the case, I'll have to figure out how to create patches > between arbitrary commits. Why? fossil can export/import whole > repositories to/from git. Maybe it turns out to be simpler to actually > work in fossil and just format-patch from git eventually. I've tried that for a while with bzr, but this turned out to be a nightmare because due to (I think) a bug in "dulwich" (the git library for python), it started to get out of sync somehow, which meant that my checkout was slightly different from a fresh clone done by the same process. I eventually just gave up and switched to "native" git. Because I had a lot of trouble convincing git to use emacs ediff as a merge tool (with hg and I think also with svn this was easy), I've recently started my third attempt to make use of magit, the emacs mode for git. I never really got used to magit and prefer to use VC-mode for everything because I have to switch between svn, hg and git a lot at home and at work, but at least magit has a key to invoke ediff-merge on a conflicted file, which is absolutely essential for all but the most trivial merge conflicts, so I'm willing to learn yet another tool (sigh...) for this fact alone. > Though it appears to me to be more the details, which I did not yet > understand. Like "which tag is supposed to track which purpose" (e.g., > master, origin), how do I commit into a fresh branch, why the hell do I > need the rebase concept at all? Rebase is nice when you are doing some long-term work on a branch while development continues on the main branch you started out from. The "numbers-integration" branch is a good example of that, I've been rebasing that a lot to make it easier for other hackers to review my changes. If you don't rebase, you'll either drift farther and farther away from the original branch and risk a lot of merge conflicts, or you have to periodically merge, which creates noisy "merge commits" that just get in the way. Rebasing also helps a lot if you're working on a branch for review, this allows you to retroactively fix mistakes in old commits. This then means the reviewer won't need to wade through all kinds of "broken commit", "oops fixed this and that", "oops, another fix" commits; you can just roll it into one commit that clearly describes the thing you're trying to do. Of course, if you rebase a branch, you should clearly communicate to your teammates that this is YOUR branch, and will be rebased, because if you don't know that it will be rebased you will end up in a world of hurt, especially if other people are committing into that branch. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] small patch
Am 23.05.2015 um 16:45 schrieb Peter Bex: > On Fri, May 15, 2015 at 02:25:56PM +0200, "Jörg F. Wittenberger" wrote: >> Attached a small patch against origin/master. It's just to silence a >> valgrind warning. > > The patch looks good to me, except for the headers. See below. I agree with you that git is needlessly complicated. And stupidly retarded. Since the early '90 I've been using all sorts of version control. Most are at least superficially similar to each other. Git not. I could accept this IF it had a good reason. But it seems different for being different, not for being better. Personally I somewhat settled on fossil for small groups. Especially because it includes small little ticket tracking right with the repository. But these days the hipsters are so many. Larger groups just have to have git for the sake of social peace. >> More important: I'd like to eventually learn how to get this right using >> git. > > It looks like you forgot to configure your username and e-mail address > in git. It says "From: Benutzer ". You can > configure this through: > > git config --global user.name "blabla" > git config --global user.email bla...@example.com Thanks a lot! These are the kind of things I expected to miss. Helpful and smart as git is, it does somehow not really obey the "name" given in .gitconfig. I'll have to figure out. This time I manually edited the patch... > Please make a new commit using the correct author and send it, so that > we get the attribution right. attached >> (I actually checked this into git. But in the origin/master branch - >> fully aware that this would not be the right thing to do if I was to >> push my changes. However I expect myself at least to accidentally check >> things into the wrong branch and need to learn how to fix the mess.) > > You can do two things: either make an ad-hoc branch and commit it to that, > then delete it. Or you can simply commit to "master", use git format-patch > to create the patch, and then run "git reset --hard origin/master" to go > back to the original version you got from upstream (that's what I always do). I tried now to to have my own branch. Funny: I expected the branch name to appear somehow in the patch(headers), but that's not the case. Since that's not the case, I'll have to figure out how to create patches between arbitrary commits. Why? fossil can export/import whole repositories to/from git. Maybe it turns out to be simpler to actually work in fossil and just format-patch from git eventually. > You should not commit to origin/master, I'm not even sure if git allows you > to do that (but, since it's git it probably allows you to shoot yourself in > the foot that way). SURE it does! > The origin/master branch is for keeping track of the > state of the "master" branch at the remote "origin" (which is what you > initially cloned it from). This allows you to always go back to the state > we're on, like with the reset command I mentioned. You can also use it > to rebase your own changes so that they are moved at the end of that branch. > > Git is a stupidly retarded tool, and needlessly complicated. All the > hipsters seem to enjoy showing off how they mastered its complexity, but > don't let that drag you down. I found > http://nfarina.com/post/9868516270/git-is-simpler > to be very helpful in making sense of the mess that is git. Thanks for yet another text attempting to make sense of git (which has won - hand down - the competition for the best match between name and function). Though it appears to me to be more the details, which I did not yet understand. Like "which tag is supposed to track which purpose" (e.g., master, origin), how do I commit into a fresh branch, why the hell do I need the rebase concept at all? Thanks for your help and comments. /Jörg From 63e0f550f53eafba33e20b6b35fa0046f4beee98 Mon Sep 17 00:00:00 2001 From: Joerg F. Wittenberger Date: Tue, 26 May 2015 16:11:59 +0200 Subject: [PATCH] silence a valgrind warning about "count" being used without initialization --- runtime.c | 1 + 1 file changed, 1 insertion(+) diff --git a/runtime.c b/runtime.c index fb5d56c..adc464d 100644 --- a/runtime.c +++ b/runtime.c @@ -2782,6 +2782,7 @@ C_regparm void C_fcall C_reclaim(void *trampoline, void *proc) if(gc_mode == GC_REALLOC) { C_rereclaim2(percentage(heap_size, C_heap_growth), 0); gc_mode = GC_MAJOR; + count = (C_uword)tospace_top - (C_uword)tospace_start; goto i_like_spaghetti; } -- 2.1.4 signature.asc Description: OpenPGP digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] small patch
On Fri, May 15, 2015 at 02:25:56PM +0200, "Jörg F. Wittenberger" wrote: > Attached a small patch against origin/master. It's just to silence a > valgrind warning. The patch looks good to me, except for the headers. See below. > More important: I'd like to eventually learn how to get this right using > git. It looks like you forgot to configure your username and e-mail address in git. It says "From: Benutzer ". You can configure this through: git config --global user.name "blabla" git config --global user.email bla...@example.com Or you can edit ~/.gitconfig directly and add [user] name = blabla email = bla...@example.com You can also configure per-repository usernames if you need different names per project. In that case, just omit --global or use --local. Finally, you can do git commit --author = "blabla " if you want to commit using a particular name only once. Please make a new commit using the correct author and send it, so that we get the attribution right. > (I actually checked this into git. But in the origin/master branch - > fully aware that this would not be the right thing to do if I was to > push my changes. However I expect myself at least to accidentally check > things into the wrong branch and need to learn how to fix the mess.) You can do two things: either make an ad-hoc branch and commit it to that, then delete it. Or you can simply commit to "master", use git format-patch to create the patch, and then run "git reset --hard origin/master" to go back to the original version you got from upstream (that's what I always do). You should not commit to origin/master, I'm not even sure if git allows you to do that (but, since it's git it probably allows you to shoot yourself in the foot that way). The origin/master branch is for keeping track of the state of the "master" branch at the remote "origin" (which is what you initially cloned it from). This allows you to always go back to the state we're on, like with the reset command I mentioned. You can also use it to rebase your own changes so that they are moved at the end of that branch. Git is a stupidly retarded tool, and needlessly complicated. All the hipsters seem to enjoy showing off how they mastered its complexity, but don't let that drag you down. I found http://nfarina.com/post/9868516270/git-is-simpler to be very helpful in making sense of the mess that is git. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers