Re: [Haskell-cafe] Darcs vs Git

On 11/15/2015 02:31 AM, Ivan Lazar Miljenovic wrote:

On 15 November 2015 at 09:37, Mike Meyer 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.