How does Hg do file renames?

[Matt Mackall]

On Mon, 2010-07-12 at 13:56 -0500, Matt Schulte wrote:
> On 7/12/2010 1:36 PM, Matt Mackall wrote:
> > On Mon, 2010-07-12 at 10:35 -0500, Matt Schulte wrote:
> >> On 7/12/2010 10:27 AM, Matt Mackall wrote:
> >>> On Mon, 2010-07-12 at 10:23 -0500, Matt Schulte wrote:
> >>>> On 7/12/2010 10:06 AM, Steve Losh wrote:
> >>>> I fully expect someone to break out some command that I have not yet
> >>>> discovered in hg that will address my gripes :-P .  But until that happens:
> >>>>
> >>>> There are some situations in which you would really like to MOVE the
> >>>> filename and its history.
> >>>>
> >>>> If I had a file name or folder name that had a typo in it, I would
> >>>> really like to actually _move_ the filename.  I don't have any interest
> >>>> in tracking the file/folder with its previously misspelled name, I just
> >>>> want a nice and clean looking history.
> >>> Yep, we're never gonna do that. The whole point of version control is to
> >>> preserve history, mistakes and all. The only way to make such a change
> >>> (one that would change -all subsequent changeset hashes-) is to use some
> >>> sort of conversion process.
> >> I know you would never remove the history, that is pretty much against
> >> everything.
> >>
> >> What about instead of moving and deleting the original file and
> >> changesets (which isn't what I meant), if it were to create a new
> >> file/folder that contained all of the changesets of the original but
> >> under the new name.
> >>
> >> Other than potentially increasing storage space, would that be bad?
> > I can't even make sense of what you're suggesting. But it doesn't matter
> > if I understand it, because whatever it is, it's still effectively
> > impossible.
> >
> > Not one bit of history can change without changing the identifiers of
> > all subsequent changesets. That means not one file name, not one date,
> > not one exec bit, not one character in any file or user name or
> > changeset description. History is effectively tamper-proof due to the
> > use of cryptographic hashes.
> I am sorry that I seem to be unable to explain myself enough to have you 
> guys understand me.
> 
> The original poster said that there weren't any problems or drawbacks to 
> using hg rename.
> 
> The point of this whole escapade is to say that there are some drawbacks 
> to using hg rename.  If you use hg rename, it is possible for your 
> previous changesets to become completely detached from the renamed 
> file.  Top me that is a considerable drawback.

That's purely a ui/usage issue. If you use 'hg rename' to rename files,
that data is recorded in history and the old versions of those files can
be found again with log/annotate -f, etc.

-- 
Mathematics is the supreme nostalgia of our time.