[Dspace-tech] Problems with official git repo?

2012-04-05 Thread Alan Orth
All,

I'm happy that DSpace is now hosted officially on github, it's a great 
place for code to live!  I'm having a problem with my normal git 
routine, though...

I set out to test upgrading our DSpace 1.7.x to 1.8.x and I noticed that 
there are some continuity issues in the history between branches[2]; on 
clean clone of the official DSpace repo[1], I cannot merge 1.8.x changes 
into 1.7.x without getting hundreds of merge conflicts:

git clone https://github.com/DSpace/DSpace
cd DSpace
git checkout -b 1.8.2-test origin/dspace-1_7_x
git merge origin/dspace-1_8_x

Maybe Peter or someone else more involved in the SVN - git transition 
can comment about?  If this is a known issue with no fix, maybe I should 
just rebase our local changes on top of 1.8.x?

Thanks!

[1] http://github.com/DSpace/DSpace
[2] graphical view of branches: 
http://img6.imagebanana.com/img/0bcnxp6y/gitkDSpace_010.png

-- 
Alan Orth
alan.o...@gmail.com
http://alaninkenya.org
http://mjanja.co.ke
I have always wished for my computer to be as easy to use as my telephone; my 
wish has come true because I can no longer figure out how to use my telephone. 
-Bjarne Stroustrup, inventor of C++


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech


Re: [Dspace-tech] Problems with official git repo?

2012-04-05 Thread Peter Dietz
After looking deeper into your situation, your problem is not that 1.7.x
and 1.7.2 are diverged, but that 1.7.x and 1.8.x and trunk/master are all
diverged. This is fine, thats the shape of the tree. if you scroll back
long enough you'll see common branch/split points between each version. I
didn't see anything that makes me think the git repo is having issues.

So Alan, I did clone your repo because I think thats the only way to fully
understand this. And three cheers for providing the perfect example to help
us get through these transition pains.

User Story:
Alan has customized his DSpace repository they were on the 1.7.x branch,
but would now like to upgrade to 1.8.x. He's noticed that he  wants to get
his changes on 1.7 into the 1.8 work, so that they can use 1.8 and continue
development off of 1.8.

The Problem:
Alan's first attempt was to merge 1.7.x into 1.8.x
git checkout -b 1.8.2-test origin/dspace-1_7_x
git merge origin/dspace-1_8_x

That will create a new commit that will have two parents
- The commit sitting at 1.7.x
- The commit sitting at 1.8.x

It will also result in a massive conflict as Alan only wants his changes
(mostly to XMLUI theme stuff), but he's carrying all of the modifications
between 1.8 and 1.7 into the situation. Git is just trying to do as its
told and create a new version of every file in 1.8 and 1.7
that accommodate all the changes in 1.8 and 1.7.

The Really Easy Solution:
git cherry-pick SHA1-parent-of-first-commit..SHA1-latest-Commit-Of-Yours

You can grab just the commits that your local repository customization team
has created on 1.7.x, (cherry pick them), and apply those changes on-top of
the 1.8.x branch. The result is that you now have a 1.8.x branch with
several dozen new commits that are all your local customizations.

A bit more detail into how I solved this.
You have to find the range of commits you'd like to cherry-pick. In Alan's
case, he's got a branch called development with 30 or so commits, that
started from dspace-1_7_x.

Find the sha1ID of his latest commit: (xmlui: Clean up the CCAFS banner) :
3d15c2ea
[image: Inline image 2]


Then, find the parent commit, of his first commit.
His first commit is: (Add ignores for webapp build folders) 570fdb, but we
don't want that commit ID. We need the parent.
The parent to his first commit is e320ebd8   ([maven-release-plugin]
prepare release dspace-1.7.2)
[image: Inline image 3]


So now that we know his last commit is 3d15c2ea and the parent of his first
commit is: e320ebd8 we have our range.
So we checkout to where we want these cherry-picks to end up.
git checkout dspace-1_8_x

And perform the cherry-pick operation.
git cherry-pick e320ebd..3d15c2e

After starting the cherry pick, git will do a whole lot of magic applying
all of your modifications to the end your current branch (dspace.1_8_x in
this case).

Best of all, in Alan's example, there were no commit conflicts, because
their changes were just creating new XMLUI themes. If he happened to have
modified some core files that are likely to have also been modified between
1.8 and 1.7, then you might run into some easy enough to resolve conflicts.

Peter Dietz



On Thu, Apr 5, 2012 at 2:45 AM, Alan Orth alan.o...@gmail.com wrote:

 All,

 I'm happy that DSpace is now hosted officially on github, it's a great
 place for code to live!  I'm having a problem with my normal git
 routine, though...

 I set out to test upgrading our DSpace 1.7.x to 1.8.x and I noticed that
 there are some continuity issues in the history between branches[2]; on
 clean clone of the official DSpace repo[1], I cannot merge 1.8.x changes
 into 1.7.x without getting hundreds of merge conflicts:

 git clone https://github.com/DSpace/DSpace
 cd DSpace
 git checkout -b 1.8.2-test origin/dspace-1_7_x
 git merge origin/dspace-1_8_x

 Maybe Peter or someone else more involved in the SVN - git transition
 can comment about?  If this is a known issue with no fix, maybe I should
 just rebase our local changes on top of 1.8.x?

 Thanks!

 [1] http://github.com/DSpace/DSpace
 [2] graphical view of branches:
 http://img6.imagebanana.com/img/0bcnxp6y/gitkDSpace_010.png

 --
 Alan Orth
 alan.o...@gmail.com
 http://alaninkenya.org
 http://mjanja.co.ke
 I have always wished for my computer to be as easy to use as my
 telephone; my wish has come true because I can no longer figure out how to
 use my telephone. -Bjarne Stroustrup, inventor of C++



 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech

--
Better than sec? Nothing is better