| 1 |
On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> On 11 August 2015 at 20:57, Tobias Klausmann <klausman@g.o> wrote: |
| 3 |
>> |
| 4 |
>> The cat/pn rule is tricky anyway: what if one commit touches 100 |
| 5 |
>> packages? Or should that be split into 100 commits for easier |
| 6 |
>> partial rollback? |
| 7 |
> |
| 8 |
>>> **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group |
| 9 |
|
| 10 |
++ |
| 11 |
Go read the proposal. This email chain simplifies it but people have |
| 12 |
already thought of most of those corner cases already. |
| 13 |
|
| 14 |
However, I do want to touch on this bit from the previous email: "Or |
| 15 |
should that be split into 100 commits for easier partial rollback?" |
| 16 |
|
| 17 |
Each commit should be one logical change. If you stabilize 100 |
| 18 |
separate packages in an afternoon, there should be 100 commits. If |
| 19 |
you stabilize kde-5.0 there probably should be one commit that touches |
| 20 |
100 packages. Likewise if you rename a package and fix 100 references |
| 21 |
to it in other packages, that should probably also be a single commit |
| 22 |
(but I'd separate renaming the package from any other changes to the |
| 23 |
content of the package). |
| 24 |
|
| 25 |
That is actually one of the advantages of git. You can stabilize |
| 26 |
kde-5 and a user doing an rsync will either get kde 4.x or the full |
| 27 |
kde 5, and nothing in-between. |
| 28 |
|
| 29 |
But, one commit in the final tree should still remain one logical change. |
| 30 |
|
| 31 |
-- |
| 32 |
Rich |
Archives