On Aug 24, 2017, at 6:21 AM, David Mason <[email protected]> wrote:
>
> I want a symlink to behave in fossil like it does in the Unix find command -
> i.e. stop at a symlink without a --follow switch
+1: principle of least surprise. Fossil should not invent new semantics.
> like it does in the Unix tar command (which should be the model - if I
> `fossil add foo` it should reference the same things as `tar cf - foo`). So
> addremove, for example should not add things in the linked-so directory
Test cases, verified here on Linux and OS X:
$ mkdir foo
$ touch foo/a
$ ln -s foo bar
$ tar cf x.tar bar
$ tar tf x.tar
bar
The only exception I’d make is maybe to follow ls’s example, in that if you
give a trailing slash to a directory symlink, you mean for it to list the
target directory’s contents. tar doesn’t do this, but POSIX isn’t perfectly
consistent with itself.
An example of where this distinction might matter is in fossil checkin:
$ fossil ci foo # checks in any changes to the foo symlink alone
$ fossil ci foo/ # checks in changes to foo and any managed files
# in the pointed-to directory
> Since then I never use addremove because I don't trust it not to make work
> for me.
I avoid it on different grounds: I’m too lazy to keep my *ignore rules up to
date, so addremove often grabs files I don’t want it to. :)
I think addremove works best on freshly checked-out trees only.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
