On July 4, 2015 2:17:41 PM EDT, "C Bergström" <[email protected]> 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.
Just a short note, the last time I read the git workflow on the wiki [0], rebase of one's commit is suggested with fallback to merge if unable to rebase. >1) "merge commits" are confusing at best and normal tools don't >display and work with them as you'd always expect It's a GUI, but dev-util/meld provides a pretty nice interface for git merges. > >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 -- NP-Hardass [0] https://wiki.gentoo.org/wiki/Gentoo_git_workflow
