On 1/15/20 4:55 AM, Jonathan Wakely wrote:
On Wed, 15 Jan 2020 at 09:49, Richard Biener wrote:
On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely wrote:
On Wed, 15 Jan 2020 at 08:40, Richard Biener wrote:
On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
Peter Bergner :
At this po
Richard Biener :
> > I like to write really fine-grained commits when I'm developing, then
> > squash before pushing so the public repo commits always go from "tests
> > pass" to "test pass". That way you can do clean bisections on the
> > public history.
>
> The question is wheter one could achi
On Wed, 15 Jan 2020 at 09:49, Richard Biener wrote:
>
> On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely
> wrote:
> >
> > On Wed, 15 Jan 2020 at 08:40, Richard Biener
> > wrote:
> > >
> > > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
> > > >
> > > > Peter Bergner :
> > > > > At thi
On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely wrote:
>
> On Wed, 15 Jan 2020 at 08:40, Richard Biener
> wrote:
> >
> > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
> > >
> > > Peter Bergner :
> > > > At this point, I get a little confused. :-) I know to submit my patch
> > > > for
On Wed, 15 Jan 2020 at 08:40, Richard Biener wrote:
>
> On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
> >
> > Peter Bergner :
> > > At this point, I get a little confused. :-) I know to submit my patch
> > > for review, I'll want to squash my commits down into one patch, but how
> > > d
On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
>
> Peter Bergner :
> > At this point, I get a little confused. :-) I know to submit my patch
> > for review, I'll want to squash my commits down into one patch, but how
> > does one do that? Should I do that now or only when I'm ready to
>
On 1/14/20 5:45 PM, Jonathan Wakely wrote:
On 14/01/20 17:05 +, Jonathan Wakely wrote:
On 14/01/20 10:07 -0600, Peter Bergner wrote:
As somewhat of a git newbie and given gcc developers will do a git
push of
our changes rather than employing a git pull development model, I'd like
a little
On 14/01/20 17:05 +, Jonathan Wakely wrote:
On 14/01/20 10:07 -0600, Peter Bergner wrote:
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow
On Tue, 14 Jan 2020, Jonathan Wakely wrote:
> > ...and this is just for changes going to trunk. How does all this change
> > when I want to push changes to a release or vendor branch?
>
> It's pretty similar. Create a branch from the release branch, merge it
> back to the release branch.
>
> Pe
On Tue, 14 Jan 2020, Jason Merrill wrote:
> I think we're prohibiting merges to master. We definitely don't want
> merges of branches with commits that don't each satisfy the normal rules
> for commits.
Yes. The hooks prevent pushing a merge commit to master or a release
branch. A branch can
On Tue, Jan 14, 2020 at 12:12 PM Jonathan Wakely wrote:
> On 14/01/20 10:07 -0600, Peter Bergner wrote:
> >As somewhat of a git newbie and given gcc developers will do a git push of
> >our changes rather than employing a git pull development model, I'd like
> >a little hand holding on what my new
Le 14/01/2020 à 17:07, Peter Bergner a écrit :
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo
On 14/01/20 10:07 -0600, Peter Bergner wrote:
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo
Peter Bergner :
> At this point, I get a little confused. :-) I know to submit my patch
> for review, I'll want to squash my commits down into one patch, but how
> does one do that? Should I do that now or only when I'm ready to
> push this change to the upstream repo or ??? Do I need to even do
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo by pushing something to the wrong place. :-)
I
15 matches
Mail list logo
