On Fri, December 2, 2011 11:39 pm, Matt Welland wrote:
> On Fri, Dec 2, 2011 at 4:03 PM, Eric <e...@deptj.eu> wrote:
>
>> On Fri, December 2, 2011 7:26 pm, Stephan Beal wrote:
>> > On Fri, Dec 2, 2011 at 8:17 PM, Eric <e...@deptj.eu> wrote:
>> >
>> >> Why on earth would you want to?
>> >>
>> >> I know others have offered suggestions and explanations for how to do
>> >> it,
>> >> but I would never have a "dotfile" (or a symlink for that matter) in
>> a
>> >> repository, so I'm really asking about the use-case.
>> >>
>> >>
>> > Think ".gitignore" and friends. Some tools support files like that for
>> > holding various metadata (some non-git tools support .gitignore).
>> >
>> > http://gitready.com/beginner/2009/01/19/ignoring-files.html
>> >
>>
>> Oh, I know about those. But they are one of
>>
>> 1) needed at build or install time, in which case the build and install
>> scripts create them
>>
>> 2) part of my common development environment, in which case they are not
>> part of what I am developing and do not belong in its repository
>>
>
> Do I detect a hint of judgment in your post Eric?

Of course. It's what I do, and what I think should be done so I will,
from time to time, say so. Others are free to disagree; and to negotiate
if we are working together.

> Items 1. and 2. are true in your world perhaps but certainly often
> not in mine. I lost an hour of my time because fossil silently ignored
> dot files that are a required critical part of a process that I moved
> from an ancient SCM into fossil.

You won't do that again will you? :) It's part of knowing what your
tools do and what assumptions they make. For any non-trivial tool,
you will sometimes learn the hard way.

> Personally I prefer my tools to let me know if i say "add" and they
> choose not to do so however the --dotfiles switch suffices.

How verbose should a tool be? There will probably always be cases the tool
author(s) never even thought of. And is it really the tool anyway? For
"fossil add *" on *ix, fossil doesn't know that it is skipping dotfiles,
because the shell has already done that.

> There are a few interesting arenas where "source" is not C, nor any
> other language you are likely to deal with as a "normal" programmer and
> yet these arenas can make good use of a tool like fossil and some even
> pay pretty dang good and maybe even deserve a bit of respect :)

Not arguing with that at all.

Eric

--
ms fnd in a lbry


_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to