* Re: Experimental branches [not found] <CAHACq4rzgyE-2cM=UV30-1MWKHsWqwF1QdtuAujgYzFJ=8Y08A@mail.gmail.com> @ 2014-12-23 13:27 ` Joel Brobecker 2014-12-23 17:38 ` Cary Coutant 0 siblings, 1 reply; 20+ messages in thread From: Joel Brobecker @ 2014-12-23 13:27 UTC (permalink / raw) To: Cary Coutant; +Cc: Binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 13:27 ` Experimental branches Joel Brobecker @ 2014-12-23 17:38 ` Cary Coutant 2014-12-23 17:42 ` H.J. Lu 0 siblings, 1 reply; 20+ messages in thread From: Cary Coutant @ 2014-12-23 17:38 UTC (permalink / raw) To: Joel Brobecker; +Cc: Binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 17:38 ` Cary Coutant @ 2014-12-23 17:42 ` H.J. Lu 2014-12-23 18:08 ` Joel Brobecker 0 siblings, 1 reply; 20+ messages in thread From: H.J. Lu @ 2014-12-23 17:42 UTC (permalink / raw) To: Cary Coutant; +Cc: Joel Brobecker, Binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 17:42 ` H.J. Lu @ 2014-12-23 18:08 ` Joel Brobecker 2014-12-23 18:21 ` Cary Coutant 0 siblings, 1 reply; 20+ messages in thread From: Joel Brobecker @ 2014-12-23 18:08 UTC (permalink / raw) To: H.J. Lu; +Cc: Cary Coutant, Binutils, gdb-patches > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 18:08 ` Joel Brobecker @ 2014-12-23 18:21 ` Cary Coutant 2014-12-23 18:26 ` H.J. Lu 0 siblings, 1 reply; 20+ messages in thread From: Cary Coutant @ 2014-12-23 18:21 UTC (permalink / raw) To: Joel Brobecker; +Cc: H.J. Lu, Binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 18:21 ` Cary Coutant @ 2014-12-23 18:26 ` H.J. Lu 2014-12-24 0:20 ` Joel Brobecker 0 siblings, 1 reply; 20+ messages in thread From: H.J. Lu @ 2014-12-23 18:26 UTC (permalink / raw) To: Cary Coutant; +Cc: Joel Brobecker, Binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-23 18:26 ` H.J. Lu @ 2014-12-24 0:20 ` Joel Brobecker 2015-01-15 21:56 ` Cary Coutant 0 siblings, 1 reply; 20+ messages in thread From: Joel Brobecker @ 2014-12-24 0:20 UTC (permalink / raw) To: H.J. Lu; +Cc: Cary Coutant, Binutils, gdb-patches > > So it'll be "user/<username>/<topic>", right? (As opposed to > > I prefer "user/<username>/<topic>". Works for me to! -- Joel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2014-12-24 0:20 ` Joel Brobecker @ 2015-01-15 21:56 ` Cary Coutant 2015-01-15 22:48 ` H.J. Lu 2015-01-15 23:57 ` Alan Modra 0 siblings, 2 replies; 20+ messages in thread From: Cary Coutant @ 2015-01-15 21:56 UTC (permalink / raw) To: Joel Brobecker; +Cc: H.J. Lu, Binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 21:56 ` Cary Coutant @ 2015-01-15 22:48 ` H.J. Lu 2015-01-15 23:04 ` Cary Coutant 2015-01-16 3:14 ` Joel Brobecker 2015-01-15 23:57 ` Alan Modra 1 sibling, 2 replies; 20+ messages in thread From: H.J. Lu @ 2015-01-15 22:48 UTC (permalink / raw) To: Cary Coutant; +Cc: Joel Brobecker, Binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 22:48 ` H.J. Lu @ 2015-01-15 23:04 ` Cary Coutant 2015-01-15 23:20 ` H.J. Lu 2015-01-16 18:41 ` Richard Henderson 2015-01-16 3:14 ` Joel Brobecker 1 sibling, 2 replies; 20+ messages in thread From: Cary Coutant @ 2015-01-15 23:04 UTC (permalink / raw) To: H.J. Lu; +Cc: Joel Brobecker, Binutils, gdb-patches >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 23:04 ` Cary Coutant @ 2015-01-15 23:20 ` H.J. Lu 2015-01-16 18:41 ` Richard Henderson 1 sibling, 0 replies; 20+ messages in thread From: H.J. Lu @ 2015-01-15 23:20 UTC (permalink / raw) To: Cary Coutant; +Cc: Joel Brobecker, Binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 23:04 ` Cary Coutant 2015-01-15 23:20 ` H.J. Lu @ 2015-01-16 18:41 ` Richard Henderson 2015-01-16 19:07 ` Cary Coutant 1 sibling, 1 reply; 20+ messages in thread From: Richard Henderson @ 2015-01-16 18:41 UTC (permalink / raw) To: Cary Coutant, H.J. Lu; +Cc: Joel Brobecker, Binutils, gdb-patches 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~ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-16 18:41 ` Richard Henderson @ 2015-01-16 19:07 ` Cary Coutant 2015-01-16 19:26 ` Doug Evans 0 siblings, 1 reply; 20+ messages in thread From: Cary Coutant @ 2015-01-16 19:07 UTC (permalink / raw) To: Richard Henderson; +Cc: H.J. Lu, Joel Brobecker, Binutils, gdb-patches >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-16 19:07 ` Cary Coutant @ 2015-01-16 19:26 ` Doug Evans 0 siblings, 0 replies; 20+ messages in thread From: Doug Evans @ 2015-01-16 19:26 UTC (permalink / raw) To: Cary Coutant Cc: Richard Henderson, H.J. Lu, Joel Brobecker, Binutils, gdb-patches 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 ...] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 22:48 ` H.J. Lu 2015-01-15 23:04 ` Cary Coutant @ 2015-01-16 3:14 ` Joel Brobecker 1 sibling, 0 replies; 20+ messages in thread From: Joel Brobecker @ 2015-01-16 3:14 UTC (permalink / raw) To: H.J. Lu; +Cc: Cary Coutant, Binutils, gdb-patches > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 21:56 ` Cary Coutant 2015-01-15 22:48 ` H.J. Lu @ 2015-01-15 23:57 ` Alan Modra 2015-01-16 3:19 ` Joel Brobecker 1 sibling, 1 reply; 20+ messages in thread From: Alan Modra @ 2015-01-15 23:57 UTC (permalink / raw) To: Joel Brobecker; +Cc: Binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-15 23:57 ` Alan Modra @ 2015-01-16 3:19 ` Joel Brobecker 2015-01-16 18:42 ` Richard Henderson 2015-01-17 3:24 ` Alan Modra 0 siblings, 2 replies; 20+ messages in thread From: Joel Brobecker @ 2015-01-16 3:19 UTC (permalink / raw) To: Binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-16 3:19 ` Joel Brobecker @ 2015-01-16 18:42 ` Richard Henderson 2015-01-17 4:17 ` Joel Brobecker 2015-01-17 3:24 ` Alan Modra 1 sibling, 1 reply; 20+ messages in thread From: Richard Henderson @ 2015-01-16 18:42 UTC (permalink / raw) To: Joel Brobecker, Binutils, gdb-patches 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~ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-16 18:42 ` Richard Henderson @ 2015-01-17 4:17 ` Joel Brobecker 0 siblings, 0 replies; 20+ messages in thread From: Joel Brobecker @ 2015-01-17 4:17 UTC (permalink / raw) To: Richard Henderson; +Cc: Binutils, gdb-patches > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Experimental branches 2015-01-16 3:19 ` Joel Brobecker 2015-01-16 18:42 ` Richard Henderson @ 2015-01-17 3:24 ` Alan Modra 1 sibling, 0 replies; 20+ messages in thread From: Alan Modra @ 2015-01-17 3:24 UTC (permalink / raw) To: Joel Brobecker; +Cc: Binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-01-17 4:17 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAHACq4rzgyE-2cM=UV30-1MWKHsWqwF1QdtuAujgYzFJ=8Y08A@mail.gmail.com> 2014-12-23 13:27 ` Experimental branches Joel Brobecker 2014-12-23 17:38 ` Cary Coutant 2014-12-23 17:42 ` H.J. Lu 2014-12-23 18:08 ` Joel Brobecker 2014-12-23 18:21 ` Cary Coutant 2014-12-23 18:26 ` H.J. Lu 2014-12-24 0:20 ` Joel Brobecker 2015-01-15 21:56 ` Cary Coutant 2015-01-15 22:48 ` H.J. Lu 2015-01-15 23:04 ` Cary Coutant 2015-01-15 23:20 ` H.J. Lu 2015-01-16 18:41 ` Richard Henderson 2015-01-16 19:07 ` Cary Coutant 2015-01-16 19:26 ` Doug Evans 2015-01-16 3:14 ` Joel Brobecker 2015-01-15 23:57 ` Alan Modra 2015-01-16 3:19 ` Joel Brobecker 2015-01-16 18:42 ` Richard Henderson 2015-01-17 4:17 ` Joel Brobecker 2015-01-17 3:24 ` Alan Modra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).