On Tue, Aug 9, 2016 at 3:50 PM, Stefan Beller <sbel...@google.com> wrote:
> On Tue, Aug 9, 2016 at 3:32 PM, Jacob Keller <jacob.e.kel...@intel.com> wrote:
>> From: Jacob Keller <jacob.kel...@gmail.com>
>> 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 <jacob.kel...@gmail.com>
>> ---
>> 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,
> Stefan
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to