Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This isn't the right place to use <code>merge --squash</code>. One good place to use it is in a throwaway topic branch, which you're going to merge into your main branch and then get rid of. All the development done in the topic branch is shown as one commit in the main branch. In your situation, you should merge from the development branch normally, and then use <code>git-rebase --interactive</code> to squash the commits you want.</p> <blockquote> <blockquote> <p>Is it possible to somehow record the merge, without producing a "merge commit" with two parents?</p> </blockquote> </blockquote> <p>If I understand the question correctly, no. <strong>Absolutely not</strong>.</p> <blockquote> <blockquote> <p>Is it possible to tell git to merge only a certain "range" of revisions, like in SVN?</p> </blockquote> </blockquote> <p>Yes. <strong><code>git merge [commit hash]</code></strong></p> <blockquote> <blockquote> <p>Or, is it possible to do a normal merge without having to download all refs from the other branch when pulling?</p> </blockquote> </blockquote> <p>See answer to previous question.</p> <blockquote> <blockquote> <p>Or should I provide a custom merge driver for the files in question, that simply renames "their" version to "our", thereby resolving the conflicts? I'm still afraid that --squash will always try to merge the whole history, up to the common parent, solving only half of my problem.</p> </blockquote> </blockquote> <p>No! <strong>Just don't use <code>git merge --squash</code></strong>. This isn't the right place to use it!</p>
 

Querying!

 
Guidance

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