1 |
On Sun, Sep 14, 2014 at 11:11 AM, hasufell <hasufell@g.o> wrote: |
2 |
> |
3 |
> The only hard part is that people have to know the differences between |
4 |
> merging/rebasing, fast-forward merges, non-fast-forward merges etc. and |
5 |
> when and when not to do them. |
6 |
> |
7 |
> 'git rebase' is a powerful thing, but also pretty good to mess up your |
8 |
> local history if used wrong. |
9 |
> |
10 |
> I think we can write up a gentoo-specific guide in 2-3 weeks. |
11 |
> |
12 |
|
13 |
Sounds good. I think one thing we need to get over with the whole git |
14 |
migration is the fact that it isn't going to be perfect. We probably |
15 |
will find minor errors in the migration itself, little glitches in the |
16 |
back-end stuff, problems in the proposed workflow, and so on. We're |
17 |
just going to have to adapt. We've been using cvs for eons and have |
18 |
learned to ignore its shortcomings and have well-polished workflows. |
19 |
|
20 |
It isn't like there are 500 devs doing commits every day. We're a |
21 |
reasonably tight community and we're just going to have to work |
22 |
together to get over the inevitable bumps. |
23 |
|
24 |
It may make sense to just start out with guidelines in the beginning, |
25 |
and then we can turn them into rules when problems actually come up. |
26 |
Once upon a time there wasn't a hard rule about changelog entries for |
27 |
removals/etc, and the world didn't end, but we decided that having the |
28 |
rule made more sense than not having it. With git we should expect |
29 |
more of the same - we won't get it 100% right out of the gate. |
30 |
|
31 |
-- |
32 |
Rich |