[llvm-dev] How to deal with accidental directory tree deletes, downstream?

Russell Gallop via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 17 09:38:16 PDT 2019

Hi Paul,

This caused merge conflicts for us due to local changes in
llvm/test/Transforms so was blocked from being merged. As we merge commit
by commit, I manually resolved the conflict merging r358546 by keeping
"ours" then restored the rest of test/Transforms ("git reset HEAD
llvm/test/Transforms", "git checkout llvm/test/Transforms") apart from
test/Transforms/LoopFusion which was supposed to be part of the commit
("git rm -r llvm/test/Transforms/LoopFusion"). When r358552 came to be
merged (also a conflict as we still had local files which were different
from the opensource files being re-added) I resolved in favour of "ours"
again. This effectively "edits out" the accidental delete between r358546
and r358552. This means that the files still exist in our tree through this
period even if they don't in opensource so git blame etc. still work (for
us locally). A slight discrepancy but hopefully not a problematic one.


On Wed, 17 Apr 2019 at 13:35, via llvm-dev <llvm-dev at lists.llvm.org> wrote:

> Hello fellow downstream residents,
> I see that r358546 accidentally deleted an entire subtree, which was
> reverted in r358552.  This of course caused a big merge conflict in
> our local repo, and internally we've been debating tactics for dealing
> with it, hopefully without losing our original history.
> Has anyone else handled this in a way that they are happy with?  We
> found a StackOverflow post that is potentially helpful:
> https://stackoverflow.com/questions/44990103/how-to-undelete-file-in-git-and-keep-his-original-blame-history
> Doing this on our local copy of the upstream repo means we would not
> have an exact copy anymore, which seems like a Bad Idea.
> Is there a smooth way to resolve the merge conflict that does *not*
> delete our local tree? I suppose we can somehow not accept the
> accidental deletes, and then when we run forward to r358552 it will
> decide we already have those files and it will Just Work?
> Tips and hints welcome.
> Thanks,
> --paulr
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/30d4054f/attachment.html>

More information about the llvm-dev mailing list