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