Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First off, are you sure this is what you want to do? There are two fairly standard solutions for this sort of situation in Git, but neither of them "zips" the commits up in exactly the way you want. The first option is just to merge "other" into "master", and delete the "other" branch. This does not leave you with a linear history, but everything is in the "master" branch, and you can look at the revisions in any particular order that you want (for instance, you can do <code>git log --date-order</code> to get the commits listed in the order that you want). You will get this history in the end:</p> <pre> A1 A2 M3 M4 *--*--*--* / \ --* *-- &lt; master \ / *----*---* B1 B2 B3 </pre> <p>You would achieve this by running:</p> <pre><code>git checkout master git merge other git branch -d other </code></pre> <p>The other option is to rebase your "other" branch on top of your master branch. This will give you a linear history, but all of your commits on the "other" branch will appear after the commits on "master." The dates will be preserved, so if you want to know when the commits actually happened, you can still find that out, but topologically, they'll be sorted afterwards:</p> <pre> A1 A2 M3 M4 B1 B2 B3 --*--*--*--*--*--*--*-- &lt; master </pre> <p>You can do this by running:</p> <pre><code>git checkout other git rebase master git checkout master git merge other git branch -d other </code></pre> <p>If you're absolutely certain that neither of the above work for you, you can consider the "zipper" approach that you're trying to do. There are no automated tools that come with Git that will do this for you, so you're going to have to work a little harder for this. It will also cause problems for anyone who is basing their history on <code>master</code>, as they will all then have to rebase their work on top of your new <code>master</code> (your proposed linear history changes the parents of each of the commits in master, which means that those commits are different than they were before, which means that anyone else is now basing their work on an entirely new set of commits, that just happen to have the same diffs as the previous set of commits).</p> <p>If you don't mind doing the ordering manually, you could use <code>git rebase -i</code> to order the commits however you want. You would run the following commands (where <code>base</code> is the first commit before the two branches diverged; if <code>a1</code> is the first commit not in common between them, then you could use <code>a1~</code> to refer to this commit):</p> <pre><code> git checkout master git merge other git rebase -i base </code></pre> <p>During the interactive rebase, you will presented with a text file containing a list of changes, which you can edit into whichever order you want them to be applied in. This is entirely manual, of course, so only an option if you have a short history and want to rearrange the commits manually. If there are any merge conflicts, you may have to resolve them manually multiple times if you do this. And as mentioned, this will mean that anyone else who was basing their work on <code>master</code> will now have to rebase as well.</p> <p>You could also automate this process somewhat, by creating a new branch starting at <code>base</code>, and cherrypicking commits from one branch or the other to this new one, and finally replacing <code>master</code> with this new branch.</p> <p>But as I mentioned, you probably don't want to do this. My first two solutions, which don't give you quite the history that you're looking for, but do give you something close to it, will behave the best in most Git-based workflows.</p>
    singulars
    1. This table or related slice is empty.
    1. POgit merge branch in a zipper like fashion
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBrian Campbell
    1. USBrian Campbell
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POgit merge branch in a zipper like fashion
      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. VTAcceptedByOriginator
    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. COYes, the motivation for the "zipper" was to have a ordninary history as it would look like if the modifications would have been done to one branch instead two ones. That is possible as they happened in two distinct subfolders. The question is if I now do the `git rebase -i` manual work or just resign and stay with a usual rebased history with their counterintuitive unordered timeline.
      singulars
      1. PO
      1. USdronus
    2. CO@user702867 I would recommend, if you work with Git, that you don't worry about having an ordered, linear timeline. Accept the fact that you are doing branched development; you can choose to either have an ordered, nonlinear timeline (as in my first suggestion), or a linear timeline in which each individual branch is ordered intuitively, but the whole thing isn't (as in my second suggestion).
      singulars
      1. PO
      1. USBrian Campbell
    3. COI think in your option 2 you still need the `git merge other` after checking out master, but it will be a fast-forward merge.
      singulars
      1. PO
      1. USKarl
 

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