(To: Chris Cc: sawfish-list) Hi, Chris. I'm thinking of putting my branches on github, and I'd like to here your opinion.
It'd be good for me, if it goes like this: 1. I put my commits in github branch. 2. Tell you what's changed, and ask to merge to the master. 3. You pull in. 4. You say "Oh, Teika has did it again. I fix it." Hack, hack, hack. 5. Commit the fix. The problem is my patches quality. If you don't think they're good enough, then it'd be better to commit *once*, i.e, you prepare an improved patch, and commit it, rather than applying mine and overwrite it with yours. Thus, the log looks cleaner. On the other hand, overwrite-by-another-commit model reduces my labor, because I can use the same branch throughout. Currently, I dedicate one branch for one patch. After submission, the branch is thrown away. I'm a bit tired ;) I think my doc patches are not bad, but Chrislein, you can speak frankly. For difficult patches, I'll first ask in the wiki or ML, so I think it'll be mostly ok. If github is ok, then each time I'll explicitly ask you to merge, and tell you what's available. It must be better than periodical automatic merges. I'm aware of difference of natures between git commit log and ChangeLog. I'll send you ChangeLog portions by email as I do so today. (In another email, I asked about ChangeLog's life.) Tschüs, Teika (Teika kazura)
