Hi Stefano, * Stefano Lattarini wrote on Sun, Jul 04, 2010 at 11:24:19PM CEST: > Hello Ralf, and sorry for taking so long to answer this.
don't worry. You have patches pending for longer, and they didn't end up in my spam folder (gah, wish I hadn't written that now ;-) > At Saturday 12 June 2010, Ralf Wildenhues wrote: > > Speaking of "OK to apply", would you prefer pushing approved > > patches yourself? If yes, please apply as project member on > > <http://savannah.gnu.org/project/memberlist.php?group=automake> > Done. > > so I can set the write bit for you. Done. Welcome aboard! You should be able to clone from the read-write URL now, or add that as new (push-able) remote to your existing repository. > Mmh.. I must admit that I'm a bit wary about the possibility of > having a full committer status, because that also entails the > possibility of messing up the *official* Automake repository with some > simple botched git command. Yes it does. But that is far less of a problem than with, say, CVS. There are several clones of this repository around from which a botch could be undone by pushing a non-forward, in the unusual case that should be necessary. Of course, such a thing should not be done lightly. > There is maybe some way to restrict committer status to e.g. certain > branches? That would be great. No. > In case that's not possible, there is maybe some git black magic to be > put in (say) the local .git/config or ~/.gitconfig, so that pushing is > allowed only against some (explicitly listed) remote branches? Not that I know of. I've made it a habit to use both gitk --all git push --dry-run in order to see what would happen, and if I intend to only change some branches, I use, e.g., git push --dry-run origin master and then remove the --dry-run if all looks good. You shouldn't push non-fast-forwards. I think the only viable exception to this should be security-related issues (where you've accidentally pushed before information that must not be public), but Automake is unlikely to deal with such. Now, I guess I will change habits a bit and let you push good patches as appropriate. When I write "OK for maint", then that implies that you may apply the patch on top of maint, and also that you may merge maint to branch-1.11 and to master whenever maint is not fully merged to them. Please let's not merge more often than necessary, i.e., it is enough to do it after a series of related patches, or at the end of a session. For merging to work reliably, you need the git-merge-changelog program from gnulib to be installed correctly, and your git repository adjusted so that it is used for the ChangeLog. See the documentation of the module. > > This change will require to weed out old > > topic branches every now and then, and in fact I think the > > following branches are ready to go: > > ad-parallel-tests > > dr-cscope > Not sure about this last one, as there still are some pending patches > of mine regarding the cscope functionality. Yep, agreed. > > The following are leftovers from the conversion from CVS, I'm > > reluctant to just remove them: > Why? No criticism here, just curious... Because I'm in general reluctant to remove information about work done by others in the past. I think at least the user-dep-gen-branch saw real development, and was merged to the main tree later (a bit of information which of course the CVS tree could not preserve), so it can help when debugging issues that relate to code added then. Such information has helped me pinpoint reasons for some code before, even when the original change was from the last millenium. > > master-UNNAMED-BRANCH > > master-UNNAMED-BRANCH-UNNAMED-BRANCH > > user-dep-gen-branch > > user-dep-gen-merge-branch Cheers, Ralf
