[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] m_getfld() bug fix

From: Ken Hornstein
Subject: Re: [Nmh-workers] m_getfld() bug fix
Date: Thu, 05 Dec 2013 11:11:17 -0500

>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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]