On Sat, Jul 04, 2015 at 02:33:04PM -0400, NP-Hardass wrote: > > > On July 4, 2015 2:17:41 PM EDT, "C Bergström" <cbergst...@pathscale.com> > 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..
Just find a workflow that works for you. Git has a lot of power, but you don't have to know everything about it. :-) > >--------- > >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. Same here, merge workflows are evil. I can't think of a reason you would be unable to rebase other than, "I don't want to resolve the conflicts, so I'm just going to merge". > > >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. guis are irrelivant if you can't use them for one reason or another. > > > > >2) merge commits lead to multiple parents, which breaks a clean and > >simple to follow linear history > >--------- Agreed. > >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.. I firmly agree. Merge commits are very difficult at best to make any sense out of. The master branch of a repo should be kept clear and clean of those. William
signature.asc
Description: Digital signature
