<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 7:32 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I use GH daily at my current employer and i can tell you that the issues with rebasing are very real.  Unless you only use merge commits you are going to have a very bad time<br>
<br>
Would it be practical to use merge commits during review (never<br>
rebasing) & then rebasing/squashing to commit to the main line?<br>
(guessing that might still make looking back at the history of the<br>
review difficult?)<br></blockquote><div>A merge appears in the UI as introducing many, many commits. Also, a key method of progressing reviews on Phabricator (for me) is to go through the differences between the updates. If there is a merge in between on GitHub, I don't want to see all the changes that come from the merged commits.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Dave<br>
</blockquote></div></div>