By dman on

Status.
I have http://drupal.org/project/pdf_to_imagefield which has a shaky, non-working D7 branch open
InternetDevels.Com has rewritten it as http://drupal.org/sandbox/InternetDevels.com/1415404
and that's pretty much a total replacement, with not a lot in common any more.

I suspect that there is a git-wizard way of bringing/merging that into this project, pulling whatever history with it. History is not vital in any way, but I'd like to learn if there was a way to do this properly.

In my naive get-r-done way, I can imagine
* branching my project to a 7.x-2.x branch
* git deleting everything
* manually copying the replacement files into there and re-adding.

I'm pretty sure that would work fine.

But I'd like to know if anyone can suggest a power-user git way that would do it the "right" way. Can I get git to say "make a new branch using the files from a different repo and make them my own from now on"?

Thanks!

⋅ Categories: Drupal 7.x

Comments

dman’s picture

dman commented

Based on some searching at http://stackoverflow.com/questions/2949738/git-merge-different-repositories
I'm looking at something like:

export REPLACEMENT_NAME=pdf_to_image;
export REPLACEMENT_PATH=http://git.drupal.org/sandbox/InternetDevels.com/1415404.git
export REPLACEMENT_BRANCH=7.x-1.x

git remote add $REPLACEMENT_NAME $REPLACEMENT_PATH
git fetch $REPLACEMENT_NAME 
git merge $REPLACEMENT_NAME/$REPLACEMENT_BRANCH

At this point I get 

Automatic merge failed; fix conflicts and then commit the result.

Which is not altogether unexpected.
Am I on the right path?

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dman’s picture

dman commented

Second attempt.
It feels like this is not a lot different from my handmade delete-and-replace method, but it does at least let git get involved in the process.

# Using some variables so you know which bits you need to customize
export REPLACEMENT_NAME=pdf_to_image;
export REPLACEMENT_PATH=http://git.drupal.org/sandbox/InternetDevels.com/1415404.git
export REPLACEMENT_BRANCH=7.x-1.x
export NEW_BRANCH=7.x-2.x

# Add a reference to the other repository to our project
git remote add $REPLACEMENT_NAME $REPLACEMENT_PATH

# Fetch those files (but not use them yet)
git fetch $REPLACEMENT_NAME 

# This deserves a new branch. Set it up and switch to it
git checkout -b $NEW_BRANCH

# Merging over the live version just can't work 
# as these two have nothing in common. Remove the old.
git rm -r *
git commit -m "Clearing out the old files to make way for a remote replacement" -a

# 'Merge' onto an empty directory is really just a copy, 
# but it keeps the timeline simple I think.
git merge $REPLACEMENT_NAME/$REPLACEMENT_BRANCH

# Seems no commit was needed, 
# a log about the merge was automatically committed.

I think I'm in the right state now.

Am I right?
Should I have deleted the files before branching? does the new branch have these old files added and removed as the first part of its history? Probably doesn't matter, but could I have done something to ensure my new branch STARTED empty?

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dman’s picture

dman commented

The above steps seem to have worked successfully. The bonus above doing it by hand is that The developer who built it in their sandbox gets proper attribution (and blame) in the git history in this project. This is excellent.
Even though I only just added InternetDevels.com as a maintainer, there are already commits showing up on the project page. I like this.

The above steps were followed up with a 

git push origin $NEW_BRANCH

to finally push these changes and the new branch back to d.o.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dman’s picture

dman commented

Update. The same process worked (with minimal issues) when pulling from a github repository and merging it to a project also.

I needed to set 

  export GIT_SSL_NO_VERIFY=true

in order to get at github in the first case, and I needed to re-add the files with 

   git add .

after the merge command (not sure why it's different this time) but after that, I ended up with a new D7 branch that started life somewhere else entirely.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dozymoe’s picture

dozymoe commented

When trying to upgrade jquery-freebase, timplunkett from #drupal-git IRC, adviced using git cherry-pick, that is if you plan to be meticulous on what changes you want to pull to your project, in case of a pull request or something.

dman’s picture

dman commented

It appears that cherry-pick can work if the code has a common ancestor. I hadn't actually realized that your github branch was a true cloned branch of the original project. So yes, it should have been possible to re-merge via cherry-pick in this case.

In my other use-case previously, the code I was trying to import had lost its historical roots to the original, so it was (probably?) unable to to be cherry-picked in in the same way. Also, I'me not reviewing changes, really just happy with a complete overwrite.
But thanks. it's worth further investigation next time I have to do this!

.dan. is the New Zealand Drupal Developer working on Government Web Standards