Subrepos and diff command

Eric ROSHAN EISNER eric.d.eisner at gmail.com
Fri Oct 21 10:56:13 CDT 2011


On Fri, Oct 21, 2011 at 07:30, Patrick Mézard <pmezard at gmail.com> wrote:

> I have some questions after looking at "Issue3056 - hg diff/status -
> subrepo files not listed on revision where subrepo was added". With the
> following setup (one modified subrepo being added):
>
>  $ hg init sub
>  $ echo b > sub/b
>  $ hg -R sub add sub/b
>  $ hg -R sub ci -m "addb"
>  $ hg init repo
>  $ cd repo
>  $ hg clone ../sub sub
>  $ echo sub = sub > .hgsub
>  $ hg add .hgsub
>  $ echo b >> sub/b
>
> 1- Should "hg diff -S" display the changes to sub/b ?
>
> I guess it should, it is the whole point of -S.
>
> 2- Say we commit this change as revision 0. Should "hg diff -S --change 0"
> display the changes to sub/b ?
>
> Yes for consistency with [1].
>
> No because it is undefined : we know the subrepo was introduced at revision
> 1, we do not know the use start adding it while being at revision 0 and
> committed it recursively.
>
> 3- Say we modify "sub" 3 times with as many recursive commits. Should "hg
> diff -S -r null:3" display the changes to sub/b and which ones ?
>

The transparent thing to do is show the file diffs as if these files were
directly tracked by the main repo. Since these files were unknown in rev 0
and known in rev 3, diff -S should show them all adding their full contents
from /dev/null. Before you wrote this I had been under the impression that
diff -S and status -S already did this.

Either way the subdiffs are useless for patching purposes (as any new commit
made with them will conflict with .hgsubstate).


> At best, we can display the changes to sub between its introduction in 1
> and its current state in 3. Again, it means the changes made in the process
> of adding sub in 0 are ignored, but we have no way to get them. Do we want
> that?
>
> The interesting part is "between its introduction in 1 and its current
> state in 3" which implies some kind of traversal to find when sub was
> introduced for the first time. This is undefined for unrelated revisions and
> brings a lot of aliasing issues.
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111021/b7ad3abc/attachment-0001.html>


More information about the Mercurial-devel mailing list