Dev-iL commented on code in PR #65629:
URL: https://github.com/apache/airflow/pull/65629#discussion_r3121498267
##########
AGENTS.md:
##########
Review Comment:
👍
##########
dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md:
##########
@@ -279,13 +279,15 @@ This is a step-by-step instruction on how to use it:
1. You need to have "airflow" repository checked out separately from the
repository you are working on. For
example in `/home/myuser/airflow-constraints` folder.
2. You need to checkout `constraints-main` branch in this repository. By
default the command expects that
- there is a remote named "apache" pointing to the official Apache
repository. You can override this
- by passing `--remote-name` option to the command.
+ there is a remote named "upstream" pointing to the `apache/airflow`
repository (the standard remote
+ naming convention — see
+
[`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)).
+ You can override this by passing `--remote-name` option to the command.
3. You need to run `breeze release-management update-constraints` command. The
`breeze` command comes usually
Review Comment:
Comsider rewriting this bullet to avoid using "usually" twice. Suggestions
by gemini:
- Option 1 (Direct):
You need to run the `breeze release-management update-constraints` command.
Typically, `breeze` is run from a separate clone of the Airflow repository,
specifically from the main branch.
- Option 2 (Concise):
Run the `breeze release-management update-constraints` command. This usually
stems from another clone of the Airflow repository (often the main branch).
- Option 3 (Action-oriented):
You need to run `breeze release-management update-constraints`. Note that
the `breeze` command generally comes from a different Airflow clone,
specifically the one tracking the main branch.
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -165,15 +165,18 @@ Step 4: Prepare PR
`How to sync your fork <10_working_with_git.rst#how-to-sync-your-fork>`_
for details.
* Create a local branch for your development. Make sure to use latest
- ``apache/main`` as base for the branch. See `How to Rebase PR
</contributing-docs/10_working_with_git.rst#how-to-rebase-pr>`_ for some details
- on setting up the ``apache`` remote. Note, some people develop their
changes directly in their own
- ``main`` branches - this is OK and you can make PR from your main to
``apache/main`` but we
+ ``upstream/main`` as base for the branch. See `How to Rebase PR
</contributing-docs/10_working_with_git.rst#how-to-rebase-pr>`_ for details
+ on setting up the ``upstream`` remote (Airflow standardises on
``upstream`` →
+ ``apache/airflow`` and ``origin`` → your fork — see
+ `Git remote naming conventions
</contributing-docs/10_working_with_git.rst#git-remote-naming-conventions>`_).
+ Note, some people develop their changes directly in their own
+ ``main`` branches - this is OK and you can make PR from your main to
``upstream/main`` but we
recommend to always create a local branch for your development. This
allows you to easily compare
changes, have several changes that you work on at the same time and many
more.
- If you have ``apache`` set as remote then you can make sure that you have
latest changes in your main
- by ``git pull apache main`` when you are in the local ``main`` branch. If
you have conflicts and
+ With ``upstream`` configured you can make sure that you have latest
changes in your main
Review Comment:
```suggestion
With ``upstream`` configured you can make sure that you have the latest
changes in your main
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
