git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Max Kirillov <max@max630.net>
To: "Jens Lehmann" <Jens.Lehmann@web.de>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: per-repository and per-worktree config variables
Date: Wed, 18 Mar 2015 23:33:42 +0200	[thread overview]
Message-ID: <20150318213342.GA25692@wheezy.local> (raw)
In-Reply-To: <54D79EAB.6060301@web.de>

On Sun, Feb 08, 2015 at 09:36:43AM -0800, Jens Lehmann wrote:
> I wonder if it's worth all the hassle to invent new names. Wouldn't
> it be much better to just keep a list of per-worktree configuration
> value names and use that inside the config code to decide where to
> find them for multiple work trees. That would also work easily for
> stuff like EOL-config and would push the complexity in the config
> machinery and not onto the user.

I actually thought about the same, and now tend to think
that most of config variables make sense to be per-worktree
in some cases. Only few variable must always be per
repository. I tried to summarize the variables which now
(in current pu) should be common, also listed all the rest
so somebody could scan through the list and spot anything I
could miss.

PS: some variables are with older case, they were mostly
collected before I got aware of their rename.

-- 
Max

Strictly common only
~~~~~~~~~~~~~~~~~~~~

Distributiveness
^^^^^^^^^^^^^^^^

A repository should behave same way regartdless of
which worktree is being accessed.

core.gitProxy::
core.askpass::
credential.helper::
credential.useHttpPath::
credential.username::
credential.<url>.*::
fetch.fsckObjects::
fetch.prune::
gitcvs.*::
gitweb.*::
gui.pruneduringfetch::
http.*::
push.followTags::
receive.*::
remote.<name>.*::
remotes.<group>::
transfer.fsckObjects::
transfer.hiderefs::
uploadarchive.allowUnreachable::
uploadpack.*::
url.<base>.insteadOf::
url.<base>.pushInsteadOf::
imap.*::

Repository storage options
^^^^^^^^^^^^^^^^^^^^^^^^^^

There should be same options of purging, compression etc.

core.compression::
core.loosecompression::
core.packedGitWindowSize::
core.packedGitLimit::
core.deltaBaseCacheLimit::
core.bigFileThreshold::
core.fsyncobjectfiles::
core.createObject::
core.logAllRefUpdates::
core.protectHFS::
core.protectNTFS::
fetch.unpackLimit::
fsck.skipList::
fsck.error::
fsck.warn::
fsck.ignore::
gc.*
pack.*
repack.*

Branch tracking settings
^^^^^^^^^^^^^^^^^^^^^^^^

Since branch are shared, they should be tracked same way
regardless of where are they updated.

branch.<name>.remote::
branch.<name>.pushremote::
branch.<name>.merge::
branch.<name>.mergeoptions::
branch.<name>.rebase::

Notes handling
^^^^^^^^^^^^^^

I don't know much about notes, and not sure about these ones, but notes looks
like a part of common history, and the options affect all of them.

notes.rewrite.<command>::
notes.rewriteMode::
notes.rewriteRef::

Misc
^^^^

core.preferSymlinkRefs::
	As description says, useful mostly for older scripts, which definitely
	not going to understand the new format. Probably incompatible with
	multiple worktrees at all.
core.repositoryFormatVersion::
	Looks like this is not used.
init.templatedir::
	This makes sense only as a global option.

Prefer common
~~~~~~~~~~~~~

Technically can be used per-worktree, but does not seem to have much sense.

Many of them are are actualy expected to be global.

advice.*::
core.ignorecase::
core.precomposeunicode::
core.trustctime::
core.checkstat::
core.quotepath::
core.symlinks::
core.ignoreStat::
core.warnAmbiguousRefs::
core.attributesfile::
	This should be common if it names tracked file.
