[PATCH stable] largefiles: handle merges between normal files and largefiles (issue3084)

[Matt Mackall]

On Fri, 2011-12-09 at 18:05 +0100, Martin Geisler wrote:
> # HG changeset patch
> # User Martin Geisler <mg at aragost.com>
> # Date 1323448500 -3600
> # Branch stable
> # Node ID f9390ba27de9bc3661b2b2bb83a3ce9e81f41772
> # Parent  5b66e55c0d938a524c0b6e933010c7a5f728bc30
> largefiles: handle merges between normal files and largefiles (issue3084)
> 
> The largefiles extension prevents users from adding a normal file
> named 'foo' if there is already a largefile with the same name.
> However, there was a loop-hole: when merging, it was possible to bring
> in a normal file named 'foo' while also having a '.hglf/foo' file.

Do largefiles never go through filemerge?

> This patch fixes this by extending the manifest merge to deal with
> these kinds of conflicts. If there is a normal file 'foo' in the
> working copy, and the other parent brings in a '.hglf/foo' file, then
> the user will be prompted to keep the normal file or the largefile.
> Likewise for the symmetric case where a normal file is brought in via
> the second parent. The prompt looks like this:

Seems to me we should just always promote files to largefiles on merge.
Or, apply the existing 'add' thresholds/patterns to decide.

> The status and diff output looks peculiar after a merge where the type
> of a file changed. If a normal file 'foo' was changed to a largefile,
> then we get:
> 
>   $ hg status
>   M foo
>   R foo

Eep. That's seriously ugly.

-- 
Mathematics is the supreme nostalgia of our time.