Re: [Chicken-hackers] small patch

[Peter Bex]

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 <address@hidden>".  You can
> > configure this through:
> > 
> > git config --global user.name "blabla"
> > git config --global user.email address@hidden
> 
> 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