-
Notifications
You must be signed in to change notification settings - Fork 2.2k
commands/prune: unify formatting #2757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2778479 to
71b60d1
Compare
|
|
|
All fixed. Here's a quick breakdown of what was going wrong --
|
technoweenie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great start. I made some suggestions relating to where the tasks are initialized and cleaned up.
commands/command_prune.go
Outdated
| pruneDeleteFiles(prunableObjects, percentage) | ||
| } | ||
|
|
||
| logger.Close() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be moved to a defer right after the logger is initialized? That ensures that it's closed if this func returns early, such as when prunableObjects is empty.
commands/command_prune.go
Outdated
| } | ||
|
|
||
| func pruneTaskDisplayProgress(progressChan PruneProgressChan, waitg *sync.WaitGroup, spinner *progress.Spinner) { | ||
| func pruneTaskDisplayProgress(progressChan PruneProgressChan, waitg *sync.WaitGroup, task *tasklog.SimpleTask) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not crazy about this function receiving a task, and then closing it. What do you think about sending it the logger instead, so that the task is created, enqueued, used, and completed all in this func?
commands/command_prune.go
Outdated
| logger.Enqueue(spinner) | ||
| // enqueue a _new_ percentage task to track deletion progress. | ||
| percentage := tasklog.NewPercentageTask("prune: Deleting objects", uint64(len(prunableObjects))) | ||
| logger.Enqueue(percentage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this percentage is only used inside pruneDeleteFiles(), why not pass logger to it instead. Same justification as my note on pruneTaskDisplayProgress().
tasklog/percentage_task_test.go
Outdated
| } | ||
|
|
||
| func TestPercentageTaskCallsDoneWhenComplete(t *testing.T) { | ||
| t.Skip() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this skip temporary, or should the test be removed?
|
@technoweenie thanks for the feedback, I agree with everything you said 😄. I un-skipped the test in 088b2ab, and changed the above methods to take a Can you take another look? 🙇 |
commands/command_prune.go
Outdated
| func pruneDeleteFiles(prunableObjects []string, task *tasklog.PercentageTask) { | ||
| func pruneDeleteFiles(prunableObjects []string, logger *tasklog.Logger) { | ||
| task := tasklog.NewPercentageTask("prune: Deleting objects", uint64(len(prunableObjects))) | ||
| logger.Enqueue(task) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small idea for another PR:
task := logger.NewPercentageTask(...) // create and enqueue task
defer task.Complete()There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ I'm silly -- this exists! Changed in 65b4f34.
commands/command_prune.go
Outdated
| info.Logf("prune: %d file(s) would be pruned (%s)", len(prunableObjects), humanize.FormatBytes(uint64(totalSize))) | ||
| if verbose { | ||
| Print(verboseOutput.String()) | ||
| for _, item := range verboseOutput { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can take out the two extra if verbose (here and L194), since verboseOutput will be empty in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good, call -- I changed this in 782c58c.
| info.Logf("\n%s", item) | ||
| } | ||
| } | ||
| info.Complete() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be moved to a defer, allowing the one on L192 to be removed too. I point it out because I think having a consistent pattern for dealing with loggers and tasks is important. I really like how the tasklog package is shaping up :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I don't think that these calls to Complete() can be deferred, since pruneDeleteFiles creates a new task, which (for the *tasklog.Logger to output), requires there to be no actively running task.
technoweenie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few nitpicky things, but overall I think this is a nice improvement. The old prune output was fine, but I very much prefer the Git style output for some reason.
In PR git-lfs#2757 the output of the "git lfs prune" command was revised to use the methods of the Logger structure of the "tasklog" package to output progress messages, replacing use of the Spinner structure from the older "progress" package. The Spinner structure and its methods were then removed in PR git-lfs#2759, and the "progress" package was removed entirely in PR git-lfs#2762. As part of this change, the "git lfs prune" command's progress messages were reformatted so as to always begin with the Git LFS subcommand name, for example, "prune: 8 local objects, 9 retained, done." Two other Git LFS commands follow the same design, the "git lfs fetch" and "git lfs migrate" commands, but no others. Git commands also do not prefix their progress messages with the name of the subcommand (although messages from a Git remote may be reported with the prefix "remote:"). To help bring all our commands' progress messages into alignment, we simply remove the "prune:" prefix from the messages output by the "git lfs prune" command. We expect to revise the progress messages from the "git lfs fetch" and "git lfs migrate" commands in the same way in subsequent commits of this PR.
In PR git-lfs#2757 the output of the "git lfs prune" command was revised to use the methods of the Logger structure of the "tasklog" package to output progress messages, replacing use of the Spinner structure from the older "progress" package. The Spinner structure and its methods were then removed in PR git-lfs#2759, and the "progress" package was removed entirely in PR git-lfs#2762. As part of this change, the "git lfs prune" command's progress messages were reformatted so as to always begin with the Git LFS subcommand name, for example, "prune: 8 local objects, 9 retained, done." Two other Git LFS commands follow the same design, the "git lfs fetch" and "git lfs migrate" commands, but no others. Git commands also do not prefix their progress messages with the name of the subcommand (although messages from a Git remote may be reported with the prefix "remote:"). To help bring all our commands' progress messages into alignment, we simply remove the "prune:" prefix from the messages output by the "git lfs prune" command. We expect to revise the progress messages from the "git lfs fetch" and "git lfs migrate" commands in the same way in subsequent commits of this PR.
In PR git-lfs#2757 the output of the "git lfs prune" command was revised to use the methods of the Logger structure of the "tasklog" package to output progress messages, replacing use of the Spinner structure from the older "progress" package. The Spinner structure and its methods were then removed in PR git-lfs#2759, and the "progress" package was removed entirely in PR git-lfs#2762. As part of this change, the "git lfs prune" command's progress messages were reformatted so as to always begin with the Git LFS subcommand name, for example, "prune: 8 local objects, 9 retained, done." Two other Git LFS commands follow the same design, the "git lfs fetch" and "git lfs migrate" commands, but no others. Git commands also do not prefix their progress messages with the name of the subcommand (although messages from a Git remote may be reported with the prefix "remote:"). To help bring all our commands' progress messages into alignment, we simply remove the "prune:" prefix from the messages output by the "git lfs prune" command. We expect to revise the progress messages from the "git lfs fetch" and "git lfs migrate" commands in the same way in subsequent commits of this PR.
This pull request removes the use of the
*progress.Spinnertype ingit-lfs-prune(1)in favor of a more consistent logging scheme.Before:
After:
This removes one of two existing uses of the
*progress.Spinnerimplementation, and the next pull-request in this series will remove the other use-case, which will allow*progress.Spinnerto be deleted.Please let me know if you have any thoughts on the formatting of these messages. I tried to make them as similar as I would imagine Git writing them, with these thoughts in mind:
*tasklog.Logger)./cc @git-lfs/core