range-diff: allow to diff files regardless submodule
diff mbox series

Message ID 20181010150916.4295-1-lucas.demarchi@intel.com
State New
Headers show
Series
  • range-diff: allow to diff files regardless submodule
Related show

Commit Message

Lucas De Marchi Oct. 10, 2018, 3:09 p.m. UTC
Do like it's done in grep so mode doesn't end up as
0160000, which means range-diff doesn't work if one has
"submodule.diff = log" in the configuration. Without this
while using range-diff I only get a

    Submodule a 0000000...0000000 (new submodule)

instead of the diff between the revisions.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
 range-diff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

brian m. carlson Oct. 11, 2018, 12:02 a.m. UTC | #1
On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> Do like it's done in grep so mode doesn't end up as
> 0160000, which means range-diff doesn't work if one has
> "submodule.diff = log" in the configuration. Without this
> while using range-diff I only get a
> 
>     Submodule a 0000000...0000000 (new submodule)
> 
> instead of the diff between the revisions.
> 
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
>  range-diff.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/range-diff.c b/range-diff.c
> index 60edb2f518..bd8083f2d1 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
>  {
>  	struct diff_filespec *spec = alloc_filespec(name);
>  
> -	fill_filespec(spec, &null_oid, 0, 0644);
> +	fill_filespec(spec, &null_oid, 0, 0100644);

If we have a system that has different mode values from the common Unix
ones, is this still correct or does it need to change?
Ævar Arnfjörð Bjarmason Oct. 11, 2018, 7:42 a.m. UTC | #2
On Wed, Oct 10 2018, Lucas De Marchi wrote:

> Do like it's done in grep so mode doesn't end up as
> 0160000, which means range-diff doesn't work if one has
> "submodule.diff = log" in the configuration. Without this
> while using range-diff I only get a
>
>     Submodule a 0000000...0000000 (new submodule)

I'm not familiar enough with this to tell what the real problem is
that's being solved from the commit message, but if it means that now
range-diff works in some configuration, presumably that can be reduced
to a simple set of commands that didn't work before but now does, and
therefore a test in t/t3206-range-diff.sh.

> instead of the diff between the revisions.
>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
>  range-diff.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/range-diff.c b/range-diff.c
> index 60edb2f518..bd8083f2d1 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
>  {
>  	struct diff_filespec *spec = alloc_filespec(name);
>
> -	fill_filespec(spec, &null_oid, 0, 0644);
> +	fill_filespec(spec, &null_oid, 0, 0100644);
>  	spec->data = (char *)p;
>  	spec->size = strlen(p);
>  	spec->should_munmap = 0;
Lucas De Marchi Oct. 11, 2018, 7:50 a.m. UTC | #3
On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > Do like it's done in grep so mode doesn't end up as
> > 0160000, which means range-diff doesn't work if one has
> > "submodule.diff = log" in the configuration. Without this
> > while using range-diff I only get a
> >
> >     Submodule a 0000000...0000000 (new submodule)
> >
> > instead of the diff between the revisions.
> >
> > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > ---
> >  range-diff.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/range-diff.c b/range-diff.c
> > index 60edb2f518..bd8083f2d1 100644
> > --- a/range-diff.c
> > +++ b/range-diff.c
> > @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
> >  {
> >       struct diff_filespec *spec = alloc_filespec(name);
> >
> > -     fill_filespec(spec, &null_oid, 0, 0644);
> > +     fill_filespec(spec, &null_oid, 0, 0100644);
>
> If we have a system that has different mode values from the common Unix
> ones, is this still correct or does it need to change?

From what I can see this would still be correct, or at least git-grep
implementation would be broken.

Lucas De Marchi
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204
Lucas De Marchi Oct. 11, 2018, 8:14 a.m. UTC | #4
On Thu, Oct 11, 2018 at 12:42 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Wed, Oct 10 2018, Lucas De Marchi wrote:
>
> > Do like it's done in grep so mode doesn't end up as
> > 0160000, which means range-diff doesn't work if one has
> > "submodule.diff = log" in the configuration. Without this
> > while using range-diff I only get a
> >
> >     Submodule a 0000000...0000000 (new submodule)
>
> I'm not familiar enough with this to tell what the real problem is
> that's being solved from the commit message, but if it means that now
> range-diff works in some configuration, presumably that can be reduced
> to a simple set of commands that didn't work before but now does, and
> therefore a test in t/t3206-range-diff.sh.

$ git config --global diff.submodule log
$ git range-diff

This produces the output above

$ git config --global diff.submodule short
$ git range-diff

This blocks forever in a wait4() call and prints this when terminated:
fatal: exec 'diff': cd to 'a' failed: Not a directory

Lucas De Marchi

>
> > instead of the diff between the revisions.
> >
> > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > ---
> >  range-diff.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/range-diff.c b/range-diff.c
> > index 60edb2f518..bd8083f2d1 100644
> > --- a/range-diff.c
> > +++ b/range-diff.c
> > @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
> >  {
> >       struct diff_filespec *spec = alloc_filespec(name);
> >
> > -     fill_filespec(spec, &null_oid, 0, 0644);
> > +     fill_filespec(spec, &null_oid, 0, 0100644);
> >       spec->data = (char *)p;
> >       spec->size = strlen(p);
> >       spec->should_munmap = 0;
Junio C Hamano Oct. 11, 2018, 8:25 a.m. UTC | #5
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Wed, Oct 10 2018, Lucas De Marchi wrote:
>
>> Do like it's done in grep so mode doesn't end up as
>> 0160000, which means range-diff doesn't work if one has
>> "submodule.diff = log" in the configuration. Without this
>> while using range-diff I only get a
>>
>>     Submodule a 0000000...0000000 (new submodule)
>
> I'm not familiar enough with this to tell what the real problem is
> that's being solved from the commit message, but if it means that now
> range-diff works in some configuration, presumably that can be reduced
> to a simple set of commands that didn't work before but now does, and
> therefore a test in t/t3206-range-diff.sh.

Yes, I agree on both counts (i.e. it was totally unclear what
problem is being solved and what the root cause of the problem is,
and we would want a new test to protect this "fix" from getting
broken in the future.

Thanks.
Johannes Schindelin Oct. 12, 2018, 9:24 a.m. UTC | #6
On Thu, 11 Oct 2018, Lucas De Marchi wrote:

> On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > > Do like it's done in grep so mode doesn't end up as
> > > 0160000, which means range-diff doesn't work if one has
> > > "submodule.diff = log" in the configuration. Without this
> > > while using range-diff I only get a
> > >
> > >     Submodule a 0000000...0000000 (new submodule)
> > >
> > > instead of the diff between the revisions.
> > >
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > >  range-diff.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/range-diff.c b/range-diff.c
> > > index 60edb2f518..bd8083f2d1 100644
> > > --- a/range-diff.c
> > > +++ b/range-diff.c
> > > @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
> > >  {
> > >       struct diff_filespec *spec = alloc_filespec(name);
> > >
> > > -     fill_filespec(spec, &null_oid, 0, 0644);
> > > +     fill_filespec(spec, &null_oid, 0, 0100644);
> >
> > If we have a system that has different mode values from the common Unix
> > ones, is this still correct or does it need to change?
> 
> From what I can see this would still be correct, or at least git-grep
> implementation would be broken.

As you can see from the Windows port: we are stuck with the simplistic
POSIX permissions in Git, and platforms that have a different permission
system have to emulate it.

We only use preciously few bit masks, anyway. For example, we do not
really use the lower 12 bits for anything but "executable or not?"

So Lucas' patch is correct, AFAICT.

Ciao,
Dscho

> 
> Lucas De Marchi
> > --
> > brian m. carlson: Houston, Texas, US
> > OpenPGP: https://keybase.io/bk2204
> 
> 
> 
> -- 
> Lucas De Marchi
>
brian m. carlson Oct. 12, 2018, 11:17 p.m. UTC | #7
On Fri, Oct 12, 2018 at 11:24:43AM +0200, Johannes Schindelin wrote:
> 
> 
> On Thu, 11 Oct 2018, Lucas De Marchi wrote:
> 
> > On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
> > <sandals@crustytoothpaste.net> wrote:
> > >
> > > On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > > > Do like it's done in grep so mode doesn't end up as
> > > > 0160000, which means range-diff doesn't work if one has
> > > > "submodule.diff = log" in the configuration. Without this
> > > > while using range-diff I only get a
> > > >
> > > >     Submodule a 0000000...0000000 (new submodule)
> > > >
> > > > instead of the diff between the revisions.
> > > >
> > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > ---
> > > >  range-diff.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/range-diff.c b/range-diff.c
> > > > index 60edb2f518..bd8083f2d1 100644
> > > > --- a/range-diff.c
> > > > +++ b/range-diff.c
> > > > @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
> > > >  {
> > > >       struct diff_filespec *spec = alloc_filespec(name);
> > > >
> > > > -     fill_filespec(spec, &null_oid, 0, 0644);
> > > > +     fill_filespec(spec, &null_oid, 0, 0100644);
> > >
> > > If we have a system that has different mode values from the common Unix
> > > ones, is this still correct or does it need to change?
> > 
> > From what I can see this would still be correct, or at least git-grep
> > implementation would be broken.
> 
> As you can see from the Windows port: we are stuck with the simplistic
> POSIX permissions in Git, and platforms that have a different permission
> system have to emulate it.

I think I may not have explained myself well.  There are a small number
of POSIXy systems which have mode bits that differ from the common ones
(e.g., a plain file is something other than 0100000).  I think one
person mentioned on the list that they have a homebrew Unix that works
this way, and I think I may have heard of some minor commercial Unices
that work this way as well.

My question was intended to ask whether we should be using an
OS-provided constant (e.g., S_IFREG) that represented that value
differently because it was a system value or whether it was the internal
Git representation.

I hadn't intended to inquire about Windows, as I was fairly confident
that this syntax does indeed work there through our compatibility layers
(because it has in the past even when we've had these kinds of issues on
other Unices).  But I'm glad that you chimed in and confirmed that it
does.
Lucas De Marchi Oct. 23, 2018, 2:07 p.m. UTC | #8
On Thu, Oct 11, 2018 at 05:25:02PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > On Wed, Oct 10 2018, Lucas De Marchi wrote:
> >
> >> Do like it's done in grep so mode doesn't end up as
> >> 0160000, which means range-diff doesn't work if one has
> >> "submodule.diff = log" in the configuration. Without this
> >> while using range-diff I only get a
> >>
> >>     Submodule a 0000000...0000000 (new submodule)
> >
> > I'm not familiar enough with this to tell what the real problem is
> > that's being solved from the commit message, but if it means that now
> > range-diff works in some configuration, presumably that can be reduced
> > to a simple set of commands that didn't work before but now does, and
> > therefore a test in t/t3206-range-diff.sh.
> 
> Yes, I agree on both counts (i.e. it was totally unclear what
> problem is being solved and what the root cause of the problem is,
> and we would want a new test to protect this "fix" from getting
> broken in the future.

have you seen I sent a v2 with proper test?

thanks
Lucas De Marchi

> 
> Thanks.
Junio C Hamano Oct. 24, 2018, 2:12 a.m. UTC | #9
Lucas De Marchi <lucas.demarchi@intel.com> writes:

>> Yes, I agree on both counts (i.e. it was totally unclear what
>> problem is being solved and what the root cause of the problem is,
>> and we would want a new test to protect this "fix" from getting
>> broken in the future.
>
> have you seen I sent a v2 with proper test?

No, otherwise I wouln't have said it needs tests, and no, because I
haven't seen the v2, I do not know if it came with proper test or
other issues pointed out and fixes suggested in the review round
were addressed in v2.  Sorry.

When you ask such a question, please accompany it with "this is the
message-id" to avoid the receiver of the question locating a wrong
version of your patch from the archive.

Thanks.
Lucas De Marchi Oct. 24, 2018, 2:43 a.m. UTC | #10
On Wed, Oct 24, 2018 at 11:12:51AM +0900, Junio C Hamano wrote:
> Lucas De Marchi <lucas.demarchi@intel.com> writes:
> 
> >> Yes, I agree on both counts (i.e. it was totally unclear what
> >> problem is being solved and what the root cause of the problem is,
> >> and we would want a new test to protect this "fix" from getting
> >> broken in the future.
> >
> > have you seen I sent a v2 with proper test?
> 
> No, otherwise I wouln't have said it needs tests, and no, because I
> haven't seen the v2, I do not know if it came with proper test or
> other issues pointed out and fixes suggested in the review round
> were addressed in v2.  Sorry.

Your reply arrived just a little after I sent the v2, so I thought it
was just the race and you would end up seeing the unread email in the
same thread. Sorry for not including the msg id:
20181011081750.24240-1-lucas.demarchi@intel.com

thanks
Lucas De Marchi

> 
> When you ask such a question, please accompany it with "this is the
> message-id" to avoid the receiver of the question locating a wrong
> version of your patch from the archive.
> 
> Thanks.
Junio C Hamano Oct. 24, 2018, 5:12 a.m. UTC | #11
Lucas De Marchi <lucas.demarchi@intel.com> writes:

> Your reply arrived just a little after I sent the v2, so I thought it
> was just the race and you would end up seeing the unread email in the
> same thread. Sorry for not including the msg id:
> 20181011081750.24240-1-lucas.demarchi@intel.com

OK, then I am not surprised that I do not recall seeing such an old
message ;-)  Let me take a look.

Thanks.
Junio C Hamano Oct. 24, 2018, 5:18 a.m. UTC | #12
Junio C Hamano <gitster@pobox.com> writes:

> Lucas De Marchi <lucas.demarchi@intel.com> writes:
>
>> Your reply arrived just a little after I sent the v2, so I thought it
>> was just the race and you would end up seeing the unread email in the
>> same thread. Sorry for not including the msg id:
>> 20181011081750.24240-1-lucas.demarchi@intel.com
>
> OK, then I am not surprised that I do not recall seeing such an old
> message ;-)  Let me take a look.

Heh, it turns out that that is the version that has been queued in
'next' for about a week already.

One issue that was pointed out in v1 was that the log message was
unclear; it seems v2 didn't address that at all, though.

Thanks.
Lucas De Marchi Oct. 24, 2018, 5:19 p.m. UTC | #13
On Wed, Oct 24, 2018 at 02:18:43PM +0900, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Lucas De Marchi <lucas.demarchi@intel.com> writes:
> >
> >> Your reply arrived just a little after I sent the v2, so I thought it
> >> was just the race and you would end up seeing the unread email in the
> >> same thread. Sorry for not including the msg id:
> >> 20181011081750.24240-1-lucas.demarchi@intel.com
> >
> > OK, then I am not surprised that I do not recall seeing such an old
> > message ;-)  Let me take a look.
> 
> Heh, it turns out that that is the version that has been queued in
> 'next' for about a week already.
> 
> One issue that was pointed out in v1 was that the log message was
> unclear; it seems v2 didn't address that at all, though.

ok, let me try to expand it.

thanks
Lucas De Marchi

> 
> Thanks.
>

Patch
diff mbox series

diff --git a/range-diff.c b/range-diff.c
index 60edb2f518..bd8083f2d1 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -354,7 +354,7 @@  static struct diff_filespec *get_filespec(const char *name, const char *p)
 {
 	struct diff_filespec *spec = alloc_filespec(name);
 
-	fill_filespec(spec, &null_oid, 0, 0644);
+	fill_filespec(spec, &null_oid, 0, 0100644);
 	spec->data = (char *)p;
 	spec->size = strlen(p);
 	spec->should_munmap = 0;