On 12/06, Jeff King wrote:
> On Tue, Dec 06, 2016 at 10:22:21AM -0800, Stefan Beller wrote:
>
> > >> Maybe even go a step further and say that the config code needs a context
> > >> "object".
> > >
> > > If I were writing git from scratch, I'd consider making a "struct
> > > repository" object. I'
On Tue, Dec 06, 2016 at 10:22:21AM -0800, Stefan Beller wrote:
> >> Maybe even go a step further and say that the config code needs a context
> >> "object".
> >
> > If I were writing git from scratch, I'd consider making a "struct
> > repository" object. I'm not sure how painful it would be to ret
On Tue, Dec 6, 2016 at 7:09 AM, Jeff King wrote:
>>
>> Maybe even go a step further and say that the config code needs a context
>> "object".
>
> If I were writing git from scratch, I'd consider making a "struct
> repository" object. I'm not sure how painful it would be to retro-fit it
> at this
On Tue, Dec 06, 2016 at 03:48:38PM +0100, Johannes Schindelin wrote:
> > Should it blindly look at ".git/config"?
>
> Absolutely not, of course. You did not need me to say that.
>
> > Now your program behaves differently depending on whether you are in the
> > top-level of the working tree.
>
>
Hi Peff,
On Tue, 6 Dec 2016, Jeff King wrote:
> On Tue, Dec 06, 2016 at 02:16:35PM +0100, Johannes Schindelin wrote:
>
> > > Johannes Schindelin writes:
> > >
> > > > Seriously, do you really think it is a good idea to have
> > > > git_config_get_value() *ignore* any value in .git/config?
> >
On Tue, Dec 06, 2016 at 02:16:35PM +0100, Johannes Schindelin wrote:
> > Johannes Schindelin writes:
> >
> > > Seriously, do you really think it is a good idea to have
> > > git_config_get_value() *ignore* any value in .git/config?
> >
> > When we do not know ".git/" directory we see is the rep
Hi Junio,
On Mon, 5 Dec 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Seriously, do you really think it is a good idea to have
> > git_config_get_value() *ignore* any value in .git/config?
>
> When we do not know ".git/" directory we see is the repository we were
> told to wo
Johannes Schindelin writes:
> Seriously, do you really think it is a good idea to have
> git_config_get_value() *ignore* any value in .git/config?
When we do not know ".git/" directory we see is the repository we
were told to work on, then we should ignore ".git/config" file. So
allowing git_co
Hi Junio,
On Thu, 1 Dec 2016, Junio C Hamano wrote:
> As to "I have to spawn config", I think it is sensible to start the
> cmd_difftool() wrapper without adding RUN_SETUP to the command table,
> then call git_config_get_bool() to check the configuration only from
> system and per-user files, and
Johannes Schindelin writes:
> The config kinda works now. But for what price. It stole 4 hours I did not
> have. When the libexec/git-core/use-builtin-difftool solution took me a
> grand total of half an hour to devise, implement and test.
>
> And you know what? I still do not really see what is
Jakub Narębski writes:
>> My original "create a file in libexec/git-core/" was simple, did the job
>> reliably, and worked also for testing.
>>
>> It is a pity that you two gentlemen shot it down for being inelegant. And
>> ever since, we try to find a solution that is as simple, works as
>> rel
Hello,
W dniu 28.11.2016 o 18:34, Johannes Schindelin pisze:
> My original "create a file in libexec/git-core/" was simple, did the job
> reliably, and worked also for testing.
>
> It is a pity that you two gentlemen shot it down for being inelegant. And
> ever since, we try to find a solution t
On Wed, Nov 30, 2016 at 01:30:47PM +0100, Johannes Schindelin wrote:
> On Tue, 29 Nov 2016, Jeff King wrote:
>
> > On Tue, Nov 29, 2016 at 09:36:55PM +0100, Johannes Schindelin wrote:
> >
> > > So the suggestion by both you and Peff, to use an environment variable,
> > > which is either global,
Hi Junio,
On Tue, 29 Nov 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > So the suggestion by both you and Peff, to use an environment variable,
> > which is either global, or requires the user to set it manually per
> > session, is simply not a good idea at all.
>
> As I alrea
Hi Peff,
On Tue, 29 Nov 2016, Jeff King wrote:
> On Tue, Nov 29, 2016 at 09:36:55PM +0100, Johannes Schindelin wrote:
>
> > So the suggestion by both you and Peff, to use an environment variable,
> > which is either global, or requires the user to set it manually per
> > session, is simply not a
Johannes Schindelin writes:
> So the suggestion by both you and Peff, to use an environment variable,
> which is either global, or requires the user to set it manually per
> session, is simply not a good idea at all.
As I already said, I do not have a strong preference between config
and env. I
On Tue, Nov 29, 2016 at 09:36:55PM +0100, Johannes Schindelin wrote:
> So the suggestion by both you and Peff, to use an environment variable,
> which is either global, or requires the user to set it manually per
> session, is simply not a good idea at all.
No, my suggestion was to use config and
Hi Junio,
On Mon, 28 Nov 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > However, I have been bitten time and again by problems that occurred only
> > in production, our test suite (despite taking already waay too long to
> > be truly useful in my daily development) was simp
Johannes Schindelin writes:
> However, I have been bitten time and again by problems that occurred only
> in production, our test suite (despite taking already waay too long to
> be truly useful in my daily development) was simply not good enough.
>
> So my plan was different: to let end user
Hi,
On Mon, 28 Nov 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Sat, Nov 26, 2016 at 02:01:36PM +0100, Johannes Schindelin wrote:
> >
> >> > If you want to control it from outside the test script, you'd need
> >> > something like:
> >> >
> >> > if test "$GIT_TEST_DIFFTOOL" = "bui
Jeff King writes:
> On Sat, Nov 26, 2016 at 02:01:36PM +0100, Johannes Schindelin wrote:
>
>> > If you want to control it from outside the test script, you'd need
>> > something like:
>> >
>> > if test "$GIT_TEST_DIFFTOOL" = "builtin"
>>
>> That is a bit magic. I first used "GIT_USE_BUILTIN_D
On Sat, Nov 26, 2016 at 02:01:36PM +0100, Johannes Schindelin wrote:
> > If you want to control it from outside the test script, you'd need
> > something like:
> >
> > if test "$GIT_TEST_DIFFTOOL" = "builtin"
>
> That is a bit magic. I first used "GIT_USE_BUILTIN_DIFFTOOL" and it did
> not wor
Hi Peff,
On Sat, 26 Nov 2016, Jeff King wrote:
> On Sat, Nov 26, 2016 at 01:22:28PM +0100, Johannes Schindelin wrote:
>
> > In other words, GIT_CONFIG_PARAMETERS is *explicitly scrubbed* from the
> > environment when we run our tests (by the code block between the "before"
> > and the "after" st
On Sat, Nov 26, 2016 at 01:22:28PM +0100, Johannes Schindelin wrote:
> In other words, GIT_CONFIG_PARAMETERS is *explicitly scrubbed* from the
> environment when we run our tests (by the code block between the "before"
> and the "after" statements in the diff above).
Sorry if I wasn't clear. I me
Hi Peff,
On Fri, 25 Nov 2016, Jeff King wrote:
> On Fri, Nov 25, 2016 at 06:41:23PM +0100, Johannes Schindelin wrote:
>
> > > Ah, I didn't realize that was a requirement. If this is going to be part
> > > of a release and real end-users are going to see it, that does make me
> > > think the conf
On Fri, Nov 25, 2016 at 06:41:23PM +0100, Johannes Schindelin wrote:
> > Ah, I didn't realize that was a requirement. If this is going to be part
> > of a release and real end-users are going to see it, that does make me
> > think the config option is the better path (than the presence of some
> >
Hi Peff,
On Fri, 25 Nov 2016, Jeff King wrote:
> On Fri, Nov 25, 2016 at 12:05:00PM +0100, Johannes Schindelin wrote:
>
> > > I would have expected it to just be a build-time flag, like:
> > >
> > > make BUILTIN_DIFFTOOL=Yes test
> >
> > That works for Git developers.
> >
> > I want to let
On Fri, Nov 25, 2016 at 12:05:00PM +0100, Johannes Schindelin wrote:
> > I would have expected it to just be a build-time flag, like:
> >
> > make BUILTIN_DIFFTOOL=Yes test
>
> That works for Git developers.
>
> I want to let as many users as possible test the builtin difftool.
> Hopefully a
Hi Peff,
On Thu, 24 Nov 2016, Jeff King wrote:
> On Thu, Nov 24, 2016 at 10:56:23PM +0100, Johannes Schindelin wrote:
>
> > > I think it would probably be OK to ship with that caveat (people would
> > > probably use --global config, or "git -c" for a quick override), but if
> > > you really want
On Thu, Nov 24, 2016 at 10:56:23PM +0100, Johannes Schindelin wrote:
> > I think it would probably be OK to ship with that caveat (people would
> > probably use --global config, or "git -c" for a quick override), but if
> > you really wanted to address it, you can do something like what
> > pager.
Hi Peff,
On Thu, 24 Nov 2016, Jeff King wrote:
> On Thu, Nov 24, 2016 at 09:55:07PM +0100, Johannes Schindelin wrote:
>
> > +/*
> > + * NEEDSWORK: this function can go once the legacy-difftool Perl script is
> > + * retired.
> > + *
> > + * We intentionally avoid reading the config directly here
On Thu, Nov 24, 2016 at 09:55:07PM +0100, Johannes Schindelin wrote:
> +/*
> + * NEEDSWORK: this function can go once the legacy-difftool Perl script is
> + * retired.
> + *
> + * We intentionally avoid reading the config directly here, to avoid messing
> up
> + * the GIT_* environment variables
This adds a builtin difftool that still falls back to the legacy Perl
version, which has been renamed to `legacy-difftool`.
The idea is that the new, experimental, builtin difftool immediately hands
off to the legacy difftool for now, unless the config variable
difftool.useBuiltin is set to true.
33 matches
Mail list logo
