You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That could work. I didn't bother with any kind of optimisation because I assumed git itself would be doing something similar when doing the fetch.
Thinking about what you said here, I think we could simplify things by taking advantage of what what a git fetch does. Instead of manually comparing local and remote refs, we could do a fetch and use the fetched refs at the definitive state. This would mean we would only ever hit the network once.
It would look something like this:
Copy all remote pull and heads refs to our own local cache (I'm using refs/git-pr as the base so people would know which tool is creating the refs).
Populate our ref dictionary using all of the refs under refs/git-pr/{remoteName}.
Fix up our pull refs using the commit at HEAD^1 trick
Further down the line we could give the user the option to skip the fetch completely and simply use the cached refs (this would be useful on large/active repositories).
What do you think? What is the sun doing where you are? 😉
Thinking about what you said here, I think we could simplify things by taking advantage of what what a git fetch does. Instead of manually comparing local and remote refs, we could do a fetch and use the fetched refs at the definitive state. This would mean we would only ever hit the network once.
It would look something like this:
pull
andheads
refs to our own local cache (I'm usingrefs/git-pr
as the base so people would know which tool is creating the refs).Populate our ref dictionary using all of the refs under
refs/git-pr/{remoteName}
.Fix up our
pull
refs using the commit atHEAD^1
trickFurther down the line we could give the user the option to skip the
fetch
completely and simply use the cached refs (this would be useful on large/active repositories).What do you think? What is the sun doing where you are? 😉
Originally posted by @jcansdale in #21 (comment)
The text was updated successfully, but these errors were encountered: