Discarding local commits

[Matt Mackall]

On Fri, 2011-07-01 at 17:32 +0100, Tom Anderson wrote:
> On 1 July 2011 17:10, Matt Mackall <mpm at selenic.com> wrote:
> > On Fri, 2011-07-01 at 15:26 +0100, Tom Anderson wrote:
> >> On 1 July 2011 15:17, Saad Khattak <saadrustam at gmail.com> wrote:
> >>
> >> > I have a repository where I made some local commits that were
> >> > 'experimental'. I unfortunately did this without cloning. I then went to
> >> > another computer later and did a bunch of 'proper' commits and pushed them
> >> > to bitbucket. Now I am back on the computer where I did 'experimental'
> >> > commits and synchronized with bitbucket. Now I have a few unwanted branches
> >> > from this computer that were 'experimental' and I don't want them to show up
> >> > on bitbucket. Now one solution is to simply delete the local repository and
> >> > clone again from bitbucket. Problem is that is quite a big repository, and I
> >> > would like not to clone it from scratch. Is there a way to discard local
> >> > commits?
> >>
> >> There is:
> >>
> >> http://mercurial.selenic.com/wiki/Strip
> >
> > While strip will work, we consider that an advanced/dangerous feature.
> > We generally recommend:
> >
> > hg clone -r <last good commit> myrepo myrepo-clean
> 
> Is the advanced dangerousness of strip related to the act of removing
> changesets from the repository, or to the particular mechanics of the
> strip command itself? If the former, is it the case that clone -r,
> followed by replacing the old repo with the cloned one, is no safer?

The issue is that strip rewrites history, which is potentially
destructive.

> To put it another way, if you back up your repository before
> stripping, is strip still more dangerous than clone -r?

No. But I'd rather simply avoid the whole "did you read the docs? did
you make a backup?" follow-up conversation/lecture and point people to
something inherently safe.

-- 
Mathematics is the supreme nostalgia of our time.