[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] Feature request: Print paths relative to the
From:       David Leuschner <david.leuschner () googlemail ! com>
Date:       2011-05-09 23:41:30
Message-ID: BANLkTikU5F5twPYneRn_yvsecrgreFuHWQ () mail ! gmail ! com
[Download RAW message or body]

>>> Now there probably are some reasons for darcs' design, and we certainly
>>> cannot simply change the default behaviour. But I would like to see a flag
>>> (that I can put in my ~/.darcs/defaults) giving me git's file name
>>> handling here:
>>
>> Unless there is a very good reason for this to be optional, could we
>> just switch to the proposed relative-path behaviour?
>>
>> Wherever possible, we should aim for sensible behaviour over options.
>
> I think I just detailed in my previous email why absolute paths can be useful.

Just to make it a little more difficult: I'd probably prefer relative
paths for a plain
"darcs whatsnew" (because of "copy/paste") but there are also good
arguments for
keeping the current behavior.

But what I find really confusing is that if I tell darcs to "give me
the changes for this directory" by
using

$ darcs whatsnew .

or

$ darcs whatsnew my/relative/path

it still does not report relative paths.  Other unix-tools like "find"
pick up the path I give them, thus "find $(pwd)" will give me absolute
paths and "find ." will give me relative paths. (At least the GNU find
does.)

A possible solution could be to keep the current behavior when no
arguments are given.  If arguments are given the reported paths always
start with path of one of the arguments.  (That's what "find" does -
try something like: "find .. subdir")

Cheers, David

-- 
David Leuschner
Kartäuserstraße 51b
79102 Freiburg
Tel.: +49 761 4296027
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users

[prev in list] [next in list] [prev in thread] [next in thread]