allow an external diff helper to be executed")),
+ OPT_CALLBACK_F(0, "textconv", options, NULL,
+ N_("run external text conversion filters when
comparing binary files"),
+ PARSE_OPT_NOARG, diff_opt_textconv),
{ OPTION
allow an external diff helper to be executed")),
+ OPT_CALLBACK_F(0, "textconv", options, NULL,
+ N_("run external text conversion filters when
comparing binary files"),
+ PARSE_OPT_NOARG, diff_opt_textconv),
{ OPTION
On Fri, Dec 14, 2018 at 12:12:01PM +0900, Junio C Hamano wrote:
> > I have a strange situation and need help with resolving funky characters in
> > .git/config. My situation is this:
> >
> > [diff "*.dat"]
> > textconv = enscribe-conv
> > --form
"Randall S. Becker" writes:
> Hi all,
>
> I have a strange situation and need help with resolving funky characters in
> .git/config. My situation is this:
>
> [diff "*.dat"]
> textconv = enscribe-conv
> --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,
On December 13, 2018 10:08, I wrote:
> I have a strange situation and need help with resolving funky characters
in
> .git/config. My situation is this:
>
> [diff "*.dat"]
> textconv = enscribe-conv
> --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),
Hi all,
I have a strange situation and need help with resolving funky characters in
.git/config. My situation is this:
[diff "*.dat"]
textconv = enscribe-conv
--format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224
Basically this is a formatter for diff so that
On 2018-09-23 06:23 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
>
>>> You probably want "--ext-diff", not "--textconv".
>> [...]
>> Would it be safe to ask the maintainer of the application to include
>>
On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
> > You probably want "--ext-diff", not "--textconv".
> [...]
> Would it be safe to ask the maintainer of the application to include
> both --textconv and --ext-diff in that 'git diff-tree'
On 2018-09-23 05:43 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
>
>> $ git config --get diff.jupyternotebook.command
>> git-nbdiffdriver diff
>
> That's an "external diff driver", not a textconv driver.
>
>
On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
> $ git config --get diff.jupyternotebook.command
> git-nbdiffdriver diff
That's an "external diff driver", not a textconv driver.
So here:
> $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb
>
Hi,
I'm using a 3rd party application that internally uses 'git diff-tree'
instead of 'git diff'. I'm trying to add filter and it works with 'git
diff' but it gets ignored with 'git diff-tree' despite having --textconv.
I was able to reproduce t
f_size))
;
else
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 64ec1745ab..8d97c84725 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -113,7 +113,8 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name,
else
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 64ec1745ab..8d97c84725 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -113,7 +113,8 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name,
die("git ca
uiltin/cat-file.c b/builtin/cat-file.c
index 64ec1745ab..8d97c84725 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -113,7 +113,8 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name,
die("git cat-file --textconv
else
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 64ec1745ab..8d97c84725 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -113,7 +113,8 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name,
die("git ca
;
else
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 64ec1745ab..8d97c84725 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -113,7 +113,8 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name,
die("git ca
git-show is unique in that it wants to use textconv by default except
for when it is showing blobs. When asked to show a blob, show doesn't
want to use textconv unless the user explicitly requested that it be
used by providing the command line flag '--textconv'.
Currently this is
T_SET(options, ALLOW_EXTERNAL);
> else if (!strcmp(arg, "--no-ext-diff"))
> DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
> - else if (!strcmp(arg, "--textconv"))
> + else if (!strcmp(arg, "--textconv")) {
> DIFF_OPT_SET(options,
On 10/30, Brandon Williams wrote:
> On 10/30, Stefan Beller wrote:
> > On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams
> > wrote:
> > > git-show is unique in that it wants to use textconv by default except
> > > for when it is showing blobs. When asked to sho
On 10/30, Stefan Beller wrote:
> On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams wrote:
> > git-show is unique in that it wants to use textconv by default except
> > for when it is showing blobs. When asked to show a blob, show doesn't
> > want to use textconv
On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams wrote:
> git-show is unique in that it wants to use textconv by default except
> for when it is showing blobs. When asked to show a blob, show doesn't
> want to use textconv unless the user explicitly requested that it be
> used
git-show is unique in that it wants to use textconv by default except
for when it is showing blobs. When asked to show a blob, show doesn't
want to use textconv unless the user explicitly requested that it be
used by providing the command line flag '--textconv'.
Currently this is
On Wed, Sep 27, 2017 at 10:06:25PM +0300, Ilya Kantor wrote:
> When textconv is specified, the program is always used for conversion.
Not always. It's enabled by default for the git-diff and git-log"
porcelain, but not for plumbing commands, nor for git-format-patch
(which need
Hello,
When textconv is specified, the program is always used for conversion.
E.g. consider this:
[diff "png"]
textconv = wc
Even if a png file is ASCII (manually created), wc gets called, and
the result is made of its output.
So, the question is: why should one specify bin
uld be broken out, and possibly other
specific formats could be broken into their own files. But I didn't
spend much time on it.
> It appears that the textconv related helpers (which was where this
> discussion thread started from) could be first restructured so that
> they do not
e files). Over time people may have added what does not
belong there merely for convenience, which may want to get ejected,
but I do not think of many instances of them offhand.
... goes and looks ...
It appears that the textconv related helpers (which was where this
discussion thread started fr
On Mon, May 8, 2017 at 2:55 PM, Jeff King wrote:
> On Mon, May 08, 2017 at 10:02:58AM +0900, Junio C Hamano wrote:
>
>> Stefan Beller writes:
>>
>> > I guess it is ok for now and in this series, but we may want
>> > to split up diff.[ch] in the future into multiple finer grained files.
>>
>> For
On Mon, May 08, 2017 at 10:02:58AM +0900, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > I guess it is ok for now and in this series, but we may want
> > to split up diff.[ch] in the future into multiple finer grained files.
>
> For what end? Such a split would require more symbols intern
Stefan Beller writes:
> I guess it is ok for now and in this series, but we may want
> to split up diff.[ch] in the future into multiple finer grained files.
For what end? Such a split would require more symbols internal to
diff.[ch] to become external, which is a big downside, so we need to
ha
On Fri, May 5, 2017 at 10:44 AM, Junio C Hamano wrote:
> Jeff Smith writes:
>
>> Signed-off-by: Jeff Smith
>> ---
>> builtin.h | 2 --
>> builtin/blame.c| 28
>> builtin/cat-file.c | 1 +
>> diff.c | 23 +++
>> diff.h
diff --git a/builtin/blame.c b/builtin/blame.c
> index 42c56eb..c419981 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -147,34 +147,6 @@ static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
> }
>
> /*
> - * Prepare diff_filespec and convert it using dif
+++ b/builtin/blame.c
@@ -147,34 +147,6 @@ static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
}
/*
- * Prepare diff_filespec and convert it using diff textconv API
- * if the textconv driver exists.
- * Return 1 if the conversion succeeds, 0 otherwise.
- */
-int textconv_object(const char
the normal case that git is doing line-ending conversion,
>>>>> but it's suppressed when textconv is in use.
>>>>
>>>> I would not consider this a bug if not for the fact that there is no ^M
>>>> without using iconv as textconv.
>>>
; >>> but it's suppressed when textconv is in use.
> >>
> >> I would not consider this a bug if not for the fact that there is no ^M
> >> without using iconv as textconv.
> >
> > I don't think it's a bug, though. You have told Git that you
of mojibake. There is 'encoding'
>>> gitattribute... but it works only for GUI ('git gui', that is).
>>>
>>> Therefore I have (ab)used textconv facility to convert from cp1250 of
>>> file encoding to utf-8 encoding of console.
>>&g
W dniu 01.04.2017 o 08:08, Jeff King pisze:
> On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote:
>
>>> I suspect in the normal case that git is doing line-ending conversion,
>>> but it's suppressed when textconv is in use.
>>
>> I would no
On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote:
> > I suspect in the normal case that git is doing line-ending conversion,
> > but it's suppressed when textconv is in use.
>
> I would not consider this a bug if not for the fact that there is no ^M
&
). My terminal, that is Git Bash from Git for Windows is set
>> up for utf-8.
>>
>> I wanted for "git diff" and friends to return something sane on said
>> utf-8 terminal, instead of mojibake. There is 'encoding'
>> gitattribute... but it works only
quot;cr-at-eol" to core.whitespace to suppress it.
Thanks! That solves the problem (or rather workarounds it).
>
> I suspect in the normal case that git is doing line-ending conversion,
> but it's suppressed when textconv is in use.
I would not consider this a bug if not for
>
> I wanted for "git diff" and friends to return something sane on said
> utf-8 terminal, instead of mojibake. There is 'encoding'
> gitattribute... but it works only for GUI ('git gui', that is).
>
> Therefore I have (ab)used textconv facility to c
al case that git is doing line-ending conversion,
but it's suppressed when textconv is in use.
-Peff
ne on said
utf-8 terminal, instead of mojibake. There is 'encoding'
gitattribute... but it works only for GUI ('git gui', that is).
Therefore I have (ab)used textconv facility to convert from cp1250 of
file encoding to utf-8 encoding of console.
I have set the following in .g
Hi Junio,
On Fri, 9 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > +test_expect_success 'path= complains without
> > --textconv/--filters' '
>
> I wonder where this "path" came from; it wasn't in v2 I queued,
Johannes Schindelin writes:
> +test_expect_success 'path= complains without --textconv/--filters'
> '
I wonder where this "path" came from; it wasn't in v2 I queued,
but somehow came back mysteriously.
Will locally amend.
> + sha1=$(g
diff was generated may not even exist locally.
In such a case, the user would have to generate a fake revision just to
be able to use --textconv or --filters.
Let's simplify this dramatically, because we do not really need that
revision at all: all we care about is that we know the path. I
With this patch, --batch can be combined with --textconv or --filters.
For this to work, the input needs to have the form
so that the filters can be chosen appropriately.
Signed-off-by: Johannes Schindelin
---
Documentation/git-cat-file.txt | 18 +++-
builtin/cat-file.c
Johannes Schindelin writes:
> However, I do not want to hold this patch series up just by being
> stubborn.
Peff and I disussed this further in the thread in which the message
appears, and agreed
that it does not matter that much either way.
The comment to [v2 2/4] would be more important than
Hi Junio,
On Wed, 24 Aug 2016, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Mentioned elsewhere, but I think the above should be
> >
> > if (!path)
> > path = obj_context.path;
> >
> > if (obj_context.mode == S_IFINVALID)
> > obj_context.mode = 0100644;
>
Junio C Hamano writes:
> Mentioned elsewhere, but I think the above should be
>
> if (!path)
> path = obj_context.path;
>
> if (obj_context.mode == S_IFINVALID)
> obj_context.mode = 0100644;
>
> IOW, even when there is an explicit path supplied, we should f
Johannes Schindelin writes:
> @@ -65,6 +68,11 @@ static int cat_one_file(int opt, const char *exp_type,
> const char *obj_name,
> if (get_sha1_with_context(obj_name, 0, sha1, &obj_context))
> die("Not a valid object name %s", obj_name);
>
> + if (!path)
> +
diff was generated may not even exist locally.
In such a case, the user would have to generate a fake revision just to
be able to use --textconv or --filters.
Let's simplify this dramatically, because we do not really need that
revision at all: all we care about is that we know the path. I
With this patch, --batch can be combined with --textconv or --filters.
For this to work, the input needs to have the form
so that the filters can be chosen appropriately.
Signed-off-by: Johannes Schindelin
---
Documentation/git-cat-file.txt | 18 +++-
builtin/cat-file.c
command line option parsing and breaks the
> check you already have.
I added a test to verify that --path without --filters nor --textconv
complains.
Ciao,
Dscho
--
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
Jeff King writes:
>> Sorry, Torsten, this is not my doing. So I cannot explain why it is not an
>> enum.
>>
>> I *guess* the rationale for 'c' being the cmdmode of --textconv is "c for
>> convert". That is why I chose "w as in worktree"
Johannes Schindelin writes:
>> I think I saw some code to ensure "when giving this option you need
>> that option in effect, too"; they should be tested here, too, no?
>
> No, I would rather not test for that. These conditionals are purely for
> any user's convenience, in case they specify an opt
at-file.c
> > > +++ b/builtin/cat-file.c
> > > @@ -17,6 +17,7 @@ struct batch_options {
> > > int print_contents;
> > > int buffer_output;
> > > int all_objects;
> > > + int cmdmode; /* may be 'w' or 'c' for --filters or --t
t; is the use case. Just put my
shoes on for a moment. As described: you have a list of object names and
their path. Now you need to use the --textconv or --filters option, but
you do not have the commit name. What do you do? Concoct a script that
goes through `git rev-list --all -- ` in the hop
On Fri, Aug 19, 2016 at 02:59:32PM +0200, Johannes Schindelin wrote:
> > The only thing that somewhat is worrysome is what would happen to
> > %(rest).
>
> What would happen is that it would print out the path, as it is exactly
> that "rest" field that is used in the implementation, piggybacking
tried to turn on %(rest) handling by
> > default, long ago). How do those work with your patch?
>
> They don't ;-)
>
> And quite frankly, the documentation should make it clear to users that
> batch mode with --filters or --textconv won't work when the object name
Hi Junio,
On Thu, 18 Aug 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
> >
> >> With this patch, --batch can be combined with --textconv or --filters.
> >> For this to wo
Hi Peff,
On Thu, 18 Aug 2016, Jeff King wrote:
> On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
>
> > With this patch, --batch can be combined with --textconv or --filters.
> > For this to work, the input needs to have the form
> >
> >
Hi Junio,
On Thu, 18 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > With this patch, --batch can be combined with --textconv or --filters.
> > For this to work, the input needs to have the form
> >
> >
> >
> > so th
tin/cat-file.c
> > @@ -17,6 +17,7 @@ struct batch_options {
> > int print_contents;
> > int buffer_output;
> > int all_objects;
> > + int cmdmode; /* may be 'w' or 'c' for --filters or --textconv */
> How do I read 'w'
On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
> With this patch, --batch can be combined with --textconv or --filters.
> For this to work, the input needs to have the form
>
>
>
> so that the filters can be chosen appropriately.
>
>
On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
> With this patch, --batch can be combined with --textconv or --filters.
> For this to work, the input needs to have the form
>
>
>
> so that the filters can be chosen appropriately.
The object name
Johannes Schindelin writes:
> With this patch, --batch can be combined with --textconv or --filters.
> For this to work, the input needs to have the form
>
>
>
> so that the filters can be chosen appropriately.
> --batch::
> --batch=::
> Print object i
Jeff King writes:
> On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
>
>> With this patch, --batch can be combined with --textconv or --filters.
>> For this to work, the input needs to have the form
>>
>>
>>
>> so that the fi
#x27;cat-file --filters converts to
> worktree version' '
> has_cr actual
> '
>
> +test_expect_success 'cat-file --filters --use-path= works' '
> + sha1=$(git rev-parse -q --verify HEAD:world.txt) &&
> + git cat-file --f
With this patch, --batch can be combined with --textconv or --filters.
For this to work, the input needs to have the form
so that the filters can be chosen appropriately.
Signed-off-by: Johannes Schindelin
---
Documentation/git-cat-file.txt | 18 +++-
builtin/cat-file.c
may not even exist locally.
In such a case, the user would have to generate a fake revision just to
be able to use --textconv or --filters.
Let's simplify this dramatically, because we do not really need that
revision at all: all we care about is that we know the path. In the
scenario desc
tion doesn't make it clear whether exit-code refers to
>> the actual diff (foo vs. bar) or to the diff after textconv (empty
>> vs. empty). In any case, "-b" should not make a difference for
>> your example.
>>
>> diff_flush() in diff.c has this p
; produces no output.
Either sounds strange, as they exit without reading their input at
all, so the other side of the pipe may get an write error it has to
handle ;-)
> The description doesn't make it clear whether exit-code refers to
> the actual diff (foo vs. bar) or to the diff a
Georg Pichler venit, vidit, dixit 20.03.2016 13:43:
> Hi,
>
> I realized that "git diff --exit-code" does not honour textconv settings.
> Maybe this behaviour is desired. It can be partially circumvented by using
> the "-b" flag if one does not care about whit
Hi,
I realized that "git diff --exit-code" does not honour textconv settings.
Maybe this behaviour is desired. It can be partially circumvented by using the
"-b" flag if one does not care about whitespace changes.
To reproduce this, create an empty repository and run the fol
On Mon, Feb 22, 2016 at 03:08:01PM -0800, Junio C Hamano wrote:
> > The only thing common in this series is it's the result of
> > -Wwrite-strings. 1/3 changes some "char *" to "const char *", you
> > don't miss anything.
>
> While reading Peff's clarification patch, I did find the assignment
> o
Duy Nguyen writes:
> On Tue, Feb 23, 2016 at 1:12 AM, Jeff King wrote:
>> On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
>>
>>> Is there a case I'm missing here where we actually leak memory or try to
>>> free non-allocated memory? I didn't see it.
>>
>> By the way, I saw only patche
On Tue, Feb 23, 2016 at 1:12 AM, Jeff King wrote:
> On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
>
>> Is there a case I'm missing here where we actually leak memory or try to
>> free non-allocated memory? I didn't see it.
>
> By the way, I saw only patches 2/3 and 3/3 on the list. So
t; internals of a diff_filespec when doing a textconv).
>
> So I think the patch below is an improvement, but if somebody really
> wants to dig into refactoring it, be my guest.
I almost went this way but I wasn't sure if driver->textconv can be
NULL on purpose. Definitely an improve
lly do want to avoid extra allocations, or cross-module
assumptions (e.g., userdiff doesn't know about diff_filespec, but rather
the other way around, and we probably do not want to muck with the
internals of a diff_filespec when doing a textconv).
So I think the patch below is an improvem
On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
> Is there a case I'm missing here where we actually leak memory or try to
> free non-allocated memory? I didn't see it.
By the way, I saw only patches 2/3 and 3/3 on the list. So maybe there
is something interesting going on in 1/3, or i
> buffer (mmfile_t). We can only free the result buffer if it's allocated
> by fill_textconv(). Correct all call sites.
Right, and those two cases (allocated or not) should follow based on
whether you passed in a textconv-enabled driver.
> diff --git a/builtin/blame.c b/builtin/blame.c
&
On Mon, Feb 22, 2016 at 7:52 PM, Nguyễn Thái Ngọc Duy wrote:
> fill_textconv() have four code paths to return a new buffer.
I forgot to add. Thanks to -Wwrite-strings pointing to '*outbuf = ""'
line in this function. I wouldn't notice otherwise.
--
Duy
--
To unsubscribe from this list: send the
n Thái Ngọc Duy
---
Frankly I don't like the way fill_textconv() returns buffer at all.
But I don't know much about textconv, or want to spend more time on
it. This patch can be dropped if people come up with a better one.
builtin/blame.c| 2 +-
combine-diff.c | 4 ++--
diff.c
objec
> SYNOPSIS
>
> [verse]
> -'git cat-file' (-t | -s | -e | -p | | --textconv )
> +'git cat-file' (-t | -s | -e | -p | | (-c | --textconv) )
Do we use "-c" for a shorthand for "--textconv" anywhere else?
Is there any other
-file.txt
index f6a16f4..b346a5d 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -9,14 +9,14 @@ git-cat-file - Provide content or type and size information
for repository objec
SYNOPSIS
[verse]
-'git cat-file' (-t | -s | -e | -p | | --textconv )
On Mon, Jun 03, 2013 at 07:25:06PM +0200, Peter Oberndorfer wrote:
> > Thanks for the report. I'd still like to pursue using a regex library
> > that does not require NUL-termination, but I've been distracted by other
> > things. I'm going to hold back my copy-to-a-NUL-buffer patch for now and
> >
On 2012-11-07 22:13, Jeff King wrote:
> On Wed, Nov 07, 2012 at 10:10:59PM +0100, Peter Oberndorfer wrote:
>
For me the key to reproduce the problem was to have 2 commits.
Adding the file in the root commit it did not work. [1]
>>> You probably would need to pass "--root" for it to do the
conv" and "show.textConv" (to allow setting it per-user for
> > all types).
>
> I strongly disagree here. I have textconv filters for pdf, gpg, odf,
> xls, doc, xoj... I know, ugly. At least some of them would benefit from
> different filteres or different settings.
O
ant line numbering), regardless of where it comes from, be
it "git show --textconv" or some other program output, but you seem
to want to have different "text version"s for different purposes out
of a single binary file
> I strongly disagree here. I have textconv filt
or a
>>> better name) similar to "diff" so that you can specifiy a diff driver to
>>> use for showing a blob (or grepping it), which may or may not be the
>>> same you use for "diff". This would be a much more fine-grained and
>>> systemati
ecifiy a diff driver to
> > use for showing a blob (or grepping it), which may or may not be the
> > same you use for "diff". This would be a much more fine-grained and
> > systematic way of setting a default for "--textconv" for blobs.
> >
> > Of
the
> same you use for "diff". This would be a much more fine-grained and
> systematic way of setting a default for "--textconv" for blobs.
>
> Of course, some driver attributes would just not matter for coverting
> blobs, but that doesn't hurt.
>
> I&
b_to_fd(1, sha1, NULL, 0);
>>>
>>> It is surprising that the necessary change is only this, but I think
>>> it is correct ;-). We ignore textconv when the command line did not
>>> mention --[no-]textconv, or the command line said --no-textconv
>>> explici
e a much more fine-grained and
systematic way of setting a default for "--textconv" for blobs.
Of course, some driver attributes would just not matter for coverting
blobs, but that doesn't hurt.
I'm just wondering whether it's worth the effort and whether I should
distingui
Jeff King writes:
> On Fri, May 10, 2013 at 11:04:01AM -0700, Junio C Hamano wrote:
>
>> One thing to notice is that those accessing rev->pending before
>> calling prepare_revision_walk(), as opposed to those receiving
>> objects in rev->commits via get_revision(), are the only ones that
>> care
e necessary change is only this, but I think
>> it is correct ;-). We ignore textconv when the command line did not
>> mention --[no-]textconv, or the command line said --no-textconv
>> explicitly.
>>
>> This (especially the first condition) may deserve an in-code comme
Junio C Hamano venit, vidit, dixit 10.05.2013 19:02:
> Michael J Gruber writes:
>
>> Currently, "diff" and "cat-file" for blobs honor "--textconv" options
>> (with the former defaulting to "--textconv" and the latter to
>> "-
On Fri, May 10, 2013 at 11:04:01AM -0700, Junio C Hamano wrote:
> One thing to notice is that those accessing rev->pending before
> calling prepare_revision_walk(), as opposed to those receiving
> objects in rev->commits via get_revision(), are the only ones that
> care about the context and wants
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> diff --git a/object.h b/object.h
>> index 97d384b..695847d 100644
>> --- a/object.h
>> +++ b/object.h
>> @@ -13,6 +13,7 @@ struct object_array {
>> struct object *item;
>> const char *name;
>> unsigned
Michael J Gruber writes:
> diff --git a/object.h b/object.h
> index 97d384b..695847d 100644
> --- a/object.h
> +++ b/object.h
> @@ -13,6 +13,7 @@ struct object_array {
> struct object *item;
> const char *name;
> unsigned mode;
> + struct obje
1 - 100 of 247 matches
Mail list logo
