All of lore.kernel.org
 help / color / mirror / 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

* 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.
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.