Re: Experimental branches

Re: Experimental branches

[Joel Brobecker]

> I'd like to create an experimental branch for two-level line number
> tables in DWARF:
> 
>    http://wiki.dwarfstd.org/index.php?title=TwoLevelLineTables
> 
> What are the protocols? Do I just create a branch with my username as
> a prefix and push it?

Actually, let's discuss of a naming scheme real quick first.

Not sure if you know, but I am working on replacing the scripts
we currently use (mostly to send emails and update bugzilla, +IRC).
And one of the things we'll be able to do is decide which branches
trigger no emails.

I'd like thirdparty branches to be under a certain namespace,
so as to be able to disable a number of features for all third-party
branches, on of them being email notifications, bugzilla, and IRC
notifications.

So, what do people think of using "topic/<username>/"?

-- 
Joel

Re: Experimental branches

[Cary Coutant]

> I'd like thirdparty branches to be under a certain namespace,
> so as to be able to disable a number of features for all third-party
> branches, on of them being email notifications, bugzilla, and IRC
> notifications.
>
> So, what do people think of using "topic/<username>/"?

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.

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?

-cary

Re: Experimental branches

[H.J. Lu]

On Tue, Dec 23, 2014 at 9:38 AM, Cary Coutant <ccoutant@google.com> wrote:
>> I'd like thirdparty branches to be under a certain namespace,
>> so as to be able to disable a number of features for all third-party
>> branches, on of them being email notifications, bugzilla, and IRC
>> notifications.
>>
>> So, what do people think of using "topic/<username>/"?
>
> 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".

> 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

-- 
H.J.

Re: Experimental branches

[Joel Brobecker]

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

Re: Experimental branches

[Cary Coutant]

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

Sounds good to me.

So it'll be "user/<username>/<topic>", right? (As opposed to
"user/<username>-<topic>" or "user/<username>_<topic>".) And no need
to put "-branch" at the end of the branch name?

-cary

Re: Experimental branches

[H.J. Lu]

On Tue, Dec 23, 2014 at 10:21 AM, Cary Coutant <ccoutant@google.com> wrote:
>> 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.
>
> Sounds good to me.
>
> So it'll be "user/<username>/<topic>", right? (As opposed to

I prefer "user/<username>/<topic>".

> "user/<username>-<topic>" or "user/<username>_<topic>".) And no need
> to put "-branch" at the end of the branch name?

I don't think "-branch" is necessary.


-- 
H.J.

Re: Experimental branches

[Joel Brobecker]

> > So it'll be "user/<username>/<topic>", right? (As opposed to
> 
> I prefer "user/<username>/<topic>".

Works for me to!

-- 
Joel

Re: Experimental branches

[Cary Coutant]

On my experimental branch, I did "git merge master", then tried to
push. I got this:

remote: *** This update introduces too many new commits (136), which would
remote: *** trigger as many emails, exceeding the current limit (100).
remote: *** Contact your repository adminstrator if you really meant
remote: *** to generate this many commit emails.
remote: error: hook declined to update
refs/heads/users/ccoutant/two-level-line-tables

Clearly, I don't want to generate all those commit emails. What do I do instead?

-cary

Re: Experimental branches

[H.J. Lu]

On Thu, Jan 15, 2015 at 1:56 PM, Cary Coutant <ccoutant@google.com> wrote:
> On my experimental branch, I did "git merge master", then tried to
> push. I got this:
>
> remote: *** This update introduces too many new commits (136), which would
> remote: *** trigger as many emails, exceeding the current limit (100).
> remote: *** Contact your repository adminstrator if you really meant
> remote: *** to generate this many commit emails.
> remote: error: hook declined to update
> refs/heads/users/ccoutant/two-level-line-tables
>
> Clearly, I don't want to generate all those commit emails. What do I do instead?
>

Can you do a rebase first?


-- 
H.J.

Re: Experimental branches

[Cary Coutant]

>> On my experimental branch, I did "git merge master", then tried to
>> push. I got this:
>>
>> remote: *** This update introduces too many new commits (136), which would
>> remote: *** trigger as many emails, exceeding the current limit (100).
>> remote: *** Contact your repository adminstrator if you really meant
>> remote: *** to generate this many commit emails.
>> remote: error: hook declined to update
>> refs/heads/users/ccoutant/two-level-line-tables
>>
>> Clearly, I don't want to generate all those commit emails. What do I do instead?
>>
>
> Can you do a rebase first?

But I've already pushed several commits onto the upstream branch.
Everything I've read about git says don't rebase if you've already
pushed your branch upstream.

-cary

Re: Experimental branches

[H.J. Lu]

