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

Reply via email to