There's a "hole" in the git-history in new solr repo, so filling that hole with the missing commits is a valid wish - so you can brose the entire history of Solr from one repo, and investigate recent changes to a file from IDE. I guess now GIT would lie to you and tell you that the previous edit to files was a year ago?
Sure, the history will remain in lucene-solr.git and that would be the authoritative repo for that period of development, as svn is the authoritative repo before git etc. Still, we chose to import svn history into git for some valid reason I guess? I have not missed that particular history myself so far, but +1 to get it consistent in one way or the other. Jan > 6. jan. 2022 kl. 14:57 skrev David Smiley <[email protected]>: > > Removing the old tags is valid too. But the current state is > confusing/inconsistent and something should be done. Thanks for raising this > Houston. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Thu, Jan 6, 2022 at 8:56 AM Uwe Schindler <[email protected] > <mailto:[email protected]>> wrote: > I agree with Dawid, why the hell do we need those tags? The old lucene-solr > repo can stay forever on Github. If I want to checkout an older version, I > would go into the old repo and check it out. In fact that’s also what tools > may do, because the old git repo is stated in the pom.xml files (or similar). > > > > I would rather go and nuke the tags (not the commits of course) from new repo > for everything before 9. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de <https://www.thetaphi.de/> > eMail: [email protected] <mailto:[email protected]> > > > From: Dawid Weiss <[email protected] <mailto:[email protected]>> > Sent: Wednesday, January 5, 2022 8:17 AM > To: Lucene Dev <[email protected] <mailto:[email protected]>> > Cc: Solr Dev <[email protected] <mailto:[email protected]>> > Subject: Re: Mirroring the later 8.x release tags in the "new" split > repositories > > > > > > I did mean that we should be pushing the tags as well as their associated > commits. > > > > You can even edit them by hand so you can definitely have references pointing > at void... > > > > I already expressed my opinion on the matter but I won't object if you wish > to do it. The problem I see is that it's really easy to break things in a > catastrophic way by force-pushing refs or by pushing refs that shouldn't be > copied - it's not hard, but it's easy to make a mistake. I'd try out ten > times on a bare test clone somewhere before actually doing it on the target > git repository. > > > > But it is definitely doable. Git repositories are conceptually very simple - > just a graph of commits and tags/ labels. > > > > Dawid >