On Thu, Jan 15, 2015 at 3:04 PM, Cary Coutant <ccoutant@google.com> wrote:
>>> On my experimental branch, I did "git merge master", then tried to
>>> push. I got this:
>>>
>>> remote: *** This update introduces too many new commits (136), which would
>>> remote: *** trigger as many emails, exceeding the current limit (100).
>>> remote: *** Contact your repository adminstrator if you really meant
>>> remote: *** to generate this many commit emails.
>>> remote: error: hook declined to update
>>> refs/heads/users/ccoutant/two-level-line-tables
>>>
>>> Clearly, I don't want to generate all those commit emails. What do I do instead?
>>>
>>
>> Can you do a rebase first?
>
> But I've already pushed several commits onto the upstream branch.
> Everything I've read about git says don't rebase if you've already
> pushed your branch upstream.
>

I use rebase to keep commit delta small on

https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/pie

After my patch is checked in, rebase will just drop
the same one on my branch.

[hjl@gnu-18 gcc]$ git status
On branch hjl/pie
Your branch is up-to-date with 'origin/hjl/pie'.
nothing to commit, working directory clean
[hjl@gnu-18 gcc]$ git fetch
Enter passphrase for key '/export/home/hjl/.ssh/id_dsa':
remote: Counting objects: 1569, done.
remote: Compressing objects: 100% (747/747), done.
remote: Total 875 (delta 559), reused 307 (delta 117)
Receiving objects: 100% (875/875), 407.12 KiB | 0 bytes/s, done.
Resolving deltas: 100% (559/559), completed with 257 local objects.
From ssh://gcc.gnu.org/git/gcc
   b6782dd..368115c  gcc-4_8-branch -> origin/gcc-4_8-branch
   3147a27..2fc732e  gcc-4_9-branch -> origin/gcc-4_9-branch
   d53441c..32cf702  master     -> origin/master
   d53441c..32cf702  trunk      -> origin/trunk
[hjl@gnu-18 gcc]$ git rebase origin/master
First, rewinding head to replay your work on top of it...
Applying: Add --enable-default-pie
Applying: Support ENABLE_DEFAULT_PIE in gcc driver
Applying: Update GNU_USER_TARGET_STARTFILE_SPEC
Applying: Compile GCC with -fno-PIE and link with -no-pie
Applying: Don't use -fPIE when compiling crtbegin/end
Applying: Add -no-pie to TOOLS_LIBS for Ada
Applying: Document -no-pie
Applying: Document --enable-default-pie
Applying: Ignore additional messages on Linux/x86 with PIE
Using index info to reconstruct a base tree...
M gcc/testsuite/g++.dg/other/anon5.C
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
[hjl@gnu-18 gcc]$ git push origin :hjl/pie
Enter passphrase for key '/export/home/hjl/.ssh/id_dsa':
To ssh://hjl@gcc.gnu.org/git/gcc.git
 - [deleted]         hjl/pie
[hjl@gnu-18 gcc]$ git push -u origin hjl/pie
Enter passphrase for key '/export/home/hjl/.ssh/id_dsa':
Counting objects: 46, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (36/36), done.
Writing objects: 100% (46/46), 6.02 KiB | 0 bytes/s, done.
Total 46 (delta 38), reused 10 (delta 10)
To ssh://hjl@gcc.gnu.org/git/gcc.git
 * [new branch]      hjl/pie -> hjl/pie
Branch hjl/pie set up to track remote branch hjl/pie from origin.
[hjl@gnu-18 gcc]$

I use merge when I need each merge point on my branch:

https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/hjl/linux/master

-- 
H.J.

Re: Experimental branches

[Richard Henderson]

On 01/15/2015 03:04 PM, Cary Coutant wrote:
> But I've already pushed several commits onto the upstream branch.
> Everything I've read about git says don't rebase if you've already
> pushed your branch upstream.

That's if you've actually got multiple developers coordinating.

For solo development on branches, rebasing minimizes the state
difference between trunk and the branch, and so is quite handy
(essential?) for preparing to submit a patch set for review.


r~

Re: Experimental branches

[Cary Coutant]

>> But I've already pushed several commits onto the upstream branch.
>> Everything I've read about git says don't rebase if you've already
>> pushed your branch upstream.
>
> That's if you've actually got multiple developers coordinating.
>
> For solo development on branches, rebasing minimizes the state
> difference between trunk and the branch, and so is quite handy
> (essential?) for preparing to submit a patch set for review.

Yes. I already had a collaborator pull from my branch, and I didn't
want to disrupt him.

-cary

Re: Experimental branches

[Doug Evans]

On Fri, Jan 16, 2015 at 11:07 AM, Cary Coutant <ccoutant@google.com> wrote:
>>> But I've already pushed several commits onto the upstream branch.
>>> Everything I've read about git says don't rebase if you've already
>>> pushed your branch upstream.
>>
>> That's if you've actually got multiple developers coordinating.
>>
>> For solo development on branches, rebasing minimizes the state
>> difference between trunk and the branch, and so is quite handy
>> (essential?) for preparing to submit a patch set for review.
>
> Yes. I already had a collaborator pull from my branch, and I didn't
> want to disrupt him.

