[
https://issues.apache.org/jira/browse/XALANJ-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776111#comment-17776111
]
Vladimir Sitnikov commented on XALANJ-2671:
-------------------------------------------
{quote}With all due respect – Could folks reach consensus on a solution?
{quote}
With all respect, could committers agree to invite committers who know the way
to operate Git and configure CI?
I suggested fixing the issue long before you started working on Maven changes,
and does not sound right to use Maven as an excuse of taking shortcuts instead
of properly fixing XALANJ-2671.
----
Below are the instructions (6 git commands). They are trivial, reproducible,
and they involve nothing from advanced git sections.
{noformat}
# Ensure local git history includes everything from the server
git fetch
# Move to master branch
git switch master
# Create branch to keep the history as some of the changes might be worth
transplanting later
git branch old_master
# Push the backup to the server for historical reasons
git push origin old_master
# Move "master" branch to origin/xalan-j_2_7_1_maint branch
git reset --hard origin/xalan-j_2_7_1_maint
# Update the server with new master
git push --force-with-lease origin master
{noformat}
First of all, the previous release was cut form xalan-j_2_7_1_maint branch.
That means, it would be better to just continue development on top of those
commits.
In other words, xalan-j_2_7_3-rc10 tag points to
25b9c336f03263749ba6046a8a57b219331181b1, so I would suggest moving master
branch to exactly that commit and proceed the development from there.
Frankly speaking, I find that xalan-java repository *misses* the release tag,
so it is hard to tell which commit xalan developers treat as the release ones,
however, that is a different story which does not impact my suggestion. I
believe it is something that the PMC must fix, and it might even be better to
fix it before fixing the current issue.
In any case, there's *absolutely no sense* in trying to align the old master
branch with xalan-j_2_7_3-rc10 as "the old master branch" was never used for
the releases, and the history in master must not unexpectedly infiltrate into
the current development branch.
> Source code history lost in "clearing all contents" + "updating master
> branch, to have same contents as..." commits
> -------------------------------------------------------------------------------------------------------------------
>
> Key: XALANJ-2671
> URL: https://issues.apache.org/jira/browse/XALANJ-2671
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Reporter: Vladimir Sitnikov
> Assignee: Gary D. Gregory
> Priority: Critical
>
> I just noticed that the following commits virtually erased all the code
> history, and they made it way harder to use git for analysis of the changes.
> I would suggest stopping further commits to the branch that contains
> "clearing all + updating all" changes, and start over from a reasonable
> branch.
> Please, take this seriously. It is really crucial to keep git annotate in a
> good shape, otherwise bug analysis becomes extremely hard.
> 0affa12bb12e45bf681a6e6a918d68884d7e1877 "clearing all the project contents
> from the xalanj master branch"
> 356ce496faa80d97ae8a8406e37f6bd994b39233 "updating master branch, to have
> same contents as the branch xalan-j_2_7_1_maint"
> For instance, if you check "git blame" for DocumentCall.java, you'll find
> that "every line was added only 2 months ago":
> https://github.com/apache/xalan-java/blame/master/src/org/apache/xalan/xsltc/compiler/DocumentCall.java
> I am afraid the above commits are showstopper for further activity on the
> branch.
> git blame on xalan-j_2_7_1_maint branch looks much better:
> https://github.com/apache/xalan-java/blame/xalan-j_2_7_1_maint/src/org/apache/xalan/xsltc/compiler/DocumentCall.java
> Since there were no releases on the master branch since the bad commits, I
> would suggest removing the commits from the repository completely.
> It is fine from the ASF policies, and it would be great to kill the commits
> as having commits that modify 400'000 lines make Git history hard to browse
> in various tools.
> Please remove those commits as they make history browsing, and error analysis
> hard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
