Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > On Wed, 25 Mar 2009, Junio C Hamano wrote: > >> This seems to follow the model of git-svn in that we treat our history as >> throw-away, export the history and give the authority to the other system >> by discarding and replacing our history with whatever the other end gives >> back to us by re-importing. Because git is more flexible than anything >> else, we could afford to do so, but I wonder if it is the right model and >> mentality. > ... > But, as a general principle, the reason a git developer would push to a > non-git remote repository is because the remote repository is > authoritative. I don't think it makes sense to have an environment > where the authoritative history is in git, but people are sharing it > through a bzr server (even if the bzr server can accurately represent > the git history). Suppose a project used to use subversion, but it migrated to git (not an unheard-of scenario these days, I hope). The git repository now is the authoritative one, all the development happens on this side. But in order to help: - people who have established their workflow to follow the project (e.g. not necessarily contributing anything back, but just doing regular "svn update"); - people who have leftover local changes from the subversion days; and - other project infrastracture (e.g. trac) that the project hasn't managed to interface to the new git repository yet; the project decides to keep feeding recent updates to the subversion repository that used to be authoritative, even though it is now declared read-only (i.e. the only update comes from the git end). My understanding is that the above scenario would not work if git-vcs-svn rewrites commits when git exports to svn, and existing git-svn two-way interface using its "dcommit" may have exactly the same issue. The reason I brought this up was to involve people who have already faced this issue with git-svn in the discussion to see if we can avoid it by doing somethink similar to clever tricks they are using in their git-svn workflow, if there are some. Perhaps your paragraph below may be one of those clever tricks, but there may be others. > I think it might be possible to do something where the synchronization > point has a list of authoritative commit-swaps, where it can tell the > multiple developers: "commit Y is really the same thing as commit X; they > have the same tree, and their parents Y1..Yn are the same as X1..Xn > (either based on the same criterion applied recursively, or having > identical hashes)". This list of commit-swaps allows the developers to be > comfortable with trivial rebases (in a commit Z with X as a parent, make a > commit Z' with Y replacing X and no other changes, and replace Z with Z' > in refs and other commits). Of course, this depends on being able to get > the foreign system to agree on both complete content and history topology, > but otherwise we kind of have to throw away our history, because the > public history simply can't be like what we've made locally. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
