| 1 |
On Sun, Jul 5, 2015 at 1:56 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> On 07/04/2015 08:17 PM, C Bergström wrote: |
| 3 |
>> I realize that this is subject to lots of different opinions and that |
| 4 |
>> my input doesn't carry much weight - At least I thought it's a topic |
| 5 |
>> that should be brought up (again?) |
| 6 |
>> --------- |
| 7 |
>> To start.... I hate git.. I have used it for years now and the |
| 8 |
>> multitude of ways that are possible to accomplish nearly the same |
| 9 |
>> thing are *annoying* at best.. With that rant out of the way on to the |
| 10 |
>> point.. |
| 11 |
>> --------- |
| 12 |
>> I super don't like "merge" workflows. |
| 13 |
>> 1) "merge commits" are confusing at best and normal tools don't |
| 14 |
>> display and work with them as you'd always expect |
| 15 |
>> |
| 16 |
>> 2) merge commits lead to multiple parents, which breaks a clean and |
| 17 |
>> simple to follow linear history |
| 18 |
>> --------- |
| 19 |
>> |
| 20 |
>> What I personally prefer is a rebase workflow. |
| 21 |
>> The downsides |
| 22 |
>> 1) Requires to you rebase before pushing. Which can be slightly more |
| 23 |
>> work than just a lazy resolution of the conflicting "merge commit" |
| 24 |
>> (depending on if you flatten your commits) |
| 25 |
>> |
| 26 |
>> 2) May not be the most popular git work-flow. |
| 27 |
>> |
| 28 |
>> 3) Due to #2 from above - may have detractors and or less people who |
| 29 |
>> are familiar with it. |
| 30 |
>> -------------- |
| 31 |
>> I'm of the mindset that if you're going to keep something under |
| 32 |
>> revision - the history should be clear and clean. Linear is the only |
| 33 |
>> way to fly for that. For those using cvs or svn - that's what they'll |
| 34 |
>> be familiar with and probably expect to find in a git log. You can |
| 35 |
>> start with forcing rebase and keep a clean history - if one day it |
| 36 |
>> proves too problematic you can switch over to "merging" - the other |
| 37 |
>> way isn't really possible to do cleanly, depending on your tools.. |
| 38 |
>> |
| 39 |
>> Thanks for the minute |
| 40 |
>> |
| 41 |
> |
| 42 |
> Forcing a rebase-only workflow on developers will increase the amount of |
| 43 |
> bad commits. Because non-trivial conflicts in rebases are difficult to |
| 44 |
> resolve, since you fix conflicts for _every_ commit separately. |
| 45 |
|
| 46 |
Not true - you have the choice to flatten the commit. This may not be |
| 47 |
ideal, but I consider that way more optimal than some |
| 48 |
hack-to-make-it-work "merge" commit. |
| 49 |
|
| 50 |
To be honest and pragmatic - I don't really see tons of conflicts in |
| 51 |
the typical gentoo dev workday. |
| 52 |
|
| 53 |
The people who own ebuilds and eclasses won't be clobbering each |
| 54 |
other. That doesn't happen today and why would switching to git |
| 55 |
magically make it start? |
| 56 |
|
| 57 |
With a rebase workflow - you |
| 58 |
a. Rebase frequently for long running branches |
| 59 |
b. Branch, rebase and push to master |
| 60 |
---------- |
| 61 |
Lastly - IF for whatever reason gentoo wants to switch to a different |
| 62 |
VCS for whatever reason - a linear history would absolutely make that |
| 63 |
easier (possible). Lets think 10+ years from now.. |
| 64 |
|
| 65 |
I'm not a git fanboy - I hope one day it's replaced by something |
| 66 |
superior (the same thing could be said about almost any piece of |
| 67 |
software and given enough time - it's probably true) |
Archives