"Maintain" a forked copy of jquery-form in this repo #394
Assignees
Comments
wincent
added a commit
that referenced
this issue
Feb 8, 2021
In service of:
#394
Basically, we want to pull in the code from this third-party project
(which is mostly on life-support at this point) and apply a small patch
on top. We don't anticipate having to change it much, if ever, so we are
sticking it under "third-party/projects/" and we won't cover it with our
normal linting/formatting/testing.
Note that because everything else in the repo pulls in history via
subtree merge, doing it here as well. That way if we ever need to `git
blame` in here we'll have something useful to look at.
Note also that in liferay-portal we are using v3.51 of this plugin and
have no plans to switch to the latest (v4.3.0) at this time, but I am
still pulling in and re-writing all of the tags so that we can easily
merge the newer stuff in in the future if we want to.
Steps follow.
Grab the code:
git remote add -f jquery-form https://github.com/jquery-form/form.git
Make directory for it. Note that it is going to live at
"third-party/projects/jquery-form/" and not "third-party/jquery-form/";
we want to reserve the top-level inside of "third-party/" for any future
tooling that we might want to share across projects, or any common
READMEs or other docs:
mkdir -p third-party/projects
Create annotated tags seeing as all the tags in the project are
unannotated:
for TAG in \
3.25.0-2013.01.18 \
3.32.0-2013.04.09 \
3.36 \
3.37.0 \
3.45.0 \
3.46.0 \
3.49 \
3.50 \
3.51; do
git tag -f -a -m jquery-form/v$TAG $TAG $TAG
done
for TAG in \
v3.19 \
v4.0.0 \
v4.0.1 \
v4.1.0 \
v4.2.0 \
v4.2.1 \
v4.2.2 \
v4.3.0; do
git tag -f -a -m jquery-form/$TAG $TAG $TAG
done
Rewrite tags to have a prefix. First tags starting with "v" and then
those without a leading "v":
support/filter-tags.sh jquery-form/master 'sed "s#^v#jquery-form/v#"'
support/filter-tags.sh jquery-form/master 'sed "s#^\([0-9]\)#jquery-form/v\1#"'
Do the actual subtree merge:
git merge -s ours --no-commit --allow-unrelated-histories jquery-form/v3.51
git read-tree --prefix=third-party/projects/jquery-form -u jquery-form/v3.51
git commit -m 'chore: merge jquery-form history into third-party/projects/'
Make sure shape of DAG is sane:
git log --oneline --decorate --graph --all
Push rewritten tags so that entire history will be reachable/explorable:
git push upstream-rw --tags --dry-run
git push upstream-rw --tags
Kill temporary remote that was added earlier. We don't want this lying
around because a careless `fetch` could pull down all the tags that we
don't want (because they aren't prefixed, or annotated, or even
consistent), and it is all too easy to accidentally contaminate the
upstream with these tags by a push. If we ever need to resync with
upstream history again, we can just re-add the remote:
git remote remove jquery-form
Amend commit to make these notes that you're reading now:
git commit --amend
This was referenced Feb 8, 2021
|
Ok, so I cut a release and will presently send an PR to liferay-portal updating to use it. As the work in this repo is done now, closing this. |
|
Upstream PR got merged: brianchandotcom/liferay-portal#98619 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See discussion over on this PR and in Slack (private link).
Basically, we need to patch jquery-form and forking a copy into our monorepo seems the least horrible way to do it. Other options considered:
PatchTask; rejected because shipping npm packages via JARs seems, er, "suboptimal".So, basic plan is to dump a copy into the repo here undo a "third-party" directory. ie. We won't apply the usual linting/formatting/testing; these projects will live off in their own separate world, even more isolated than the stuff in the
maintenance/directory (which at least uses shared linting/formatting etc), and it will be for stuff that we don't intend to update much... If that changes for any project, and we realize we need to update a project more invasively or frequently, we have the option of turning it into a "real" project and opting in to linting/formatting/testing etc. At that point it really becomes a hard fork. We can cross that bridge when we come to it.The text was updated successfully, but these errors were encountered: