Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Regarding the alternatives</p> <pre><code>git checkout iphone -b iphone31 git merge master </code></pre> <p>and</p> <pre><code>git checkout master -b iphone31 git merge iphone </code></pre> <p>they will have identical ease or difficulty, it is like arguing whether a glass is half full or half empty.</p> <h2>Version tree perception</h2> <p>How we look at version trees are in some way just our arbitrary perception. Let's say that we have a version tree like the following:</p> <pre><code> A----------+ | | | | \_/ \_/ B X | | | | \_/ \_/ C Y | | \_/ D | | \_/ E </code></pre> <p>And let's say that we want to make a new version Z checked out from Y based on the changes from C to E but not including the changes made from A to C.</p> <p>"Oh, that will be difficult because there is no common starting point." Well not really. If we just place the objects a little differently in the graphical layout like this</p> <pre><code> / C+---------+ | \ | | | \_/ | D B | / \ | | \_/ | E A | | \_/ X | | \_/ Y </code></pre> <p>now things are starting to look promising. Notice that I have not changed any relation ships here, the arrows all point the same way as in the previous picture and version A is still the common base. Only the layout is changed.</p> <p>But it now trivial to imagine a different tree</p> <pre><code> C'---------+ | | | | \_/ \_/ D B' | | | | \_/ \_/ E A | | \_/ X | | \_/ Y </code></pre> <p>where the task would just be to merge version E normally.</p> <p>So you can merge anything you want, the only thing that influence the ease or difficulty is the aggregate of changes done between where you select as a starting point or common base and where you merge to. You are not limited to using the natural starting point the your versioning tool suggest.</p> <p>This might not be simple with some version control systems/tools, but if all else fails there is nothing that stops you from doing this manually by checking out version C and save the file as file1, checking out version E and save the file as file2, checking out version Y and save the file as file3, and run <code>kdiff3 -o merge_result file1 file2 file3</code>.</p> <h2>Answer</h2> <p>Now for your specific situation it is difficult to say exactly what strategy that will produce the least amount of problems, but if there are many changes that create some kind of conflict it probably is easier to split up and merge smaller parts.</p> <p>My suggestion would be that since there are 32 commits between last-working and iphone, you could for instance start by branching of master and then merge in the first 16 commits. If that turns out to be too much trouble, revert and try to merge the 8 first commits. And so on. In worst case you end up merging each of the 32 commits one by one, but it would probably be easier than having to handle all the accumulated conflicts in one single merge operation (and in that case you are working with a <em>really</em> diverging code base).</p> <h2>Tips:</h2> <p>Draw on paper a version tree and note with arrows what you want to merge. Cross off things as they are done if you split up the process in several steps. This will give you a clearer picture of what you want to achieve, what you have done so far and what is left.</p> <p>I can really recommend <a href="http://kdiff3.sourceforge.net/" rel="noreferrer">KDiff3</a>, it is an excellent diff/merge tool.</p>
    singulars
    1. This table or related slice is empty.
    1. POgit: merge two branches: what direction?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. UShlovdal
    1. UShlovdal
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO"And let's say that we want to make a new version Z checked out from Y based on the changes from C to E but not including the changes made from A to C." I don't want to exclude any commits. I don't really see how that is related to what I want. I just want to merge master with iphone.
      singulars
      1. PO
      1. USAlbert
    2. CO"My suggestion would be that since there are 32 commits between last-working and iphone, you could for instance start by branching of master and then merge in the first 16 commits." Would that be easier? Wouldn't I have to resolve the same conflicts again and again then for each commit? Like I have added a single line in one commit and another line right after it in another commit. Now handling these both together would be easier than doing it twice, wouldn't it?
      singulars
      1. PO
      1. USAlbert
    3. CO"they will have identical ease or difficulty," That exactly was my question. So both ways I have suggested in the beginning will produce *exactly* the same results? So Git merging is 100% symmetric?
      singulars
      1. PO
      1. USAlbert
 

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