On Sat, 3 Dec 2016 15:06:36 +
Markos Chandras wrote:
> That's reasonable but I also think that bumping and fixing an ebuild at
> the same time can be considered an atomic change since it's effectively
> a _new_ ebuild
One problem is that can seriously confuse git about what's happening,
give
On 12/02/2016 03:14 PM, Andrew Savchenko wrote:
>
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (o
On 12/02/2016 07:14 AM, Andrew Savchenko wrote:
> Hi all!
>
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
>
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
>
> 2) revision bump policy [2]:
> each change sufficie
Ühel kenal päeval, R, 02.12.2016 kell 11:26, kirjutas Matt Turner:
> On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko
> wrote:
> >
> > Hi all!
> >
> > Right now we have two somewhat conflicting policies (at least up to
> > my understanding of them):
> >
> > 1) git atomic commits [1]:
> > each l
On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko wrote:
> Hi all!
>
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
>
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
>
> 2) revision bump policy [2]:
> each change su
On Fri, 2 Dec 2016 18:14:05 +0300
Andrew Savchenko wrote:
> Hi all!
>
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
>
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
>
> 2) revision bump policy [2]:
> each cha
On 12/02/2016 10:14 AM, Andrew Savchenko wrote:
>
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
>
> While such versioning change is technically correct, it is
>
On 02/12/16 10:32 AM, Dirkjan Ochtman wrote:
> On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko wrote:
>> What about the following forkflow:
>> - version bump first with minimal changes required, but without
>> pushing commit to the tree;
>> - make each logical change as a separate commit without
On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko wrote:
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the t
Hi all!
Right now we have two somewhat conflicting policies (at least up to
my understanding of them):
1) git atomic commits [1]:
each logical change should be a separate commit.
2) revision bump policy [2]:
each change sufficiently affecting application run-time or
installed files should have a
10 matches
Mail list logo
