Re: [gentoo-dev] Git workflow

[NP-Hardass]

On July 4, 2015 2:17:41 PM EDT, "C Bergström" <cbergstrom@×××××××××.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..
>---------
>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