| 1 |
Davide Pesavento: |
| 2 |
>> Main developer repo |
| 3 |
>> ------------------- |
| 4 |
>> |
| 5 |
>> I was able to create a start git repository that takes around 66M |
| 6 |
>> as a git pack (this is how much you will have to fetch to start working |
| 7 |
>> with it). The repository is stripped clean of history and ChangeLogs, |
| 8 |
>> and has thin Manifests only. |
| 9 |
>> |
| 10 |
>> This means we don't have to wait till someone figures out the perfect |
| 11 |
>> way of converting the old CVS repository. You don't need that history |
| 12 |
>> most of the time, and you can play with CVS to get it if you really do. |
| 13 |
> |
| 14 |
> +1 |
| 15 |
> |
| 16 |
|
| 17 |
+1 |
| 18 |
|
| 19 |
>> In any case, we would likely strip the history anyway to get a small |
| 20 |
>> repo to work with. |
| 21 |
>> |
| 22 |
>> I have prepared a basic git update hook that keeps master clean |
| 23 |
>> and attached it to the bug [1]. It enforces basic policies, prevents |
| 24 |
>> forced updates and checks GPG signatures on left-most history line. It |
| 25 |
>> can also be extended to do more extensive tree checks. |
| 26 |
> |
| 27 |
> Are we going to disallow merge commits and ask devs to rebase local |
| 28 |
> changes in order to keep the history "clean"? |
| 29 |
> |
| 30 |
|
| 31 |
I'd say it doesn't make sense to create merge commits for conflicts that |
| 32 |
arise by someone having pushed earlier than you. |
| 33 |
|
| 34 |
Merge commits should only be there if they give useful information. |
| 35 |
|
| 36 |
Also... if you merge from a _user_ who is untrusted and allow a |
| 37 |
fast-forward merge, then the signature verification fails. That means |
| 38 |
for such pull requests you either have to use "git am" or "git merge |
| 39 |
--no-ff". |
Archives