On 28 March 2011 11:35, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore <p.f.moore at gmail.com> wrote: >> For people in the "clean history" school, I'd recommend looking at mq >> for your personal use. But it's definitely an advanced feature of >> Mercurial, so it may be better to understand core Mercurial (and at >> least temporarily accept that Mercurial is based on the "keep all >> history" school of thought, or you'll struggle to match the >> assumptions of the documentation to your thinking :-)) before diving >> into mq. > > I'm seeing if I can get the best of both worlds by having a public > sandbox repo where I work on things (which has the full messy history > of development on its feature branches), and then just drop them into > the main repo as coherent patches. Once I land a patch, I'll close the > original feature branch in the sandbox, so merge conflicts won't be an > issue. > > Mercurial makes merging easy enough that I'm happy with the way that > approach is working so far. That's in essence what I was thinking of when I said "You can do everything that mq provides using core Mercurial commands", but never having done it myself, I wasn't sure how straightforward it would feel to someone in Neil's "second school". Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4