My intuition says: Use -M|--message-file.
- Altu
-----Original Message-----
From: Stephan Beal <sgb...@googlemail.com>
To: fossil-users@lists.fossil-scm.org
Sent: Thu, Dec 10, 2009 4:19 pm
Subject: Re: [fossil-users] Commit failing... retyping commit message
On Thu, Dec 10, 2009 at 9:41 AM, Daniel Hoolihan <d...@archoo.net> wrote:
i completely agree with "lets keep options to a minimum" and i
appreciate the comment "we shouldn't mind code complexity"
so .. might i suggest that -m be overloaded?? so both of these would work..
Good morning!
i've changed it to -ZZZ and --read-message-from-file.
Just kidding.
The original justification for using "-M" was "-M is an alternate form of -m,"
and my instinct says to use -M over -i/--infile (which i find a bit confusing
in this context because the committed files are the "input files"). Jeremy's
suggestion of --message-file is a good alternative to --comment-file, and seems
more intuitive to me.
fossil commit -m ./file.txt would
fossil commit -m "commit message"
essentially -m <value> would first check to see if <value> resolves to a
valid file, otherwise take <value> to be the comment text..
This would actually more than double the code needed, i think. Currently i use
blob.c::blob_read_from_file() to populate the comment string from, and that
function calls fossil_panic() (i.e. exit app) if the file doesn't exist:
if( zComment ){ /* -m TEXT */
blob_zero(&comment);
blob_append(&comment, zComment, -1);
}else if( zCommentFile ){ /* -M FILENAME */
blob_zero(&comment);
blob_read_from_file(&comment, zCommentFile);
}else{ /* use editor */
prepare_commit_comment(&comment);
}
We'd need to merge the first 'if' and 'else if', and then add the logic to test
for file existence (or just try to open it), and fall back to using zComment as
a -m string if we can't find/open the file. While that would work 99.9% of the
time, it would fail with unexpected results when a commit message string really
does resolve to a readable file. i honestly don't think it would ever happen,
but the possibility is there:
f commit -m /etc/hosts foo.c
Not tragic, but mildly disturbing to look at in the commit log (and may require
a purge of the artifact, depending on the security/sensitivity level of the
system it was pulled from). On a similar note:
f commit -m /etc/sudoers foo.c
would fail (via fossil_panic()) for non-root users because /etc/sudoers is mode
0440 on most systems.
Again, far-fetched but possible.
i'm with Jeremy on this one: -M/--message-file. That said, Richard's been
interestingly quiet throughout this conversation, which leads me to suspect
that he's hacking away at some clever alternative which will make all this moot
:).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________fossil-users mailing
listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
