Subrepos and diff command

Patrick Mézard pmezard at gmail.com
Sat Oct 22 08:02:24 CDT 2011


Le 21/10/11 18:47, Eric ROSHAN EISNER a écrit :
> On Fri, Oct 21, 2011 at 09:07, Patrick Mézard <pmezard at gmail.com <mailto:pmezard at gmail.com>> wrote:
> 
>     Le 21/10/11 17:56, Eric ROSHAN EISNER a écrit :
>     > On Fri, Oct 21, 2011 at 07:30, Patrick Mézard <pmezard at gmail.com <mailto:pmezard at gmail.com> <mailto:pmezard at gmail.com <mailto: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).
> 
>     Then how do you address [1]? Display a diff of sub/b against /dev/null instead of the actual change in the subrepo?
> 
>     If you do that, you do not know what you are committing in the subrepo unless you ask the subrepo yourself.
> 
> 
> Well you're doing two different things with the recursive commit, so I think it's reasonable to ask the two repos separately to get the two different answers.
> 
>   $ hg diff -S # effect on root repo
>   ---/dev/null
>   +++sub/b
>   +b
>   +b
>   $ cd sub
>   $ hg diff # effect on sub repo
>   ---sub/b
>   +++sub/b
>   b
>   +b
>   $ hg commit -m b2 # manual recursive commit
>   $ cd ..
>   $ hg diff -S
>   ---/dev/null
>   +++sub/b
>   +b
>   +b
> 
> Importantly, it is consistent that a diff -S in the root repo gives the same result before and after the inner commit, because they end up with the same contents. I agree this is a bit confusing, but it reflects the confusing nature of recursive commit.

Right, I agree this approach gives well defined, consistent results. I guess "hg status -S" will do the same, again for consistency.

I am just afraid it does not completely solve the "let me easily see if I am going to commit a subrepository and what I am going to commit" problem when adding a new subrepository. But maybe that's a corner case and people just ought to be careful and manually check the subrepositories being added (probably not many in a single step).

--
Patrick Mézard


More information about the Mercurial-devel mailing list