Creating empty revisions by committing and invalid .hgsub file

[Mads Kiilerich]

On 04/02/2012 10:55 AM, Angel Ezquerra wrote:
...
> E:\test-repo>"c:\Program Files\Mercurial\hg.exe" commit -m "add subrepo"
> committing subrepository include\subrepo
>
> E:\test-repo>"c:\Program Files\Mercurial\hg.exe" log -v --debug
> changeset:   0:33c71447a927edddeb0c1613411152c04cad4888
> tag:         tip
> phase:       draft
> parent:      -1:0000000000000000000000000000000000000000
> parent:      -1:0000000000000000000000000000000000000000
> manifest:    0:95de667a6dedb615cccabb595783606b248d7265
> user:        aem
> date:        Mon Apr 02 10:47:34 2012 +0200
> files+:      .hgsub .hgsubstate
> extra:       branch=default
> description:
> add subrepo
>
>
>
> E:\test-repo>"c:\Program Files\Mercurial\hg.exe" status
>
> E:\test-repo>"c:\Program Files\Mercurial\hg.exe" commit -m "add subrepo again"
> committing subrepository include\subrepo

Mercurial is not trying to "add subrepo again". It already committed a 
.hgsub and .hgsubstate with include\subrepo.

I guess what happens is that Mercurial can see that .hgsubstate isn't 
correct and thus wants to commit an updated .hgsubstate ... but it is so 
wrong that it doesn't know what to commit and ends up committing the 
same without any changes. Garbage in garbage out.

See also http://mercurial.selenic.com/bts/issue2403 .

Yes, there is room for some minor improvements:

1: Mercurial could try harder to not make an empty commit.

2: Mercurial could refuse to commit a .hgsub with entries that doesn't 
point to an actual existing repo

3: Mercurial could refuse to commit a .hgsub with entries that doesn't 
match what it can read in the file system, considering for example 
casing and 'slash direction'.

>> The first .hgsub you gave is not technically wrong ... but it is probably
>> not what you want.
>
> Sorry, what do you mean? Do you mean that the first .hgsub file is
> saying that there is a subrepo in a folder called "include\subrepo"
> (where "\" is part of the folder name?). If so that is definitely
> wrong on windows, where (AFAIK) that folder name is invalid.
>
> If that is the case I think it is all too easy to make this mistake on windows.

http://mercurial.selenic.com/bts/issue2644

/Mads