Well said Rick.
On Fri, Jun 17, 2016 at 2:26 AM, Rick Harding
wrote:
> I'm going to push back on the why squash or even the "let's make it just
> auto clean it up".
>
> A commit to the tree should be a single, well thought out, chunk of work
> that another can review and process easily. Having th
On Thu, Jun 16, 2016 at 3:08 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:
> A new development release of Juju, 2.0-beta9 is here!
>
> ## What's new?
>
> * New `juju unregister` command for cleaning up local references to
> controllers
> Usage: juju unregister
> * `juju status` ha
A new development release of Juju, 2.0-beta9 is here!
## What's new?
* New `juju unregister` command for cleaning up local references to
controllers
Usage: juju unregister
* `juju status` has been enhanced for ease of reading
* Removal of support for legacy lxc containers in favor of lxd
*
One justification that I just had first hand experience of: change
ported from master to 1.25 where the change has already got a +1 on
master. I would like to see any changes that haven't already been
reviewed so squashing to two changes makes the life of the reviewer
easier.
Will shut up now.
On
I would love to be given small, isolated, well planned work to do, the
specification of which never changes. That isn't the world I live in,
which is why I would like our ideals to be good and to have guidelines
to support them, but not to have unbreakable rules that may trip us
up. I am only advoc
I'm going to push back on the why squash or even the "let's make it just
auto clean it up".
A commit to the tree should be a single, well thought out, chunk of work
that another can review and process easily. Having the history of how you
got there isn't valuable in my opinion. The most important
TLDR: Having guidelines rather than rules is good. Having a tool
mindlessly squashing commits can throw away valuable information.
I am a little confused as to why we need to squash stuff at all. Git
history isn't flat so if you don't want to see every commit in a
branch that has landed then you d
This is purely anecdotal, but on the ecosystem side for a lot of our
projects I've tried to psuedo-enforce the "one commit", or really, a
change/fix/feature per commit. Thereby allowing me to cherrypick for patch
releases to stable (or revert a commit) with confidence and without a lot
of hunting f
Note that if github is squashing the commits when it lands into Master, I
*believe* that this breaks the ancestry with your local branch. So it isn't
a matter of "the history just isn't present in the master branch", but "it
looks like a completely independent commit revision, and you have no
obvio
Thanks Tim and I want to say that I really appreciate this change. The way
the API exposed the Go-ism that all exported attributes are capitalized has
been annoying for some time. I really appreciate you cleaning that up for
users of the API.
I think the only thing I'd change on this is that we no
On 16/06/16 19:04, David Cheney wrote:
> Counter suggestion: the bot refuses to accept PR's that contain more
> than one commit, then it's up to the submitter to prepare it in any
> way that they feel appropriate.
>
Please no. I do not want to be forced to alter my local history.
I was hopeful
Much like communism, it's still in practice at small territory
On Thursday, 16 June 2016, David Cheney wrote:
> I thought feature branches, like communism, sounded good but had
> failed in practice.
>
> On Thu, Jun 16, 2016 at 7:06 PM, Horacio Duran
> > wrote:
> > On second thought, this might b
I thought feature branches, like communism, sounded good but had
failed in practice.
On Thu, Jun 16, 2016 at 7:06 PM, Horacio Duran
wrote:
> On second thought, this might be a problem for feature branches but we can
> device a way to tell the bot that something is a fb
>
>
> On Thursday, 16 June
On second thought, this might be a problem for feature branches but we can
device a way to tell the bot that something is a fb
On Thursday, 16 June 2016, Horacio Duran
wrote:
> +1 on Dave's suggestion
>
> On Thursday, 16 June 2016, David Cheney > wrote:
>
>> Counter suggestion: the bot refuses
+1 on Dave's suggestion
On Thursday, 16 June 2016, David Cheney wrote:
> Counter suggestion: the bot refuses to accept PR's that contain more
> than one commit, then it's up to the submitter to prepare it in any
> way that they feel appropriate.
>
> On Thu, Jun 16, 2016 at 6:44 PM, roger peppe
Counter suggestion: the bot refuses to accept PR's that contain more
than one commit, then it's up to the submitter to prepare it in any
way that they feel appropriate.
On Thu, Jun 16, 2016 at 6:44 PM, roger peppe wrote:
> Squashed commits are nice, but there's something worth watching
> out for:
Squashed commits are nice, but there's something worth watching
out for: currently the merge commit is committed with the text
that's in the github PR, but when a squashed commit is made, this
text is ignored and only the text in the actual proposed commit ends up
in the history. This surprised me
17 matches
Mail list logo
