On 2/20/2013 3:53 AM, Matt Welland wrote:
Regarding extras noise ... if your extras puts out junk then consider
setting up your ignore-glob.
I find keeping extras clean using ignore-glob makes addremove useful and
generally makes repos more manageable. Just my two cents.
While this is generally good advice, until the advent of versionable
settings it was nearly impossible to follow in the sorts of embedded
systems cross-development projects stuck with horrible
manufacturer-specific IDEs I am generally plagued with.
Even with versionable settings, it can be annoying to maintain. It might
be handy to have a --ignore-ignore-glob option for fossil extras that
includes files that would have been ignored, probably also marked in
some way, so that the ignore-glob setting can be tested, audited, and
debugged. Although a much better name for that options should be found.
The problem I see with including extras in status is that as I
understand it the extras require a complete traversal of the open
checkout's file tree to be identified. Everything else that status
reports on is discoverable by traversing the repository, and only
resorting to the file tree to discover changes and files that went
missing due to unrecorded renames or deletions.
So I second the notion of a separate json extra command to signal that
the additional work really is wanted.
I have no strong opinions about the structure of the payload, other than
the segregation of extras from other changes. Perhaps I'd even go so far
as to imagine json status, json changes, and json extras where status
doesn't include anything more than an indication of whether changes are
known to exist, and the two commands changes and extras are analogous to
their CLI namesakes.
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
