Re: [gentoo-dev] Git workflow

[William Hubbs]

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" <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..

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