Paul Tan <pyokagan@xxxxxxxxx> writes:
>> Hmph, it is somewhat surprising that we do not have such a helper
>> already. Wouldn't we need this logic to implement $branch@{upstream}
>> syntax?
>
> Right, the @{upstream} syntax is implemented by branch_get_upstream()
> in remote.c. It, however, does not check to see if the branch's remote
> matches what is provided on the command-line, so we still have to
> implement this check ourselves, which means this helper function is
> still required.
>
> I guess we could still use branch_get_upstream() in this function though.
It is entirely expected that existing function may not do exactly
what the new caller you introduce might want to do, or may do more
than what it wants. That is where refactoring of existing code
comes in.
It somewhat feels strange that you have to write more than "shim"
code to glue existing helpers and API functions together to
re-implement what a scripted Porcelain is already doing, though.
It can't be that git-pull.sh implements this logic as shell script,
and it must be asking existing code in Git to do what the callers
you added for this function would want to do, right? That suggests
that we must have enough logic already in C.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html