| 1 |
On 07/05/2015 08:57 PM, William Hubbs wrote: |
| 2 |
> On Sun, Jul 05, 2015 at 04:03:27PM +0200, hasufell wrote: |
| 3 |
>> On 07/05/2015 06:10 AM, C Bergström wrote: |
| 4 |
>>>>> 5) More about linear commits and "history" - I need to double check, |
| 5 |
>>>>> but I don't think rebase changes the actual commit date (I could be |
| 6 |
>>>>> mistaken). |
| 7 |
>>>> |
| 8 |
>>>> You are mistaken, and should have double checked before you argued. |
| 9 |
>>>> |
| 10 |
>>>> Arguing without checking makes you look bad. |
| 11 |
>>> |
| 12 |
>>> How? I didn't claim to know and clearly not knowing didn't seem |
| 13 |
>>> important (to me). I'm not trying to overstate anything. I'm just |
| 14 |
>>> trying to passionately bring this up. I ***wish*** someone with some |
| 15 |
>>> guts would actually take charge of this on the gentoo side, have a |
| 16 |
>>> vote or make some executive decision which is stronger than this wimpy |
| 17 |
>>> policy we have now. |
| 18 |
>>> |
| 19 |
>> |
| 20 |
>> Most of what you brought up wasn't really useful critique, but rather |
| 21 |
>> noise based on your personal frustration with git. |
| 22 |
>> |
| 23 |
>> This thread is not about giving lectures on how git works. We appreciate |
| 24 |
>> useful comments on the git workflow. But in order to give useful |
| 25 |
>> comments, you have to know and understand the project and how it works |
| 26 |
>> internally. |
| 27 |
>> |
| 28 |
>> There will be a sh*tload of developer, feature and whatnot branches. It |
| 29 |
>> is just insane to tell everyone to unconditionally do rebases |
| 30 |
>> everywhere. You haven't even commented on a fraction of the resulting |
| 31 |
>> problems. So please lets stop this discussion and move on. |
| 32 |
> |
| 33 |
> The only thing you would have to worry about is rebasing your commits if |
| 34 |
> they are already pushed. |
| 35 |
> |
| 36 |
|
| 37 |
I will repeat it once more: |
| 38 |
1. conflict resolution is more difficult with rebases (rebases are still |
| 39 |
encouraged though in the current git workflow draft, it just seems |
| 40 |
people haven't read it), it will increase the amount of bad commits. And |
| 41 |
it can be a lot more work. |
| 42 |
2. doesn't work if you want to properly merge user branches (or |
| 43 |
literally any branch) without losing information (such as development |
| 44 |
information contained in the branch-structure or user signatures) |
| 45 |
3. is totally unrelated to the topic of a "clean" git history. You can |
| 46 |
have an unclean git history with rebases and merges and without rebases |
| 47 |
and without merges. |
| 48 |
4. complicates concurrent branches... it will lead to |
| 49 |
mass-cherry-picking or non-fast-forward pushes (which will be rejected, |
| 50 |
at least on the master branch) which are both terrible workflows and |
| 51 |
very prone to error |
| 52 |
5. doesn't work particularly well with pull requests since the "merged" |
| 53 |
pull request may diverge non-trivially from the branch it comes from |
| 54 |
(especially if the guy who "merges" decides to squash commits or |
| 55 |
whatnot). There are workarounds to that, but they may complicate a |
| 56 |
PR-workflow without further tooling (such as gerrit). |
| 57 |
6. limits developers to a particular workflow type without a good reason |
| 58 |
("I want a linear history!" alone isn't really one). The gentoo git |
| 59 |
workflow draft already tries to give hints about when to use rebases and |
| 60 |
when to use merges in order to ensure a clean history. Ofc these hints |
| 61 |
could be improved. |
| 62 |
7. If you want a patch-based DVCS, then git is the wrong choice. Use |
| 63 |
darcs instead. It does a far better job at that. |
| 64 |
|
| 65 |
Rebases are not easy in non-trivial projects. They have some advantages |
| 66 |
though and that's why the draft recommends to try a rebase first for |
| 67 |
regular push-conflicts. Ofc, you only know that if you have read it. |
Archives