Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter <b...@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.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs