Hi, On Wed, 14 May 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > In commit fef3a7cc(cvsexportcommit: be graceful when "cvs status" > > reorders the arguments), caution was taken to get the status even for > > files with leading or trailing whitespace. > > > > However, the author of that commit missed that chomp() removes only > > trailing whitespace. But the author realized his mistake. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > > > Really my fault. > > I am not quite sure if I understand what is going on correctly. > > Is this about a filename that has leading or trailing whitespace, or > lazily not parsing a protocol message but attempting to match with > possible whitespaces around the place where a filename should be? > > If you are saying that the output from cvs status is so unreliable that > we can only strip all whitespaces from both ends and hope for the best > (e.g. files " a" (two leading spaces in the name), "a " (two trailing > spaces in the name), and "a" (no such funny spaces) cannot be > distinguished from cvs status output), then perhaps you would also need > to remove as many trailing whitespaces as you can? Yes, that is the idea. The point is: there are at least two different implementations of cvs, and I do not want to rely on a particular one. To prevent bad things from happening, the status is checked on a set of files which have unique names with regard to the chomp()ed name (well, whatever we do to the name, really). So yes, this patch needs an update. Will do so in a couple of hours, Dscho -- 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
