Gitlab workflow

Sven Panne svenpanne at
Thu Jul 11 15:49:39 UTC 2019

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

> [...] 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: <>

More information about the ghc-devs mailing list