>For the past 15 years, we've used the hardcoded 64 as the length limit of the >filename of the output from the "git format-patch" >command. Since the value is shorter than the 80-column terminal, it could grow >without line wrapping a bit. At the same time, since the value is longer than half >of the 80-column terminal, we could fit two or more of them in "ls" output on >such a terminal if we allowed to lower it. > >Introduce a new command line option --filename-max-length=<n> and a new >configuration variable format.filenameMaxLength to override the hardcoded >default. > It would be very hard to remove a config knob rather than add a new one and we already have too many. Does it worth to add a new configuration variable for this or just a hard-coded value is enough? >While we are at it, remove a check that the name of output directory does not >exceed PATH_MAX---this check is pointless in that by the time control reaches the >function, the caller would already have done an equivalent of "mkdir -p", so if the >system does not like an overly long directory name, the control wouldn't have >reached here, and otherwise, we know that the system allowed the output >directory to exist. In the worst case, we will get an error when we try to open the >output file and handle the error correctly anyway. > >Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
