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

[via llvm-dev]

@echristo not blaming you, Bad Stuff happens, I managed to delete an
entire tree in an internal repo once.

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Simon
> Pilgrim via llvm-dev
> Sent: Thursday, April 18, 2019 5:14 AM
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] How to deal with accidental directory tree
> deletes, downstream?
> 
> test/Transforms svn log has been lost in the same way as git blame - if
> there's any way that we can get both back it'd be very useful!

Hi Simon,
We'd probably have to take down the repo, reconstruct the SVN history from
the git history, and then everybody in the world would have to rebase or
reclone to synchronize with the new history.  I don't think one test tree
would be disastrous enough to warrant that sort of heroic measure, but it's
really up to the Foundation to figure that out.

IIUC the history is actually still there, just harder to find; you need to
checkout a branch prior to the mass delete, and the old history will be 
there. It's just not directly accessible from HEAD.
--paulr

> 
> On 18/04/2019 08:11, Mikael Holmén via llvm-dev wrote:
> > Hi,
> >
> > Isn't this a bit of a nuisance also directly on trunk and not only for
> > downstream repos?
> >
> > If I do e.g.
> >
> >    git blame test/Transforms/LoopUnroll/basic.ll
> >
> > then every line in the file is attributed to the commit where the
> > testcases were added back again.
> >
> > With
> >
> >    gitk test/Transforms/LoopUnroll/basic.ll
> >
> > older commits are shown as well so it's not like all history is gone,
> > but at least blame is messed up.
> >
> > For our downstream clone, we didn't merge from trunk to our
> > development-branch while the testcases were gone, so we never got any
> > conflicts at all, and since the tests were later put back I think the
> > situation for us now is the same as being directly on trunk.
> >
> > /Mikael
> >
> >
> > On 4/17/19 2:35 PM, via llvm-dev 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
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev