On Tue, Aug 9, 2016 at 3:50 PM, Stefan Beller <[email protected]> wrote:
> On Tue, Aug 9, 2016 at 3:32 PM, Jacob Keller <[email protected]> wrote:
>> From: Jacob Keller <[email protected]>
>>
>> For projects which have frequent updates to submodules it is often
>> useful to be able to see a submodule update commit as a difference.
>> Teach diff's --submodule= a new "diff" format which will execute a diff
>> for the submodule between the old and new commit, and display it as
>> a standard diff. This allows users to easily see what changed in
>> a submodule without having to dig into the submodule themselves.
>>
>> Signed-off-by: Jacob Keller <[email protected]>
>> ---
>> There are no tests yet. Stefan suggested the use of child_process,
>
> Well you said "I just want this one command but don't know where to put it "
> so it's natural to suggest using child_process. ;)
Right this is a straight forward way..
>
>> but I
>> really believe there has to be some way of getting the diff without
>> having to run a sub process (as this means we also can't do the diff
>> without a checked out submodule). It doesn't properly handle options
>> either, so a better solution would be much appreciated.
>
> Oh right, we would need to codify all options again (and all future options,
> too)
That's why I'd prefer if we had a way to do this via builtins, because
it would make option passing easier.
>
>>
>> I also would prefer if the diff actually prefixed the files with
>> "path/to/submodule" so that it was obvious where the file was located in
>> the directory.
>>
>> Suggestions welcome.
>>
>> +
>> + if (start_command(&cp))
>
> I wonder if we want to stay single-execution here,
> i.e. if we rather want to use run_processes_parallel
> for all the submodules at the same time?
>
> Though then non deterministic ordering may be an issue.
There is no easy way to do this, we're given it one module at a time
and it would be a huge re-write to make it go in parallel. I think
that's the wrong way to think about this.
>
>> + return -1;
>> +
>> + if (strbuf_read(buf, cp.out, 0) < 0)
>
> So we keep the whole diff in memory
> I don't know much about the diff machinery, but I thought
> the rest of the diff machinery just streams it out?
Yea, but I can't figure out how to do that. Is there an easy way to
stream chunks from the pipe straight into the file?
>
>> +
>> +void show_submodule_diff(FILE *f, const char *path,
>> + const char *line_prefix,
>> + unsigned char one[20], unsigned char two[20],
>> + unsigned dirty_submodule, const char *meta,
>> + const char *reset)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + struct strbuf sb = STRBUF_INIT;
>> + const char *message = NULL;
>> +
>> + if (dirty_submodule & DIRTY_SUBMODULE_UNTRACKED)
>> + fprintf(f, "%sSubmodule %s contains untracked content\n",
>> + line_prefix, path);
>> + if (dirty_submodule & DIRTY_SUBMODULE_MODIFIED)
>> + fprintf(f, "%sSubmodule %s contains modified content\n",
>> + line_prefix, path);
>> +
>> + if (!hashcmp(one, two)) {
>> + strbuf_release(&sb);
>> + return;
>> + }
>> +
>> + if (add_submodule_odb(path))
>> + message = "(not checked out)";
>
> When not checked out, we can invoke the diff command
> in .git/modules/<name> as that is the git dir of the submodule,
> i.e. operating diff with a bare repo?
We can actually do this every time. How would you pass that in a
child_process? I don't think it's "dir" but instead passing
"--git-dir" somehow?
Thanks,
Jake
>
> Thanks,
> Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
