| 1 |
On 12/02/2016 03:14 PM, Andrew Savchenko wrote: |
| 2 |
> |
| 3 |
> What about the following forkflow: |
| 4 |
> - version bump first with minimal changes required, but without |
| 5 |
> pushing commit to the tree; |
| 6 |
> - make each logical change as a separate commit without revision |
| 7 |
> bumps and without pushing stuff to the tree (of course repoman |
| 8 |
> scan/full is required as usual for each commit); |
| 9 |
> - well test package after the last commit (that it builds with |
| 10 |
> various USE flag combinations, old and new functionality works fine |
| 11 |
> and so on); |
| 12 |
> - fix any problems found and only afterwards push changes to the |
| 13 |
> tree. |
| 14 |
> |
| 15 |
> This way users will see only foo-1.0 -> foo-1.1 change in the tree, |
| 16 |
> while git will still retain each logical change as a separate |
| 17 |
> commit, which will make future maintenance and debugging much |
| 18 |
> easier. |
| 19 |
|
| 20 |
That's reasonable but I also think that bumping and fixing an ebuild at |
| 21 |
the same time can be considered an atomic change since it's effectively |
| 22 |
a _new_ ebuild |
| 23 |
|
| 24 |
-- |
| 25 |
Regards, |
| 26 |
Markos Chandras |
Archives