Skip to content
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

Check git status on upstream ultralytics or origin dynamically #8694

Merged
merged 12 commits into from
Jul 31, 2022

Conversation

pourmand1376
Copy link
Contributor

@pourmand1376 pourmand1376 commented Jul 23, 2022

This repo has 10k forks. Mosts of them would never update their repos and use outdated versions. We should warn them since this has great cost. Currently, It just compares it to master. This approach doesn't work for forked repos!

git remote -v
origin	https://github.com/pourmand1376/yolov5 (fetch)
origin	https://github.com/pourmand1376/yolov5 (push)
ultralytics	https://github.com/ultralytics/yolov5.git (fetch)
ultralytics	https://github.com/ultralytics/yolov5.git (push)

Then, I separate them by '\n' character and find the name of the remote which has the address of main repo. For normal repos, this is origin, but for forked repos, this doesn't exist! We should create it for the first time and use it afterwards.

This is because I have wasted two days of my time debugging and finding errors in the code that has been already fixed. I think we should really warn users for outdated repos.

🛠️ PR Summary

Made with ❤️ by Ultralytics Actions

🌟 Summary

Enhanced git status checks in YOLOv5 with more robust handling of git remotes.

📊 Key Changes

  • 🔄 The check_git_status function can now specify a repository.
  • 🔍 Improved detection of the repository's remote URL.
  • 🔄 If the necessary remote does not exist, it is added dynamically.
  • 🗂️ The git fetch command now uses the correct remote.
  • 🆕 Added a more dynamic way to determine the number of commits behind the upstream.

🎯 Purpose & Impact

  • 🤝 This update makes the codebase more flexible by allowing status checks against different repositories.
  • 🔗 By automatically adding missing remotes, users are eased from manual git configuration steps.
  • 🛠 The dynamic commit comparison reduces the likelihood of errors when checking if the local repository is up to date.
  • 🔄 Potential impact: Easier maintenance for users with forks or customized setups of the YOLOv5 repository.

@pourmand1376 pourmand1376 marked this pull request as ready for review July 23, 2022 20:18
@pourmand1376
Copy link
Contributor Author

Is this idea interesting to you?
@glenn-jocher

@Mandroide
Copy link

I

This repo has 10k forks. Mosts of them would never update their repos and use outdated versions. We should warn them since this has great cost. Currently, It just compares it to master. This approach doesn't work for forked repos!

git remote -v
origin	https://github.com/pourmand1376/yolov5 (fetch)
origin	https://github.com/pourmand1376/yolov5 (push)
ultralytics	https://github.com/ultralytics/yolov5.git (fetch)
ultralytics	https://github.com/ultralytics/yolov5.git (push)

Then, I separate them by '\n' character and find the name of the remote which has the address of main repo. For normal repos, this is origin, but for forked repos, this doesn't exist! We should create it for the first time and use it afterwards.

This is because I have wasted two days of my time debugging and finding errors in the code that has been already fixed. I think we should really warn users for outdated repos.

I find two commits noisy for the history of the repo:

[pre-commit.ci] auto fixes from pre-commit.com hooks
[Merge branch 'add_update_branch' of https://github.com/pourmand1376/yolov5

It would be good if you rewrite history and cut them back to just these two commits:
add check
use else clause

@pourmand1376
Copy link
Contributor Author

pourmand1376 commented Jul 25, 2022

@Mandroide
This can be easily done using squash and merge option in GitHub when merging in finalized. See here.

However I am willing to fix it if you have disabled squash commits in GitHub.

@pourmand1376
Copy link
Contributor Author

This is now squashed into one commit!

@glenn-jocher
Copy link
Member

I

This repo has 10k forks. Mosts of them would never update their repos and use outdated versions. We should warn them since this has great cost. Currently, It just compares it to master. This approach doesn't work for forked repos!

git remote -v
origin	https://github.com/pourmand1376/yolov5 (fetch)
origin	https://github.com/pourmand1376/yolov5 (push)
ultralytics	https://github.com/ultralytics/yolov5.git (fetch)
ultralytics	https://github.com/ultralytics/yolov5.git (push)

Then, I separate them by '\n' character and find the name of the remote which has the address of main repo. For normal repos, this is origin, but for forked repos, this doesn't exist! We should create it for the first time and use it afterwards.
This is because I have wasted two days of my time debugging and finding errors in the code that has been already fixed. I think we should really warn users for outdated repos.

I find two commits noisy for the history of the repo:

[pre-commit.ci] auto fixes from pre-commit.com hooks [Merge branch 'add_update_branch' of https://github.com/pourmand1376/yolov5

It would be good if you rewrite history and cut them back to just these two commits: add check use else clause

Yes don't worry, only Squash and merge commits are allowed for PRs so all the individual commits get squashed into just one.

@glenn-jocher
Copy link
Member

glenn-jocher commented Jul 25, 2022

@pourmand1376 this PR is a very good idea, but I wonder if there's a more concise way to implement this.

The steps are 1) determine if ultralytics/yolov5:master is added as a remote origin, and 2) if not add it, then 3) get the diff using the existing code.

@pourmand1376
Copy link
Contributor Author

@glenn-jocher
Actually I haven't found any easier way to solve this. We have git ls-remote but that's totally for another purpose.

For checking existence of a remote, I first do a git remote -v then analyse lines to see if that exists and if that doesn't exist, I add it.

