This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Experimental branches


> > 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
company-sponsored.

> > 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
scheme.

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.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]