[Bioc-devel] Git-svn: getting it to work while keeping your git history
Yes I will try and update the current documentation to address this situation. When it was first written we (I?) was not aware of all the issues with prior history, merging and how best to handle them. On Thu, Oct 15, 2015 at 2:00 PM, Leonardo Collado Torres <lcollado at jhu.edu> wrote:
Jim, Thank you! This works perfectly!! It'd be great to have this information at http://bioconductor.org/developers/how-to/git-mirrors/ I realize now that you already had mentioned using "git cherry-pick" at https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html and Siddhartha covered it in https://stat.ethz.ch/pipermail/bioc-devel/2015-July/007797.html I appreciate the detailed steps you outline in this thread! I'll also try to be careful to avoid the potential pitfall Sid mentioned. I'm guessing that for the first time you merge the git and svn histories, following Mike's steps would be the easiest. Then use "git cherry pick" from then on. Cheers, Leo On Thu, Oct 15, 2015 at 12:21 PM, Jim Hester <james.f.hester at gmail.com> wrote:
Leo, You can use your current git repo, please don't delete it or your
history!
The most foolproof way of using git-svn with existing git history is to
use
`git cherry-pick` to pick commits to add to the `devel` branch rather than merging changes
from
the master branch. This will avoid including the old pre-bioconductor inclusion commits so you won't have the rebase issues. You can use merges in your master branch (including from pull requests), but when you want to commit those
changes to
SVN you need to cherry pick the individual commits to include. You can give `git cherry-pick` a commit range to include like `git cherry-pick 52a6636565..408659187` and it will include all commits within that range. So the workflow would be, do work and commit in master then, ```bash git checkout devel git svn rebase # figure out what commit range to use and cherry pick them git log master git cherry-pick 52a6636565..408659187 git svn dcommit ``` In this way your devel branch remains completely linear (so no conflicts from git-svn) and you can retain your full git history in your master branch. I hope this makes sense, let me know if you have questions! Jim On Thu, Oct 15, 2015 at 12:04 PM, Leonardo Collado Torres <
lcollado at jhu.edu>
wrote:
Hi, Now that BioC 3.2 is released, I need a little bit of guidance on
git-svn.
I know that the bridges won't work anymore and my past attempt at the new git-svn setup was kind of a mess (see https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html). But I'm ready to give it another go. My understanding is that the easiest thing to do right now would be to fork https://github.com/Bioconductor-mirror/REPO and continue from there as in scenario 2 from http://bioconductor.org/developers/how-to/git-mirrors/ Doing so would mean losing the git history, which would mean losing links between commit messages and issues: well, the issues would be gone too, etc. In this scenario, I guess that folks in my situation could keep their current git repo somewhere as an archive of what happened in case the info is needed. However, from Jim Hester's message at https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008013.html I'm inferring that things would break again with a GitHub pull request that involved a git merge, which would be a bummer. Jim also mentions that there might be alternatives coming soon. Now, looking at other git-svn threads in bioc-devel I found that the steps Mike specified in https://stat.ethz.ch/pipermail/bioc-devel/2015-September/008018.html work well. I tested this yesterday with success. However, you have to keep following his steps every time you want to commit to svn because following the scenario 2 steps in http://bioconductor.org/developers/how-to/git-mirrors/ lead to a "unable to determine upstream SVN history" error. As of right now, Mike's steps are the best alternative for using git-svn and keeping your git history. I know that it would add spurious commits like
(from "git merge -s ours git_svn_starting_point_commit_id" step in Mike's instructions) and
(from "git checkout master; git merge devel" to merge back the svn history to git). It's not super clean, but it works. Or is there another option that I'm missing? Is there any reason why I should not follow Mike's steps? I'm guessing that any alternatives to git-svn will take a while to develop. Thanks, Leo Leonardo Collado Torres, PhD Candidate Department of Biostatistics Johns Hopkins University Bloomberg School of Public Health Website: http://lcolladotor.github.io/about.html