<div dir="ltr">To add to Philip's experience, and maybe I was using Github wrong somehow, but I found that force pushing to rebase resulted in a loss of information in the review for whatever reason (inline comments lost etc), making it hard to trace back what happened and what still needed addressing.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Nov 2019 at 16:43, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-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"><br>
On 11/8/19 9:29 AM, David Greene wrote:<br>
> Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
><br>
>> Weak -1 in general.  I'm not strongly opposed, but I see very little<br>
>> value in this migration and a lot of headache.  Others have explained<br>
>> this well, so I'll mostly skip that.  I particular dislike the assumed<br>
>> fork model; I work in patches, so that's a ton of overhead process wise. <br>
> Can you explain this a bit more?  The way I anticipate doing this:<br>
><br>
> 1. Create fork once for all time<br>
> 2. Set a remote for the fork in my local clone once for all time<br>
><br>
> while ((I am employed or financially independent) and working on LLVM)<br>
>   1. Make a commit<br>
>   2. Push to fork remote<br>
>   3. Open PR (probably right in emacs using Magit)<br>
>   4. Respond to comments, push further commits, squash as needed, etc.<br>
>   5. Declare done and request CI/merge<br>
> elihw<br>
><br>
> I would never delete the fork or the fork remote.<br>
<br>
In my experience, it isn't the simple workflow you've sketched where<br>
problems arise, it's all of the cornercases. <br>
<br>
Let's say I post a patch, and the (warranted) reviewer comment is that<br>
it should be split.  I push a couple new PRs, they get approved, and<br>
landed.  (All as new branches off master.)  Then, I have a stale branch<br>
(say it contains 2 commits) which needs rewritten.  I can of course do<br>
an interactive rebase, and a force push, but a) I've found interactive<br>
rebases to be very error prone, and b) I *strongly* prefer to never be<br>
in the habit of doing a force push.  The alternative is to close the<br>
original PR, and simply post a new one - which looses history of review. <br>
<br>
To be clear, my point is not that I can't do all that.  My point is<br>
there's a lot of conceptual overhead and room for error, which doesn't<br>
exists with the patch model.  My experience is pull requests work *very<br>
well* for simple things, and somewhat poorly for more complicates ones. <br>
<br>
(Again, the above is entirely personal opinion based on my own experience.)<br>
<br>
><br>
>> One exception for me would be docs.  If we could open pull requests -<br>
>> and possibly the web-edit tool for folks with commit access? - for the<br>
>> docs subtree I could see a lot of advantage in making those easy for new<br>
>> contributors to update.  It might also be a good proving ground for the<br>
>> workflow as a whole.<br>
> That's a really great idea!<br>
><br>
>                   -David<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>