This is the mail archive of the
mailing list for the binutils project.
Re: Experimental branches
- From: Joel Brobecker <brobecker at adacore dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 23 Dec 2014 13:08:02 -0500
- Subject: Re: Experimental branches
- Authentication-results: sourceware.org; auth=none
- References: <CAHACq4rzgyE-2cM=UV30-1MWKHsWqwF1QdtuAujgYzFJ=8Y08A at mail dot gmail dot com> <20141223132714 dot GA11973 at adacore dot com> <CAHACq4qPSC6YX_uAcT0n35QD61LxATcKhjG0BXQ-qRhQ+GU63A at mail dot gmail dot com> <CAMe9rOqGKgd2gF6FLEAO4JQuDzyQJ8DXw94eE3ckO=ZiEep+SA at mail dot gmail dot com>
> > Sounds good to me. At the risk of bikeshedding, "topic" sounds too
> > general to me -- how about "com" for company-sponsored branches (e.g.,
> > com/google/...") and "user" for individuals (e.g.,
> > "user/ccoutant/...")? Or "experimental"? But I'm OK with whatever you
> > decide.
> I like "user" or "users".
Let's go for "user/", if people are OK with that.
I'd rather not have multiple namespaces in this case, since it doesn't
really make much of a difference to us whether it's personal or
> > That ship may already have sailed, though -- there are already quite a
> > few personal branches, some "<username>[-_]<topic>[-_]branch", some
> > "<username>/<topic>". Would it be easier to whitelist a few patterns
> > for branches that you *do* want those notifications for?
> We can rename a branch with:
> # git branch -m hjl/pr17729 user/hjl/pr17729
> # git push origin :hjl/pr17729
> # git push -u origin user/hjl/pr17729
Agreed, let's rename the active branches once we agree on the naming
I would revert the order of the last two commands, so that you first
add the new branch as a copy of the old, and then delete the old branch.
>From an email notification perspective, it makes a difference because,
when you add the new branch, the commits are "pre-existing" and therefore
trigger no email for the commit. Just one email for the new branch.