Gitlab workflow

[Sven Panne]

Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter <b at chreekat.net>:

> [...] When references to commits (in emails etc.) get invalidated,
> it adds confusion and extra work. Seeing this happen is what led me to
> wonder why people even prefer this strategy.
>

I think there is a misunderstanding here: You never ever force-push rebased
commits to a public repo, this would indeed change commit hashes and annoy
all your collaborators like hell. In a rebase-only workflow you rebase
locally, pushing your then fast-forward-only merge to the public repo. You
can even disable force-pushed on the receiving side, an that's what is
normally done (well, not on GitHub...).


> [...] One final thing I like about merges is conflict resolution. Resolving
> conflicts via rebase is something I get wrong 40% of the time. It's
> hard. Even resolving a conflict during a merge is hard, but it's
> easier.


Hmmm, I don't see a difference with conflict resolution in both cases, the
work involved is equivalent.


> Plus, the eventual merge commit keeps a record of the
> resolution! (I only learned this recently, since `git log` doesn't
> show it by default.) Keeping a public record of how a conflict was
> resolved seems like a huge benefit. [...]
>

To me it is quite the opposite: In a collaborative environment, I don't
care even the tiniest bit about how somebody resolved the conflicts of his
branch: This is a technical artifact about when the branch was made and
when it is merged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190711/b8df2dea/attachment.html>