this reminds me of a question: how likely is it that a checkout of
any arbitrary git commit will work well? skimming the logs, there's
what looks like a fair amount of "oops, didn't mean that", or "back
out test code" sort of stuff. i know that's what source control is
for, and git is inherently unstable -- but i'm running git from
a while ago, and am happy to upgrade with some regularity, but i'd
like a sense of whether i'm likely to hit the middle of development
churn.
That recent churn you've seen with those log messages is mostly one of
us interfacing with the buildbot; sometimes it's hard to see why the
buildbot is failing a regression test, so we have to add extra debugging
messages to figure out what is going wrong. Those are the ones I'm most
familiar with. In general, my personal feeling is that master should
always compile, pass the regression tests and generally "work", but
that's not a hard and fast rule.
Now, this is just on master. When I do a bunch of changes over time, I
use a branch (see the recent encode-rfc2047). On a branch, I regularly
commit stuff I know is incomplete or even completely broken. Sometimes
I do that because I want to move stuff between machines and it's easy to
use git as a transport mechanism; other times I want to document and/or
backup a significant amount of code I've worked on. I personally feel
branches are more free-form and you're free to have stuff that's busted.
That's just my personal style, though. Again, we don't have any hard
and fast rules here; I'm fine to let people use git however they want
as long as it doesn't impact people too much.
somewhat related: does everyone use git rebase before pushing? when
possible, i've found that rearranging/squashing my development commits
before pushing upstream (mainly using "git rebase --interactive") can
help reduce clutter and make for more concise changesets. folks are
probably doing this already, but thought i'd mention it just in case --
the ability to rearrange patches on private branches is one of git's
finest features.
Personally, I always use git rebase when pushing directly to master.
I don't when merging a branch, even though the encode-rfc2047 branch
had a lot of busted stuff in it. Three reasons I don't:
- It's a pain to do so; I mean, yeah, git rebase --interactive makes it
easier, but there were something like 40+ commits on that branch.
Figuring out which ones to squash would have been a pain. Also,
technically there were a number of commits on that branch that didn't
have anything to do with the RFC 2047 encoder; part of them was
documenting things I had found about the address parser, and I knew
adding them in master would make the merge harder later (I was changing
other things in the same section). Yeah, I could have cherry-picked
those across ... but why? I knew I was merging it soon. If we had
more developers or more churn in the tree I've be more vigilant.
- I like having the complete development history available.
- It makes tracking things with git bisect easier.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers