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. Additionally, it will also mess up user-branches with user gpg signatures and will hide development information that can be useful. It also complicates working on concurrent branches, a lot (mass cherry-picking is bad, rebasing on already pushed commits is bad too). Whether people use merges or rebases is totally orthogonal to the topic of a "clean git history". It only matters _how_ people use both methods. I'd even say it would achieve the opposite of what you want, at least for a project as large as the gentoo tree. If you have a small project with only one master branch and a very strict review policy, then a rebase-only workflow might work. That said, I don't think this discussion is particularly useful. There's no gain and no strong logical reason (except some personal aesthetical preference) to enforce a rebase-only workflow.
