-
-
Notifications
You must be signed in to change notification settings - Fork 954
BF: tolerate errors while parsing fetch lines #1015
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
Merged
Byron
merged 1 commit into
gitpython-developers:master
from
yarikoptic:bf-fetch-configmsg
May 31, 2020
Merged
BF: tolerate errors while parsing fetch lines #1015
Byron
merged 1 commit into
gitpython-developers:master
from
yarikoptic:bf-fetch-configmsg
May 31, 2020
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At first I thought to provide special treatment to git config lines and otherwise keep raising uncaught exception, but then decided that it might be better to loose some progress information than to crash. Also _get_push_info below is doing similarish catching of all exceptions (although doesn't even log them). With this change, log (if enabled and not suppressed) would show [WARNING] Git informed while fetching: git config pull.rebase false # merge (the default strategy) in the case of recently introduced change to the output in the following git commit : d18c950a69f3a24e1e3add3d9fc427641f53e12b is the first bad commit commit d18c950a69f3a24e1e3add3d9fc427641f53e12b Author: Alex Henrie <alexhenrie24@gmail.com> Date: Mon Mar 9 21:54:20 2020 -0600 pull: warn if the user didn't say whether to rebase or to merge Often novice Git users forget to say "pull --rebase" and end up with an unnecessary merge from upstream. What they usually want is either "pull --rebase" in the simpler cases, or "pull --ff-only" to update the copy of main integration branches, and rebase their work separately. The pull.rebase configuration variable exists to help them in the simpler cases, but there is no mechanism to make these users aware of it. Issue a warning message when no --[no-]rebase option from the command line and no pull.rebase configuration variable is given. This will inconvenience those who never want to "pull --rebase", who haven't had to do anything special, but the cost of the inconvenience is paid only once per user, which should be a reasonable cost to help a number of new users. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> builtin/pull.c | 16 ++++++++++++++++ t/t5521-pull-options.sh | 22 +++++++++++----------- t/t7601-merge-pull-config.sh | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+), 11 deletions(-) Closes gitpython-developers#1014
Thanks a lot!
Since this is an issue many users could start seeing soon, I will cut a release right away.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At first I thought to provide special treatment to git config lines and
otherwise keep raising uncaught exception, but then decided that it might be
better to loose some progress information than to crash.
Also _get_push_info below is doing similarish catching of all exceptions
(although doesn't even log them).
With this change, log (if enabled and not suppressed) would show
in the case of recently introduced change to the output in the following
git commit :
Closes #1014