Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First, as many others have pointed out, using a named branch for short lived work is not a recommended practice. Named branches are predominantly for long lived features, or for release management.</p> <p>Given that you are in this situation, there are a few options available. All of them involve modifying history (as you're obviously trying to change something you've done).</p> <p>One is to just push the branches as is, learn from the experience, and move on. If the rest of the team is fine with this, then it's a case of adding --new-branch to your push command. </p> <p>If the rest of the team, or you, really want the history to be clean, then you'll need to dig deeper.</p> <p>If you aren't pushing, then definitely make a clone of your current repo. This way you have a copy of the original work to fall back on.</p> <p>I see 2 main approaches here. Strip off the merges and rebase your branches onto default. This will get rid of the named branches or graft/transplant your changes. Both will be the same end result, but the implementation is slightly different.</p> <p>If you merely want to use <a href="http://www.selenic.com/mercurial/hg.1.html#graft" rel="nofollow">graft</a>, that is now a built-in function starting with HG 2.0. It replaces the transplant plugin, and is much nicer to work with as it uses your usual merge tool if there are conflicts.</p> <p>To use it, update to the default branch. Then, use the command:</p> <pre><code>hg graft -D "2085::2093 and not 2091" </code></pre> <p>the string after -D is an hg revision selection query. In your case, you'd likely only need '{start}::{end}' where start is the changeset at the start of the branch, and end is the end changeset of the branch (ignoring the merge).</p> <p>If you did several merges, you'd have to pick and choose the changesets more precisely.</p> <p>The other option is to strip the final merges, and use the rebase command that is part of the mq plugin. </p> <p>You'll have to strip your merge changesets to get rid of them, and then update to the tip of the branch you want to keep. Select the start of the first named branch, and do a rebase. This will change the parentage of the branch (if you're familiar with Git, then this is very much like it's rebase).</p> <p>Then repeat for the second branch. You should now have one long branch with the name default.</p>
    singulars
    1. This table or related slice is empty.
    1. POMercurial push problem
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMikezx6r
    1. USMikezx6r
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMercurial push problem
      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
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COhad the answer you wanted, so it was by definition the right answer, but I'd be remiss in not adding a comment that most Mercurial workflows assume an immutable history and arrange things to avoid needing `strip` or `rebase`. In this specific case one does that by avoiding **named** branches for short-lived entities. Had these hotfixes been **anonymous** branches or **bookmarks** you'd have not needed to rewrite history with `strip` or `rebase`. Building your workflow atop tools that modify history isn't wrong, it's just not usually considered Mercurial best practices.
      singulars
      1. PO
      1. USRy4an Brase
    2. CO@Ry4an Totally agree. I focused strictly on the question, but should have made mention of best practices to avoid this situation in the future (and first place). Thank you for ensuring this was done.
      singulars
      1. PO
      1. USMikezx6r
    3. COThank you for the addition. I will modify the question shortly to incorporate changes in HG. Starting with 2.0, there's a better command than the transplant plugin. The new command is graft, and provides the usual merging help. Transplant does not.
      singulars
      1. PO
      1. USMikezx6r
 

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