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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).