Lobbying for -p1 diffs

[Robert Collins]

On Tue, 2006-02-28 at 09:27 -0600, John Arbash Meinel wrote:
> Michael Ellerman wrote:
> > On 3/1/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
> >> Michael Ellerman wrote:
> >>> On 2/28/06, Wouter van Heyst <larstiq at larstiq.dyndns.org> wrote:
> >>>>> --- work.orig/arch/powerpc/kernel/setup-common.c
> >>>>> +++ work/arch/powerpc/kernel/setup-common.c
> >>>> Hmm, will branch nick work with "Aaron's integration" type nicks?
> >>>> +1 on using -p1, just need to figure out sensible labels.
> >> Well, you could always just make it the last component of
> >> WorkingTree.basedir/Branch.base. Those have to be a valid path.
> > 
> > Yeah, except that will look like the branch nick *most* of the time,
> > until you change the nick to
> > "really-important-name-thats-a-valid-path" and you wonder why it
> > doesn't show up in the diff. But it's still a reasonable option.
> > 
> 
> Well, we could do the opposite, and use branch nick, unless it is an
> invalid path. :)
> 
> But I think if we leave it as part of the path, then it will always
> *look* like the last portion of the url. Which happens to be the branch
> nick. I think most people would see the URL association before they saw
> the nick association.
> 
> >> If I read what you had correctly, you want to use
> >>
> >> SOMETHING.orig/path/inside/branch
> >> SOMETHING/path/inside/branch
> >>
> >> Is that correct? You prefer the prefixes SOMETHING.orig and SOMETHING?
> > 
> > I'm really not fussy, I just thought branch nick would look nicer and
> > impart a little more info, but if it gets problematic I don't think
> > it's a biggy.
> > 
> >> I was actually thinking, if it is available, we could use revision
> >> numbers. so you would have 'work.1500/' and 'work.1501/' with fallbacks
> >> to 'work.orig' and 'work.mod' if a revision number was not available.
> >> (Say you diff'd against a merged revision, or for the working tree).
> > 
> > Hmm, that'd be kinda cool. Except it'd often be work.1500 and
> > work.working-tree. And actually having to fallback to work.orig and
> > work.mod kinda sucks - users who don't understand about merged
> > revisions not having a revno are going to wonder what the hell's going
> > on.
> 
> But 99% of the time, you won't diff against a specific revision. You
> would diff against another tree. Which means we would want to show:
> 
> --- bzr.dev.1500/bzr
> +++ bzr-jam-integration.1483/bzr
> 
> > 
> >> I don't care whether we use ., -, {}, whatever to denote it.
> > 
> > Spot the arch user ;D
> > 
> > cheers
> 
> True enough, though technically, Martin was never truly an Arch user,
> and he *liked* and *used* {} to denote revision-ids. (If you look
> through the code, there are a lot of places where revision ids are
> formatted as "No revision id: {%s}" % (rev_id,).
> 
> So {} can exist outside of Arch. But yes, this one was from me. :)
> 
> The problem I specifically have with '.revno' is that it depends on how
> people name their branch. If they numbered by revision you would get:
> 
> --- bzr-0.7.1.1500/
> +++ bzr-0.8.1600/
> 
> (Actually, I think the above looks pretty cool, but if your revision
> numbers were low, it might be confusing whether the final number was an
> actual release number, or a revno)

I need to check the diff parser... but what about @?
--- bzr-0.7.1 at 1500/
+++ bzr-0.8 at 1600/

> And I use '-' to denote my branches, while Martin uses '.'. Hence
> 'bzr-jam-integration' versus 'bzr.mbp.integration'.

and I use '/'

> Ultimately, I might prefer to use path separators (once we have
> repositories) to give us "bzr/jam/integration/", and that doesn't
> translate well into -p1 paths.
> 
> Oh, and branch-nicks can certainly contain slashes, so we would need to
> be extra careful in using them.

Yup.

But all that said, I'm +1 on p1 paths.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060301/5a5ed73a/attachment.pgp