summaryrefslogtreecommitdiff
path: root/contrib/hg-to-git/hg-to-git.py
diff options
context:
space:
mode:
authorShawn O. Pearce <spearce@spearce.org>2007-04-20 06:37:18 (GMT)
committerJunio C Hamano <junkio@cox.net>2007-04-20 08:43:57 (GMT)
commitad57cbca61afc921349ddb9e884ceee5bf2322a8 (patch)
tree6d6cfe80e4d5aaada820a81b314aa1d4cb2c3716 /contrib/hg-to-git/hg-to-git.py
parent744747ef1d75c85fb3a1785cb08d36497128d3d3 (diff)
downloadgit-ad57cbca61afc921349ddb9e884ceee5bf2322a8.zip
git-ad57cbca61afc921349ddb9e884ceee5bf2322a8.tar.gz
git-ad57cbca61afc921349ddb9e884ceee5bf2322a8.tar.bz2
Kill the useless progress meter in merge-recursive
The mess known as the progress meter in merge-recursive was my own fault; I put it in thinking that we might be spending a lot of time resolving unmerged entries in the index that were not handled by the simple 3-way index merge code. Turns out we don't really spend that much time there, so the progress meter was pretty much always jumping to "(n/n) 100%" as soon as the program started. That isn't a very good indication of progress. Since I don't have a great solution for how a progress meter should work here, I'm proposing we back it out entirely. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'contrib/hg-to-git/hg-to-git.py')
0 files changed, 0 insertions, 0 deletions