[Haskell-cafe] Darcs vs Git

[Bardur Arantsson]

On 11/15/2015 02:31 AM, Ivan Lazar Miljenovic wrote:
> On 15 November 2015 at 09:37, Mike Meyer <mwm at mired.org> wrote:
>>
>> I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
>> are introduced. But that's minor to not wanting history hidden. I even had
>> someone ask that I collapse a bunch of changes when I pushed them to my
>> github repo before creating a PR. Not going to happen.
> 
> On the other hand, when accepting a PR, I don't want it to be full of
> lots of little "let's see if this worked; nope I need a second commit"
> messages cluttering up the git log: I recently had such a case where
> there were empty commits called "test commit", etc.  Or in my own
> work, if I accidentally forgot to include a hunk in a commit I prefer
> to squash that change with the commit it was meant to be in rather
> than have an extra commit.
> 

Yes -- this is one extremely important use case for rebase/squash. In
git, the commit history is *not* meant for preserving "what happened".
It's meant for humans to read when you're digging through change logs,
perhaps because you're hunting a bug.

I tend to find that people who want to preserve what happened have a
different way of working where they tend to try to create good commits
as they go whereas I (post-git) just create a bunch of "WIP" commits
for almost every change regardless of whether it compiles or not and
then clean up the "history" for readability once the full change is
ready for pushing to the world. I used to be in the former group, but
have found that moving to the in the latter workflow is incredibly
liberating. It means that I don't waste nearly as much time checking
that everything compiles (etc.) for every little change I make. I just
check all that stuff for the final series of commits.

"Patch theory" is all well and good, but it's missing the point, IMO.
Tools *must* have a manual override for when the user knows best[1] and
that also means adapting to *my* workflow rather than me having to
constantly think mind "should I commit now?", "which order do I need to
do my refactoring in to get small reviewable commits?", etc. With git,
it's very rare to have to think about this.

Now, we've talked about squashing, but I also find that *splitting*
commits to be hugely valueable in that you can often
(post-working-frenzy) split everything into neat, logically coherent
easily reviewable commits/chunks. Absent strong AI, no "patch theory"
can do this since it's not a technical problem.

That's what I like about Git -- it works on *my* terms rather than its
terms. (Yeah, the UI isn't exactly great[1], but once you're over the
learning curve the UX *is*, IMO.)

Regards,

[1] If you're an emacs user: Use "magit" it's incredible. Maybe even
worth learning emacs for.