[PATCH][UPDATED] Re: make "merge" work nicely with revno:N:patch

[Matthieu Moy]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> There's no reason you shouldn't be able to do "bzr diff
> http://bazaar-vcs.org/bzr.dev -r -5..0".  You can't, but that's arguably
> a bug.

That would be nice also, still, it doesn't provide the solution when
the revisions belong to different branches.

>> Command-line interface doesn't mean only /user/ interface, it's the
>> interface to anything calling bzr as an executable (as opposed to
>> calling bzrlib).
>
> Yes, but the commandline should be friendly to users.  If the only way
> of diffing remote revisions is by using a syntax only a shell script
> could love, I think we've got a problem.
>
> And if we provide all the operations a shell script could want, I don't
> think it's cruel to shell scripts to make them use user-friendly syntax.

Well, matter of taste, but I don't find my proposed syntax
non-user-friendly ;-).

>>>>> so it's better to have it working.
>>> I really, really don't like jamming the branch info into the revision
>>> spec.  
>> 
>> Well, I'm not the one who started this. "branch:..." has been there
>> for some time before I proposed and implemented that other revision
>> spec. 
>
> By 'jamming', I meant making the branch location part of the spec's
> output.  branch: only produces a revision id.

Because it does this local fetch. But that's internal implementation
"detail", it doesn't make a difference for the user.

And it makes the same UI problem. What does

$ bzr cat http://some/branch/some/file -r branch:http://some-other.branch/

mean for example ?

>> The difference beign that "branch:..." does a local fetch.
>> That's conveinient in some cases, but [...]
>
> This is an unusual case.  The vast majority of the time, the fetch is
> helpful, because you'll do 'cd /my/kernel/tree; diff -r
> branch:http://example.com/my/other/kernel/tree/'.  And then subsequent
> operations will not need to fetch the data from a remote branch again.

Agreed. In the vast majority of the time, the fetch is useful. Still,
in the long term, I'd like to see this "branch:" not do a local fetch
if the branches are unrelated for example, and "branch:" could work
also when called from outside a branch.

> There is another way: allow two branches to be specified.  That would be
> much more consistent with what we already do.

I don't think this is the perfect solution either (disclaimer: I'm not
claiming my solution is perfect!):

$ bzr diff -r 4..4 branch/ other-branch/

At a glance, you see "4..4" and may think you're diff-ing twice the
same revision. The information about the first and the second revision
to diff are interleaved on the command line, I find it really strange.

$ bzr diff -r 4 branch -r 4 other-branch/

would be a bit more natural in this regard, but then it raises the old
"should a second -r override the first one", ...

>> I don't like the idea of providing the full path in a single URL.
>
> It made more sense when remote branches always had working trees.  I
> agree it's a bit odd.  Still, it's a pretty compact way of representing
> this information.  Maybe we can change this convention, but we shouldn't
> make commands inconsistent just because you don't like the convention.

Well, here, I don't know what best to do. So, I'm really open to
proposals. Indeed, (cf. above), the problem already exists with
"branch:".

I'd probably like something like

usage: bzr cat FILENAME [BRANCH]

instead of the existing, but that means breaking the existing
behavior :-(.

> Remember that we already have the revid: revision spec, so we already
> permit most of our commands to accept totally arbitrary revisions.

True, I forgot about that.

That said, for log, I just tried "bzr log -r revid:xxx..revid:yyy",
with xxx and yyy beign two unrelated merges in a branch, it seems to
fall back silently to "bzr log".

-- 
Matthieu