summaryrefslogtreecommitdiffstats
path: root/progress.py
Commit message (Collapse)AuthorAgeFilesLines
* Fix blank line issues reported by flake8David Pursehouse2020-02-121-0/+1
| | | | | | | | | | | | | | | | | | | | - E301 expected 1 blank line - E302 expected 2 blank lines - E303 too many blank lines - E305 expected 2 blank lines after class or function definition - E306 expected 1 blank line before a nested definition Fixed automatically with autopep8: git ls-files | grep py$ | xargs autopep8 --in-place \ --select E301,E302,E303,E305,E306 Manually fix issues in project.py caused by misuse of block comments. Change-Id: Iee840fcaff48aae504ddac9c3e76d2acd484f6a9 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254599 Reviewed-by: Mike Frysinger <vapier@google.com> Tested-by: David Pursehouse <dpursehouse@collab.net>
* Fix indentation issues reported by flake8David Pursehouse2020-02-121-18/+18
| | | | | | | | | | | | | | | | | | | | | - E121 continuation line under-indented for hanging indent - E122 continuation line missing indentation or outdented - E125 continuation line with same indent as next logical line - E126 continuation line over-indented for hanging indent - E127 continuation line over-indented for visual indent - E128 continuation line under-indented for visual indent - E129 visually indented line with same indent as next logical line - E131 continuation line unaligned for hanging indent Fixed automatically with autopep8: git ls-files | grep py$ | xargs autopep8 --in-place \ --select E121,E122,E125,E126,E127,E128,E129,E131 Change-Id: Ifd95fb8e6a1a4d6e9de187b5787d64a6326dd249 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254605 Reviewed-by: Mike Frysinger <vapier@google.com> Tested-by: David Pursehouse <dpursehouse@collab.net>
* sync: merge project updates with status barMike Frysinger2019-11-121-2/+3
| | | | | | | | | | | | | | The current sync output displays "Fetching project" and "Checking out project" messages and progress bar updates independently leading to a lot of spam. Lets merge these periodic outputs with the status bar to get a little bit tighter output in the normal case. This doesn't solve all our problems, but gets us closer. Bug: https://crbug.com/gerrit/11293 Change-Id: Icd627830af4dd934a9355b7ace754b56dc96cfef Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/244934 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* sync: improve output with intermingled progress bars and statusMike Frysinger2019-09-131-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When displaying progress bars, we use \r to reset the cursor to the start of the line before showing the new update. This assumes the new line will fully erase whatever was displayed there previously. The "done" codepath tries to handle this by including a few extra spaces at the end of the message to "white out" what was there. Lets replace that hack with the standard ECMA escape sequence that clears the current line completely. This is the CSI "erase in line" sequence that the terminal will use to delete all content. The \r is still needed to move the cursor to the start of the line. Using this sequence should be OK since we're already assuming the terminal is ECMA compliant with our use of coloring sequences. We also put the \r after the CSI sequence on the off chance the terminal can't process it and displays a few bytes of garbage. The other improvement is to the syncbuffer API. When it dumps its status information, it almost always comes after a progress bar update which leads to confusing comingled output. Something like: Fetching projects: 100% (2/2) error: src/platform2/: branch ... Since the progress bar is "throw away", have the syncbuffer reset the current output to the start of the line before showing whatever messages it has queued. Bug: https://crbug.com/gerrit/11293 Change-Id: I6544d073fe993d98ee7e91fca5e501ba5fecfe4c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/236615 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* rename local trace moduleMike Frysinger2019-08-271-1/+1
| | | | | | | | | | There is a standard Python "trace" module, so having a local trace.py prevents us being able to import that. Rename the module to avoid. Change-Id: I23e29ec95a2204bb168a641323d05e76968d9b57 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/234832 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* set default file encoding to utf-8Mike Frysinger2019-06-131-0/+1
| | | | | | | | There's no reason to support any other encoding in these files. This only affects the files themselves and not streams they open. Bug: https://crbug.com/gerrit/10418 Change-Id: I053cb40cd3666ce5c8a0689b9dd938f24ca765bf
* Always print percentage when syncing quietlyTim Schumacher2017-07-151-2/+4
| | | | Change-Id: I574396e63520781067ed1e991c41caf7640e5731
* Add a newline after "Fetching projects" progress outputTim Schumacher2017-06-131-3/+5
| | | | | | | | | | | | | | | | | Output before change: Fetching project platform/packages/providers/UserDictionaryProvider Fetching projects: 66% (773/1171) Fetching project platform/external/regex-re2 Fetching project device/generic/mini-emulator-x86_64 Output after change: Fetching project platform/packages/providers/UserDictionaryProvider Fetching projects: 66% (773/1171) Fetching project platform/external/regex-re2 Fetching project device/generic/mini-emulator-x86_64 Change-Id: I4da84da58316c69294e4da2792f83885dc942701
* Support units in progress messagesShawn O. Pearce2011-09-191-7/+8
| | | | | | | | This allows our progress meter to be used for bytes transferred, by setting the units to KB or MB to let the user know the size. Change-Id: Ie8653d4a40d79439026c18bd51915845b2c5bba9 Signed-off-by: Shawn O. Pearce <sop@google.com>
* Do not emit progress if stderr is not a ttyShawn O. Pearce2010-05-271-2/+5
| | | | | | | | Avoids logging progress data into cron logs, etc. Suggested-by: Michael Richardson <mcr@sandelman.ottawa.on.ca> Change-Id: I4eefa2c282f0ca0a95a0185612b52e2146669e4c Signed-off-by: Shawn O. Pearce <sop@google.com>
* Only display a progress meter once we spend 0.5 seconds on a taskShawn O. Pearce2009-04-181-1/+10
| | | | | | | | | | | | | | | The point of the progress meter is to let the user know that the task is progressing, and give them a chance to estimate when it will be complete. If the task completes in under 0.5 seconds then it is sufficiently fast enough that the user doesn't need to be kept up-to-date on its progress; in fact showing the meter may just slow the task down waiting on the tty to redraw. We now delay the progress meter 0.5 seconds (or 1 second if the Python time.time() function isn't accurate enough) to avoid any really fast tasks, like a no-op local sync. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Disable the progress meter when trace is enabledShawn O. Pearce2009-04-181-0/+7
| | | | | | | | | The trace output often interfers with the progress meter, so its easier to just disable the progress meter if trace is active. Its already verbose enough to let the user know we are working, which is all the progress meter is there for anyway. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Don't divide by zero in progress meterShawn O. Pearce2009-04-161-14/+27
| | | | | | | | | If there are no projects to fetch, the progress meter would have divided by zero during `repo sync`, and that throws a ZeroDivisionError. Instead we report the progress with an unknown amount remaining. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Add a project progress meter to 'repo sync'Shawn O. Pearce2009-04-101-0/+45
This way users can see how much is left during fetch. Its especially useful when most syncs are no-ops but there are hundreds of repositories to poll. Signed-off-by: Shawn O. Pearce <sop@google.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-05-13 02:57:53 +0000