[Bioc-devel] Bioconductor Git/GitHub Mirrors

[Siddhartha Bagaria]

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
>>
> ​
>

	[[alternative HTML version deleted]]