From: Jakub Narebski <jnareb@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files
Date: Tue, 05 Nov 2019 01:21:10 +0100 [thread overview]
Message-ID: <86imnzgoll.fsf@gmail.com> (raw)
In-Reply-To: <20191103214608.GC32531@camp.crustytoothpaste.net> (brian m. carlson's message of "Sun, 3 Nov 2019 21:46:08 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2019-11-03 at 19:40:36, Jakub Narebski wrote:
>>
>> Your proposed change:
>>
>> +If the file you want to change is some sort of configuration file (say,
>> +for a build tool, IDE, or editor), a common solution is to use a
>> +templating mechanism, such as Ruby's ERB, to generate the ignored
>> +configuration file from a template stored in the repository and a source
>> +of data using a script or build step.
>>
>> I don't see how such templating mechanism could be used. You have some
>> kind of configuration file with placeholders comitted, and you have a
>> version of this file with local changes -- how templating mechanism
>> could solve this? I would like to see few lines of an example and its
>> use.
>>
>> Alternatives:
>> ~~~~~~~~~~~~~
>>
>> In our build system, we have versioned Makefile, and not versioned
>> config.mak (with local configuration), which is included by Makefile.
>
> Essentially, make and shell support this by themselves, but if, for
> example, I wanted to adjust my dotfiles to set the email address once
> and for all, I could create the following files:
>
> .muttrc.erb:
> ----
> my_hdr From: brian m. carlson <<%= data["email"] -%>>
> ----
>
> .gitconfig.erb:
> ----
> [user]
> name = brian m. carlson
> email = <%= data["email"] -%>
> ----
All right, the above might be useful as an example (well, one of those),
but might be not necessary if the description of preferred solution is
stated in more detail. I think it is better to start with generics,
i.e. track template, and generate untracked file, then provide examples
like Ruby's ERB.
> template.rb:
> ----
> #!/usr/bin/env ruby
>
> require 'erb'
>
> class Template
> def name
> @name ||= 0
> @name += 1
> "name_a#{@name}"
> end
>
> def data
> ENV.map { |k, v| [k.downcase, v] }.to_h
> end
>
> def erb(file)
> ERB.new(File.read(file), nil, '-', name).result(binding)
> end
> end
>
> puts Template.new.erb(ARGV[0])
> ----
This is certainly too much detail.
> and then run:
>
> EMAIL=sandals@crustytoothpaste.net template.rb .muttrc.erb >.muttrc
> EMAIL=sandals@crustytoothpaste.net template.rb .gitconfig.erb >.gitconfig
That could be kept as an example, after simplification.
> The problem that folks tend to have is that they have a single editor or
> IDE project file, such as an XCode configuration file, that can't be
> split among multiple files, some of which are checked in and some of
> which are not. Other situations are generating a configuration file for
> a web server like nginx in development, which may of course differ
> depending on where the user has checked out the repository.
All right.
> Using some sort of file like a config.mak is a fine solution, but many
> programs don't support that, so it's necessary to create a template for
> the build process and add a script to generate it. The actual
> configuration values can come from the environment, the user's
> gitconfig, a YAML file the user has configured, or anywhere else that
> makes sense.
I still think that config.mak (or equivalent) solution might be worth
mentioning in passing.
> As you can see, the example is large and unwieldy, and would not make a
> good inclusion in the man page. I included that paragraph because Peff
> stated that it would be nice if we could offer people a solution, but
> I'd rather drop it if it's too confusing without an example.
I think it can be done even without example, but without example it
would need careful crafting of the wording.
Best,
--
Jakub Narębski
next prev parent reply other threads:[~2019-11-05 0:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 19:26 [PATCH v3 0/4] Documentation for common user misconceptions brian m. carlson
2019-11-02 19:26 ` [PATCH v3 1/4] doc: move author and committer information to git-commit(1) brian m. carlson
2019-11-03 11:13 ` Jakub Narebski
2019-11-04 22:18 ` Jeff King
2019-11-06 1:55 ` Junio C Hamano
2019-11-02 19:26 ` [PATCH v3 2/4] doc: provide guidance on user.name format brian m. carlson
2019-11-03 13:13 ` Jakub Narebski
2019-11-03 19:23 ` brian m. carlson
2019-11-02 19:26 ` [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files brian m. carlson
2019-11-02 20:14 ` rsbecker
2019-11-03 15:46 ` Jakub Narebski
2019-11-03 15:04 ` Jakub Narebski
2019-11-03 18:59 ` brian m. carlson
2019-11-03 19:40 ` Jakub Narebski
2019-11-03 21:46 ` brian m. carlson
2019-11-05 0:21 ` Jakub Narebski [this message]
2019-11-04 22:24 ` Jeff King
2019-11-04 23:52 ` brian m. carlson
2019-11-02 19:26 ` [PATCH v3 4/4] docs: mention when increasing http.postBuffer is valuable brian m. carlson
2019-11-04 22:26 ` [PATCH v3 0/4] Documentation for common user misconceptions Jeff King
2019-11-06 1:58 ` Junio C Hamano
2019-11-06 2:19 ` brian m. carlson
2019-11-06 3:15 ` Junio C Hamano
2020-01-16 21:08 ` Emily Shaffer
2020-01-16 23:35 ` brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86imnzgoll.fsf@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.