pre-commit hooks and $Id$ banners?

Jan Hudec bulb at ucw.cz
Wed Apr 26 18:29:15 BST 2006


On Wed, Apr 26, 2006 at 12:38:29 -0400, John Yates wrote:
> On Tuesday, 2006-04-25 Jan Hudec wrote:
> 
> > IMO an only way to maintain overall sanity is to define 'internal' and
> > 'external' representation and convert 'external'->'internal' on EVERY
> read
> > and 'internal'->'external' on EVERY write.
> 
> I assume that 'internal' would be platform independent while 'external'
> would be at least platform dependent and possibly configurable.

Internal is what is stored inn the repository and external is what is placed
in the working tree.

> >                                             Well, actually an
> exception would
> > be diff -- we should be able to produce BOTH diff of external and of
> internal
> > representations.
> 
> I would hope that if I had not edited a file the presence of expanded
> keywords would not lead diff output.  Many script authors assume two
> files
> are identical if their diff is empty.

Picky note: you mean the other way 'round -- if their diff is non-empty, they
are changed.

While you don't want any diff output if only keyword expansion changes, you
usually want the diff to apply cleanly to the working tree. You even usually
assume, that if you make a diff between two revisions and than apply it to
exported working tree from the first, you get the secodn -- and that means
doing the diff on the *external* representation, ie. with keywords
*expanded*. But that's the reason I say we want both ways.

In fact we may even want one more option in between, where each filter could
specify whether the in between is with that filter applied or unapplied, so
you could diff with collapsed keywords, but local line endings by default.

> >                   Not that it's too important for keywords, but
> newline style
> > and charset conversion should use the same mechanism.
> 
> Hear! Hear!

Yes, the mechanism is really the same. We need a possibility to hook a filter
class to the read and write to/from working tree and then various classes
would attach themselves to the inventory entry (via properties mechanism or
something like that) and provide those filters.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060426/9b9fcd31/attachment.pgp 


More information about the bazaar mailing list