Re: [gentoo-dev] Git workflow

[hasufell]

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.