1 |
On Mon, Oct 12, 2015 at 1:44 PM, Alec Warner <antarus@g.o> wrote: |
2 |
> |
3 |
> |
4 |
> On Mon, Oct 12, 2015 at 3:58 AM, Rich Freeman <rich0@g.o> wrote: |
5 |
>> |
6 |
>> On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
7 |
>> > |
8 |
>> > It is, however, worth repeating that in git, commits are entirely |
9 |
>> > separate from pushes and are very (as in, extremely!) cheap, while |
10 |
>> > pushes, particularly if properly repoman-checked, are obviously much |
11 |
>> > more |
12 |
>> > expensive. |
13 |
>> |
14 |
>> Each commit really should be able to stand on its own all the same. |
15 |
>> |
16 |
>> They should all be able to pass a repoman check. |
17 |
> |
18 |
> |
19 |
> I guess in some ideal world I sort of agree; but in practice I think |
20 |
> workflows exist that involve people messing around in their local repo until |
21 |
> they get stuff right, then running repoman at the end and pushing the result |
22 |
> (that is kind of the whole point of having a local staging repo.) |
23 |
|
24 |
I think the best practice here really depends on the nature of what |
25 |
you're working on. For most software the right way to handle such |
26 |
things is to either: |
27 |
1. If you're just doing multiple iterations on one true logical |
28 |
change, rebase your commits into a single commit once you have it |
29 |
right. You could extend this into a few commits in some cases as long |
30 |
as they can stand on their own. |
31 |
2. Do all the work on a side branch and do a merge commit into the |
32 |
master branch. Then master still has a history where every commit |
33 |
(along one side) works. This is the best approach for the development |
34 |
of major features which necessarily will not be complete for extended |
35 |
periods but where the details are still useful. |
36 |
|
37 |
#1 is likely to be most appropriate for the Gentoo repo in most cases. |
38 |
|
39 |
-- |
40 |
Rich |