filter refs by spec #532
Merged
filter refs by spec #532
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's wrong though, and it turns out that for proper matching, it would need probably need a normalization step to turn partial ref-specs into full names, and from there the matching must also provide tracking branch information or generally, the other side of the spec for later updates.
Both differ as pattern on the command-line of ls-remote are just that, without needing to be parsed as ref-spec. Thus many pattenrs there seem to work when they should fail (if they were a ref-spec). It's worth noting though that patterns which are source-only can technically work just like a pattern, which would certainly make them more flexible.
Turns out that `tail +2` or channel redirection may reorder lines, or the timing is very different to cause certain output to end up at the end of the stream. Maibe `tail +2` just works differently.
…`MatchGroup` (#450) The group can handle things like ambiguity which can later lead to rejection and error message generation.
These are single-refspec matches without anything added to them. We might just go straight to matchgroups actually as it it make handling types easier. Let's see.
…450) It's also a way to normalize input strings as there is only one way to serialize instructions, which themselves are already normalized towards what's possible.
still need to check expectations though.
The new data model makes it easier to apply negations and handle a set of edges prior to dealing with conflicts. This makes it easier to test and cleaner as well.
And most importantly, it seems to integrate nicely with everything that's already there.
Now it seems en-par with the git implementation, which also manages without `git-glob`.
Our matching is too broad in case of negations, which requires full ref names. This is something we could reject early actually.
Git is more lenient, but will then fail to match against such patterns which seems like avoidable surprising behaviour.
Just have to figure out a decent API for that.
however, it's not actually correct as git ignores these entirely.
Still we don't handle (or trigger) any santiization.
…it. (#450) Looked for "warning: refs/remotes/origin/branch1 usually tracks refs/heads/branch1, not refs/heads/branch2"" but it seems to take more to get it. Ultimately it's about multiple destinations, and that's caught either way.
Even though the test still fails.
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tasks
fetchhead parsingnot actually needed for baselinegit fetchwith a local remote and outputdetermine ambiguity by weak and strong matches, i.e. those who are partial and thus ambiguous with those who are not.todo()assure to skip local symbolic refsdone by callerRemoteNext
git-repositorygix remotesub-command to display information about what would be donePredecessor