build: merges are incorrectly handled when calculating a build tag #225
Comments
isaac-io
added a commit
that referenced
this issue
Nov 9, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
isaac-io
added a commit
that referenced
this issue
Nov 12, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
Nov 15, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
Nov 25, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
Nov 25, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
Nov 25, 2022
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
Apr 30, 2023
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Yuval-Ariel
pushed a commit
that referenced
this issue
May 4, 2023
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
udi-speedb
pushed a commit
that referenced
this issue
Nov 13, 2023
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
udi-speedb
pushed a commit
that referenced
this issue
Nov 15, 2023
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
udi-speedb
pushed a commit
that referenced
this issue
Dec 3, 2023
) Merge commits were incorrectly handled due to the named use of `git rev-list`, which does not give an ancestry path as I expected, but simply a list of unique commits between the two refs. Additionally, the check for the base tag was wrong in the face of merge commits, since a tag could be an ancestor through a merge commit, but not be the actual base of the branch. Both of these issues resulted in an incorrect tag being calculated, as well as a build slowdown due to the iteration over all of the commits from the other parent of the merge commit, which is unneeded. While at it, add logic for caching the build tag in order to speed up builds when the checked-out git tree hasn't changed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Due to the use of naked
git rev-list, the build tag attempts to calculate a build tag spanning the entire merge commit history from the other parent, resulting in incorrect base calculation for both the base tag and the base branch. Additionally, when long histories are merged, the calculation of the build tag takes a very long time due to the inclusion of all of these commits.To Reproduce
./build_tools/spdb_get_build_tag.pyExpected behavior
A correct build tag is calculated in a reasonable duration of time, especially in incremental builds.
Additional context
N/A
The text was updated successfully, but these errors were encountered: