On Thu, 23 Jan 2020 at 23:15, Peter Bergner wrote:
>
> On 1/23/20 12:09 PM, Peter Bergner wrote:
> > On 1/23/20 4:29 AM, Jakub Jelinek wrote:
> >> so it is not a fast forward merge and we have the requirement that
> >> From-SVN: shouldn't appear in commit logs of new commits.
> >
> > So I just did
On 1/23/20 12:09 PM, Peter Bergner wrote:
> On 1/23/20 4:29 AM, Jakub Jelinek wrote:
>> so it is not a fast forward merge and we have the requirement that
>> From-SVN: shouldn't appear in commit logs of new commits.
>
> So I just did "git merge releases/gcc-9" into our branch and I'm not
> seeing
On 1/23/20 4:29 AM, Jakub Jelinek wrote:
> Just FYI if somebody needs to do something similar, I needed to do a merge
> from origin/releases/gcc-9 to our vendor branch -
> refs/vendors/redhat/heads/gcc-9-branch
> This branch has some extra commits origin/releases/gcc-9 branch doesn't
> have,
This
On Thu, 23 Jan 2020, Jakub Jelinek wrote:
> Just FYI if somebody needs to do something similar, I needed to do a merge
> from origin/releases/gcc-9 to our vendor branch -
> refs/vendors/redhat/heads/gcc-9-branch
> This branch has some extra commits origin/releases/gcc-9 branch doesn't
> have, so
Hi!
Just FYI if somebody needs to do something similar, I needed to do a merge
from origin/releases/gcc-9 to our vendor branch -
refs/vendors/redhat/heads/gcc-9-branch
This branch has some extra commits origin/releases/gcc-9 branch doesn't
have, so it is not a fast forward merge and we have the r
On Thu, Nov 12, 2009 at 01:23:30PM -0500, David Edelsohn wrote:
>
> Yes, more Graphite merges are planned. The VTA merge broke Graphite
> and we are waiting for Alexandre's recent VTA fixes for Graphite to be
> updated based on the initial feedback from Sebastian and merged
On Thu, Nov 12, 2009 at 12:03 PM, Jack Howarth wrote:
> Are there any plans for further merges out of the
> graphite branch before gcc 4.5 is branched? I was
> under the impression that the graphite developers
> originally intended to keep trunk more closely
> synchronized wi
Are there any plans for further merges out of the
graphite branch before gcc 4.5 is branched? I was
under the impression that the graphite developers
originally intended to keep trunk more closely
synchronized with the graphite branch during the
gcc 4.5 release cycle and this doesn't se
On 10/13/2009 12:09 PM, Dave Korn wrote:
Alas that doesn't prevent the conflicts, it just makes them "was removed on
trunk" rather than "was changed on trunk"! Well, that's what happened to me
anyway. It's a shame that svn doesn't have separate --accept types for files
and for properties, th
Richard Henderson wrote:
> Managing branches with svnmerge is nice and friendly. Certainly much
> easier than doing it by hand. However, when it comes time to integrate
> that branch into mainline, one must use more caution.
>
> If you use svnmerge on your branch, and then integrate the branch t
On 10/13/09 11:34, Richard Henderson wrote:
Managing branches with svnmerge is nice and friendly. Certainly much
easier than doing it by hand. However, when it comes time to
integrate that branch into mainline, one must use more caution.
If you use svnmerge on your branch, and then integrate
Managing branches with svnmerge is nice and friendly. Certainly much
easier than doing it by hand. However, when it comes time to integrate
that branch into mainline, one must use more caution.
If you use svnmerge on your branch, and then integrate the branch to
mainline with "svn merge" (as
On Mon, Oct 12, 2009 at 08:09:48AM -0700, Bingfeng Mei wrote:
> Richard,
> Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
> want to specify target-specific pragma? It becomes part of libbackend.a,
> which is linked to lto1. One solution I see is to put them into a separ
On 10/12/2009 08:09 AM, Bingfeng Mei wrote:
Richard,
Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
want to specify target-specific pragma? It becomes part of libbackend.a,
which is linked to lto1. One solution I see is to put them into a separate
file so the linker wo
when they are not
actually used by lto1.
Thanks,
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 12 October 2009 15:34
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Issues of the latest trunk with LTO merges
&g
On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei wrote:
> Hello,
> I ran into an issue with the LTO merges when updating to current trunk.
> The problem is that my target calls a few functions/uses some data structures
> in the gcc directory: c_language, paragma_lex, c_register_pragma,
Hello,
I ran into an issue with the LTO merges when updating to current trunk.
The problem is that my target calls a few functions/uses some data structures
in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
gcc -m32 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite
On 28/09/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
>
> Sorry, I still don't see where is the problem. You either want the
> extension in your branch, so you merge it and simply update libstdc++,
> or you don't want the extension just yet, so you just don't update
> libstdc++ (or update back
>
>
> Sorry, I still don't see where is the problem. You either want the
> extension in your branch, so you merge it and simply update libstdc++,
> or you don't want the extension just yet, so you just don't update
> libstdc++ (or update back to your previous revision).
That means you have to fol
On 27/09/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > Manuel López-Ibáñez wrote on 09/27/06 17:38:
> >
> > > Why? Perhaps I am entirely wrong but can't you just don't update (svn
> > > up) those directories that are switched until main
Manuel López-Ibáñez wrote on 09/27/06 18:50:
> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> Manuel López-Ibáñez wrote on 09/27/06 18:25:
>>> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>>>
If a pristine directory needs changes from the directory I branched, I'm
in
On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote on 09/27/06 18:25:
> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> If a pristine directory needs changes from the directory I branched, I'm
>> in trouble.
>>
>
> Why? Sorry, I think I don't understand wha
> Why? Perhaps I am entirely wrong but can't you just don't update (svn
> up) those directories that are switched until mainline is in an usable
> state?
That's only feasible if you're the only person working on that branch, and you
only ever use one checkout on one machine.
I guess you could us
>
> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > Manuel López-Ibáñez wrote on 09/27/06 17:38:
> >
> > > Why? Perhaps I am entirely wrong but can't you just don't update (svn
> > > up) those directories that are switched until mainline is in an usable
> > > state?
> > >
> > If a pri
Manuel López-Ibáñez wrote on 09/27/06 18:25:
> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> If a pristine directory needs changes from the directory I branched, I'm
>> in trouble.
>>
>
> Why? Sorry, I think I don't understand what you mean.
>
Say I branch gcc/gcc and keep all the run
On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote on 09/27/06 17:38:
> Why? Perhaps I am entirely wrong but can't you just don't update (svn
> up) those directories that are switched until mainline is in an usable
> state?
>
If a pristine directory needs changes fro
Manuel López-Ibáñez wrote on 09/27/06 17:38:
> Why? Perhaps I am entirely wrong but can't you just don't update (svn
> up) those directories that are switched until mainline is in an usable
> state?
>
If a pristine directory needs changes from the directory I branched, I'm
in trouble.
On 27/09/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 9/27/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote on 09/27/06 16:37:
>
> > If you are just writing a new pass, you can probably get away with
> > branching only a few files, and switching those may be a lot better
> >
On Wednesday 27 September 2006 21:37, Daniel Berlin wrote:
> I see occasional complaints about the size of mainline merges to
> branches Most people working on branches are only modifying a very
> small subset of the files that are in mainline, and certainly not the
> entire trun
ranch to modify 6 files
> in the gcc dir.
>
But this means that I'm at the mercy of mainline random breakage, right?
Yes
Most of the time I would rather do controlled merges when I know
mainline is in a usable state.
Some of us like to live on the edge.
Seriously though, it's a
ans that I'm at the mercy of mainline random breakage, right?
Most of the time I would rather do controlled merges when I know
mainline is in a usable state.
I see occasional complaints about the size of mainline merges to
branches Most people working on branches are only modifying a very
small subset of the files that are in mainline, and certainly not the
entire trunk tree.
You guys should be aware that you can simply branch those files you
want
single commit to fix a
particular bug (or a set of closely related bugs). Plain merges from
other branches should just say what branch, perhaps revisions were merged.
I agree. Long log messages might be useful for a revision, but not for
all the bugs affected -
if the commit message is larger
ly need them at least for release branches...
Yes. I think they are useful for all branches if you backport a patch for
a particular fix or e.g. fix something that is not yet fixed on the trunk
and will be only when a particular devel branch with that fix is merged
into trunk. But in all cases that
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>> mysql> delete from longdescs where length(thetext) > 100;
>> Query OK, 251 rows affected (2 min 12.11 sec)
>
> Thank you.
>
>> I may just set up a pre-commit hook to check the log message length and
>> hav eit not let you commit if it's ridiculousl
Daniel Berlin wrote:
mysql> delete from longdescs where length(thetext) > 100;
Query OK, 251 rows affected (2 min 12.11 sec)
Thank you.
I may just set up a pre-commit hook to check the log message length and
hav eit not let you commit if it's ridiculously large.
Maybe checkins on a bran
On Thu, 2006-01-12 at 00:55 +0100, Bernd Schmidt wrote:
> Daniel Berlin wrote:
> > On Wed, 11 Jan 2006, Bernd Schmidt wrote:
> >> The merge script relies only on the svnmerge-integrated property, not
> >> on the commit messages?
> >
> >
> > Right.
> >
> > It's just trying to generate a nice mes
Daniel Berlin wrote:
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
The merge script relies only on the svnmerge-integrated property, not
on the commit messages?
Right.
It's just trying to generate a nice message for you, but in our world,
the messages are so huge as to be useless.
I've fixed
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
Joern RENNECKE wrote:
Your merges are spamming the bugzilla database and anybody who is on the CC
list of the affected bugs.
both 20470 and 19199 got 1.2 Megabytes of ChangeLog.
Argh. That's a side effect of the merge script I wasn't
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
Giovanni Bajo wrote:
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
Your merges are spamming the bugzilla database and anybody who is on
the CC list of the affected bugs.
both 20470 and 19199 got 1.2 Megabytes of ChangeLog.
Argh. That's a
40 matches
Mail list logo
