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
Improve "git sync" and "git fork" resilience #1226
Conversation
…urrent directory with existing repo
* Use new URI instead of URI.create from user input, according to spec * Properly respect --no-remote for --sync * Tighten variable types from String to specialized types * Add/improve comments
(including moving GitCredentials.approve to an earlier location)
|
And oh, I added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I like the cleanups.
@magicus This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 4 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, too.
/integrate |
Going to push as commit e6ce7a6.
Your commit was automatically rebased without conflicts. |
The Skara CLI tools
git sync
andgit fork
are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-)These changes make sure that
git sync
always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), andgit fork
always sets up your repository for suchgit sync
usage.If you really know what you are doing, you can still use
git sync
to sync between fully unrelated repos using the--to
and--from
arguments, but this is highly discouraged (and will require the--force
flag as well, to be accepted).Before syncing,
git sync
will check that you have a properorigin
andupstream
remote configured, and that the upstream is consistent with what the Git Forge provider says. If theupstream
remote is missing, it will be configured for you (unless--no-remote
is given).git fork
will now always set theupstream
remote (unless given--no-remote
).If these sounds like obvious behavior, it is worth noting what happened before. If
upstream
was missing,git sync
had no idea what to do.git fork
had a second, undocumented *) mode, in which you could rungit fork
without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keeporigin
as the upstream repo URI, and instead add afork
remote for the newly created personal fork. This mode of operation was barely supported (and broken) ongit sync
. The backwards way of naming the remotes could lead to no end of troubles.*) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to
git fork
is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified).When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in
git fork
, where adding--no-remote
would disable--sync
and--setup-pre-push-hooks
. I fixed that also.Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc.
Progress
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/skara pull/1226/head:pull/1226
$ git checkout pull/1226
Update a local copy of the PR:
$ git checkout pull/1226
$ git pull https://git.openjdk.java.net/skara pull/1226/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1226
View PR using the GUI difftool:
$ git pr show -t 1226
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/skara/pull/1226.diff