Peter,
Thanks for looking into this. I hope there are other DSpace users who
will benefit from my/our adventure. :)
I think part of the problem was a flaw in my understanding of the git
history. I incorrectly assumed that changes in the 1.7.x branch were
automatically in the 1.8.x branch (ie, a linear history). I now
understand that this isn't necessarily so. As I now understand it,
development of major revisions happens in the master branch. After
release, major revisions are given branches, and development of point
releases (security and bug fixes) on those revisions are committed to
those branches, for example dspace-1_7_x or dspace-1_8_x. Those changes
have no place in master, which is what causes them to rightly "diverge"
from master.
I'm wondering how to deal with this in the future. For now I've just done:
git checkout -b 1.8.x-dev dspace/dspace-1_8_x
git cherry-pick e320ebd..3d15c2e
Basically: checkout a new local branch based on the upstream
dspace-1_8_x branch, and then cherry pick all my changes in. This
cherry pick works because it grabs a sequence of commits containing only
MY commits; it would have been uglier if there were any upstream commits
in there (notice I apparently started our development branch on top of
what was already 1.7.2, and there were no upstream changes during that
time).
I guess in the future I'll do something like this:
- base my development on the upstream branch for the current stable
major revision, ie dspace-1_8_x
- when a new major upstream revision comes out (like 1.9), I will
interactively rebase my changes onto the new major revision's branch, ie
dspace-1_9_x. With the interactive rebase I can choose only MY commits,
and leave any upstream stuff (like point release fixes) out.
Any comments or suggestions, Peter?
Thanks again!
Alan
On 04/05/2012 07:28 PM, Peter Dietz wrote:
> 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
> 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)
> 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 <[email protected]
> <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> 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
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
--
Alan Orth
[email protected]
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++
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
