On 2010-12-15 at 12:32 +0000, David Woodhouse wrote:
> On Wed, 2010-12-15 at 03:21 -0500, Phil Pennock wrote:
> > Please audit http://git.exim.org/users/pdp/exim.git before I push those
> > changes to the master repo. I do not expect to make any more changes
> > tonight.
> >
> > David, if you +1 the changes, I'll push to master. If you don't want to
> > wait, just pull them in. I can believe that git will let you do that,
> > even if the master is bare, but I don't currently know how.
>
> I don't know why git would *not* let me do that. If I pull the commits
> into my tree...
That's pull to third party, then push to master, not pull to master, but
hey, it works.
> Except I didn't actually do the latter; I think the va_copy thing is
> better not compiling, since we have a report that it doesn't actually
> work. The whole point in va_copy being implementation-defined is that
> you can't assume it's a normal data structure.
Yes, your fix is better. Sorry for that code, it seemed sanest at the
time. <aside> 11 years since C99 and the content was known before that,
but we *still* can't rely on it. :( 10 years after ANSI C, I was
declaring that 10 years is enough and K&R compatibility could die.
</aside>
> We *possibly* need to do something about va_copy, and then we're fairly
> much ready to do a release candidate?
I think that Ian Jackson's suggestion, as forwarded by Andreas Metzler,
is a good one. People do edit files directly, instead of using SCM, so
we should filter out various config file name patterns. It's bad to
filter known-bad instead of only accepting known-good, but it's the most
reasonable thing we can do.
> Never rebase. Why would you try doing advanced stuff like that?
To join two patches into one, as you did with commit --amend; I didn't
realise that there was plumbing to effectively change the most recent
commit. My reading, over the past few months, has suggested that
rebasing is used to merge commits.
> > I recreated work, did more (more fiddly) work, discovered
> > why pushes to pdp-tahini were recovering the old work, switched to
> > master,
>
> That sounds like you might have made the mistake of trying to use
> branches, too? I also consider that to be advanced use of git, and
> mostly pointless. Don't do that.
I like to work on independent changes and not make them dependent on one
another, because when I had ~7 changes for Exim queued up in just the
"master" and I needed to commit all but one in the middle, I spent a lot
of frustrating time working around this.
But no, this wasn't me working with branches. This was a :cq from
editing for a rebase dumping me out into the detached HEAD state and my
not realising that I was no longer in the default single branch.
> > then was only able to recover my work because another terminal
> > window had { git log } in it so I could go back to that most recent
> > commit. { git reset --hard } was my friend, but appears to be the sort
> > of friend you meet in a dark alley and are always "cautious" about.
>
> :)
>
> --
> dwmw2
>