@democat3457
Copy link
Contributor

This will not work if ssh is used as the cloning method. Perhaps the url search should be changed to just ultralytics/yolov5?

@glenn-jocher
Copy link
Member

@pourmand1376 would @democat3457's idea here make this simpler?

This will not work if ssh is used as the cloning method. Perhaps the url search should be changed to just ultralytics/yolov5?

@pourmand1376
Copy link
Contributor Author

pourmand1376 commented Jul 31, 2022

I agree with @democat3457 but that would only remove https:// part in that string.

Other that this, I think git should have a one-liner which outputs remote's name based on url. I haven't found that yet. Does anybody know any commands for this purpose?

If that's not the case, I think I can rewrite the whole thing using list comprehension to make it simpler. I will do it as soon as I have my laptop :)

@glenn-jocher
Copy link
Member

@pourmand1376 I've made a few updates. The current implementation will not create new remotes if ultralytics/yolov5 is already linked to origin, and it should also be compatible with SSH clones (original PR only works for HTTPS).

@glenn-jocher
Copy link
Member

This also now advises on proper git pull ultralytics master command in case remote ultralytics needs to be added.

@glenn-jocher
Copy link
Member

@pourmand1376 can you test this on your side?

@glenn-jocher glenn-jocher changed the title Add remote ultralytics and check git status with that Check git status on upstream ultralytics or origin dynamically Jul 31, 2022
@glenn-jocher glenn-jocher merged commit afa403a into ultralytics:master Jul 31, 2022
@glenn-jocher
Copy link
Member

@pourmand1376 PR is merged. Tested locally with a fork and everything works correctly.

Thank you for your contributions to YOLOv5 🚀 and Vision AI ⭐

@glenn-jocher glenn-jocher removed the TODO label Jul 31, 2022
@glenn-jocher
Copy link
Member

@AyushExel this should make it easier for forks to stay up to date. Automatically adds a new ultralytics remote and fetches from there for comparison to indicate how many commits behind your fork is. Also indicates correct git pull ultralytics master command to user to update fork.

@pourmand1376
Copy link
Contributor Author

pourmand1376 commented Jul 31, 2022

Thanks for all of this!

I also tested locally and It works just fine.

But, When I tested on colab, it says that:

github: skipping check (Docker image), for updates see https://github.com/ultralytics/yolov5

I do not think this should be the case. Colab users should also get their updates. However I think I should report this bug on another issue.

@pourmand1376 pourmand1376 deleted the add_update_branch branch July 31, 2022 21:46
@glenn-jocher
Copy link
Member

@pourmand1376 ah thanks for spotting the Colab issue, I see it too. This is likely related to a recent update to is_docker() in #8711

@glenn-jocher
Copy link
Member

glenn-jocher commented Aug 1, 2022

@pourmand1376 Colab issue should be resolved now in #8813

Not sure if I've introduced a Docker issue now though. Waiting for the Docker image to update and will test.

EDIT: All Colab and Docker issues resolved.

@AyushExel
Copy link
Contributor

This is a great feature!
@glenn-jocher maybe update the CONTRIBUTING.md "keeping up to date with master branch" section with this command?

@glenn-jocher
Copy link
Member

@AyushExel yeah this is great. It's too bad the current 10k forks don't have this, but at least the next 10k will!

@glenn-jocher
Copy link
Member

glenn-jocher commented Sep 4, 2022

@pourmand1376 got a slight issue with this. Was working on my local fork and when I pushed to the fork it also pushed to ultralytics repo by accident since it had been added for both fetching and pulling.

Most users won't have this problem as they don't have push permissions to ultralytics/yolov5 but a few employees do so we need to be very careful.

I couldn't find any easy way to add a remote only for fetching but not pushing, i.e. https://stackoverflow.com/questions/7556155/git-set-up-a-fetch-only-remote

So I thought what if we simply do not add a remote but instead explicitly git fetch directly from ultralytics master, i.e.:
https://stackoverflow.com/questions/7556155/git-set-up-a-fetch-only-remote

$ git fetch https://github.com/ultralytics/yolov5
  
From https://github.com/ultralytics/yolov5
 * branch            HEAD       -> FETCH_HEAD

@pourmand1376
Copy link
Contributor Author

One idea is to add a .env file for developers and add a parameter in there. If the file exists and the parameter is set to True, this function should be disabled altogether.

Also, I think having a .env file for developers is a pretty common way.

Note that this file should not be committed to repo. This one should be in .gitignore and this will also be useful for extra parameters when in need.

@glenn-jocher
Copy link
Member

@pourmand1376 are there any downsides to simply fetching directly from the master URL?

git fetch https://github.com/ultralytics/yolov5

ctjanuhowski pushed a commit to ctjanuhowski/yolov5 that referenced this pull request Sep 8, 2022
…ltralytics#8694)

* Add remote ultralytics and check git status with that

* Simplify

* Update general.py

* Update general.py

* s fix

Co-authored-by: Glenn Jocher <glenn.jocher@ultralytics.com>
@pourmand1376
Copy link
Contributor Author

pourmand1376 commented Sep 9, 2022

@glenn-jocher
Do you mean we should fetch from the master URL without adding the remote?

@glenn-jocher
Copy link
Member

glenn-jocher commented Sep 9, 2022

@pourmand1376 yes exactly. Then there's no push attempts to ultralytics master, i.e. we wouldn't need to add it as a remote

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants