| commit | ad57cbca61afc921349ddb9e884ceee5bf2322a8 | |
| author | Shawn O. Pearce <spearce@spearce.org> | |
| Fri, 20 Apr 2007 06:37:18 +0000 (20 02:37 -0400) | ||
| committer | Junio C Hamano <junkio@cox.net> | |
| Fri, 20 Apr 2007 08:43:57 +0000 (20 01:43 -0700) | ||
| tree | 6d6cfe80e4d5aaada820a81b314aa1d4cb2c3716 | treesnapshot (tar.gz zip) |
| parent | 744747ef1d75c85fb3a1785cb08d36497128d3d3 | commitdiff |
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>
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>
| merge-recursive.c | diffblobblamehistory |