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 <u@utilite.localdomain>". 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