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, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 42.3 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers