monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] diff bug 20447


From: Thomas Keller
Subject: Re: [Monotone-devel] diff bug 20447
Date: Mon, 10 May 2010 09:53:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.4

Am 10.05.2010 06:06, schrieb Derek Scherger:
> At the moment these changes result in slightly different diff output for
> additions and deletions which both now use /dev/null for one file (the
> source for adds and the target for deletes). There's a big comment in
> diff_output.cc that made this seem like the right approach. This new
> implementation currently does output a diff against /dev/null for a deletion
> where previously we simply didn't display anything. I'm not sure which is
> preferable but it's trivial to change, maybe we even want an option to
> control this? The new implementation also shows the both names involved when
> a rename occurs although I'm not sure if this is such a good idea as it may
> confuse patch and friends. Changing this is also trivial.

It always stroke me quite odd why our diffs contain file additions, but
not deletions, especially since this is the only way to tell standard
patch tools to delete the file / the contents, so this change is greatly
appreciated. Other than that we should test if standard patch accepts
the rename information (and even acts accordingly) - if yes, this should
not be a problem, since most tools behave patch-compliant anyways.

> This problem is closely related to the problem of adding a directory d, then
> adding a file f to it and then restricting a commit to just the file d/f
> which fails because the directory addition is excluded. One fix for this
> would be to change the restrictions code so that including a file implicitly
> includes changes to all of its parent directories (non-recursively). So a
> commit of d/f would include d and d/f but not other children of d. I'm not
> sure if there are other ways we could deal with this.
> 
> In the case of mv d d2 above if we include parents of f committing d2/f
> would also commit the rename of d to d2. This would effectively rename all
> other children x of d to d2/x as well which seems somewhat questionable,
> although it might be better than failing with 'mtn: misuse: file d/f does
> not exist'.

I'm also for this solution, because I think the parent rename is
expected to happen as well from a user's point of view (well, at least
mine, because I think this is much more consistent :). If the user
doesn't want that other files change from d/x to d2/x, he simply has to
commit the patch before he starts renaming anything.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]