[Bioc-devel] Bioconductor Git/GitHub Mirrors
Thank you Jim for your reply. SubGit does highlight its ability to handle non-linear histories as compared to GitSVN -- http://www.subgit.com/documentation/gitsvn.html. I will keep looking as well. Thanks.
On Wed, Jul 15, 2015 at 9:03 AM Jim Hester <james.f.hester at gmail.com> wrote:
Sid, I think you have characterized the main issue well, a number of people have run into issues stemming from the same problem. ( https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html, https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007730.html and a number of off-list queries). As you mentioned the problems stem from the fact the SVN repositories has only truncated history compared to the git repositories. Because git-svn only handles completely linear histories even if you merge the two histories locally you can still run into problems when running git svn dcommit. I agree syncing the SVN history with the original GitHub history should in theory fix this problem, however because you cannot rewrite history with SVN I am not positive it is actually possible to accomplish. I will investigate that stackoverflow answer to see if there is any techniques we could apply here, thank you for the link I had not come across that previously. I am also separately investigating a SubGit <http://www.subgit.com/> solution that I believe will address this issue and also allow users to interact with Bioconductor repositories exactly how they would with any other git remote. Thank you reaching out, this is definitely a pain point I am aware of and trying to actively address. The current solution is IMHO less than ideal. I would be happy to talk at Bioc2015 next week if you want to discuss in person. Jim On Tue, Jul 14, 2015 at 4:34 PM, Siddhartha Bagaria <sidb at google.com> wrote: [cc]: bioc-devel for discussion with wider community.
Hello Jim! This is related to using the new git mirror setup with pre-existing github repos (not forks of the mirror). I tried following the thread on https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007725.html but it looks like the problem was not clearly reproduced, and a solution was not reached. I will briefly describe the problem here but am inclined to discuss possible solutions further in person during the upcoming conference if you will be there. The problem with an already existing github repo in the new setup is that the master branch of that repo will have its own commit history, which will be different from the svn commit history (no common ancestor). As a result, merging the entire master branch into the newly created devel branch will try to merge all the commits from master since the beginning. Because there is no common ancestor, all the new edits will appear as merge-conflicts. One can manually resolve these conflicts but the process is cumbersome and error-prone. One way of skipping to manually resolve all the conflicts is merging the commits from devel into master first with strategy "ours", so that master gets the commit logs from devel but the content in master is unchanged (to avoid addressing conflicts). After this, a merge back into devel will work without conflicts. However, there is a problem with both these merge approaches. After a resolved merge (through manual resolution of conflicts, or through pre-merging histories), the commit histories between devel and master branches will be in sync, but the commit history in devel will now have extra entries from master interleaved with its previously existing entries. This would mean that now the devel branch and the svn repo do not have a common history. 'git svn' will get confused by these interleaved commits and will complain "Unable to determine upstream SVN information from HEAD history". So a merge does not work with this setup. The easiest solution so far is to cherry-pick the new commits from master and only merge those with the devel branch, so that svn and git continue to share a common history up until the cherry-picks. While this works smoothly, this is error-prone again as a commit can be missed when manually cherry-picking. It seems like one solution would be a one-time ability to sync the commit history of SVN repo with the commit history of the original github repo. This way, all three repos will have common ancestors. Other solutions which I have not studied in depth include: http://stackoverflow.com/questions/3864934/how-do-i-re-integrate-a-svn-and-git-repository-without-a-common-history Let me know if you would like a reproducible example. I am happy to discuss more. Cheers! Sid
?