[PATCH 0 of 4] Subrepository log

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Thu, 2010-09-23 at 17:03 +0200, Martin Geisler wrote:
>> Hi everybody,
>> 
>> Please take a look at these patches for subrepository log.
>> 
>> The one thing I'm not so happy about is the heading that is printed
>> when entering a subrepo
>
> (Then why don't you show us some example output to discuss? And no, a
> test buried somewhere in a patch series does not count. This is like
> my #2 peeve behind people proposing non-backward-compatible features.)

Yeah, I didn't think of that since it's right there in the test output
and I had been starring at it all day :)

> Here's what it looks like:
>
> +Recursive log:
> +
> +  $ hg log -S -l 1
> +  changeset:   2:1326fa26d0c0
> +  tag:         tip
> +  user:        test
> +  date:        Thu Jan 01 00:00:00 1970 +0000
> +  summary:     2-3-2
> +  
> +  log in subrepository foo
> +  changeset:   3:65903cebad86
> +  tag:         tip
> +  user:        test
> +  date:        Thu Jan 01 00:00:00 1970 +0000
> +  summary:     2-3-2
>
> Yeah, that marker is not terribly useful. But I think there are bigger
> issues here.
>
> I can't imagine how this is going to work with SVN and Git subrepos,
> especially once we throw in all the various top-level log options. And
> things like -r are just going to be random/broken.

I guess we can restrict this to the simple case where we just support
-r. That flag should be easy enough across all systems since it's just a
matter of mapping the top-level revisions numbers to lower-level
subrepository revisions. We already do this for status and diff.

> Further, most people would probably 'expect' some sort of topological
> ordering between upper-level and lower-level commits, ie if top at 3 points
> to sub at 4, then we'd expect to see all the changes leading up to/back to
> sub at 4 first. And for cases where I'm pulling in a bunch of third-party
> component like the Linux kernel or glibc or whatever, most of those
> commits just aren't going to be useful.

Yeah, I also see some usability problems with this command :) The idea
of sorting changesets topologically is interesting, but since a repo can
reference arbitrary changesets in the subrepo, I don't think it would
really work.

> I think this piece as a whole is going to need more discussion. And at
> some level, there are just going to be some things where the most
> sensible solution is going to be 'cd sub; hg/svn/git <cmd>'.

I'll ask if they can come up with some good usecases...

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/