Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You should be able to do this with a graft. Grafting is designed to be used for bringing in legacy repositories is my understanding. It lets you <em>manually</em> tell git that some ref has a common parent.</p> <p>As mentioned in the comments, there may be a simpler solution. This would work if all else failed though.</p> <p>You'd pull down the current git repo (either with git or git-svn) and add your old git-svn repo as a remote. They won't be related, so gitk will look like this:</p> <p><img src="https://i.stack.imgur.com/I8uaJ.png" alt="unrelated ancestry"> </p> <p>I had an incident at work where we had some do a file system copy instead of an svn copy, so some of my branch names allude to that. Hopefully it all makes sense anyway. Pretty lucky that I just happen to have all these images and story. What are the chances!? Probably pretty good, git-svn is easily confused.</p> <p><img src="https://i.stack.imgur.com/5ZW59.png" alt="naming branches"></p> <p>The copied_from branch is where they copied from. The graft_ref is where this met up. They had added a bunch of files, changes properties, and then changed some of the files. It was a bit of a mess.</p> <p>The general idea is to get the index of the original source, but the file contents to match the modifications. So we start in the ref branch, then reset mixed to get the index.</p> <pre><code>$ git checkout graft_ref $ git checkout -b graft_parent $ git reset --mixed copied_from </code></pre> <p><img src="https://i.stack.imgur.com/Naxqb.png" alt="reset mixed"></p> <p>If you didn't make changes between the two branches when it was broken, then you shouldn't have to worry about this step.</p> <pre><code>$ git commit -a -m "svn_branch changes made on svn_trunk filesystem copy" </code></pre> <p>Now we need to do the actual graft. I trimmed the hashes here for readability.</p> <pre><code>$ git log -1 --pretty=format:%H graft_ref 631d3c84e35de98236c3d36c08d14ec92f9c62ae $ git log -1 --pretty=format:%H graft_parent 96a4e87b554e0030035d35ca3aac23e9d71962af $ echo "631d3... 96a4e8..." &gt; .git/info/grafts </code></pre> <p><img src="https://i.stack.imgur.com/fXum4.png" alt="grafted"></p> <p>Which looks about how you would expect. Now we just need to rebase the changes up the tree. My notes are missing for this, but I think this is what I would have done, hehe.</p> <pre><code>$ git checkout svn_branch/master $ git checkout -b consolidate_changes </code></pre> <p><img src="https://i.stack.imgur.com/v3w9Z.png" alt="consolidated"></p> <pre><code>$ git rebase master </code></pre> <p><img src="https://i.stack.imgur.com/ThQ6T.png" alt="rebase"></p> <p>You should be able to push these changes where ever. Grafts are not tracked by git though, so the grafted branch (svn_branch/master and friends) will break again. It is effectively a dead tree unless you do the graft again. For git-svn this isn't much of an issue because you just commit changes and then pull the source down again as a clean copy.</p>
    singulars
    1. This table or related slice is empty.
    1. PO"Unable to determine upstream SVN information from working tree history"
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTom Kerr
    1. USTom Kerr
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO"Unable to determine upstream SVN information from working tree history"
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. CO+1, very nice answer (from one of your blog posts, maybe...?). I'm not sure if it's directly applicable to the problem being addressed (for that, a simpler solution may be most appropriate), but as an applicable and usable procedure for grafting changes across repositories in an inconsistent state, I completely approve. :)
      singulars
      1. PO
      1. USMrGomez
    2. CO@MrGomez I hope there is a simpler solution. :)) All else fails, I am fairly certain it would work though.
      singulars
      1. PO
      1. USTom Kerr
    3. COSo, essentially, I start from a fresh repo, insert my topic branches into the not-broken git-svn history at the right point via a graft, and use rebase to make the graft obsolete. Did I get the right end of the stick?
      singulars
      1. PO
      1. USams
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload