hg diff --subrepos

[Michael Sperber]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Mike Kupfer writes:
>  > Jerry James wrote:
>  > 
>  > > How about hg pull?  I did an hg pull in the top level packages
>  > > directory, and was told that manifests were updated ... but no actual
>  > > source files.  By looking at the ChangeLog, I found the subdirectories
>  > > I had to enter to pull the actual file changes.  Is there some way of
>  > > doing a pull on all subrepos?  (I can't see one in the help
>  > > text.)
>
> The help text in "hg help subrepos" isn't terribly explicit, but if
> you decode the descriptions of "pull" and "update", it implies that
> update in the top repo actually does a pull on the subrepos based on
> the current content of .hgsubstate, then updates them to the specified
> revision.

Yes.  (Before it updates, it can't know which revisions to pull.)

>  I'm not sure if the subrepo now contains "future" revisions
> or if they get "hg strip"'ed.

It doesn't ever strip in this scenario.

> I suspect that using the hg onsub extension (at least for pull) is a
> bad idea here.

I think so, too.

>  I think it has potential to pollute .hgsubstate.

Definitely.

> # Package maintainer
> cd .../package-top
> hg pull -u                             # get all *published* changes to
>                                        # packages recursively
> cd xemacs-packages/<pkg>
> hg pull -u                             # *optional* and useful only if
>                                        # there are "unpublished" changes
>                                        # in the public repo
> xemacs <file1> ...
> hg commit -m "changed <file1> ..."     # look Ma, no push yet!
>                                        # it may *not* be OK to push here:
>                                        # that means that people who do
>                                        # "hg onsub pull -u; hg commit"
>                                        # will pollute .hgsubstate!

There's no problem pushing here.  It's just that what gets pushed here
doesn't get pulled automatically by a top-level "hg update", unless a
commit in the top level gets pushed.

> cd ../..
> hg commit -m "publish sources of <pkg>" xemacs-packages/<pkg>
>                                        # updates .hgsubstate
> hg push                                # recursively pushes

That's correct, but to my mind is what Norbert should do.

So the package maintainer that wants Norbert to actually update the
package everybody sees should send Norbert e-mail.  He does:

cd xemacs-packages/<pkg>

hg pull

cd ../..
hg commit -m "Updated package <pkg> to ..."
hg push

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla