Sheriffing/How To/Unified Repos: Difference between revisions

Jump to navigation Jump to search

Sheriffing/How To/Unified Repos (view source)

Revision as of 19:46, 1 January 2015

2,684 bytes removed ,  1 January 2015
m
edit
(Clean up rebase instructions)
m (edit)
Line 55: Line 55:


=== Recovering from mistakes ===
=== Recovering from mistakes ===
* [20:55] KWierso gps: actually, one last question :)
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* [20:56] KWierso at the moment with all of the separate repositories, cleaning up stuff that's not right is some combination of | hg pull -u | and | hg strip | to get rid of non-pushed local changes and bring in newly-pushed things
* hg strip 'not public()'
* [20:57] KWierso how would I do that in a unified repo?
* [21:05] gps KWierso: generally speaking, if you have to "clean up stuff that's not right," that's probably a sign you are doing something wonky
* [21:06] gps i rarely find myself running `hg strip`
* [21:06] gps although that's partially because i use evolve
* [21:07] gps running `hg strip` in a shared repo is somewhat dangerous. if another working copy is using changesets that were stripped, that could corrupt the working copy
* [21:07] gps if you have old screw-ups, it's best to leave them be
* [21:07] gps if you have evolve, you can `hg prune <rev>` to mark them hidden
* [21:07] gps they kinda just vanish, without the bad consequences
* [21:10] gps as long as you don't have a shared repo referencing commits that you strip, you should be OK
* [21:10] gps e.g. if you `hg pull` and then want to `hg strip` what you just pulled, that's fine
* [21:10] gps but if you go back in history and start removing random things, watch out!
* [21:11] KWierso gps: I probably should have put the whole command, not just "hg strip"
* [21:11] KWierso | hg strip --no-backup 'roots(outgoing())' |
* [21:12] gps well, if you have a unified repo, outgoing() will report changesets from all repos, and that will almost certainly strip a lot of commits!
* [21:12] gps depending on what you've pulled, of course
* [21:13] gps if you have aurora and central in the same repo and out outgoing against central, all aurora commits will be in that set
* [21:13] KWierso ick
* [21:14] gps |not public()| may be a better selector
* [21:14] gps but that assumes you don't have any local commits that haven't landed yet
* [21:15] KWierso most of the time for sheriffing-related stuff, it's not our own commits, but stuff we're checking in for others or uplifting
* [21:16] KWierso so it's stuff others already put up in patches on bugzilla or landed on m-c and need uplifted to aurora/beta/etc
* [21:16] KWierso so losing local changes isn't devastating
* [21:16] gps in that case, you can probably repopulate it easily enough, so |not public()| might be better
* [21:17] KWierso so | hg strip --no-backup 'roots(not public())' | ?
* [21:17] KWierso or hg strip --no-backup 'not public()' ?
* [21:20] gps the latter.
* [21:20] gps you know --no-backup is somewhat dangerous, righ?
* [21:22] KWierso yep
* [21:22] KWierso if the hg strip/hg pull combo doesn't get me back to a known-good state, I'm more than willing to delete and reclone that repository
* [21:23] KWierso less willing now if I'm using a unified repo...
* [21:24] gps generally speaking, you should *never* have to reclone
* [21:25] gps if you have extra local commits, just deal with them
* [21:25] gps not doing so ignores the realities of how distributed version control works
KWierso
Confirmed users
396

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1044472"

Navigation menu