Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Git workflow
Date: Sat, 04 Jul 2015 20:58:10
Message-Id: 559848D2.6060106@gentoo.org
In Reply to: Re: [gentoo-dev] Git workflow by "C Bergström"
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.