On Sun, Jul 5, 2015 at 1:56 AM, hasufell <hasuf...@gentoo.org> wrote: > On 07/04/2015 08:17 PM, C Bergström wrote: >> I realize that this is subject to lots of different opinions and that >> my input doesn't carry much weight - At least I thought it's a topic >> that should be brought up (again?) >> --------- >> To start.... I hate git.. I have used it for years now and the >> multitude of ways that are possible to accomplish nearly the same >> thing are *annoying* at best.. With that rant out of the way on to the >> point.. >> --------- >> I super don't like "merge" workflows. >> 1) "merge commits" are confusing at best and normal tools don't >> display and work with them as you'd always expect >> >> 2) merge commits lead to multiple parents, which breaks a clean and >> simple to follow linear history >> --------- >> >> What I personally prefer is a rebase workflow. >> The downsides >> 1) Requires to you rebase before pushing. Which can be slightly more >> work than just a lazy resolution of the conflicting "merge commit" >> (depending on if you flatten your commits) >> >> 2) May not be the most popular git work-flow. >> >> 3) Due to #2 from above - may have detractors and or less people who >> are familiar with it. >> -------------- >> I'm of the mindset that if you're going to keep something under >> revision - the history should be clear and clean. Linear is the only >> way to fly for that. For those using cvs or svn - that's what they'll >> be familiar with and probably expect to find in a git log. You can >> start with forcing rebase and keep a clean history - if one day it >> proves too problematic you can switch over to "merging" - the other >> way isn't really possible to do cleanly, depending on your tools.. >> >> Thanks for the minute >> > > 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)
