se for flattening our changes.
> > > > > - Squash is still an "okay" heuristic that accomplishes the same
> > > > > thing, most of the time.
> > > > > On Tue, Oct 23, 2018 at 1:06 PM Dewayne Richardson <
> > dewr...@apache.org>
> > > > w
generate one from the commit
> > > messages
> > > > > within that release window.
> > > > >
> > > > > -Dew
> > > > >
> > > > > On Tue, Oct 23, 2018 at 12:58 PM Gray, Jonathan <
> > > jonathan_g...@comcast.com
t; > > > > large a use case for us. The repo forensics are nice with merge,
> > but the
> > > > > reality we found was that git blame was more useful when we could
> > track to
> > > > > the PR rather than a mid-stream commit and then having to ma
tay on track with 1 PR == 1 issue because it
> made
> > > > unrelated fixes more apparent.
> > > >
> > > > Jonathan G
> > > >
> > > >
> > > > On 10/23/18, 12:40 PM, "Fieck, Brennan"
> > > > wrote:
>
e to require PRs to squash things into atomic chunks. No
> > > commits
> > > that say "started x" or "minor fixes", but idk if it's reasonable to be
> > > able to boil every PR forever down to 70 characters. And sure you can make
> > >
This is exactly what I was trying to say, but far more eloquent. +1 for atomic
commits
From: Chris Lemmons
Sent: Tuesday, October 23, 2018 4:49 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Squash and Merge for PRs
I don't thin
; > multiple PRs if changes are too big to fit in one commit message, but then
> > it becomes really easy to become entwined in a chain of dependent PRs so
> > that every time one of them gets merged you have to rebase them all.
> >
> > Of course, a "reasonable squash" is pretty hard
ot;reasonable squash" is pretty hard to define absolutely,
> and could actually just make PRs harder to review - maybe it's not even
> enforceable at all.
> ________________________
> From: Rawlin Peters
> Sent: Tuesday, October 23, 2018 11:14 AM
> To: dev@trafficcontrol.apache.org
>
t make PRs harder to review - maybe it's not even
enforceable at all.
From: Rawlin Peters
Sent: Tuesday, October 23, 2018 11:14 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Squash and Merge for PRs
+1 on enabling squash and merge.
ot; is pretty hard to define absolutely, and could
actually just make PRs harder to review - maybe it's not even enforceable at
all.
From: Rawlin Peters
Sent: Tuesday, October 23, 2018 11:14 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL]
+1 on enabling squash and merge.
This will not only make cherry picks easier to manage with respect to
merge conflicts, but it will also make the git log more useful because
we will be able to see the full changeset of the PR in a single commit
of the git log. Ideally, I'd also like the squashed c
+1 on the squishing.
> On Oct 23, 2018, at 12:41 PM, Dave Neuman wrote:
>
> This seems to have stalled, so let me try to move it along.
>
> There is an ability to do "squash and merge" in github, we just need to
> agree that we want to enable it for our project.
>
> @Jeremy Mitchell I am not
This seems to have stalled, so let me try to move it along.
There is an ability to do "squash and merge" in github, we just need to
agree that we want to enable it for our project.
@Jeremy Mitchell I am not sure exactly how to
handle the multiple committers thing, but I assume we can squash into
I'll be honest, I think the simplest thing is still to just require a changelog
message, added to a central file, to be included in the commit. We've been
going over and over this for months instead of actually writing change logs.
Let's just propose it and put it to a vote.
> On Oct 18, 2018,
14 matches
Mail list logo
