Re: [RFC/PATCH 6/8] config: add core.untrackedCache
On 12/01/2015 09:31 PM, Christian Couder wrote: When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. I'm not sure if ever "we know" ? How can we know without testing ? I personaly can not say "I know" in all the different system I am using, so I always want to test and verify that the untracked cache is working, before I rely on it. Also when we know that mtime is not supported by the environment, for example because the repo is shared over a network file system, then we might want 'git update-index --untracked-cache' to fail immediately instead of it testing if it works (because it might work on some systems using the repo over the network file system but not others). Same here. Signed-off-by: Christian Couder --- Documentation/config.txt | 10 ++ Documentation/git-update-index.txt | 11 +-- builtin/update-index.c | 28 ++-- cache.h| 1 + config.c | 10 ++ contrib/completion/git-completion.bash | 1 + dir.c | 2 +- environment.c | 1 + wt-status.c| 9 + 9 files changed, 60 insertions(+), 13 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index b4b0194..bf176ff 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -308,6 +308,16 @@ core.trustctime:: crawlers and some backup systems). See linkgit:git-update-index[1]. True by default. +core.untrackedCache:: + If unset or set to 'default' or 'check', untracked cache will + not be enabled by default and when + 'update-index --untracked-cache' is called, Git will test if + mtime is working properly before enabling it. If set to false, + Git will refuse to enable untracked cache even if + '--force-untracked-cache' is used. If set to true, Git will + blindly enabled untracked cache by default without testing if + it works. See linkgit:git-update-index[1]. + Please no. The command line option should always be able to overwrite any settings from a config file. Sorry, I may missing the big picture here. What exactly should be achieved ? A config variable that should ask Git to always try to use the untracked cache ? Or a config variable that tells Git to never use the untracked cache ? Or a combination ? core.untrackedCache:: false: Never use the untracked cache ? true: Always try to use the untracked cache ? Try means: probe, and if the probing fails, record that if fails in the index, for this hostname/os/kernel/path (Don't remember all the details) unset: As today, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arbitrary memory allocation
On Thu, Nov 26, 2015 at 05:06:35AM +0100, ytr...@sdf-eu.org wrote: > First, something I still don t understand, should I always ulimit ram > usage for security purposes when I m manage a public server? You didn't define "public" here. For serving fetches, the memory tends to be fairly bounded and dependent on the repo you're serving. For accepting pushes, it's trivial to convince the server to allocate a lot of memory (you can send an unbounded set of ref updates, or you can simply send a 50GB object that compresses down to a tiny size). Git does not have any internal memory controls, and will generally rely on malloc() to tell it when it is not being reasonable. I'd suggest using OS-level memory controls like cgroups if you're hosting something public. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make error message after failing commit_lock_file() less confusing
On Mon, Nov 30, 2015 at 6:40 AM, SZEDER Gábor wrote:
> The error message after a failing commit_lock_file() call sometimes
> looks like this, causing confusion:
>
> $ git remote add remote g...@server.com/repo.git
> error: could not commit config file .git/config
> # Huh?!
> # I didn't want to commit anything, especially not my config file!
>
> While in the narrow context of the lockfile module using the verb
> 'commit' in the error message makes perfect sense, in the broader
> context of git the word 'commit' already has a very specific meaning,
> hence the confusion.
>
> Reword these error messages to say "could not write" instead of "could
> not commit".
>
> While at it, include strerror in the error messages after writing the
> config file or the credential store fails to provide some information
> about the cause of the failure, and update the style of the error
> message after writing the reflog fails to match surrounding error
> messages (i.e. no '' around the pathname and no () around the error
> description).
>
> Signed-off-by: SZEDER Gábor
> ---
> diff --git a/config.c b/config.c
> @@ -64,7 +64,8 @@ static void rewrite_credential_file(const char *fn, struct
> credential *c,
> print_line(extra);
> parse_credential_file(fn, c, NULL, print_line);
> if (commit_lock_file(&credential_lock) < 0)
> - die_errno("unable to commit credential store");
> + die_errno("unable to write credential store: %s",
> + strerror(errno));
Hmm, this is already calling die_errno(), so adding another strerror()
to the mix seems superfluous.
> }
>
> static void store_credential_file(const char *fn, struct credential *c)
> diff --git a/fast-import.c b/fast-import.c
> @@ -1824,7 +1824,7 @@ static void dump_marks(void)
>
> dump_marks_helper(f, 0, marks);
> if (commit_lock_file(&mark_lock)) {
> - failure |= error("Unable to commit marks file %s: %s",
> + failure |= error("Unable to write file %s: %s",
> export_marks_file, strerror(errno));
Since you're already doing some normalization of the error messages
with this patch, do you want to drop capitalization on this one?
> return;
> }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clean: new option --exclude-from
On Tue, Dec 01, 2015 at 06:18:30PM -0800, Junio C Hamano wrote: > > Should this perhaps be an option to the main "git" to append to the set > > of excludes? > > > > You can kind-of do this already with: > > > > git -c core.excludesfile=/path/to/whatever clean ... > > > > but of course you might be using core.excludesfile already. I wonder if > > that config option should take multiple values and respect all of them, > > rather than last-one-wins. > > It is likely that existing users are already using $HOME/.gitconfig > that sets core.excludesfile=$HOME/.gitconfig as the personal > fallback, that is overriden, not tweaked, by project specific > settings of the same variable in .git/config, so that would not fly > very well, I suspect. Maybe. I would think the more common setup is: 1. Personal exclude files (e.g., your editor's backup files) come from ~/.gitconfig. 2. Per-project personal excludes go directly into .git/info/exclude. But you're right that it would be a backwards-incompatible change. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am
Stefan Beller writes: > Do we as the Git community have a place where we take notes for version 3? I do not think there is, I do think we might need one when a need arises, and I do not think this topic is one that creates such a need. And I said "might" in the second one, based on the experience at 2.0; we didn't need such a separate place when managing the backward incompatible changes for that release. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am
Jeff King writes: > The "[]" convention is a microformat used by Linux kernel folks. So it's > not "whoops, we are stripping stuff not added by git". It is respecting > a microformat used by the tool's authors. > > That being said, if we were choosing a default from scratch today, it > might go the other way. But we aren't, and we have to deal with the > burden of breaking existing scripts by flipping it. And I do think it no longer is sensible to expect that it still is kernel-only convention. Any project that uses e-mail based workflow with Git have known how "[]" microformat works, may even have taken advantage of it to build their workflow around it, and flipping the default will only hurt them. A project that chooses not to follow the convention can easily tweak a knob to keep using different conventions, so I do not see anything to change here. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make error message after failing commit_lock_file() less confusing
Jeff King writes: > On Mon, Nov 30, 2015 at 12:40:53PM +0100, SZEDER Gábor wrote: > >> The error message after a failing commit_lock_file() call sometimes >> looks like this, causing confusion: >> >> $ git remote add remote g...@server.com/repo.git >> error: could not commit config file .git/config >> # Huh?! >> # I didn't want to commit anything, especially not my config file! > > I like the intent of this patch; I've had the same "huh" moment myself. > >> The error message is of course bikeshedable. > > You chose "write", which I think is OK. It's really a "rename", and > maybe that matters for some values of errno. I'd guess in practice > probably not (the likely reason is going to be something like EPERM). > And I can't think of a concise way to express rename (just saying > "rename" is confusing, too, without indicating that it's from the > tempfile to the final resting place). > > So perhaps "write" is the best we can do. Yeah, "finalize" came to me but "write" is far easier to understand by laypeople. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clean: new option --exclude-from
Jeff King writes: > On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote: > >> From: James Rouzier >> >> Specify a file to read for exclude patterns. >> --- > > Lots of commands care about excludes (e.g., "add", "status"). > > Should this perhaps be an option to the main "git" to append to the set > of excludes? > > You can kind-of do this already with: > > git -c core.excludesfile=/path/to/whatever clean ... > > but of course you might be using core.excludesfile already. I wonder if > that config option should take multiple values and respect all of them, > rather than last-one-wins. It is likely that existing users are already using $HOME/.gitconfig that sets core.excludesfile=$HOME/.gitconfig as the personal fallback, that is overriden, not tweaked, by project specific settings of the same variable in .git/config, so that would not fly very well, I suspect. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am
On Tue, Dec 1, 2015 at 4:58 PM, Jeff King wrote: > On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote: > >> Yes, it looks like the `--keep-non-patch` option works around this. >> >> However, shouldn't that be the default behaviour? >> I mean, what is the point in stripping stuff that is not proven to be >> inserted by `git` itself? >> That's not what I expect a tool to do which I trust. > > The "[]" convention is a microformat used by Linux kernel folks. So it's > not "whoops, we are stripping stuff not added by git". It is respecting > a microformat used by the tool's authors. > > That being said, if we were choosing a default from scratch today, it > might go the other way. But we aren't, and we have to deal with the > burden of breaking existing scripts by flipping it. Do we as the Git community have a place where we take notes for version 3? This sounds perfectly fine (to me at least) to change the default with a major version number as the changelog for major version numbers may even be read by kernel devs maintaining such scripts ;) Or could we even patch that today to have `--keep-non-patch` be default later on by checking for our version number ourselves and deciding upon that for the default? > > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am
On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote: > Yes, it looks like the `--keep-non-patch` option works around this. > > However, shouldn't that be the default behaviour? > I mean, what is the point in stripping stuff that is not proven to be > inserted by `git` itself? > That's not what I expect a tool to do which I trust. The "[]" convention is a microformat used by Linux kernel folks. So it's not "whoops, we are stripping stuff not added by git". It is respecting a microformat used by the tool's authors. That being said, if we were choosing a default from scratch today, it might go the other way. But we aren't, and we have to deal with the burden of breaking existing scripts by flipping it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] Add Travis CI support
On Tue, Dec 1, 2015 at 4:45 PM, Jeff King wrote: > On Tue, Dec 01, 2015 at 09:43:45AM +0100, Lars Schneider wrote: > >> > Thanks. I don't have any other comments on this one. I guess the next >> > step is for me to get git/git signed up for Travis, and then merging >> > this to 'master' will have the desired effect. >> >> Thanks! You're right, signing up git/git for Travis should do it. >> Right now it is configured to build all branches on git/git that >> contain a travis.yml. That means if you merge it to pu or next then we >> should see builds already. > > I merged to 'pu', and signed up peff/git, and got a build. Incidentally, > something in pu causes a bunch of tests to fail on OS X (but not Linux). > :) > :) As I currently maintain a the regular coverity scan and just remembered that it integrates with travis[1], we may want to look into that further, too. [1] https://scan.coverity.com/travis_ci > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clean: new option --exclude-from
On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote: > From: James Rouzier > > Specify a file to read for exclude patterns. > --- Lots of commands care about excludes (e.g., "add", "status"). Should this perhaps be an option to the main "git" to append to the set of excludes? You can kind-of do this already with: git -c core.excludesfile=/path/to/whatever clean ... but of course you might be using core.excludesfile already. I wonder if that config option should take multiple values and respect all of them, rather than last-one-wins. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-for-windows] How is detected binary files?
On Fri, Nov 27, 2015 at 03:14:58PM +0100, Johannes Schindelin wrote: > On Wed, 25 Nov 2015, Andrzej Borucki wrote: > > > How git detects that file is binary? This must be safe because it not > > allowed to change line breaks in binary files. > > Binary files can contain byte 0 (zero), but: > > - 16 bit UTF also can contain zero > > - short binary files can not contain zero > > It would probably be better to direct this question to the general Git > mailing list (you reached the Git for Windows one, and this issue is not > specific to Windows). > > To answer your question, a NUL byte within the first 8000 bytes is indeed > considered as an indicator for binary files. > > If you use UTF-16, you will need to mark your files as such explicitly > (Git does not handle UTF-16 internally). I'm not sure if it is a good idea to treat UTF-16 as text. The rest of the diff (headers, etc) will all be in ASCII, so one or the other is going to be mojibake. You can get readable diffs by textconv-ing them to an ASCII-superset encoding like UTF-8. Something like: echo 'myfile diff=utf16' >.gitattributes git config diff.utf16.textconv 'iconv -f utf16 -t utf8' but of course the resulting patches cannot be applied, and you may miss any changes that do not make it through the encoding (e.g., using different bytes to represent the same code point). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] Add Travis CI support
On Tue, Dec 01, 2015 at 09:43:45AM +0100, Lars Schneider wrote: > > Thanks. I don't have any other comments on this one. I guess the next > > step is for me to get git/git signed up for Travis, and then merging > > this to 'master' will have the desired effect. > > Thanks! You're right, signing up git/git for Travis should do it. > Right now it is configured to build all branches on git/git that > contain a travis.yml. That means if you merge it to pu or next then we > should see builds already. I merged to 'pu', and signed up peff/git, and got a build. Incidentally, something in pu causes a bunch of tests to fail on OS X (but not Linux). :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] push: add recurseSubmodules config option
On Tue, Dec 01, 2015 at 11:49:43AM +, Mike Crowe wrote: > The --recurse-submodules command line parameter has existed for some > time but it has no config file equivalent. > > Following the style of the corresponding parameter for git fetch, > invent push.recurseSubmodules to provide a default for this parameter. > This also requires the addition of --recurse-submodules=no to allow > the configuration to be overridden on the command line when required. > > The most straightforward way to implement this appears to be to make > push use code in submodule-config in a similar way to fetch. > > Signed-off-by: Mike Crowe > --- > Changes in v3: Hrm, I merged v2 of this to 'next' last week. The options at this point are either to revert that and re-start the topic, or just make the further changes a patch on top. Thoughts? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2015, #01; Tue, 1)
What's cooking in git.git (Dec 2015, #01; Tue, 1) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. This should by my final whats-cooking before handing things back to Junio. Thanks all for review help and for your patience during the past few weeks. You can find the normal integration branches at: https://github.com/git/git/ and all topic branches at: https://github.com/peff/git/ But note that I will _not_ be pushing to kernel.org. -- [New Topics] * bc/object-id (2015-11-20) 12 commits - remote: convert functions to struct object_id - Remove get_object_hash. - Convert struct object to object_id - Add several uses of get_object_hash. - object: introduce get_object_hash macro. - ref_newer: convert to use struct object_id - push_refs_with_export: convert to struct object_id - get_remote_heads: convert to struct object_id - parse_fetch: convert to use struct object_id - add_sought_entry_mem: convert to struct object_id - Convert struct ref to use object_id. - sha1_file: introduce has_object_file helper. More transition from "unsigned char[40]" to "struct object_id". This needed a few merge fixups, but is mostly disentangled from other topics. Will merge to 'next'. * dt/fsck-verify-pack-error (2015-12-01) 1 commit - verify_pack: do not ignore return value of verification function The exit code of git-fsck would not reflect some types of errors found in packed objects. Will merge to 'next'. * kn/ref-filter-atom-parsing (2015-12-01) 10 commits - ref-filter: introduce objectname_atom_parser() - ref-filter: introduce contents_atom_parser() - ref-filter: introduce remote_ref_atom_parser() - ref-filter: introduce align_atom_parser() - strbuf: introduce strbuf_split_str_without_term() - ref-filter: introduce color_atom_parser() - ref-filter: skip deref specifier in match_atom_name() - ref-fitler: bump match_atom() name to the top - ref-filter: introduce struct used_atom - ref-filter: introduce a parsing function for each atom in valid_atom Refactoring of ref-filter's format-parsing code, in preparation for "branch --format" and friends. This replaces (for now) kn/for-each-ref-remainder, which will be built on top. Waiting for review. * ls/travis-yaml (2015-11-28) 1 commit - Add Travis CI support Provides the necessary infrastructure to build topics using the free Travis CI. Developers forking from this topic (and enabling Travis) can do their own builds, and we can turn on auto-builds for git/git (including build-status for pull requests that people open). I'm inclined to merge this up, as the worst case is that it becomes dormant cruft in the repository root. Will merge to 'next'. * rs/status-detached-head-memcmp (2015-11-28) 1 commit - wt-status: correct and simplify check for detached HEAD Fix some string-matching corner cases when digging in the reflog for "git status". Will merge to 'next', then 'maint'. * sg/lock-file-commit-error (2015-12-01) 1 commit - Make error message after failing commit_lock_file() less confusing Cosmetic improvement to lock-file error messages. Comments on the new messages? Will merge to 'next' after giving time for bikeshedding. -- [Graduated to "master"] * ar/doc-env-variable-format (2015-11-11) 1 commit (merged to 'next' on 2015-11-24 at 5ddf33e) + Documentation: make environment variable formatting more consistent Minor documentation fixup. Will merge to 'master'. * cb/hook-sigpipe (2015-11-16) 1 commit (merged to 'next' on 2015-11-24 at 0bf4228) + allow hooks to ignore their standard input stream We now consistently allow all hooks to ignore their standard input, rather than having git complain of SIGPIPE. Will merge to 'master'. * cb/ssl-config-pathnames (2015-11-24) 1 commit (merged to 'next' on 2015-11-24 at 658a9c9) + http: treat config options sslCAPath and sslCAInfo as paths Allow tilde-expansion in some http config variables. Will merge to 'master'. * dg/subtree-test-cleanup (2015-11-13) 7 commits (merged to 'next' on 2015-11-24 at 1297941) + contrib/subtree: Handle '--prefix' argument with a slash appended + contrib/subtree: Make each test self-contained + contrib/subtree: Add split tests + contrib/subtree: Add merge tests + contrib/subtree: Add tests for subtree add + contrib/subtree: Add test for missing subtree + contrib/subtree: Clean and refactor test code Test cleanups for the subtree project. Will merge to 'master'. * dk/check-ignore-docs (2015-11-24) 1 commit (merged to 'next' on 2015-11-24 at 0cce5c5) + check-ignore: correct documentation about output Documentation clarification for "check-ignore" without "--verbose". Will merge to 'master'. * dk/rerere-train-quoting (2015
Re: [PATCH] verify_pack: do not ignore return value of verification function
On Mon, Nov 30, 2015 at 05:47:42PM -0500, David Turner wrote: > In verify_pack, a caller-supplied verification function is called. > The function returns an int. If that return value is non-zero, > verify_pack should fail. > > The only caller of verify_pack is in builtin/fsck.c, whose verify_fn > returns a meaningful error code (which was then ignored). Now, fsck > might return a different error code (with more detail). This would > happen in the unlikely event that a commit or tree that is a valid git > object but not a valid instance of its type gets into a pack. > > Signed-off-by: David Turner > --- > pack-check.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, this looks good to me. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 05/10] ref-filter: introduce color_atom_parser()
On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
> Introduce color_atom_parser() which will parse a "color" atom and
> store its color in the "use_atom" structure for further usage in
s/use_atom/used_atom/
> 'populate_value()'.
>
> Signed-off-by: Karthik Nayak
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> @@ -29,6 +29,9 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME }
> cmp_type;
> static struct used_atom {
> const char *str;
> cmp_type type;
> + union {
> + const char *color;
> + } u;
> } *used_atom;
> @@ -53,6 +56,13 @@ static int match_atom_name(const char *name, const char
> *atom_name, const char *
> +void color_atom_parser(struct used_atom *atom)
> +{
> + match_atom_name(atom->str, "color", &atom->u.color);
> + if (!atom->u.color)
> + die(_("expected format: %%(color:)"));
> +}
> +
> @@ -175,6 +185,9 @@ int parse_ref_filter_atom(const char *atom, const char
> *ep)
> REALLOC_ARRAY(used_atom, used_atom_cnt);
> used_atom[at].str = xmemdupz(atom, ep - atom);
> used_atom[at].type = valid_atom[i].cmp_type;
> + memset(&used_atom[at].u, 0, sizeof(used_atom[at].u));
> + if (valid_atom[i].parser)
> + valid_atom[i].parser(&used_atom[at]);
> if (*atom == '*')
> need_tagged = 1;
> if (!strcmp(used_atom[at].str, "symref"))
> @@ -833,11 +846,10 @@ static void populate_value(struct ref_array_item *ref)
> refname = branch_get_push(branch, NULL);
> if (!refname)
> continue;
> - } else if (match_atom_name(name, "color", &valp)) {
> + } else if (starts_with(name, "color")) {
Hmm, so this will also match "colorize". Is that desirable?
> char color[COLOR_MAXLEN] = "";
> + const char *valp = atom->u.color;
>
> - if (!valp)
> - die(_("expected format: %%(color:)"));
> if (color_parse(valp, color) < 0)
Rather than declaring variable 'valp', why not just say:
if (color_parse(atom->u.color, color) < 0)
?
> die(_("unable to parse format"));
> v->s = xstrdup(color);
> --
> 2.6.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make error message after failing commit_lock_file() less confusing
On Mon, Nov 30, 2015 at 12:40:53PM +0100, SZEDER Gábor wrote: > The error message after a failing commit_lock_file() call sometimes > looks like this, causing confusion: > > $ git remote add remote g...@server.com/repo.git > error: could not commit config file .git/config > # Huh?! > # I didn't want to commit anything, especially not my config file! I like the intent of this patch; I've had the same "huh" moment myself. > The error message is of course bikeshedable. You chose "write", which I think is OK. It's really a "rename", and maybe that matters for some values of errno. I'd guess in practice probably not (the likely reason is going to be something like EPERM). And I can't think of a concise way to express rename (just saying "rename" is confusing, too, without indicating that it's from the tempfile to the final resting place). So perhaps "write" is the best we can do. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 04/10] ref-filter: skip deref specifier in match_atom_name()
On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
> Signed-off-by: Karthik Nayak
A bit of explanation about why this change is desirable would be
welcome. I'm guessing it's because a future patch is going to make
calls to match_atom_name() with the '*' deref indicator still attached
to the name, whereas existing code does not do so.
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> @@ -37,6 +37,10 @@ static int match_atom_name(const char *name, const char
> *atom_name, const char *
> {
> const char *body;
>
> + /* skip the deref specifier*/
> + if (name[0] == '*')
> + name++;
> +
> if (!skip_prefix(name, atom_name, &body))
> return 0; /* doesn't even begin with "atom_name" */
> if (!body[0]) {
> --
> 2.6.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2015, #04; Tue, 24)
On Sat, Nov 28, 2015 at 05:09:32PM +, brian m. carlson wrote: > > I got a bunch of conflicts trying to merge it into 'next' and 'pu' and > > punted on it. I think the tricky bits are coming from > > dt/refs-backend-pre-vtable, where there was a lot of code movement. > > I think as for merging into the latest pu, the thing you want to do in > refs.c is simply take what pu has. You'll have to fix up one additional > struct object call site. The same thing goes for builtin/merge.c and > builtin/branch.c, where the code I changed has since been eliminated. > > I also noticed that merge-recursive.c and builtin/ff-refs.c needed some > minor fixups as well, but a quick compile will show you where those are. > I've included a diff for those two below. Thanks, this gave me an opportunity to play with Junio's merge-fix scripts. :) The result will be in the "pu" I push out shortly. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 02/10] ref-filter: introduce struct used_atom
On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
> Introduce the 'used_array' structure which would replace the existing
I guess you meant s/used_array/used_atom/ or something?
Also, s/which would/to/
> implementation of 'used_array' (which a list of atoms). This helps us
s/which a/which is a/
> parse atom's before hand and store required details into the
s/atom's/atoms/
s/before hand/beforehand/
> 'used_array' for future usage.
>
> Signed-off-by: Karthik Nayak
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> @@ -16,6 +16,23 @@
> +/*
> + * An atom is a valid field atom listed below, possibly prefixed with
> + * a "*" to denote deref_tag().
> + *
> + * We parse given format string and sort specifiers, and make a list
> + * of properties that we need to extract out of objects. ref_array_item
> + * structure will hold an array of values extracted that can be
> + * indexed with the "atom number", which is an index into this
> + * array.
> + */
> +static struct used_atom {
> + const char *str;
This is really the atom's name, isn't it? If so, perhaps "name" would
be a better field name.
> + cmp_type type;
> +} *used_atom;
> +static int used_atom_cnt, need_tagged, need_symref;
> +static int need_color_reset_at_eol;
> +
> static struct {
> const char *name;
> cmp_type cmp_type;
> @@ -93,21 +110,6 @@ struct atom_value {
> };
>
> /*
> - * An atom is a valid field atom listed above, possibly prefixed with
> - * a "*" to denote deref_tag().
> - *
> - * We parse given format string and sort specifiers, and make a list
> - * of properties that we need to extract out of objects. ref_array_item
> - * structure will hold an array of values extracted that can be
> - * indexed with the "atom number", which is an index into this
> - * array.
> - */
> -static const char **used_atom;
> -static cmp_type *used_atom_type;
> -static int used_atom_cnt, need_tagged, need_symref;
> -static int need_color_reset_at_eol;
You're moving this block of declarations up above the valid_atom[]
array because the previous patch added a new field named "parser" to
valid_atom[] which references 'struct used_atom' added by this patch
(2). I wonder if this movement should be done as a separate
preparatory patch to make it easier to review since, as it stands, the
reviewer has to read much more carefully to detect changes in the
moved block.
> -/*
> * Used to parse format string and sort specifiers
> */
> int parse_ref_filter_atom(const char *atom, const char *ep)
> @@ -787,7 +788,8 @@ static void populate_value(struct ref_array_item *ref)
>
> /* Fill in specials first */
> for (i = 0; i < used_atom_cnt; i++) {
> - const char *name = used_atom[i];
> + struct used_atom *atom = &used_atom[i];
> + const char *name = atom->str;
Why not just:
const char *name = used_atom[i].str;
?
> struct atom_value *v = &ref->value[i];
> int deref = 0;
> const char *refname;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clean: new option --exclude-from
On Tue, Dec 1, 2015 at 4:36 PM, James Rouzier wrote: > Eric thank you for the feedback. [re-adding git@vger.kernel.org to recipient list since this response was likely intended to be public] > On Sun, Nov 29, 2015 at 9:24 PM, Eric Sunshine > wrote: >> On Thu, Nov 26, 2015 at 9:44 AM, James wrote: >> > From: James Rouzier >> > >> > Specify a file to read for exclude patterns. >> > --- >> > @@ -61,6 +61,9 @@ OPTIONS >> > $GIT_DIR/info/exclude, also consider these patterns to be in the >> > set of the ignore rules in effect. >> > >> > +--exclude-from=:: >> > + Read exclude patterns from ; 1 per line. >> >> s/;/,/ maybe? > > I copied this from Documentation/git-ls-files.txt to try and keep the > documentation style consistent. > However if it is believed to be better I will change it here and also in a > separate patch for Documentation/git-ls-files.txt I don't feel strongly about it. Existing precedence may be a good argument in its favor. >> Also, why move the memset() all the way up here as opposed, say, to >> moving it just before the parse_options() invocation? Is it just to >> make it easier for the next person who comes along wanting to >> manipulate 'dir' early on (before git_config(), for instance)? > > Yes I want to make sure that the 'dir' is initialized before any usage. > >> > + git clean -f --exclude-from=.git/clean-exclude && >> > + test -e 1 && >> > + test -e 2 && >> > + ! (test -e 3) && >> >> I see that you copied this from the "git clean -e" test, but it's not >> obvious why parentheses are needed or wanted, and none of the other >> tests use parentheses when negating the return of 'test', thus they >> probably ought to be dropped. > > Ok will do > >> > + test -e known >> >> Modern scripts would normally use test_path_is_file() and >> test_path_is_missing() instead of 'test -e', however, you are again >> matching existing style in this script, so 'test -e' may be >> reasonable. > > Since it is the standard I could just take the time to upgrade 'test -e' in > this test file to use newer standard. This test script is probably relatively quiescent right now, so such cleanup may be reasonable. Since it is conceptually distinct from the purpose of the current patch, you would want to do the cleanup as a preparatory patch, thus making this a 2-patch series. >> > +test_expect_success 'git clean -e --exclude-from' ' >> > + rm -fr repo && >> > + mkdir repo && >> > + ( >> > + cd repo && >> > + git init && >> > + touch known 1 2 3 && >> > + git add known && >> > + echo 1 >> .git/clean-exclude && >> > + git clean -f -e 2 --exclude-from=.git/clean-exclude && >> > + test -e 1 && >> > + test -e 2 && >> > + ! (test -e 3) && >> > + test -e known >> > + ) >> > +' >> >> Should a test be added which uses --exclude-from multiple times in the >> same git-clean invocation? > > That does make sense will do. > >> Would it make sense add a test checking the behavior when the file >> named by --exclude-from doesn't exist or is otherwise unusable as an >> exclusion file? > > At the moment the add_excludes_from_file function will exit the program if > there is a problem loading the exclude file. > I could add a test for that behavior. In case in the future this behavior is > changed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail
Junio C Hamano writes:
> I do not think you would need a new option for this, by the way.
> Just add a new syntax for the LFS of a refspec that cannot possibly
> be confused with existing choices of what can come there (i.e. an
> empty string to denote deletion, or a partial refname), e.g. come up
> with an appropriate string in $sign and allow the following:
>
> $ git fetch ${sign}c78f7b5ed9dc
> $ git fetch ${sign}c78f7b5ed9dc:refs/remotes/origin/frotz
>
> to do the obvious thing, perhaps? We could even allow some form of
> extended SHA-1 expressions with some restrictions ...
Note that the above example already uses a form of extended SHA-1
expression, and I personally do not think we should support it in
the very initial version.
This is because the actual object name, if resolved on the remote
side, will not be known by "fetch". To support the "resolve on the
remote end", we would need protocol extension to have the remote end
tell the "fetch", i.e. "you asked to fetch HEAD@{4}, the exact
object name for that is 03f4c81729d2cb862a317e41a60a7111b98d";
otherwise we cannot add a line to FETCH_HEAD and cannot update the
RHS of the refspec.
Instead, we should limit us to 40-hex object name and nothing else
in the initial incarnation.
i.e.
$ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
$ git fetch
${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07:refs/remotes/origin/frotz
If the remote end (which, as Peff pointed out earlier, already knows
how to respond to a fetch request for an exact object when
configured to do so) allows such a fetch to go through, "fetch" can
(and will) update the ref named by the RHS of storing refspec with
the current code, so there is no need to do anything special to
support this.
As to ${sign}, I was tempted to say an empty string might be
sufficient (i.e. "do not use 40-hex as your branch name"), but it
probably is a bad idea. A single dot "." would be a possibility
(i.e. a ref component cannot begin with a dot), but squating on it
and saying "anything that begins with . must be followed by 40-hex
(and in the future by an extended SHA-1)" would rob extensibility
from us, so perhaps ".@c78f7b5ed9dc1c6edc8db06ac65860151d54fd07" or
something? That is leading "." denotes "this is an extended refspec"
and the next character denotes what kind of extended refspec it is.
For now we say that "@" denotes "exact object name is used instead
of a(n abbreviated) refname".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Submodule Groups
Am 01.12.2015 um 00:54 schrieb Stefan Beller: On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann wrote: Hmm, I doubt it makes much sense to add the --group option to "git submodule init". I'd rather init all submodules and do the group handling only in the "git submodule update" command. That way upstream can change grouping later without having the user to fiddle with her configuration to make that work. Mind to elaborate a bit more here? The way I understand you now is to pass not --groups to init, but init initializes all submodules. But that is worse IMHO Hmm, I did not mean to imply that "git init" should initialize all submodules. Me thinks that "git clone --groups" should do that but then only fetch and checkout those submodules the chosen groups select. I expect "git submodule init" to be obsolete when submodule groups (or recursive update) are used, and that's why IMO it doesn't need a --groups option. (If the user wants to change the groups later we might need to teach "git submodule sync" the --groups option though) (In the naive way of dealing with groups in the first patch series) as then we open up two possibilities: * a submodule which happened to be part of the repository when cloning is added to a new group, which a user has configured, on pulling, this is no problem, we just checkout the desired version of the submodule. That'll only work automatically when we follow my proposal to init all those submodules present on clone, because otherwise it won't be initialized. * a submodule which was not part of the repository at the time of cloning, is added to the superproject with a group the user is subscribed to. This would not be checked out as it is uninitialized on disk. That's why I propose a mechanism to "auto-init" new submodules on fetching their gitlink in the superproject. Then both your groups proposal and my recursive update could make them appear in the work tree on the next update/checkout. And as fetch is part of clone, I'd expect clone to "auto-init" all submodules referenced in gitlinks too. So when a change of the set of submodules as defined by groups occurs, that is the point in time, when we want to init/fetch/checkout these submodules, no? Well if upstream changes grouping later, you could just run git submodule update --init --groups and get what you want? And make life harder than necessary for our users without having a reason for that? So if upstream changes groups, ideally we want to follow without much hassle for the user. So a plain git pull should /just work/. (I am repeating myself here I'd guess), we would need to react to that. if we drop the --groups call to init, we'd still tell the user to run git submodule update Sure, that's still needed until we have recursive update. We do not need --groups any more in a later patch as instead of passing in --groups we can detect for `git config submodule.groups` to be available or not. Yes. --init should not be needed as when the groups are there we automatically init new submodules in the group set? Right. Except for the URL copying submodule settings on init is wrong, as it sets in stone what happened to be in the .gitmodules file when you ran init and doesn't allow upstream to easily change defaults later. We still do that with the update setting for historical reasons, but I avoided making the same mistake with all the options I added later. You can override these settings if you want or need to, but that shouldn't be necessary by default to make life easier for our users. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail
Duy Nguyen writes:
> maybe
>
> git clone --commit-id repo (*)
>
> instead. Detached head is implied, and this way you don't have to
> disambiguate sha-1 vs refname. And --commit-id can also be added in
> git-fetch. Actually the git-fetch case is even more interesting, what
> do we do with refspec..
>
> (*) as usual, we accept committish sha-1, not just comit sha-1, so
> --commit-id may be confusing..? Or maybe just go with --tag where we
> accept either tag names, tag sha-1 or commit-sha1
I agree with you that it is sensible to think this topic around
"fetch" not "clone".
I however do not think "--commit-id" is a good name for that option.
You are naming the option after what it is that is given, not after
what the commit specified with that commit-id is used for. It is
just as nonsense as renaming the "--not-merged" option used in
"branch --not-merged $commit" to "--commit-id" because the option
takes the object name for a committish.
Besides, "git fetch" can grab any object, not limited to committish,
which makes "--commit-id" a doubly unsuitable name for the option.
I do not think you would need a new option for this, by the way.
Just add a new syntax for the LFS of a refspec that cannot possibly
be confused with existing choices of what can come there (i.e. an
empty string to denote deletion, or a partial refname), e.g. come up
with an appropriate string in $sign and allow the following:
$ git fetch ${sign}c78f7b5ed9dc
$ git fetch ${sign}c78f7b5ed9dc:refs/remotes/origin/frotz
to do the obvious thing, perhaps? We could even allow some form of
extended SHA-1 expressions with some restrictions (e.g. limit its
use in a protected friendly environment to avoid excessive resource
use at the server side):
$ git fetch ${sign}c78f7b5ed9dc~12
$ git fetch ${sign}HEAD@{4}:refs/remotes/origin/frotz
The ${sign} signals two things. (1) That the endpoint of the
history (or the name of the object being fetched, be it a blob, a
tree and all its contents, a commit and everything reachable from
it, etc.) is specified and (2) that the specification will be
interpreted at the remote side.
Hmm?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] git-candidate: git based patch tracking and review
On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote: > Cc-ing dborowitz, who has been working on storing Gerrit's code review > information in Git instead of a separate database (e.g., see [1]). Thanks, we actually already had a thread going that I realize only in retrospect did not include the git mailing list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] git-candidate: git based patch tracking and review
Michael Haggerty wrote: > On 11/10/2015 01:56 PM, Richard Ipsum wrote: >> I've continued my work[1] to add patch tracking and candidate review >> capability >> to git. >> >> git-candidate now has a more git-like user interface, so remote candidates >> can now be specified in a similar way to remote refs (e.g. origin/candidate) >> as well as various other improvements, such as versioned metadata. > > This is a really interesting project. I've seen a blog post or two > proposing to store bug tracker information in Git in a distributed way, > but I don't recall anything about doing the same for code review > information. Cc-ing dborowitz, who has been working on storing Gerrit's code review information in Git instead of a separate database (e.g., see [1]). Thanks, Jonathan [1] https://storage.googleapis.com/gerrit-talks/summit/2015/NoteDB.pdf -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dependency query regarding contrib scripts
Richard Ipsum wrote: > Having read the docs for integrating new subcommands into git[1] I am looking > for some clarification of the following, > > "While we strongly encourage coding in portable C for portability, > these [C, shell, perl] specific scripting languages are also acceptable. > We won’t accept more without a very strong technical case, > as we don’t want to broaden the Git suite’s required dependencies" > > Does this also mean that use of non-core modules by, for example, perl > scripts, > is out of the question for contrib scripts? Or is it acceptable but ideally > minimised? > > In particular I'd like to be able to make use of Git::Raw[2] and also ideally > the Moo framework[3]. contrib is its own world. Your best bet is to ask the maintainer of the relevant contrib script what kind of portability they require (cc-ing this list). If you are the maintainer, then go wild. ;-) Thanks, Jonathan > [2]: http://search.cpan.org/~jacquesg/Git-Raw-0.58/lib/Git/Raw.pm > [3]: http://search.cpan.org/~haarg/Moo-2.02/lib/Moo.pm -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 7/8] update-index: prevent --untracked-cache from performing tests
`git update-index --untracked-cache` used to perform tests to
check that the underlying operating system and file system
change `st_mtime` field of a directory if files are added or
deleted in that directory. But those tests take a long time
and there is now `--test-untracked-cache` to perform them.
So to be more consistent with other git commands it's better
to make `--untracked-cache` not perform them, which is the
purpose of this patch.
Note that after this patch there is no difference any more
between `--untracked-cache` and `--force-untracked-cache`.
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 31 ---
builtin/update-index.c | 7 ++-
t/t7063-status-untracked-cache.sh | 2 +-
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 4e6078b..5f74cc7 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -175,27 +175,28 @@ may not support it yet.
--no-untracked-cache::
Enable or disable untracked cache extension. This could speed
up for commands that involve determining untracked files such
- as `git status`. The underlying operating system and file
- system must change `st_mtime` field of a directory if files
- are added or deleted in that directory. If you want to always
- enable, or always disable, untracked cache, you can set the
- `core.untrackedCache` configuration variable to 'true' or
- 'false' respectively, (see linkgit:git-config[1]).
+ as `git status`.
++
+The underlying operating system and file system must change `st_mtime`
+field of a directory if files are added or deleted in that
+directory. You can test that using
+`--test-untracked-cache`. `--untracked-cache` used to test that too
+but it doesn't anymore. If you want to always enable, or always
+disable, untracked cache, you can set the `core.untrackedCache`
+configuration variable to 'true' or 'false' respectively, (see
+linkgit:git-config[1]).
--test-untracked-cache::
Only perform tests on the working directory to make sure
untracked cache can be used. You have to manually enable
- untracked cache using `--force-untracked-cache` (or
- `--untracked-cache` but this will run the tests again)
- afterwards if you really want to use it.
+ untracked cache using `--untracked-cache` or
+ `--force-untracked-cache` afterwards if you really want to use
+ it.
--force-untracked-cache::
- For safety, `--untracked-cache` performs tests on the working
- directory to make sure untracked cache can be used. These
- tests can take a few seconds. `--force-untracked-cache` can be
- used to skip the tests. It cannot enable untracked cache if
- `core.untrackedCache` configuration variable is set to false
- (see linkgit:git-config[1]).
+ Same as `--untracked-cache`. Note that this option cannot
+ enable untracked cache if `core.untrackedCache` configuration
+ variable is set to false (see linkgit:git-config[1]).
\--::
Do not interpret any more arguments as options.
diff --git a/builtin/update-index.c b/builtin/update-index.c
index bf697a5..fb0ea3d 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1106,12 +1106,9 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
the_index.split_index = NULL;
the_index.cache_changed |= SOMETHING_CHANGED;
}
- if (untracked_cache == 2 || (untracked_cache == 1 &&
use_untracked_cache == -1)) {
+ if (untracked_cache == 2) {
setup_work_tree();
- if (!test_if_untracked_cache_is_supported())
- return 1;
- if (untracked_cache == 2)
- return 0;
+ return !test_if_untracked_cache_is_supported();
}
if (untracked_cache > 0) {
if (!use_untracked_cache)
diff --git a/t/t7063-status-untracked-cache.sh
b/t/t7063-status-untracked-cache.sh
index 0e8d0d4..8c3e703 100755
--- a/t/t7063-status-untracked-cache.sh
+++ b/t/t7063-status-untracked-cache.sh
@@ -11,7 +11,7 @@ avoid_racy() {
# It's fine if git update-index returns an error code other than one,
# it'll be caught in the first test.
test_lazy_prereq UNTRACKED_CACHE '
- { git update-index --untracked-cache; ret=$?; } &&
+ { git update-index --test-untracked-cache; ret=$?; } &&
test $ret -ne 1
'
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 6/8] config: add core.untrackedCache
When we know that mtime is fully supported by the environment, we
might want the untracked cache to be always used by default without
any mtime test or kernel version check being performed.
Also when we know that mtime is not supported by the environment,
for example because the repo is shared over a network file system,
then we might want 'git update-index --untracked-cache' to fail
immediately instead of it testing if it works (because it might
work on some systems using the repo over the network file system
but not others).
Signed-off-by: Christian Couder
---
Documentation/config.txt | 10 ++
Documentation/git-update-index.txt | 11 +--
builtin/update-index.c | 28 ++--
cache.h| 1 +
config.c | 10 ++
contrib/completion/git-completion.bash | 1 +
dir.c | 2 +-
environment.c | 1 +
wt-status.c| 9 +
9 files changed, 60 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b4b0194..bf176ff 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -308,6 +308,16 @@ core.trustctime::
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
+core.untrackedCache::
+ If unset or set to 'default' or 'check', untracked cache will
+ not be enabled by default and when
+ 'update-index --untracked-cache' is called, Git will test if
+ mtime is working properly before enabling it. If set to false,
+ Git will refuse to enable untracked cache even if
+ '--force-untracked-cache' is used. If set to true, Git will
+ blindly enabled untracked cache by default without testing if
+ it works. See linkgit:git-update-index[1].
+
core.checkStat::
Determines which stat fields to match between the index
and work tree. The user can set this to 'default' or
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 0ff7396..4e6078b 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -177,7 +177,10 @@ may not support it yet.
up for commands that involve determining untracked files such
as `git status`. The underlying operating system and file
system must change `st_mtime` field of a directory if files
- are added or deleted in that directory.
+ are added or deleted in that directory. If you want to always
+ enable, or always disable, untracked cache, you can set the
+ `core.untrackedCache` configuration variable to 'true' or
+ 'false' respectively, (see linkgit:git-config[1]).
--test-untracked-cache::
Only perform tests on the working directory to make sure
@@ -190,7 +193,9 @@ may not support it yet.
For safety, `--untracked-cache` performs tests on the working
directory to make sure untracked cache can be used. These
tests can take a few seconds. `--force-untracked-cache` can be
- used to skip the tests.
+ used to skip the tests. It cannot enable untracked cache if
+ `core.untrackedCache` configuration variable is set to false
+ (see linkgit:git-config[1]).
\--::
Do not interpret any more arguments as options.
@@ -406,6 +411,8 @@ It can be useful when the inode change time is regularly
modified by
something outside Git (file system crawlers and backup systems use
ctime for marking files processed) (see linkgit:git-config[1]).
+Untracked cache look at `core.untrackedCache` configuration variable
+(see linkgit:git-config[1]).
SEE ALSO
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 2cbaee0..bf697a5 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1106,19 +1106,27 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
the_index.split_index = NULL;
the_index.cache_changed |= SOMETHING_CHANGED;
}
+ if (untracked_cache == 2 || (untracked_cache == 1 &&
use_untracked_cache == -1)) {
+ setup_work_tree();
+ if (!test_if_untracked_cache_is_supported())
+ return 1;
+ if (untracked_cache == 2)
+ return 0;
+ }
if (untracked_cache > 0) {
- if (untracked_cache < 3) {
- setup_work_tree();
- if (!test_if_untracked_cache_is_supported())
- return 1;
- if (untracked_cache == 2)
- return 0;
- }
+ if (!use_untracked_cache)
+ die("core.untrackedCache is set to false; "
+ "the untracked cache will not be enabled");
[RFC/PATCH 2/8] update-index: add --test-untracked-cache
It is nice to just be able to test if untracked cache is
supported without enabling it.
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 9 -
builtin/update-index.c | 8 ++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 3df9c26..0ff7396 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -17,7 +17,7 @@ SYNOPSIS
[--[no-]assume-unchanged]
[--[no-]skip-worktree]
[--ignore-submodules]
-[--[no-|force-]untracked-cache]
+[--[no-|test-|force-]untracked-cache]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
[-z] [--stdin] [--index-version ]
@@ -179,6 +179,13 @@ may not support it yet.
system must change `st_mtime` field of a directory if files
are added or deleted in that directory.
+--test-untracked-cache::
+ Only perform tests on the working directory to make sure
+ untracked cache can be used. You have to manually enable
+ untracked cache using `--force-untracked-cache` (or
+ `--untracked-cache` but this will run the tests again)
+ afterwards if you really want to use it.
+
--force-untracked-cache::
For safety, `--untracked-cache` performs tests on the working
directory to make sure untracked cache can be used. These
diff --git a/builtin/update-index.c b/builtin/update-index.c
index e568acc..b7b5108 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -996,8 +996,10 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
N_("enable or disable split index")),
OPT_BOOL(0, "untracked-cache", &untracked_cache,
N_("enable/disable untracked cache")),
+ OPT_SET_INT(0, "test-untracked-cache", &untracked_cache,
+ N_("test if the filesystem supports untracked
cache"), 2),
OPT_SET_INT(0, "force-untracked-cache", &untracked_cache,
- N_("enable untracked cache without testing the
filesystem"), 2),
+ N_("enable untracked cache without testing the
filesystem"), 3),
OPT_END()
};
@@ -1107,10 +1109,12 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
if (untracked_cache > 0) {
struct untracked_cache *uc;
- if (untracked_cache < 2) {
+ if (untracked_cache < 3) {
setup_work_tree();
if (!test_if_untracked_cache_is_supported())
return 1;
+ if (untracked_cache == 2)
+ return 0;
}
if (!the_index.untracked) {
uc = xcalloc(1, sizeof(*uc));
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 3/8] update-index: move 'uc' var declaration
Signed-off-by: Christian Couder
---
builtin/update-index.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index b7b5108..b54ddc3 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1107,8 +1107,6 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
the_index.cache_changed |= SOMETHING_CHANGED;
}
if (untracked_cache > 0) {
- struct untracked_cache *uc;
-
if (untracked_cache < 3) {
setup_work_tree();
if (!test_if_untracked_cache_is_supported())
@@ -1117,7 +1115,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
return 0;
}
if (!the_index.untracked) {
- uc = xcalloc(1, sizeof(*uc));
+ struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
strbuf_init(&uc->ident, 100);
uc->exclude_per_dir = ".gitignore";
/* should be the same flags used by git-status */
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 8/8] update-index: make core.untrackedCache a bool
Most features in Git can be enabled or disabled using a simple
bool config variable and it would be nice if untracked cache
behaved the same way.
This makes --[no-|force-]untracked-cache change the value of
core.untrackedCache in the repo config file, to avoid making
those options useless and because this avoids the untracked
cache being disabled by a kernel change or a directory
change. Of course this breaks some backward compatibility,
but the simplification and increased useability is worth it.
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 13 ++---
builtin/update-index.c | 10 --
config.c | 8 +---
3 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 5f74cc7..256b9c5 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -181,10 +181,11 @@ The underlying operating system and file system must
change `st_mtime`
field of a directory if files are added or deleted in that
directory. You can test that using
`--test-untracked-cache`. `--untracked-cache` used to test that too
-but it doesn't anymore. If you want to always enable, or always
-disable, untracked cache, you can set the `core.untrackedCache`
-configuration variable to 'true' or 'false' respectively, (see
-linkgit:git-config[1]).
+but it doesn't anymore.
++
+This sets the `core.untrackedCache` configuration variable to 'true'
+or 'false' in the repo config file, (see linkgit:git-config[1]), so
+that the untracked cache stays enabled or disabled.
--test-untracked-cache::
Only perform tests on the working directory to make sure
@@ -194,9 +195,7 @@ linkgit:git-config[1]).
it.
--force-untracked-cache::
- Same as `--untracked-cache`. Note that this option cannot
- enable untracked cache if `core.untrackedCache` configuration
- variable is set to false (see linkgit:git-config[1]).
+ Same as `--untracked-cache`.
\--::
Do not interpret any more arguments as options.
diff --git a/builtin/update-index.c b/builtin/update-index.c
index fb0ea3d..048c293 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -,15 +,13 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
return !test_if_untracked_cache_is_supported();
}
if (untracked_cache > 0) {
- if (!use_untracked_cache)
- die("core.untrackedCache is set to false; "
- "the untracked cache will not be enabled");
+ if (!use_untracked_cache &&
git_config_set("core.untrackedCache", "true"))
+ die("could not set core.untrackedCache to true");
add_untracked_cache();
fprintf(stderr, _("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (!untracked_cache) {
- if (use_untracked_cache > 0)
- die("core.untrackedCache is set to true; "
- "the untracked cache will not be disabled");
+ if (use_untracked_cache > 0 &&
git_config_set("core.untrackedCache", "false"))
+ die("could not set core.untrackedCache to false");
if (the_index.untracked) {
remove_untracked_cache();
fprintf(stderr, _("Untracked disabled\n"));
diff --git a/config.c b/config.c
index 7d50f43..f023ee7 100644
--- a/config.c
+++ b/config.c
@@ -692,13 +692,7 @@ static int git_default_core_config(const char *var, const
char *value)
return 0;
}
if (!strcmp(var, "core.untrackedcache")) {
- if (!strcasecmp(value, "default") || !strcasecmp(value,
"check"))
- use_untracked_cache = -1;
- else {
- use_untracked_cache = git_config_maybe_bool(var, value);
- if (use_untracked_cache == -1)
- error("unknown core.untrackedCache value '%s';
using default", value);
- }
+ use_untracked_cache = git_config_bool(var, value);
return 0;
}
if (!strcmp(var, "core.checkstat")) {
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 4/8] dir: add add_untracked_cache()
This new function will be used in a later patch.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 11 +--
dir.c | 14 ++
dir.h | 1 +
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index b54ddc3..ec67d14 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1114,16 +1114,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
if (untracked_cache == 2)
return 0;
}
- if (!the_index.untracked) {
- struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
- strbuf_init(&uc->ident, 100);
- uc->exclude_per_dir = ".gitignore";
- /* should be the same flags used by git-status */
- uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
- the_index.untracked = uc;
- }
- add_untracked_ident(the_index.untracked);
- the_index.cache_changed |= UNTRACKED_CHANGED;
+ add_untracked_cache();
fprintf(stderr, _("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (!untracked_cache && the_index.untracked) {
the_index.untracked = NULL;
diff --git a/dir.c b/dir.c
index d2a8f06..0f7e293 100644
--- a/dir.c
+++ b/dir.c
@@ -1938,6 +1938,20 @@ void add_untracked_ident(struct untracked_cache *uc)
strbuf_addch(&uc->ident, 0);
}
+void add_untracked_cache(void)
+{
+ if (!the_index.untracked) {
+ struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
+ strbuf_init(&uc->ident, 100);
+ uc->exclude_per_dir = ".gitignore";
+ /* should be the same flags used by git-status */
+ uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
+ the_index.untracked = uc;
+ }
+ add_untracked_ident(the_index.untracked);
+ the_index.cache_changed |= UNTRACKED_CHANGED;
+}
+
static struct untracked_cache_dir *validate_untracked_cache(struct dir_struct
*dir,
int base_len,
const struct pathspec
*pathspec)
diff --git a/dir.h b/dir.h
index 7b5855d..ee94c76 100644
--- a/dir.h
+++ b/dir.h
@@ -308,4 +308,5 @@ void free_untracked_cache(struct untracked_cache *);
struct untracked_cache *read_untracked_extension(const void *data, unsigned
long sz);
void write_untracked_extension(struct strbuf *out, struct untracked_cache
*untracked);
void add_untracked_ident(struct untracked_cache *);
+void add_untracked_cache(void);
#endif
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/8] update-index: add untracked cache notifications
Doing:
cd /tmp
git --git-dir=/git/somewhere/else/.git update-index --untracked-cache
doesn't work how one would expect. It hardcodes "/tmp" as the directory
that "works" into the index, so if you use the working tree, you'll
never use the untracked cache.
With this patch "git update-index --untracked-cache" tells the user in
which directory tests are performed and in which working directory the
untracked cache is allowed.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 7431938..e568acc 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -121,7 +121,7 @@ static int test_if_untracked_cache_is_supported(void)
if (!mkdtemp(mtime_dir.buf))
die_errno("Could not make temporary directory");
- fprintf(stderr, _("Testing "));
+ fprintf(stderr, _("Testing mtime in '%s' "), xgetcwd());
atexit(remove_test_directory);
xstat_mtime_dir(&st);
fill_stat_data(&base, &st);
@@ -1122,9 +1122,11 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
}
add_untracked_ident(the_index.untracked);
the_index.cache_changed |= UNTRACKED_CHANGED;
+ fprintf(stderr, _("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (!untracked_cache && the_index.untracked) {
the_index.untracked = NULL;
the_index.cache_changed |= UNTRACKED_CHANGED;
+ fprintf(stderr, _("Untracked disabled\n"));
}
if (active_cache_changed) {
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 5/8] dir: add remove_untracked_cache()
This new function will be used in a later patch.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 3 +--
dir.c | 6 ++
dir.h | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index ec67d14..2cbaee0 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1117,8 +1117,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
add_untracked_cache();
fprintf(stderr, _("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (!untracked_cache && the_index.untracked) {
- the_index.untracked = NULL;
- the_index.cache_changed |= UNTRACKED_CHANGED;
+ remove_untracked_cache();
fprintf(stderr, _("Untracked disabled\n"));
}
diff --git a/dir.c b/dir.c
index 0f7e293..ffc0286 100644
--- a/dir.c
+++ b/dir.c
@@ -1952,6 +1952,12 @@ void add_untracked_cache(void)
the_index.cache_changed |= UNTRACKED_CHANGED;
}
+void remove_untracked_cache(void)
+{
+ the_index.untracked = NULL;
+ the_index.cache_changed |= UNTRACKED_CHANGED;
+}
+
static struct untracked_cache_dir *validate_untracked_cache(struct dir_struct
*dir,
int base_len,
const struct pathspec
*pathspec)
diff --git a/dir.h b/dir.h
index ee94c76..3e5114d 100644
--- a/dir.h
+++ b/dir.h
@@ -309,4 +309,5 @@ struct untracked_cache *read_untracked_extension(const void
*data, unsigned long
void write_untracked_extension(struct strbuf *out, struct untracked_cache
*untracked);
void add_untracked_ident(struct untracked_cache *);
void add_untracked_cache(void);
+void remove_untracked_cache(void);
#endif
--
2.6.3.391.g95a3a5c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/8] Untracked cache improvements
Following the discussions on the "config: add core.trustmtime" patch I previously sent, here is a patch series that tries to improve the untracked cache feature. This patch series implements core.untrackedCache instead of core.trustmtime. core.untrackedCache is more complex because basically when it's set to true git should always try to use the untracked cache, and when set to false git should never use it. Patchs 1/8 and 2/8 add some features that are missing. Patchs 3/8, 4/8 and 5/8 are some refactoring to prepare for patch 6/8 which implements core.untrackedCache. Up to patch 6/8 backward compatibility is preserved. Patchs 7/8 and 8/8 are trying to improve usability by making the untracked cache cli and config options more in line with other git cli and config options, but this sacrifies some backward compatibility. Christian Couder (8): update-index: add untracked cache notifications update-index: add --test-untracked-cache update-index: move 'uc' var declaration dir: add add_untracked_cache() dir: add remove_untracked_cache() config: add core.untrackedCache update-index: prevent --untracked-cache from performing tests update-index: make core.untrackedCache a bool Documentation/config.txt | 10 + Documentation/git-update-index.txt | 30 +++--- builtin/update-index.c | 39 -- cache.h| 1 + config.c | 4 contrib/completion/git-completion.bash | 1 + dir.c | 22 ++- dir.h | 2 ++ environment.c | 1 + t/t7063-status-untracked-cache.sh | 2 +- wt-status.c| 9 11 files changed, 90 insertions(+), 31 deletions(-) -- 2.6.3.391.g95a3a5c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-gui: Remove ancient Cygwin compatibility code
Remove special path handling for Cygwin in the git-gui Makefile. This used to be necessary, but has been being patched out of the official Cygwin distribution builds since Git v1.7.9, and should really be patched out of the upstream code rather than being patched every time in the Cygwin build process. Signed-off-by: Adam Dinwoodie --- I'm the current Cygwin maintainer for Git; this code has been patched out of the Cygwin Git builds since v1.7.9,* well before I took over. It's clearly stable and causing no problems, so having it in the upstream code rather than patching every time seems The Right Thing To Do. (* The actual patch used in the Cygwin builds just replaces `ifeq ($(uname_O,Cygwin))` with `ifeq ($(uname_O,noThanks))`, but that's clearly the appropriate solution for a quick manual patch, not for the actual upstream code.) Sending with apologies to Shawn Pearce for the noise; I'd misread the SubmittingPatches doc and sent to him alone first. I've based this patch off the git-gui tree rather than the main Git tree per the SubmittingPatches doc. Pipe it through `sed 's!Makekfile!git-gui/\0!g'` for a version that applies cleanly to the main Git source tree. Makefile | 21 +++-- 1 file changed, 3 insertions(+), 18 deletions(-) diff --git a/Makefile b/Makefile index 4f00bdd..e369046 100644 --- a/Makefile +++ b/Makefile @@ -136,25 +136,10 @@ GITGUI_RELATIVE := GITGUI_MACOSXAPP := -ifeq ($(uname_O),Cygwin) - GITGUI_SCRIPT := `cygpath --windows --absolute "$(GITGUI_SCRIPT)"` - - # Is this a Cygwin Tcl/Tk binary? If so it knows how to do - # POSIX path translation just like cygpath does and we must - # keep libdir in POSIX format so Cygwin packages of git-gui - # work no matter where the user installs them. - # - ifeq ($(shell echo 'puts [file normalize /]' | '$(TCL_PATH_SQ)'),$(shell cygpath --mixed --absolute /)) - gg_libdir_sed_in := $(gg_libdir) - else - gg_libdir_sed_in := $(shell cygpath --windows --absolute "$(gg_libdir)") - endif -else - ifeq ($(exedir),$(gg_libdir)) - GITGUI_RELATIVE := 1 - endif - gg_libdir_sed_in := $(gg_libdir) -endif +ifeq ($(exedir),$(gg_libdir)) + GITGUI_RELATIVE := 1 +endif +gg_libdir_sed_in := $(gg_libdir) ifeq ($(uname_S),Darwin) ifeq ($(shell test -d $(TKFRAMEWORK) && echo y),y) GITGUI_MACOSXAPP := YesPlease -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] builtin/clone: support submodule groups
On Mon, Nov 30, 2015 at 10:53 PM, Michael J Gruber
wrote:
> I think we have to solve more basic issues for sparse checkouts first.
> I'm using them with extra worktrees now and everything seems to be
> working fine. But we need to get the UI right for the simple case (no
> submodules, maybe not even extra worktrees) first: setting up patterns
> before checkout etc. Having submodules in mind doesn't hurt, tough.
Well my thinking comes from the other side: "I want to improve submodule
handling, but do I need to pay any attention to sparse checkout?", as Trevor
pointed out, this may or may not be similar enough from a users perspective,
that we want to have a similar/same UI there.
>
> I still consider sparse checkouts a local "cludge" (not technically
> cludgy) in the sense that it helps you cater to some specific local
> needs; not something whose config you'd want to transport as part of the
> object store.
Right, the submodule groups would be in the same boat. Each user would decide
locally what groups they think is worth having. Unlike the sparse checkout
the repository contains the groups however. As fair as I understand the sparse
checkout you would specify to checkout /foo/* but not checkout /bar/*
Now it is likely that some people will have very similar preferences for their
sparse checkout, so it may make sense to add an abstraction layer in there,
which can be done by groups. These groups could be defined using similar
patterns as in .gitattributes or .gitignore in another .gitgroups file. Maybe
the .gitattributes file could be reused.
The definition of the groups would be in the repository, such that it is kept
maintained and the individual user only needs to specify a few groups they're
interested in.
Currently you can already checkout submodules in a sparse fashion by just
initializing and checking out those submodules you want. But I think this
is not feasible if you have a huge amount of submodules, because you cannot
apply file patterns like you could with a .git{attributes, ignore, groups}
file. Because of the missing pattern, I'd want to add the groups.
>
> Minor implementation detail: Do we have any precedence of comma
> separated values for config values? I'd say we rather use multiple
> entries, don't we?
Ok, I'll fix that.
>
> Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git clone fails during pre-commit hook due to GIT_WORK_TREE=. (regression 2.5 -> 2.6)
On Mon, Nov 30, 2015 at 9:16 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> I was wrong, GIT_WORK_TREE support was added in git-clone many years >> ago in 20ccef4 (make git-clone GIT_WORK_TREE aware - 2007-07-06). So >> my change accidentally triggers an (undocumented) feature. We could >> add a hack to ignore GIT_WORK_TREE if GIT_DIR is set too, but I don't >> think people will like it. I don't really like reverting d95138e >> (setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR - >> 2015-06-26) because another bug reappears. > >> So I'm out of options.. > > Perhaps d95138e can be reverted and then the bug it tried to fix can > be fixed in a different way somehow? > > (I am not quite up to speed yet, so the above may turn out to be > infeasible--take it with a large grain of salt please). That would mean we do not set $GIT_DIR too early. While it sounds good, it could be just another trap, and could be a lot of reorganizing setup code. I'm more tempted to revert 20ccef4, with deprecation warning for some releases, and a new git-clone option for the same functionality. But let me sleep on it (and everybody please give ideas if you have any). Meanwhile, maybe reverting d95138e should be done any way for now. Broken aliases are not as bad as broken hooks. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dependency query regarding contrib scripts
Hi, Having read the docs for integrating new subcommands into git[1] I am looking for some clarification of the following, "While we strongly encourage coding in portable C for portability, these [C, shell, perl] specific scripting languages are also acceptable. We won’t accept more without a very strong technical case, as we don’t want to broaden the Git suite’s required dependencies" Does this also mean that use of non-core modules by, for example, perl scripts, is out of the question for contrib scripts? Or is it acceptable but ideally minimised? In particular I'd like to be able to make use of Git::Raw[2] and also ideally the Moo framework[3]. Thanks, Richard Ipsum [1]: ftp://www.kernel.org/pub/software/scm/git/docs/v2.4.0/howto/new-command.html [2]: http://search.cpan.org/~jacquesg/Git-Raw-0.58/lib/Git/Raw.pm [3]: http://search.cpan.org/~haarg/Moo-2.02/lib/Moo.pm -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 'pre-receive' hook and 'git-clang-format' script to reliably reject pushes that violate code style conventions
I don't want to smell like a nasty bumper here, but assuming that my questions were posted not in appropriate time (Saturday evening), I would like to call for help one last time. Thank you. Kind regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail
On Tue, Dec 1, 2015 at 1:47 AM, Stefan Beller wrote: > On Mon, Nov 30, 2015 at 10:11 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> +cc Junio, Duy >>> >>> So cloning from an arbitrary SHA1 is not a new thing I just came up with, >>> but has been discussed before[1]. >>> >>> Junio wrote on Oct 09, 2014: This is so non-standard a thing to do that I doubt it is worth supporting with "git clone". "git clone --branch", which is about >>> "> I want to follow that particular branch", would not mesh well with "I want to see the history that leads to this exact commit", either. You would not know which branch(es) is that exact commit is on in the first place. >>> >>> I disagree with this. This is the *exact* thing you actually want to do when >>> dealing with submodules. >> >> Yup, I know, but I do not think the above disagrees with you (read >> again ;-). It merely says "--branch" option to "clone" is not a >> good place to add a new "clone at this single commit" mode of >> operation. > > Ok. So maybe a bit of bike shedding time: > > How does > > git clone --detached-head maybe git clone --commit-id repo (*) instead. Detached head is implied, and this way you don't have to disambiguate sha-1 vs refname. And --commit-id can also be added in git-fetch. Actually the git-fetch case is even more interesting, what do we do with refspec.. (*) as usual, we accept committish sha-1, not just comit sha-1, so --commit-id may be confusing..? Or maybe just go with --tag where we accept either tag names, tag sha-1 or commit-sha1 > sound? I would imagine that this would either present you with a fresh clone > with a detached head at the specified sha1, or if the server doesn't support > getting a specific sha1, it would error out. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] push: add recurseSubmodules config option
The --recurse-submodules command line parameter has existed for some time but it has no config file equivalent. Following the style of the corresponding parameter for git fetch, invent push.recurseSubmodules to provide a default for this parameter. This also requires the addition of --recurse-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe --- Changes in v3: * Incorporate feedback from Junio C Hamano: ** Declare recurse_submodules variable on a separate line. ** Accept multiple --recurse-submodules options on the command line and the last one wins. * Add extra tests for multiple --recurse-submodules options on command line and improve existing tests slightly. Changes in v2: * Incorporate feedback from Eric Sunshine: ** push.recurseSubmodules config option now supports 'no' value. ** --no-recurse-submodules is now a synonym for --recurse-submodules=no. ** use "git -c" rather than "git config" in tests to avoid leaving config options set if a test fails. * Fix several && chain failures in tests noticed by Stefan Beller. * Minor tweaks to documentation * Fix minor naming issues in tests Documentation/config.txt | 14 Documentation/git-push.txt | 24 +++--- builtin/push.c | 35 submodule-config.c | 29 +++ submodule-config.h | 1 + submodule.h| 1 + t/t5531-deep-submodule-push.sh | 182 - 7 files changed, 259 insertions(+), 27 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index b4b0194..8c02e43 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2226,6 +2226,20 @@ push.gpgSign:: override a value from a lower-priority config file. An explicit command-line flag always overrides this config option. +push.recurseSubmodules:: + Make sure all submodule commits used by the revisions to be pushed + are available on a remote-tracking branch. If the value is 'check' + then Git will verify that all submodule commits that changed in the + revisions to be pushed are available on at least one remote of the + submodule. If any commits are missing, the push will be aborted and + exit with non-zero status. If the value is 'on-demand' then all + submodules that changed in the revisions to be pushed will be + pushed. If on-demand was not able to push all necessary revisions + it will also be aborted and exit with non-zero status. If the value + is 'no' then default behavior of ignoring submodules when pushing + is retained. You may override this configuration at time of push by + specifying '--recurse-submodules=check|on-demand|no'. + rebase.stat:: Whether to show a diffstat of what changed upstream since the last rebase. False by default. diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 85a4d7d..4c775bc 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -257,16 +257,20 @@ origin +master` to force a push to the `master` branch). See the is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. ---recurse-submodules=check|on-demand:: - Make sure all submodule commits used by the revisions to be - pushed are available on a remote-tracking branch. If 'check' is - used Git will verify that all submodule commits that changed in - the revisions to be pushed are available on at least one remote - of the submodule. If any commits are missing the push will be - aborted and exit with non-zero status. If 'on-demand' is used - all submodules that changed in the revisions to be pushed will - be pushed. If on-demand was not able to pus
Re: Investment/loan
Hello, Kindly permit me to properly introduce myself, I'm a broker, financial consultant in Beverly Hills, California, US. I'm contacting you regarding the company GIFG, a financial institute funding extremely wide variety of projects including real estate, amusement parks, eco and green projects, golf courses, hotels and hotel resorts, manufacturing, residential housing, tourism and tourist projects, water parks and many other types of project in over 60 countries worldwide. Kindly let me know if you have a viable project which need partnership funding, joint Investment or loan. Thanks and Regards, Ali +1 424 2266684 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/2] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
On 28 Nov 2015, at 18:10, Jeff King wrote: > On Fri, Nov 27, 2015 at 10:15:14AM +0100, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is >> flaky in the following case: >> 1. remote upload-pack finds out "not our ref" >> 2. remote sends a response and closes the pipe >> 3. fetch-pack still tries to write commands to the remote upload-pack >> 4. write call in wrapper.c dies with SIGPIPE >> >> t5504 "9 - push with transfer.fsckobjects" is flaky, too, and returns >> SIGPIPE once in a while. I had to remove the final "To dst..." output >> check because there is no output if the process dies with SIGPUPE. > > s/PUPE/PIPE/ :) > > I think it would be nice for future readers to understand a bit better > _why_ this is flaky, and why the fix is to the test suite and not to git > itself. I added this paragraph in between the two above: > >The test is flaky because the sending fetch-pack may or may not have >finished writing its output by step (3). If it did, then we see a >closed pipe on the next read() call. If it didn't, then we get the >SIGPIPE from step (4) above. Both are fine, but the latter fools >test_must_fail. > Sounds good! Thank you :-) - Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] OS X El Capitan + Xcode ships without SSL header?!
On 29 Nov 2015, at 18:04, Torsten Bögershausen wrote: > On 21/11/15 19:58, Lars Schneider wrote: >> Hi, >> >> I cannot build Git on a clean machine with OS X El Capitan 10.11, Xcode >> 7.1.1 and Xcode command line tools because of missing OpenSSL headers. >> >> It looks like as there are no OpenSSL headers at all. I only found this >> weird non working version: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-migrator/sdk/MacOSX.sdk/usr/include/openssl/ssl.h >> >> I installed OpenSSL with brew, added the include path and it works. >> >> Can anyone confirm? >> >> Thanks, >> Lars >> > (Does it make sense that you send a patch which auto-detects brew similar to > fink or mac ports?) I think that would make sense. I'll look into it if I find some free cycles... > > After some proper updating of one test machine I ran into the same problem. > A possible patch may look like this: > > > commit 5e7c16f3350e8e62bfdb181b0b5da7352945d046 > Author: Torsten Bögershausen > Date: Sun Nov 29 17:29:22 2015 +0100 > >Mac OS X 10.11: set NO_OPENSSL > >There is no openssl/ directory any more in Mac OS X 10.11, >openssl is depracated since Mac OS X 10.7 > >Set NO_OPENSSL to YesPlease as default under Mac OS X, and make it >possible to override this and use openssl by defining DARWIN_OPENSSL > > diff --git a/config.mak.uname b/config.mak.uname > index f34dcaa..a8a8b07 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -105,6 +105,12 @@ ifeq ($(uname_S),Darwin) >ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 > && echo 1),1) >HAVE_GETDELIM = YesPlease >endif > + # MacOS 10.11 and higher > + ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 15 > && echo 1),1) > + ifndef DARWIN_OPENSSL > + NO_OPENSSL = YesPlease > + endif > + endif That would propably do it. However, what are the ramifications here? Does this affect `git clone` over HTTPS or even SSH? Sorry if this question sounds stupid but I am not too familiar with these systems. If there are indeed these severe ramifications then I would probably print a little tutorial how to install OpenSSL via brew. Maybe one could use Apple's TLS implementation [1] on OS X alternatively. However, I don't know how different the APIs are and the resulting "ifdefs" are probably undesired. Cheers, Lars [1] https://developer.apple.com/library/mac/documentation/Security/Reference/secureTransportRef/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] Add Travis CI support
On 28 Nov 2015, at 18:12, Jeff King wrote: > On Fri, Nov 27, 2015 at 10:23:26AM +0100, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> diff to v7: >> * remove NO_GETTEXT patch and install gettext on OS X to compile with >> no additional flags (thanks Torsten) >> * fix P4 version (15.2 is the latest one available) > > Thanks. I don't have any other comments on this one. I guess the next > step is for me to get git/git signed up for Travis, and then merging > this to 'master' will have the desired effect. Thanks! You're right, signing up git/git for Travis should do it. Right now it is configured to build all branches on git/git that contain a travis.yml. That means if you merge it to pu or next then we should see builds already. Cheers, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
