Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Disclaimer: I have now tested this, and it seems like it works as expected (assuming I understood you correctly, of course). However, there's still a lot that can go wrong. <strong>Absolutely only try this out on a separate working copy of your project's repository, and make sure to examine everything before pushing it anywhere. Keep full directory backups of the state before you did this.</strong></p> <p>So I assume you have two independent repositories. The original project (Gephi):</p> <pre><code>A---B---C---D---E ^ HEAD of Gephi </code></pre> <p>And your project, whose first revision looks identical to the original project's last revision:</p> <pre><code>E'---V---W---Y---...---Z ^ HEAD of your project </code></pre> <p>(possibly with some branches, but that doesn't really matter here.)</p> <p>What you'd like to have (if I understood correctly) is:</p> <pre><code>A---B---C---D---E---V---W---Y---...---Z </code></pre> <p>You could try the following. <strong>Again, do this on your own, separate working tree, and make sure everything is in order before pushing this to any central repository!</strong></p> <p>While in the directory of your own working tree, fetch the heads and objects of the original Gephi repository:</p> <pre><code>git fetch /path/to/original/gephi </code></pre> <p>If you haven't cloned the Gephi repository, you might as well specify the github URL instead of a local filesystem path.</p> <p>This will result in the following situation in your current working tree:</p> <pre><code>A---B---C---D---E ^ FETCH_HEAD E'---V---W---Y---...---Z ^ HEAD </code></pre> <p>We haven't changed a lot. Currently, the two heads coexist peacefully and completely independently from each other, but you now have access to the objects from both repositories and can try to combine them.</p> <p>We now want to discard E' (it should be identical to E), and instead make E the parent of your project's first commit, which is V. To do this, you can use <code>git filter-branch</code>:</p> <pre><code>git filter-branch -f --parent-filter 'test $GIT_COMMIT = &lt;V&gt; &amp;&amp; echo "-p &lt;E&gt;" || cat' </code></pre> <p>Replace <code>&lt;V&gt;</code> and <code>&lt;E&gt;</code> by the commit hashes of V and E respectively. To find those out, you can do <code>git log</code> to examine your project's commits and, since we've fetched them, <code>git log FETCH_HEAD</code> to examine Gephi's commits.</p> <p>This will effectively connect V directly to E.</p> <p>This should even work if it turns out that the head (i.e. the latest commit) of the original Gephi repository isn't what you based your project on, meaning that there have been new commits in Gephi that you haven't (yet?) taken care of. Just be sure, again to substitute <code>&lt;E&gt;</code> with the hash of the commit that you have based your changes on, <em>not</em> with the head.</p> <p>Conversely, be sure that you substitute <code>&lt;V&gt;</code> with the hash of the <em>first change you made</em>. Maybe your repository doesn't contain an E' identical to E, but the very first commit already contains changes toward the original. Then this first commit hash will be your <code>&lt;V&gt;</code>, instead of the one after it.</p> <p>To summarize both last paragraphs: the above command should also work if your situation looks like, for example, this:</p> <pre><code>A---B---C---D---E---F---G---H---I ^ ^ FETCH_HEAD point where your project branched off V---W---Y---...---Z ^ ^ HEAD first change based on E </code></pre> <p>Just make sure to use the commit hashes that make sense in this context.</p>
    singulars
    1. This table or related slice is empty.
    1. POMerge two repositories (original project and changed project WITHOUT HISTORY)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJulien Oster
    1. USJulien Oster
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMerge two repositories (original project and changed project WITHOUT 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. VTModeratorReview
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI just tested this, and it seems to work (so I updated my warning on top). I still absolutely advise you to try this out on a disposable working tree and to make full backups. It's easy to get the `filter-branch` statement wrong, or to mix up the hashes!
      singulars
      1. PO
      1. USJulien Oster
    2. COIf the local project has multiple branches, or if there are any merges in the history, `git rebase` is not the right tool because it will linearize the history. Use `filter-branch` instead.
      singulars
      1. PO
      1. USRichard Hansen
    3. COThanks. That was what I had originally, but I thought rebase had the easier syntax. I reverted my changes and it now only mentions filter-branch again.
      singulars
      1. PO
      1. USJulien Oster
 

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