Don't worry about me! :-)

I know git well enough now to cope.

[Which isn't to dismiss your point, which is valid,
but if it's just me ...]

Re: Experimental branches

[Joel Brobecker]

> > On my experimental branch, I did "git merge master", then tried to
> > push. I got this:
> >
> > remote: *** This update introduces too many new commits (136), which would
> > remote: *** trigger as many emails, exceeding the current limit (100).
> > remote: *** Contact your repository adminstrator if you really meant
> > remote: *** to generate this many commit emails.
> > remote: error: hook declined to update
> > refs/heads/users/ccoutant/two-level-line-tables
> >
> > Clearly, I don't want to generate all those commit emails. What do I do instead?
> 
> Can you do a rebase first?

Sorry - it's not about rebase vs merge, but rather the fact that
there was a small error in the configuration that caused the hooks
to think there should be email notifications for commits on those
branches (extra '/' at the start of the reference regexp). Now fixed,
can you try it again? It should display a small message confirming
that hooks.noemail config is set for your branch and that commit
emails will not be sent.

-- 
Joel

Re: Experimental branches

[Alan Modra]

On Thu, Jan 15, 2015 at 01:56:51PM -0800, Cary Coutant wrote:
> On my experimental branch, I did "git merge master", then tried to
> push. I got this:
> 
> remote: *** This update introduces too many new commits (136), which would
> remote: *** trigger as many emails, exceeding the current limit (100).
> remote: *** Contact your repository adminstrator if you really meant
> remote: *** to generate this many commit emails.
> remote: error: hook declined to update
> refs/heads/users/ccoutant/two-level-line-tables
> 
> Clearly, I don't want to generate all those commit emails. What do I do instead?

Joel, can you turn off emails on all users branches?
See https://sourceware.org/ml/binutils-cvs/2015-01/
I don't think these emails are very useful.

We also seem to be getting a full diff on binutils-cvs rather than the
summary we used to have.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Experimental branches

[Joel Brobecker]

> Joel, can you turn off emails on all users branches?
> See https://sourceware.org/ml/binutils-cvs/2015-01/
> I don't think these emails are very useful.

That was the plan; just a configuration typo.

> We also seem to be getting a full diff on binutils-cvs rather than the
> summary we used to have.

That one is actually intentional. I really think that those diffs
are really useful - at least to me - and this was discussed a bit
when I made the proposal to switch to the new hooks. Do you think
they are a problem?

-- 
Joel

Re: Experimental branches

[Richard Henderson]

On 01/15/2015 07:18 PM, Joel Brobecker wrote:
>> We also seem to be getting a full diff on binutils-cvs rather than the
>> summary we used to have.
> 
> That one is actually intentional. I really think that those diffs
> are really useful - at least to me - and this was discussed a bit
> when I made the proposal to switch to the new hooks. Do you think
> they are a problem?

Are they really useful?  There's always the link at the top of the
commit email that allows you to view the diff.


r~

Re: Experimental branches

[Joel Brobecker]

> > That one is actually intentional. I really think that those diffs
> > are really useful - at least to me - and this was discussed a bit
> > when I made the proposal to switch to the new hooks. Do you think
> > they are a problem?
> 
> Are they really useful?  There's always the link at the top of the
> commit email that allows you to view the diff.

I can only speak personally, but I think they are. I usually take
a glance at the diffs that actually went in, and I've been catching
a few little things here and there. Having to click on links makes that
clunky enough that I just don't do it; this is compounded by the fact
that I use a text-based mail-reader. I'm also regularly offline as well
when reading emails (which I have downloaded onto my computer). Having
the diff in the email is also the difference between looking at it and
not.

Despite all that, I do not have a necessarily strong opinion about
this. Unless we actually find that the diffs are causing trouble,
I'd like to give the diffs a try. But if people want to go back,
then I'll make that happen.

-- 
Joel

Re: Experimental branches

[Alan Modra]

On Fri, Jan 16, 2015 at 07:18:11AM +0400, Joel Brobecker wrote:
> > We also seem to be getting a full diff on binutils-cvs rather than the
> > summary we used to have.
> 
> That one is actually intentional. I really think that those diffs
> are really useful - at least to me - and this was discussed a bit
> when I made the proposal to switch to the new hooks. Do you think
> they are a problem?

Not a problem, just not terribly useful.  Patches are supposed to be
posted to binutils (hi Nick!) before or when committing so why
duplicate the diff on binutils-cvs?

-- 
Alan Modra
Australia Development Lab, IBM