git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC/GSOC] make git-pull a builtin

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Mar 21, 2015, 17:27 UTC
Message-ID
<0c67273f0d1b8af3391db66617b24de5@www.dscho.org>
In-Reply-To
<CACRoPnQ4iJMn7+eujOXUN6dks2HMQYRw+nYfM1QvOD+k7BCtEQ@mail.gmail.com>
Hi Paul,
On 2015-03-21 15:00, Paul Tan wrote:
Show 18 quoted lines
> Thanks for your suggestions, I agree with most of them :).
> 
> On Wed, Mar 18, 2015 at 5:00 PM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
>>> +static int parse_opt_rebase(const struct option *opt, const char
>>> *arg, int unset)
>>> +{
>>> +     if (arg)
>>> +             *(int *)opt->value = parse_rebase(arg);
>>> +     else
>>> +             *(int *)opt->value = unset ? REBASE_FALSE : REBASE_TRUE;
>>> +     return (*(int *)opt->value) >= 0 ? 0 : -1;
>>> +}
>>
>> In this function (and also in other places below), there is this pattern that a `struct option` pointer is passed to the function, but then only `*(int *)opt->value` is written to. Therefore, I would suggest to change the signature of the function and pass `(int *)opt->value` as function parameter.
> 
> It's used as a callback for the argument parser though, so the
> callback signature is required.
Good point ;-)
For readability, I would then suggest to declare `int *result = (int *)opt->value;` on the top of the function and then use `*result = ...` later.
Show 14 quoted lines
>>> +static int has_unstaged_changes(void)
>>
>> Yeah, this function, as well as the ones below it, look as if they are so common that they *should* be already somewhere in libgit.a. But I did not find them, either...
>>
>> Of course it *would* be nice to identify places where essentially the same code is needed, and refactor accordingly. But I think that is outside the scope of this project.
> 
> Actually, I think that identifying the places where code can be
> trivially shared (without requiring major refactoring) should be part
> of the project, otherwise lots of code may be duplicated and cause
> code bloat. The obvious one would be fork_point() in this patch, which
> is copied from the merge-base builtin and not accessible because it
> has static linkage. The project should, at the very least, allow the
> function to be shared between git-pull and git-merge-base, as well as
> to modify the function so that it can fail without die()-ing.
Yes, I agree wholeheartedly. But I like your choice to strike a balance for the sake of a proof-of-concept.

Ciao, Johannes

Previous: Paul TanNext: Matthieu Moy
Message 6 of 15 in “make git-pull a builtin”
  1. make git-pull a builtinPaul Tan, Mar 17, 2015
  2. Stephen RobinMar 18, 2015
  3. Johannes SchindelinMar 18, 2015
  4. Johannes SchindelinMar 18, 2015
  5. Paul TanMar 21, 2015
  6. Johannes SchindelinMar 21, 2015
  7. Matthieu MoyMar 18, 2015
  8. Paul TanMar 21, 2015
  9. Johannes SchindelinMar 21, 2015
  10. Paul TanMar 22, 2015
  11. Johannes SchindelinMar 23, 2015
  12. Duy NguyenMar 23, 2015
  13. Paul TanMar 24, 2015
  14. Junio C HamanoMar 18, 2015
  15. Paul TanMar 21, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.