Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You're correct that rebasing and merging can produce the same final tree. The history they produce is very different, though, and version control is of course all about history. You've voiced a preference for linear history; that's indeed desirable on a local scale, while merges help to record the larger scale interaction of features, bugfixes, and so on. </p> <p>The simple answer to your central question (why not just rebase) is that sometimes there's a right place for a branch to start, and if that's the case, you should merge, not rebase.</p> <p>For example, you could have a bugfix which applies to a maintenance release as well as the current release; you'd want to branch it from the latest commit which is an ancestor of both releases. You can't ever rebase that branch forward along either the master or the maintenance branch, or you'd no longer be able to merge it into the other.</p> <p>Similarly, all topic branches start somewhere. At some point, you want to preserve that history. You mention one of the clear-cut cases (others have pulled your work), but it could be something far less obvious. Maybe there's some interaction with other features, maybe this feature has subfeatures, and you're trying to keep that entire hierarchy preserved. </p> <p>So, sure, if the branch is local and there are no reasons to keep its base fixed, it is as you say much simpler to just rebase it and be done. But sometimes that's not the right thing to do.</p> <p>Your final question is actually about something very different, nothing to do with merge conflicts. Linus said that <a href="http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html" rel="noreferrer">in the context</a> of merges which <em>didn't need to be done</em>. This is very much an issue of branch and merge philosophy. Junio Hamano wrote an <a href="http://gitster.livejournal.com/42247.html" rel="noreferrer">excellent blog post</a> about that very issue. A brief quote which sums up the topic at hand: </p> <blockquote> <p>when you merge a topic branch 'add-frotz' to your 'master' branch, you are obviously incorporating the new 'frotz' feature, but more importantly, you are stating that it is desirable to have that 'frotz' feature in the 'master' branch</p> </blockquote> <p>Linus doesn't want to see you merging this odd branch called 'linus' all the time, because clearly you're not merging some specific topic which is desirable to have in your branch. You're repeatedly merging the upstream branch into the topic branch, which is entirely the wrong direction. You don't need all the stuff from master (or linus) to develop your topic. You should finish your topic, then merge it the other way, upstream into master! It's not desirable to have <em>all of the content of master</em> in your topic branch. (And a single developer's master is really a topic branch, as far as an integrator's concerned.)</p> <p>So, Linus doesn't have a problem with frequent merges; he has a problem with purposeless and counterproductive merges. (And generally, if you make sure your merges are done for a good reason, they won't be frequent - and they'll almost never be downstream merges.) If your rebases are done for a good reason, and they make the history better, then they are a good thing, however frequent.</p>
    singulars
    1. This table or related slice is empty.
    1. POgit workflow: throwaway merges and git-rerere - what's the point?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCascabel
    1. USCascabel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POgit workflow: throwaway merges and git-rerere - what's the point?
      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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COGreat, thanks for the reply. The bugfix comment - branch from the latest commit that's an ancestor of both, was actually very enlightening. It seems like a simple idea, but I was under the impression that one should branch from the tip of a maintentance branch, and then cherry-pick the bug fix over to the master. This approach though seems much cleaner, and does prevent necessarily prevent rebasing.
      singulars
      1. PO
      1. USJosh
    2. CO@user370562: The principle here is to merge upstream/upwards, and to create your branches in such a way that that's possible. (Incidentally, maintenance branches quite often can be merged straight back into master; the bugfixes you've made on v5 likely still apply to the in-development v6.) Most suggestions of workflows emphasize merging upwards - see `man gitworkflows`, for example. Glad to be of help!
      singulars
      1. PO
      1. USCascabel
 

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