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, [email protected] (arlington, ma, where it's 42.3 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
