title: How to know if a branch has been squashed into another
body: <p>At work we squash feature branches instead of merging them to keep <code>release</code> branches clean and disconnected from the <code>feature</code> branch.</p>
  
  <p>We're currently doing that with:</p>
  
  <pre><code>git checkout release
  git merge --squash feature
  git commit -m 'Squashed Feature 123'
  </code></pre>
  
  <p>But due to some <strong>backend automation system</strong> requirements, we would like to know what sha in the feature created the squash commit <strong>without merging</strong> and <strong>without modifying the feature branch</strong>.</p>
  
  <p>The goal of the automation is to tell management that the <code>feature</code> has been squashed into <code>release</code> (regardless of conflicts and its resolution). The only consistent way of doing it would be to somehow "register" the <code>feature</code> HEAD sha into the squash commit. If the developer pushes more commits to the <code>feature</code>, the automation system would flag it as "unsquashed" again, since the <code>feature</code> HEAD now points to a sha that has not been squashed.</p>
  
  <p>I've found 3 ways that could flag the squash commit so that the automation system could identify <code>feature</code> as squashed into <code>release</code>, but none are satisfactory:</p>
  
  <p>1) <code>git merge -Xours feature</code> after the squash will create an additional commit that could serve to indicate to the automation system the <code>feature</code> sha that was merged into <code>release</code>. But now we have 2 commits plus the whole history just like a merge, so <strong>not a solution</strong> since we don't want the <code>feature</code> history.</p>
  
  <p>2) <code>git replace --graft release release~1 feature</code> after the squash will make <code>feature</code> an ancestor of <code>release</code>. This works too, but just like 1), this will bring history again, which we want to avoid, so <strong>not a solution either</strong>.</p>
  
  <p>3) <code>git commit -m 'squashed from [SHA=$feature_squashed_sha]'</code> the string can flag the automation system the squash commit is actually a merge from a certain commit. This could be a solution.... The problem is that getting that commit message right is <strong>messy and prone to errors</strong>.</p>
  
  <p>Any insight on how to accomplish this in a manner that is both robust for the automation to parse and easy enough for users to implement into their merge workflow?</p>
  
  <p>Now, we <em>don't have to</em> use a <code>git merge --squash</code>, any other non-mergeable approaches are welcome if it makes the squash point to its original sha in a consistent way.</p>
  
  <p>Also, the automation system can be configured to run any command, as long as it gives the answer to the question <strong>has the <code>feature</code> HEAD been squashed into <code>release</code>?</strong></p>