Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here's an easy way, or I hope it will seem easy after a bit of study, that avoids the merge commits.</p> <p>From text and comments I see you're doing the marching-ants trick with <code>master</code> and <code>stable</code>, where the only operation (at least usually) permitted on either of them is a fast-forward merge:</p> <pre><code>...--X--...S stable \ m--...--M master \ f--...--F feature </code></pre> <p>What I suggest follows, bear with me when you get to the ugly-looking result of this first part:</p> <pre><code>git checkout master -B m-temp # let's do this with nonce names at first git revert X # (maybe **amend** the commit to what X should have been here) git checkout stable -B s-temp git cherry-pick m-temp git checkout feature -B f-temp git cherry-pick m-temp </code></pre> <p>producing:</p> <pre><code>...--X--...S---X'' s-temp \ m--...--M---X' m-temp \ f--...--F---X''' f-temp </code></pre> <p>and all your branches have exactly one fix for X on them. This looks like a mess, but</p> <p>notice what a fast-forward merge really <strong>is</strong>. When it's time to catch stable up to master, you can do it correctly with either of</p> <pre><code>git checkout s-temp # the slow way git reset --hard @{1} # . (reset one commit from s-temp, i.e. to S) git merge m-temp # . </code></pre> <p>or get the exact same effect with:</p> <pre><code>git checkout -B s-temp m-temp # exactly the same, without the rube goldberg </code></pre> <p>each of those producing:</p> <pre><code> X'' &lt;-- discarded cherry-pick of X' / ...--X--...S---m--...--M---X' m-temp s-temp \ f--...--F---X''' f-temp </code></pre> <p>... and your branches still all have exactly one fix for X. When it's time to fast-forward master just do likewise, leaving X' also discarded and X''' the sole X fix in your history, or you can have your feature-branch devs rebase onto X' and discard their own X'''s</p> <hr> <p>Git has a 'description' config item for branches. Here's something useful to put in a post-checkout hook:</p> <pre><code>cat &gt;&gt;.git/hooks/post-checkout &lt;&lt;\EOF #!/bin/sh # # if there's a stored note about this checkout, show it: # $3 = 1 for a full branch checkout if branch=`git symbolic-ref --short -q HEAD` &amp;&amp; test $3 = 1; then git config --get-all branch.$branch.description fi EOF chmod +x .git/hooks/post-checkout </code></pre> <p>and then when you want to remind yourself of something,</p> <pre><code>git config --add branch.stable.description \ "reset to commit c0ffee before merging master" </code></pre> <p>which makes cherry-picking any master fixes you want about as easy as can be. When you want the note gone,</p> <pre><code>git config --unset branch.stable.description c0ffee </code></pre> <p>makes all the notes matching regex <code>c0ffee</code> go away.</p>
    singulars
    1. This table or related slice is empty.
    1. POGit rebase workflow - adding bugfixes to a "stable" branch
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USjthill
    1. USjthill
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGit rebase workflow - adding bugfixes to a "stable" branch
      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. VTAcceptedByOriginator
    1. COThis looks like a great solution! My one question is, the end result (after I eventually catch `S` up with `M`), it seems like the end result will be that the commits will be in a different order - i.e., the new commits from `M` will be inserted *before* the `X` commit in `S`. This seems like it should be "safe" to me, but just to confirm: if, after going through this process, on a client I do `git checkout stable && git pull`, will it want to merge? It seems like it should still be able to fast-forward, if I understand correctly.
      singulars
      1. PO
      1. USCmdrMoozy
    2. COTo your question: no, X'' is completely discarded and (assuming you have your feature-branch devs rebase onto master as usual) no master-branch history will ever change -- the pictures above have all relevant information, commit graphs in git are not just conceptual.
      singulars
      1. PO
      1. USjthill
    3. CORe clients pulling `stable`, ah, no, what will happen after you reset `stable` is clients who have previously pulled `X''` will get a reset warning on their next pull unless they've configured `branch.stable.rebase`. Good eyes. It doesn't seem like much of a problem to me, nobody "should" be basing work off that, right? The fix itself, if not that exact commit, will still be on their next pull anyway.
      singulars
      1. PO
      1. USjthill
 

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