Lobbying for -p1 diffs

[Michael Ellerman]

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.

> 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.

> I don't care whether we use ., -, {}, whatever to denote it.

Spot the arch user ;D

cheers