Dear customer,
Many thanks for your time to reading this email !
We are producer of tungsten carbide wear parts for oil & gas industry for 16
years in Chengdu , China!
We supply :
Carbide balls and seats
Carbide wear sleeves , carbide bottom sleeves
Carbide tube for choke beans
On Thu, Jan 16, 2020 at 4:54 PM GT wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, January 15, 2020 3:20 PM, GT wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, January 9, 2020 8:42 AM, Richard Biener
> > richard.guent...@gmail.com wrote:
> >
> > > As for the other qu
> I think it's desirable for development that *happens on* the personal and
> vendor branches to be visible in gcc-cvs - that is different from things
> getting merged into them.
>
> Likewise for the refs/heads/devel/* development branches -
> non-fast-forward pushes are not permitted there, bu
> Unfortunately, that's not as simple to implement as I'd hoped, because
> git.py:git_run removes all leading and trailing whitespace from the output
> of the git command it runs, so the code checking commit messages can't
> tell whether there was whitespace at the start of the first line (or th
> A quick run of the testsuite reveals that this assumption is made
> all over. I am opposed to having this feature be a standard feature
> of the git-hooks, so you wouldn't have to add an ad hoc check.
> The way I would do it is by enhancing the git_run function to check
> for a parameter named "_
Joel Brobecker wrote:
I think it's desirable for development that *happens on* the personal and
vendor branches to be visible in gcc-cvs - that is different from things
getting merged into them.
Likewise for the refs/heads/devel/* development branches -
non-fast-forward pushes are not permitte
On Fri, 17 Jan 2020, Joel Brobecker wrote:
> Would it be sufficient to say that some branches would only
> trigger a summary email, but not individual commit emails?
Maybe that will end up being appropriate for users / vendors branches, if
we can't effectively distinguish rebased commits from ne
On Fri, 17 Jan 2020, Joel Brobecker wrote:
> Do open a GitHub issue if you'd like me to add this check to
> the git-hooks. I will likely give it less priority because
> you'll have a way to implement it on your on, but I will get to it
> eventually.
I think https://github.com/AdaCore/git-hooks/is
> AFAIU, we have access to more fine-grained information; isn’t it possible
> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> (because a ‘new’ commit does not have the extra fields set up for merges
> and rebases).
In my opinion, this would create a lot of complication for the
On 1/17/20 11:55 AM, Joel Brobecker wrote:
AFAIU, we have access to more fine-grained information; isn’t it possible
to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
(because a ‘new’ commit does not have the extra fields set up for merges
and rebases).
In my opinion, this wou
> > Would it be sufficient to say that some branches would only
> > trigger a summary email, but not individual commit emails?
>
> Maybe that will end up being appropriate for users / vendors branches, if
> we can't effectively distinguish rebased commits from new ones. But for
> shared fast-fo
> > > AFAIU, we have access to more fine-grained information; isn’t it possible
> > > to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> > > (because a ‘new’ commit does not have the extra fields set up for merges
> > > and rebases).
> >
> > In my opinion, this would create a lo
Joel Brobecker wrote:
AFAIU, we have access to more fine-grained information; isn’t it
possible
to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
(because a ‘new’ commit does not have the extra fields set up for merges
and rebases).
In my opinion, this would create a lot of
On 1/17/20 12:59 PM, Iain Sandoe wrote:
Joel Brobecker wrote:
AFAIU, we have access to more fine-grained information; isn’t it possible
to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
(because a ‘new’ commit does not have the extra fields set up for merges
and rebases).
In
On Fri, 17 Jan 2020, Joel Brobecker wrote:
> Also, you guys have to understand that you are all coming to me from
> multiple directions at the same time, and making requests that are
> not always easy to reconcile. I do completely understand that getting
The issues filed on GitHub are meant to he
Snapshot gcc-8-20200117 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
16 matches
Mail list logo
