Skip to content

[Bioc-devel] Git svn mirror: Duplicated commit entries (introduced by git svn rebase?)

2 messages · Dan Tenenbaum, Jim Hester

#
Hi Henrik,

I am not an expert in these matters but I'll take a stab at this (I have asked someone who might know but have not yet heard back).

See below.


----- Original Message -----
BTW you should probably change the repo comment on this repo as it refers to the defunct git-svn bridge.
I'm not sure why you did this forking. You could have just run update_remotes.sh in
https://github.com/HenrikBengtsson/aroma.light . But it doesn't do any harm, I guess, you just have to keep track of where you want your development to happen.
I think this is a result of the old git-svn bridge being kind of brain dead, which I can say because I wrote it. 

One thing you might want to try is...

- git checkout devel
- do your git svn rebase, make a note of the first and last commits that 
  are pulled down (let's call them FIRST and LAST)
- check out a temporary branch. (git checkout -b temp)
- git cherry-pick FIRST..LAST . You might need to resolve some conflicts here.
  This will basically 'replay' all those commits into a single new commit.
- git checkout master
- git merge temp
- if all looks ok, then push

Not sure if I've totally addressed your actual problem here, but HTH anyway....

Dan
#
The Git-Bridge commits are in SVN, so unfortunately there is no good way to
avoid the duplication as they will be reintroduced each time you run `git
svn rebase`. Here is the corresponding commit in the Git mirrors directly
from SVN (
https://github.com/Bioconductor-mirror/aroma.light/commit/a0ee1399c24d36b96d5f737907228e250b5ffcba
).

Because of this the best way to have a clean history on the Git side is to
handle all interaction with SVN in a separate branch and simply cherry-pick
the commits you want to commit to SVN from your master branch when needed.
Trying to use `git svn rebase` directly on your master branch will cause
the duplication you observed.

See
http://bioconductor.org/developers/how-to/git-mirrors/#dealing-with-prior-history--merge-conflicts
for an example of this approach.

I realize this is not an ideal workflow, however because SVN commits are
immutable there isn't a lot that can be done to clean up the history
retroactively.

Jim

On Tue, Feb 23, 2016 at 2:59 PM, Dan Tenenbaum <dtenenba at fredhutch.org>
wrote: