1 |
On 07/04/2015 09:23 PM, C Bergström wrote: |
2 |
> On Sun, Jul 5, 2015 at 1:56 AM, hasufell <hasufell@g.o> wrote: |
3 |
>> |
4 |
>> Forcing a rebase-only workflow on developers will increase the amount of |
5 |
>> bad commits. Because non-trivial conflicts in rebases are difficult to |
6 |
>> resolve, since you fix conflicts for _every_ commit separately. |
7 |
> |
8 |
> Not true - you have the choice to flatten the commit. This may not be |
9 |
> ideal, but I consider that way more optimal than some |
10 |
> hack-to-make-it-work "merge" commit. |
11 |
> |
12 |
> To be honest and pragmatic - I don't really see tons of conflicts in |
13 |
> the typical gentoo dev workday. |
14 |
> |
15 |
> The people who own ebuilds and eclasses won't be clobbering each |
16 |
> other. That doesn't happen today and why would switching to git |
17 |
> magically make it start? |
18 |
> |
19 |
> With a rebase workflow - you |
20 |
> a. Rebase frequently for long running branches |
21 |
> b. Branch, rebase and push to master |
22 |
> ---------- |
23 |
> Lastly - IF for whatever reason gentoo wants to switch to a different |
24 |
> VCS for whatever reason - a linear history would absolutely make that |
25 |
> easier (possible). Lets think 10+ years from now.. |
26 |
> |
27 |
> I'm not a git fanboy - I hope one day it's replaced by something |
28 |
> superior (the same thing could be said about almost any piece of |
29 |
> software and given enough time - it's probably true) |
30 |
> |
31 |
|
32 |
|
33 |
So, you've commented on one of my points and proposed to use a |
34 |
workaround for something that a merge can do properly. |
35 |
|
36 |
I'd say that is bikeshedding (to put it diplomatic). |
37 |
|
38 |
Judging from your more recent answer to this thread it seems you haven't |
39 |
even read the current gentoo git workflow proposal. I suggest you do |
40 |
some research first before continuing this discussion. |