[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pushing patches (was: [PATCH] Extend tests/README (trailing `:' in t
From: |
Stefano Lattarini |
Subject: |
Re: pushing patches (was: [PATCH] Extend tests/README (trailing `:' in test scripts)) |
Date: |
Sun, 4 Jul 2010 23:24:19 +0200 |
User-agent: |
KMail/1.12.1 (FreeBSD/8.0-RELEASE; KDE/4.3.1; i386; ; ) |
Hello Ralf, and sorry for taking so long to answer this.
In my defense, I can say that gmail put this message in Spam :-(, and
I haven't seen it until today (yeah, stupid me trusting gmail filter
so blindly). BTW, gmail marked as spam also the message "the branch
a patch is for (was: [PATCH] Testsuite: ensure verbose printing of
captured stderr.)", where you were referring to this one. Murphy hit
really hard here.
I'm really really sorry about this.
Now back to business...
At Saturday 12 June 2010, Ralf Wildenhues wrote:
> Hi Stefano,
>
> * Stefano Lattarini wrote on Fri, Jun 11, 2010 at 12:42:24PM CEST:
> > OK to apply this patch to tests/README? [...]
>
> 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.
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.
There is maybe some way to restrict committer status to e.g. certain
branches? That would be great.
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?
> I have been waiting with this step for quite a while, mainly
> because I wanted to gain some experience working with multiple,
> long-lived branches and getting a more-or-less coherent git
> workflow. The single-push integratory scheme of the last year or
> so works quite well for me, so I don't mind continuing that, since
> I pretty much apply all patches I review to my tree anyway. The
> bottle-neck is the reviewing, not the slurping of patches, thanks
> to git.
>
> If you prefer pushing, then I would push the pointer of my maint
> branch to the public repo as well, plus any other topic branches
> that are longer-lived.
Yes, I'd like that. This way a contributor can merge those branches
in his own remote ones, thus making the future merge of these personal
branches into the main ones easier.
> 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.
>
> This one we could revive, with some reasonable policy:
> next
>
> The vala and silent-rules support probably can see some more
> improvements at some point:
> je-silent
> mh-vala-support
>
> The following are leftovers from the conversion from CVS, I'm
> reluctant to just remove them:
Why? No criticism here, just curious...
> master-UNNAMED-BRANCH
> master-UNNAMED-BRANCH-UNNAMED-BRANCH
> user-dep-gen-branch
> user-dep-gen-merge-branch
>
Thanks, and again, please accept my apologies.
Regards,
Stefano
- Re: pushing patches (was: [PATCH] Extend tests/README (trailing `:' in test scripts)),
Stefano Lattarini <=