Theodore Tso <tytso@xxxxxxx> writes: >> > +# This file is licensed under the GPL v2, or a later version >> > +# at the discretion of Linus Torvalds. >> >> Heh ;-). > > Hey, that's what the COPYING file requested, and it was late when I > started doing the git package integration, hence the stupid think-o > with the man page. :-) > > I assume you would prefer that it read Junio instead? Oh, no, sorry. The text itself is just fine as is, if that is the way you want. I just laughed out because I remembered the list discussion (which might also have cc'ed the kernel list, but I do not remember) about possible relicensing schenario, where Linus mentioned that exact clause in the COPYING file, saying that his discretion would by now be to let me decide ;-). >> You should be able to set IFS to exclude SP and then you only >> have to say you do not support LF and HT, both of which are much >> less likely than SP to be in the pathname. > > Do we have any coding guidelines about what characters we have to > support in filenames? I had assumed that we should support at least > SP and HT, but life does get easier if we don't need to worry about HT. The core scripts, at least the ones I personally use, are meant to handle all characters, including SP, HT and LF, so if there were any guidelines that would be it. However, your particular case to interface with external editor needs `eval` with sq magic if it needs to be coded in portable bourne, which can be done, but I suspect it is not worth doing, as we would not see HT in pathnames in the practice. UNIXy folks tend to avoid any whitespaces in the filenames, and Windows folks cannot use HT in pathnames as far as I understand. > Yeah, that should probably read "merge conflict resolution programs", > even though that's a lot more words. > >> > +if test $# -eq 0 ; then >> > + files=`git ls-files -u --abbrev=8 | colrm 1 24 | sort -u` >> >> Careful. I think --abbrev=8 just means use at least 8 but more >> as needed to make them unique. sed -e 's/^[^ ]* //' >> (whitespace are HTs) would be safer and simpler, as you are not >> dealing with a pathname that has LF in it anyway. > > OK, I can do that. Alternatively I guess I could submit a patch which > caused git-ls-files to only list the files that still needed merging. > (i.e., git-ls-files -u --nostage".) Do you have any preferences? The latter would be more useful in general, and something I should have done long time ago to help scripts. Thanks. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html