core.editor::
core.commentchar::
sequence.editor::
core.pager::
core.preloadindex::
alias.*::
browser.<tool>.path::
color.branch::
color.diff::
color.diff.<slot>::
color.decorate.<slot>::
color.grep::
color.grep.<slot>::
color.interactive::
color.interactive.<slot>::
color.pager::
color.showbranch::
color.status::
color.status.<slot>::
color.ui::
color.branch.<slot>::
column.*::
commit.cleanup::
commit.gpgsign::
commit.status::
commit.template::
difftool.*::
fetch.recurseSubmodules::
	Since submodules can differ, this also can.
gui.commitmsgwidth::
gui.diffcontext::
gui.encoding::
	While in theory possible to use per-workree value, probably this is intended
	to correspond to the actual data in repository. Not sure though.
gui.trustmtime::
gui.spellingdictionary::
help.*
i18n.commitEncoding::
i18n.logOutputEncoding::
index.version::
instaweb.*::
mailmap.*::
man.*::
mergetool.*::
pager.*::
sendemail.*::
tar.umask::
user.email::
user.name::
user.signingkey::
web.browser::
mailinfo.scissors::

Ok to be per-worktree
~~~~~~~~~~~~~~~~~~~~~

core.fileMode::
core.eol::
core.safecrlf::
core.autocrlf::
core.bare::
core.worktree::
core.excludesfile::
core.whitespace::
core.notesRef::
core.sparseCheckout::
core.abbrev::
add.ignore-errors::
add.ignoreErrors::
am.keepcr::
apply.ignorewhitespace::
apply.whitespace::
branch.autosetupmerge::
branch.autosetuprebase::
clean.requireForce::
format.*::
filter.*::
	For some worktrees it may be desired to have them unsmudged.
grep.*::
gpg.program::
gui.displayuntracked::
gui.matchtrackingbranch::
gui.newbranchtemplate::
gui.fastcopyblame::
gui.copyblamethreshold::
gui.blamehistoryctx::
guitool.*
interactive.singlekey::
log.*::
notes.displayRef::
pretty.<name>::
pull.ff::
pull.rebase::
pull.octopus::
pull.twohead::
push.default::
rebase.stat::
rebase.autosquash::
rebase.autostash::
remote.pushdefault::
rerere.*::
showbranch.*::
status.*::
submodule.*::
tag.sort::
diff.*::
	not sure about  "diff.<driver>" commands, but I could imagine cases when it is desirable
merge.*::
	not sure about  "merge.<driver>" commands, but I could imagine cases when it is desirable
versionsort.prereleaseSuffix::

  parent reply	other threads:[~2015-03-18 21:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-08 13:16 [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 1/3] config.c: new config namespace worktree.* stored in $GIT_DIR/config.worktree Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 2/3] setup: add worktree.path to shadow core.worktree Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 3/3] submodule: use worktree.path instead of core.worktree Nguyễn Thái Ngọc Duy
2015-02-08 17:36 ` [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees Jens Lehmann
2015-02-08 17:41   ` Jens Lehmann
2015-02-09  9:35   ` Duy Nguyen
2015-03-18 21:33   ` Max Kirillov [this message]
2015-03-24 13:48     ` per-repository and per-worktree config variables Duy Nguyen
2015-03-26 12:04       ` [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree Nguyễn Thái Ngọc Duy
2015-03-26 22:19         ` Max Kirillov
2015-03-29  1:25           ` Duy Nguyen
2015-03-30 21:26             ` Max Kirillov
2015-03-31 12:14         ` [PATCH v3] " Nguyễn Thái Ngọc Duy
2015-03-31 12:17           ` Duy Nguyen
2015-04-01 20:56           ` Max Kirillov
2015-04-03 10:30             ` Duy Nguyen
2015-04-13 23:37           ` Max Kirillov
2015-04-18 11:10             ` Duy Nguyen
2015-04-20  2:51               ` Max Kirillov
2015-04-20  3:22                 ` Duy Nguyen
2015-03-25 21:33     ` per-repository and per-worktree config variables Jens Lehmann

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150318213342.GA25692@wheezy.local \
    --to=max@max630.net \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).