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