>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
