summaryrefslogtreecommitdiff
path: root/git-gui/lib/choose_font.tcl
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <Johannes.Schindelin@gmx.de>2008-02-18 17:55:22 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2008-02-19 22:44:20 -0800
commitfef3a7cc5593d3951a5f95c92986fb9982c2cc86 (patch)
tree81ce1c065ed8096c17c696bc3adaa391fee48ac1 /git-gui/lib/choose_font.tcl
parentGIT 1.5.4.2 (diff)
downloadtgif-fef3a7cc5593d3951a5f95c92986fb9982c2cc86.tar.xz
cvsexportcommit: be graceful when "cvs status" reorders the arguments
In my use cases, "cvs status" sometimes reordered the passed filenames, which often led to a misdetection of a dirty state (when it was in reality a clean state). I finally tracked it down to two filenames having the same basename. So no longer trust the order of the results blindly, but actually check the file name. Since "cvs status" only returns the basename (and the complete path on the server which is useless for our purposes), run "cvs status" several times with lists consisting of files with unique (chomped) basenames. Be a bit clever about new files: these are reported as "no file <blabla>", so in order to discern it from existing files, prepend "no file " to the basename. In other words, one call to "cvs status" will not ask for two files "blabla" (which does not yet exist) and "no file blabla" (which exists). This patch makes cvsexportcommit slightly slower, when the list of changed files has non-unique basenames, but at least it is accurate now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-gui/lib/choose_font.tcl')
0 files changed, 0 insertions, 0 deletions