Jonathan Wakely writes:
> On Tue, 25 Oct 2022 at 13:23, Gaius Mulley via Gcc wrote:
>>
>>
>> Just wondering what is the safest way to delete a user branch?
>>
>> [I used ./contrib/git-add-user-branch.sh and wanted to start over
>> (user branch for m2 and gcc12)],
>
> When you say start over, do
On Tue, 25 Oct 2022 at 13:23, Gaius Mulley via Gcc wrote:
>
>
> Just wondering what is the safest way to delete a user branch?
>
> [I used ./contrib/git-add-user-branch.sh and wanted to start over
> (user branch for m2 and gcc12)],
When you say start over, do you mean reuse the same branch name
Just wondering what is the safest way to delete a user branch?
[I used ./contrib/git-add-user-branch.sh and wanted to start over
(user branch for m2 and gcc12)],
many thanks,
Gaius
Hi,
Don't use git gcc-verify for development branches or user branches,
it checks the rules required for release branches and the trunk only.
Other branches have different rules.
Thanks to everybody for their help.
I have now pushed the merge to the branch successfully. I'm glad
that the par
On Wed, Oct 28, 2020 at 06:53:35PM +0100, Thomas Koenig via Gcc wrote:
> I tried to update the coarray_native branch to current master with
> "git merge master" as given by
>
> https://gcc.gnu.org/gitwrite.html#branches
>
> That worked without any error message.
>
> Next, I tried to verify that
Thomas Koenig via Gcc wrote:
I tried to update the coarray_native branch to current master with
"git merge master" as given by
https://gcc.gnu.org/gitwrite.html#branches
That worked without any error message.
Next, I tried to verify that a "git push" would succeed, and
got an error:
$ git g
Hi Thomas,
at work we usually do not merge master back into a dev branch, but use 'git
rebase -i master'. This will so to say stash any commits on the dev-branch,
i.e. roll it back, then apply all changes of master and then apply the
stashed changes again. This should allow to bypass any server s
I tried to update the coarray_native branch to current master with
"git merge master" as given by
https://gcc.gnu.org/gitwrite.html#branches
That worked without any error message.
Next, I tried to verify that a "git push" would succeed, and
got an error:
$ git gcc-verify
Checking bf6dad60c338a
On 6/2/20 11:01 AM, Jakub Jelinek wrote:
On Tue, Jun 02, 2020 at 10:53:57AM +0200, Richard Biener wrote:
On Mon, Jun 1, 2020 at 2:17 PM Thomas Koenig via Fortran
wrote:
Hi Martin,
For now, I would recommend doing 1:1 backports. Otherwise, you'll need
to merge
all ChangeLog entries in a form
On Tue, Jun 02, 2020 at 10:53:57AM +0200, Richard Biener wrote:
> On Mon, Jun 1, 2020 at 2:17 PM Thomas Koenig via Fortran
> wrote:
> >
> > Hi Martin,
> >
> > > For now, I would recommend doing 1:1 backports. Otherwise, you'll need
> > > to merge
> > > all ChangeLog entries in a format the server
On Mon, Jun 1, 2020 at 2:17 PM Thomas Koenig via Fortran
wrote:
>
> Hi Martin,
>
> > For now, I would recommend doing 1:1 backports. Otherwise, you'll need
> > to merge
> > all ChangeLog entries in a format the server hook accepts. That can
> > require some
> > work.
>
> If the first commit caused
On Jun 01 2020, Jonathan Wakely via Fortran wrote:
> On Mon, 1 Jun 2020 at 13:25, Thomas Koenig wrote:
>>
>> Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
>> > It will only "keep" it for a matter of seconds, between that
>> > backported commit and the backported fix. And unless you push t
Jonathan Wakely via Gcc wrote:
On Mon, 1 Jun 2020 at 13:25, Thomas Koenig wrote:
Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
It will only "keep" it for a matter of seconds, between that
backported commit and the backported fix. And unless you push the
first commit before pushing th
On Mon, 1 Jun 2020 at 13:25, Thomas Koenig wrote:
>
> Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
> > It will only "keep" it for a matter of seconds, between that
> > backported commit and the backported fix. And unless you push the
> > first commit before pushing the fix, nobody will ev
Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
It will only "keep" it for a matter of seconds, between that
backported commit and the backported fix. And unless you push the
first commit before pushing the fix, nobody will ever see the
regression without also seeing the fix (unless they sp
On Mon, 1 Jun 2020 at 12:56, Thomas Koenig wrote:
>
> Hi Martin,
>
> > For now, I would recommend doing 1:1 backports. Otherwise, you'll need
> > to merge
> > all ChangeLog entries in a format the server hook accepts. That can
> > require some
> > work.
>
> If the first commit caused a regression,
Hi Martin,
For now, I would recommend doing 1:1 backports. Otherwise, you'll need
to merge
all ChangeLog entries in a format the server hook accepts. That can
require some
work.
If the first commit caused a regression, which the second one fixed,
this would keep the first regression, right?
On 5/30/20 11:38 PM, Jakub Jelinek via Gcc wrote:
On Sat, May 30, 2020 at 09:35:05PM +0100, Jonathan Wakely via Gcc wrote:
On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
Dear experts,
let's assume I need to backport a series of commits on master to a release
branch.
In the release branc
On Sat, May 30, 2020 at 09:35:05PM +0100, Jonathan Wakely via Gcc wrote:
> On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
> >
> > Dear experts,
> >
> > let's assume I need to backport a series of commits on master to a release
> > branch.
> > In the release branch, this series of commits shou
On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
>
> Dear experts,
>
> let's assume I need to backport a series of commits on master to a release
> branch.
> In the release branch, this series of commits should become a single commit.
>
> With bare git, there is "cherry-pick -n" that seems to b
Dear experts,
let's assume I need to backport a series of commits on master to a release
branch.
In the release branch, this series of commits should become a single commit.
With bare git, there is "cherry-pick -n" that seems to be applicable.
What is the right way to do it for gcc?
Thanks,
Ha
Hi Andreas,
git is not doing a plain patch, it is doing a merge. It is not unusual
for a merge to have changes that are already present on both sides.
... which just goes to show that it is very easy to make a fool of
yourself with git if you have no mental model of what it does.
That's not n
On Mai 21 2020, Thomas Koenig wrote:
> Obviously, reverting the already applied patch was a no-op.
Obviously not, since the first revert was partial only.
> I would assume that git noticed that, and could issue a message
> like "applying diff to foo.c failed". patch(1) manages it.
git is not do
Am 21.05.20 um 13:05 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig wrote:
An error message or warning from git might have been nice, though.
How can it know?
Obviously, reverting the already applied patch was a no-op.
I would assume that git noticed that, and could issue a message
l
On Mai 21 2020, Thomas Koenig wrote:
> An error message or warning from git might have been nice, though.
How can it know?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Am 21.05.20 um 11:45 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig via Gcc wrote:
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is even
less wa
On Mai 21 2020, Thomas Koenig via Gcc wrote:
> $ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
>
> on origin/releases/gcc-9, and now only the ChangeLog entries reversed
> (which is not wanted), but the code is unchanged (which is even
> less wanted).
You are trying to revert a comm
What is the current established way of reverting a patch, with
the current state of the tools?
I did
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is ev
On Thu, Jan 16, 2020 at 07:51:37PM +0100, Gerald Pfeifer wrote:
> It turns out I fumbled the commit message on the commit below to wwwdocs.
>
> Instead of
> Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
> I committed this with a message of
> Redirect cvs.html to git.h
It turns out I fumbled the commit message on the commit below to wwwdocs.
Instead of
Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
I committed this with a message of
Redirect cvs.html to git.html instead of svn.html.
and pushed already.
In CVS I could manually edit t
Jonathan Wakely writes:
> On Wed, 15 Jan 2020 at 11:21, Gaius Mulley wrote:
>>
>> Andrew Pinski writes:
>>
>> >
>> > One thing which you could do is kinda of what glibc did when they
>> > merged glibc and glibc-ports.
>> > Really it would useful if you get GM2 into the base sources of gcc
>> >
On Wed, 15 Jan 2020 at 11:21, Gaius Mulley wrote:
>
> Andrew Pinski writes:
>
> >
> > One thing which you could do is kinda of what glibc did when they
> > merged glibc and glibc-ports.
> > Really it would useful if you get GM2 into the base sources of gcc
> > instead for GCC 11 :).
>
> Hello,
>
Andrew Pinski writes:
>
> One thing which you could do is kinda of what glibc did when they
> merged glibc and glibc-ports.
> Really it would useful if you get GM2 into the base sources of gcc
> instead for GCC 11 :).
Hello,
yes indeed this is a huge priority for gm2 - all the big issues are
re
Jonathan Wakely writes:
> Is there a reason you can't just make it a branch of the GCC repo?
>
> It would mean you need to merge from upstream GCC into your repo,
> rather than just dropping your repo into/onto a GCC clone, but to me
> it seems the more natural solution. The modifications to the
On Wed, Jan 15, 2020 at 2:14 AM Gaius Mulley wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro. When gcc was using s
On 15/01/2020 10:13, Gaius Mulley wrote:
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro. When gcc was using subversion I
On Wed, 15 Jan 2020 at 10:14, Gaius Mulley wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro. When gcc was using sub
Hello,
Firstly many thanks to all who have worked on the git migration and also
for the offer of help :-)
I'm seeking a little advice on an efficient way to combine the gm2 git
repro with the gcc git repro. When gcc was using subversion I had a
script which untared the gm2 git over the subvers
Thomas Rodgers writes:
> I am also happy to help
>
rodgertq on freenode and oftc
> Jonathan Wakely writes:
>
>> I imagine a lot of people are going to feel lost in the first few
>> weeks of using Git.
>>
>> If you are stuck or confused about using Git for GCC development and
>> too embarrassed
I am also happy to help
Jonathan Wakely writes:
> I imagine a lot of people are going to feel lost in the first few
> weeks of using Git.
>
> If you are stuck or confused about using Git for GCC development and
> too embarrassed to ask in public, feel free to contact me on IRC. I'm
> jwakely on O
Paul Smith writes:
> On Mon, 2020-01-13 at 11:33 +, Jonathan Wakely wrote:
>> I imagine a lot of people are going to feel lost in the first few
>> weeks of using Git.
>
> I don't do IRC (and I'm not a GCC dev :)) but I'm happy to help via email.
>
> One thing I'll say though: if you're an Em
On 1/13/20 10:58 AM, Andreas Schwab wrote:
On Jan 13 2020, Jason Merrill wrote:
On Mon, Jan 13, 2020 at 10:29 AM Nathan Sidwell wrote:
If I drop 'master' from the command I get:
>git worktree add ../../error/src
Preparing ../../error/src (identifier src1)
* what does 'identifier src1' mea
On Jan 13 2020, Jason Merrill wrote:
> On Mon, Jan 13, 2020 at 10:29 AM Nathan Sidwell wrote:
>
>> If I drop 'master' from the command I get:
>> >git worktree add ../../error/src
>> Preparing ../../error/src (identifier src1)
>>
>> * what does 'identifier src1' mean, and what did that do?
>>
>
>
On Mon, Jan 13, 2020 at 10:29 AM Nathan Sidwell wrote:
> On 1/13/20 6:33 AM, Jonathan Wakely wrote:
> > I imagine a lot of people are going to feel lost in the first few
> > weeks of using Git.
>
> thanks. I have a question, but first some info that may well be useful
> to others.
>
> Today I le
On 1/13/20 6:33 AM, Jonathan Wakely wrote:
I imagine a lot of people are going to feel lost in the first few
weeks of using Git.
thanks. I have a question, but first some info that may well be useful
to others.
Today I learnt that one can use worktrees to work with different checked
out br
On Mon, 2020-01-13 at 11:33 +, Jonathan Wakely wrote:
> I imagine a lot of people are going to feel lost in the first few
> weeks of using Git.
I don't do IRC (and I'm not a GCC dev :)) but I'm happy to help via email.
One thing I'll say though: if you're an Emacs user then IMO you should run
I'm also happy to help.
On Mon, Jan 13, 2020 at 6:40 AM Jonathan Wakely
wrote:
> I imagine a lot of people are going to feel lost in the first few
> weeks of using Git.
>
> If you are stuck or confused about using Git for GCC development and
> too embarrassed to ask in public, feel free to conta
I imagine a lot of people are going to feel lost in the first few
weeks of using Git.
If you are stuck or confused about using Git for GCC development and
too embarrassed to ask in public, feel free to contact me on IRC. I'm
jwakely on OFTC, redi on Freenode.
It would be nice if other experienced
48 matches
Mail list logo
