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

[Paul Fox]

david wrote:
 > Paul wrote:
 ...
 > > 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.
 > 
 > Mistakes happen, especially when hacking certain areas.
 > 
 > As far as the test code goes, that's an artifact.  Lyndon's
 > buildbot picks up only changes to master so they've got to be
 > on it.  This doesn't happen often and is very clustered, such as
 > when a new platform is added to it.

ah -- that explains a lot.  i wondered if there was something i was
missing.

ken wrote:
 > 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 agree -- single developer temporary branches can be as messy as they
wish.

ken wrote:
 > The super short answer: you can rebase/amend all you want, AS LONG AS
 > YOU DON'T PUSH.  Once you've pushed a commit, you have to think of it
 > permamently and irrevocably published to the world.  You can push new
 > changes that fix problems in previous commits, you just can't rewrite
 > history once you've told everyone else about it.

yes, exactly this.

the other place "rebase" causes confusion is in the argument to
"git pull --rebase":

in that case, again, it's fine to use when you're pulling onto a
private branch (the usual case, pulling from an upstream repo).  using
--rebase in this case avoids a merge, and keeps your outstanding
un-pushed commits all together on the top of your development branch. 
the downside is loss of the true commit order.

but if you were pulling onto a public branch, you would NEVER use
--rebase.  this case won't normally happen with nmh development,
since there's only one public repo, and we all push to it.

paul
----------------------
 paul fox, address@hidden (arlington, ma, where it's 42.3 degrees)