This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: GDB 7.6.90 available for testing


On 01/13/2014 06:27 PM, Eli Zaretskii wrote:
>> Date: Mon, 13 Jan 2014 17:51:32 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
>>
>> On 01/11/2014 08:55 AM, Eli Zaretskii wrote:
>>
>>>
>>> This is because of the "-I./../" part on the GCC command line.  My
>>> version of GCC doesn't like the trailing slash.
>>
>> Guessing that's an old gcc.
> 
> Your guess is correct.  (I also tried a newer GCC, and the problem
> never happened there.)  But I think that slash is the odd one out
> anyway: the other -I arguments don't have it.
> 
>>> OK to push the following (with a suitable log entry)?
>>
>> Sure.
> 
> Thanks.
> 
> As this will be my first push when we are branched, what are the
> procedures for that with git?  I'm guessing
> 
>   git checkout gdb-7.7-branch
>   (hack, hack)
>   git commit
>   git push

Yeah.

As a matter of principle, I prefer fixing master first though, and
then backport to any stable branches.  So that there's never a chance
of the branch getting a fix that's not in mainline (and so the
same bug could reappear in mainline later in the next release).
(You never know when you might be interrupted, and then forget to
merge a change.)

> Is that correct?  If so, what about doing the same on master -- should
> I merge it myself and then push, or are these merges handled in some
> other way by someone else?

You have to do it yourself.  I use stgit, so I just rebase my series
on top of master or whatever stable branch, and then push, but with
raw git, I'd use git cherry-pick.

Thanks,
-- 
Pedro Alves


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