Keeping two repos in sync
Hi all, I'm wondering how best to go about this problem. I've got two separate git repositories -- one is a portable version which I'll call portable, the other is part of a BSD project, which I'll call bsd. Both repositories have the same set of *conceptual* files in them, it's just that the portable repository has additional files which are not found in the bsd repository. It should be noted that the bsd repository is an automatically managed cvsexport clone of a CVS repository -- but I don't think this matters here, as we're just talking about two git repositories. The workflow if you can call it that, is commits happen in the bsd repository and are then put in the portable repo. At the moment, I am using git grafts to do this. The important point to remember here is the two repositories DO NOT have any common history to them -- it's just that where the files are the same in both the bsd and portable repository I can see and hence tell git, where to graft the two master branches from each repository and for me to merge bsd:master - portable:master. However, I am wondering how best to handle this situation. It's pretty convoluted -- not to mention the fact that git grafts are never permanent. What I'd like is for some safe way of setting up an initial git graft which tied the two master branches between bsd and portable to reflect changes on bsd:master not on portable:master and then for me to treat those two branches as though they shared common history so that I can merge one to the other. Unfortunately, what I'm doing at the moment is each time changes happen to bsd:master, I'm having to reset the git graft each time; and since that operation is a local one, it makes things rather awkward in a shared repository situation as I am the sole person who can perform these merges. I'm guessing I could rebase at some point and push those changes out? I'm just wondering how other people handle this situation or if it's just unique to me? Kindly, David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keeping two repos in sync
Hi, On 9 September 2012 09:36, Andreas Schwab sch...@linux-m68k.org wrote: Add bsd as a remote in portable and cherry-pick each commit in bsd. I am already kind of doing this at the moment. Hence: 1. In portable, I have: % git remote add bsd /path/to/bsd/repo % git fetch bsd 2. At this point I scan the two branches looking for a point to graft; I might have done this already in the past, but the point is since grafting is a local operation and I am not working in that repository, I might need to do it again anyway -- that graft represents a way of tieing the branches together at a point I can then git merge. Kindly, David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
Hi, Earlier this month I asked how best to handle two branches without a common ancestor to sync changes from one branch to another. Initially I did this via the grafts mechanism, but this wasn't a shared solution, in that the graft was local to my checkout of the repository and no one else's. I read on StackOverflow that git-replace can be used instead. Having read this: http://stackoverflow.com/questions/3810348/setting-git-parent-pointer-to-a-different-parent I followed the instructions to use git-replace. Have successfully done that, I was then able to merge the two branches which didn't have a common ancestor and have the correct commits on the branch I was hoping for. AFAIAC, this worked fine. But now I have some questions: 1. I thought the replace data in .git/refs/replace was published when I did git push so that others could use this information as a base-point, yet it seems not to be the case. How do I publish this? 2. If I do publish it, are there any caveats with that? i.e., because the replace data will likely point to a repo which in my working checkout I added with git-remote, is that going to be a problem? I assume I can instruct people who care, to git remote add foo and then treat master and foo/master as intended? i.e., foo/master will see commits on it over time which master won't have, so git checkout master git merge foo/master can always happen? 3. If it is possible to publish this replace data, is there anything which needs to happen in .git/config either on the bare repo or local checkouts? What I'm aiming for now, in publishing this merge, is that if I can publish the replace data, that people besides me, can clone the repo, and the remote repo in place, and merge the branches as outlined in question 2. What I also am unsure of is whether or not I have to keep updating the replace refs each time I merge the branch? TIA! David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
Hi, On 15 September 2012 18:21, Junio C Hamano gits...@pobox.com wrote: David Chanters david.chant...@googlemail.com writes: 2. If I do publish it, are there any caveats with that? i.e., because the replace data will likely point to a repo which in my working checkout I added with git-remote, is that going to be a problem? That is between you and other project participants. They may not want to see replacement in their project in the first place. Assuming that they do, pushing the replacement ref makes the replacing object available in the pushed-into repository, so they will *not* rely on your repository. This makes sense. But it is more the mechanics of what happens with needing to update the fetch line for the remote in .git/config I am more puzzled by. For example, if I have two repos -- repoA and repoB, where repoA contains the replace refs for repoB -- if I clone both repos with the intent of wanting to look at the two histories, what must I do in repoA to fetch the replace refs in the first place? I've tried: [remote origin] fetch = +refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/* But this results in: % git pull fatal: Invalid refspec '+refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/*' So I'm clearly not understanding something here, and even then, I'm assuming that I can manipulate the correct fetch line via git config, it's just that I'm not sure which one to use. I keep meaning to read up on refspec stuff because it looks so useful. Kindly, David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
