<div dir="ltr"><div dir="ltr">Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter <<a href="mailto:b@chreekat.net">b@chreekat.net</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] Rather than argue against GHC's current practices, however, I would like <br>
to understand them better. What issues led to a rebase-only workflow? <br>
Which expert opinions were considered? What happy stories can people <br>
relate? We recently switched away from a rebase-only workflow at <br>
$workplace, and it's already made life so much nicer for us -- so I'm <br>
curious what unforeseen pain we might be in for. :)</blockquote><div><br></div><div>I've worked for several companies of several sizes, and from my experience the rule is: The bigger the company, the more there is a tendency to use a rebase-only workflow, with big/huge projects exclusively relying on rebases, explicitly forbidding (non-fast-forward) merges. There are several good reasons for this IMHO:</div><div><br></div><div>   * Clarity: Even with a single release branch, merges tend to create an incomprehensible mess in the history. Things get totally unmanageable when you have to support several releases in various branches. IMHO this reason alone is enough to rule out non-fast-forward merges in bigger projects.</div><div><br></div><div>   * Bisecting: With merges you will have a very, very hard time bisecting your history to find a bug (or a fix). With a linear (single release) or tree-shaped (for several supported releases) history, this gets trivial and can easily be automated.</div><div><br></div><div>   * Hash instability: Simply relying on a hash to find out if a fix/feature is in some branch is an illusion: Sooner or later you get a merge conflict and need to modify your commit.</div><div><br></div><div>   * Tool integration via IDs: For the reason stated above, you will have some kind of bug/feature/issue/...-ID e.g. in your commit message, anyway. This ID is then used in your issue tracker/release management tool/..., not the hash of a commit in some branch.</div><div><br></div><div>Of course your mileage may vary, depending on your team and project size, the additional tools you use, how good your CI/testing/release framework is, etc.  GitLab's machinery may still be in it's infancy, but some kind of bot picking/testing/committing (even reverting, if necessary) your changes is a very common and scalable way of doing things. Or the other way round: If you don't do this, and your project gets bigger, you have an almost 100% guarantee that the code in your repository is broken in some way. :-}</div></div></div>