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