> 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? >
It doesn't lie - it tells you the truth how it sees it (the new repository does not have any commits made to another repository). It's pretty much like any forks work until they're merged somehow. If you'd like to keep the commits made to lucene_solr in the solr repository then occasional merging would be sufficient to keep this in sync. > Sure, the history will remain in lucene-solr.git and that would be the > authoritative repo for that period of development, > It would be an identical set of commits, with the same hashes, etc. So it's not in any way "not" authoritative - you could take the new repo, make new commits on top of those on the 8x branch and then push these to the old repo. This is how git works (with multiple remotes) and there's nothing wrong or odd with this. > as svn is the authoritative repo before git etc. Still, we chose to import > svn history into git for some valid reason I guess? > It's different - we wanted to preserve the history of the project and changes made in the past. We never wanted to replay any changes made to svn (in theory we still could add something there) on top of the git. I went through cvs-svn-git conversion in multiple projects and the intention was always the same: preserve historical information about changes. Anyway, if you guys want to keep those git repositories in sync then I'll not stand in the way. I don't understand the point of doing it but it's essentially not much more than adding a few commits and references to new repositories. Dawid
