| Message ID | 20181010150916.4295-1-lucas.demarchi@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | range-diff: allow to diff files regardless submodule | expand |
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?
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;
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
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;
Æ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.
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 >
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.
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.
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.
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.
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 <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.
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. >
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;
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(-)