<div dir="ltr">Hey Paul,<div>Maybe use a pull request type model for merging in upstream commits to your internal repository?  I know it is not the cleanest method of merging upstream commits, but it would allow you to gate your upstream merges on a quick and dirty merge test and then you could alert an engineer to the merge problem before it hits your mainline branch?  In the scenario you described below, r358546 would have come in on a separate branch and attempted to merge with master (assuming your main dev branch is called master).  When the merge failed an engineer could have been notified and begun to work through the issue to see what the best course of action would be.  I'm really over simplifying here, but the point is, when possible, test each commit coming from upstream in as much isolation as possible, prior to merging.  I'm a big fan of pre-commit testing and of pull requests.  If there is a way, which works for you to integrate automated pull requests into the upstream merging workflow, it may be of benefit.  Hope this helps.</div><div><br></div><div>-Mike</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 17, 2019 at 5:36 AM 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">Hello fellow downstream residents,<br>
<br>
I see that r358546 accidentally deleted an entire subtree, which was<br>
reverted in r358552.  This of course caused a big merge conflict in <br>
our local repo, and internally we've been debating tactics for dealing <br>
with it, hopefully without losing our original history.<br>
<br>
Has anyone else handled this in a way that they are happy with?  We<br>
found a StackOverflow post that is potentially helpful:<br>
<a href="https://stackoverflow.com/questions/44990103/how-to-undelete-file-in-git-and-keep-his-original-blame-history" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/44990103/how-to-undelete-file-in-git-and-keep-his-original-blame-history</a><br>
Doing this on our local copy of the upstream repo means we would not<br>
have an exact copy anymore, which seems like a Bad Idea.<br>
<br>
Is there a smooth way to resolve the merge conflict that does *not*<br>
delete our local tree? I suppose we can somehow not accept the<br>
accidental deletes, and then when we run forward to r358552 it will<br>
decide we already have those files and it will Just Work?<br>
<br>
Tips and hints welcome.<br>
Thanks,<br>
--paulr<br>
<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>