Hi All,
I've got in my repo a small number of files that are changing but
these changes are not meant to be send to the repo (are kind of
user-specific). The files are needed in the repo but only in their
initial or some specific version. Is there any way to turn off change
tracking for some
Hi! No, there us no such mechanism in fossil. I sometimes have similar
problems with makefiles and config *files*, but i have never considered
that to be an scm-level problem (maybe it is?).
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Jul 2, 2012 11:24 AM,
Hi Stephan,
I think it is an scm-level problem, at least for me ;-)
The thing is that either I'll commit these file every time they change
(which makes a bit of mess in the repo) or I need to do a selective
commit which omits these files (which after a tens of commits become a
bit annoying).
On Mon, Jul 2, 2012 at 1:19 PM, Jacek Cała jacek.c...@gmail.com wrote:
The thing is that either I'll commit these file every time they change
(which makes a bit of mess in the repo) or I need to do a selective
commit which omits these files (which after a tens of commits become a
bit
On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal sgb...@googlemail.com wrote:
i'm not personally convinced that an ignore list would completely solve
the problem (i think that just might lead to more confusion (i changed the
file, why isn't it showing as changed?) and corresponding bug reports).
On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal sgb...@googlemail.comwrote:
i'm not personally convinced that an ignore list would completely solve
the problem (i think that just might lead to more confusion (i changed the
This is exactly how I would expect it to work. And I like the '--all'
option, too.
The only thing is if anything better than a list like 'ignore-glob'
can be proposed. In my case it's just a few files, so such a list
would be enough. However, I can imagine that someone has a large repo
and needs
On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała jacek.c...@gmail.com wrote:
would be enough. However, I can imagine that someone has a large repo
and needs to set no-autocommit to more than 10 files. Then maintaining
an 'ignore-glob'-like list may become a pain.
fossil/sqlite has routines for
2012/7/2 Stephan Beal sgb...@googlemail.com:
On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała jacek.c...@gmail.com wrote:
would be enough. However, I can imagine that someone has a large repo
and needs to set no-autocommit to more than 10 files. Then maintaining
an 'ignore-glob'-like list may
One more thought. Perhaps, there's no need for a separate ignore list
but just a bit different semantics of the existing 'ignore-glob'.
Couldn't it just be that when a file (a set of files '*.whatever') is
in the ignore-glob it behaves exactly like Richard suggested. From a
user perspective that
On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała jacek.c...@gmail.com wrote:
One more thought. Perhaps, there's no need for a separate ignore list
but just a bit different semantics of the existing 'ignore-glob'.
In my experience, changing/extending semantics means lots of new room for
special
2012/7/2 Stephan Beal sgb...@googlemail.com:
On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała jacek.c...@gmail.com wrote:
Couldn't it just be that when a file (a set of files '*.whatever') is
in the ignore-glob it behaves exactly like Richard suggested. From a
user perspective that would be simpler
On Mon, Jul 2, 2012 at 5:24 AM, Jacek Cała jacek.c...@gmail.com wrote:
Hi All,
I've got in my repo a small number of files that are changing but
these changes are not meant to be send to the repo (are kind of
user-specific). The files are needed in the repo but only in their
initial or
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała jacek.c...@gmail.com wrote:
Is there any difference except from being in the repo. I'd say,
truly ignored files are not in the repo at all, while partially
ignored happen to be although the scm just ignores their local
counterparts. Am I missing
If it happens I have some spare time, I'll look on the
{is/if}_selected and will report on any progress.
Cheers,
Jacek
2012/7/2 Stephan Beal sgb...@googlemail.com:
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała jacek.c...@gmail.com wrote:
Is there any difference except from being in the
On Mon, 2 Jul 2012 08:08:18 -0400
Richard Hipp d...@sqlite.org wrote:
I am willing to *consider* some option that says do not commit these
files, even if they change, unless that are specifically named on the
command-line. I think this would be easy to implement by messing
with the
On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer m...@mired.org wrote:
My solution has been to push things out to the build system. What gets
stored in the repo is config.template. In this, the values for
Another option might, depending on the system, be to include a local
config file/make
Just a general comment on this proposal
To reiterate the solution provided by Mike, I think this problem can be
easily solved by user methodology with no changes to fossil. If you have
generated or user edited files create and check in templates. Add the
appropriate targets to your make file
18 matches
Mail list logo
