* [PATCH 3/4] config: support parsing config data from buffers
From: Jeff King @ 2012-01-26 7:40 UTC (permalink / raw)
To: git
In-Reply-To: <20120126073547.GA28689@sigill.intra.peff.net>
The only two ways to parse config data are from a file or
from the command-line. Because the command-line format is
totally different from the file format, they don't share any
code. Therefore, to add new sources of file-like config data,
we have to refactor git_parse_file to handle reading from
something besides stdio.
To fix this, our config_file structure now holds either a
"FILE *" pointer or a memory buffer. We intercept calls to
fgetc and ungetc and either pass them along to stdio, or
fake them with our buffer. This leaves the main parsing code
intact and easy to read.
Signed-off-by: Jeff King <peff@peff.net>
---
cache.h | 1 +
config.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 21bbb0a..a298897 100644
--- a/cache.h
+++ b/cache.h
@@ -1110,6 +1110,7 @@ extern int update_server_info(int);
typedef int (*config_fn_t)(const char *, const char *, void *);
extern int git_default_config(const char *, const char *, void *);
extern int git_config_from_file(config_fn_t fn, const char *, void *);
+extern int git_config_from_buffer(config_fn_t fn, void *, const char *, char *, unsigned long );
extern void git_config_push_parameter(const char *text);
extern int git_config_from_parameters(config_fn_t fn, void *data);
extern int git_config(config_fn_t fn, void *);
diff --git a/config.c b/config.c
index b82f749..49a3d1a 100644
--- a/config.c
+++ b/config.c
@@ -18,6 +18,9 @@ typedef struct config_file {
const char *name;
int linenr;
int eof;
+ char *buf;
+ unsigned long size;
+ unsigned long cur;
struct strbuf value;
char var[MAXNAME];
} config_file;
@@ -101,19 +104,45 @@ int git_config_from_parameters(config_fn_t fn, void *data)
return nr > 0;
}
+static int get_one_char(void)
+{
+ if (cf->f)
+ return fgetc(cf->f);
+ else if (cf->buf) {
+ if (cf->cur < cf->size)
+ return cf->buf[cf->cur++];
+ return EOF;
+ }
+
+ die("BUG: attempt to read from NULL config_file");
+}
+
+static int unget_one_char(int c)
+{
+ if (cf->f)
+ ungetc(c, cf->f);
+ else if (cf->buf) {
+ if (cf->cur == 0)
+ return EOF;
+ cf->buf[--cf->cur] = c;
+ return c;
+ }
+
+ die("BUG: attempt to ungetc NULL config_file");
+}
+
static int get_next_char(void)
{
int c;
- FILE *f;
c = '\n';
- if (cf && ((f = cf->f) != NULL)) {
- c = fgetc(f);
+ if (cf && (cf->f || cf->buf)) {
+ c = get_one_char();
if (c == '\r') {
/* DOS like systems */
- c = fgetc(f);
+ c = get_one_char();
if (c != '\n') {
- ungetc(c, f);
+ unget_one_char(c);
c = '\r';
}
}
@@ -833,6 +862,9 @@ static void config_file_push(config_file *top, const char *name)
top->name = name;
top->linenr = 1;
top->eof = 0;
+ top->buf = NULL;
+ top->size = 0;
+ top->cur = 0;
strbuf_init(&top->value, 1024);
cf = top;
}
@@ -863,6 +895,22 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
return ret;
}
+int git_config_from_buffer(config_fn_t fn, void *data, const char *name,
+ char *buf, unsigned long size)
+{
+ int ret;
+ config_file top;
+
+ config_file_push(&top, name);
+ top.buf = buf;
+ top.size = size;
+
+ ret = git_parse_file(fn, data);
+
+ config_file_pop(&top);
+ return ret;
+}
+
const char *git_etc_gitconfig(void)
{
static const char *system_wide;
--
1.7.9.rc2.293.gaae2
^ permalink raw reply related
* [PATCH 4/4] config: allow including config from repository blobs
From: Jeff King @ 2012-01-26 7:42 UTC (permalink / raw)
To: git
In-Reply-To: <20120126073547.GA28689@sigill.intra.peff.net>
One often-requested feature is to allow projects to ship
suggested config to people who clone. The most obvious way
of implementing this would be to respect .gitconfig files
within the working tree. However, this has two problems:
1. Because git configuration can cause the execution of
arbitrary code, that creates a potential security problem.
While you may be comfortable running "make" on a newly
cloned project, you at least have the opportunity to
inspect the downloaded contents. But by automatically
respecting downloaded git configuration, you cannot
even safely use git to inspect those contents!
2. Configuration options tend not to be tied to a specific
version of the project. So if you are using "git
checkout" to sight-see to an older revision, you
probably still want to be using the most recent version
of the suggested config.
Instead, this patch lets you include configuration directly
from a blob in the repository (using the usual object name
lookup rules). This avoids (2) by pointing directly to a tag
or branch tip. It is still possible to be dangerous as in
(1) above, but the danger can be avoided by not pointing
directly into remote blobs (and the documentation warns of
this and gives a safe example).
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/config.txt | 41 ++++++++++++++++++++++++++++++++++++++++-
config.c | 25 ++++++++++++++++++++++++-
t/t1305-config-include.sh | 38 ++++++++++++++++++++++++++++++++++++++
3 files changed, 102 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e55dae1..38e83df 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -93,7 +93,14 @@ included file is expanded immediately, as if its contents had been
found at the location of the include directive. If the value of the
`include.path` variable is a relative path, the path is considered to be
relative to the configuration file in which the include directive was
-found. See below for examples.
+found.
+
+You can also include configuration from a blob stored in your repository
+by setting the special `include.ref` variable to the name of an object
+containing your configuration data (in the same format as a regular
+config file).
+
+See below for examples.
Example
~~~~~~~
@@ -120,6 +127,38 @@ Example
[include]
path = /path/to/foo.inc ; include by absolute path
path = foo ; expand "foo" relative to the current file
+ ref = config:.gitconfig ; look on "config" branch
+ ref = origin/master:.gitconfig ; this is unsafe! see below
+
+
+Security Considerations
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Because git configuration may cause git to execute arbitrary shell
+commands, it is important to verify any configuration you receive over
+the network. In particular, it is not a good idea to point `include.ref`
+directly at a remote tracking branch like `origin/master:shared-config`.
+After a fetch, you have no way of inspecting the shared-config you have
+just received without running git (and thus respecting the downloaded
+config). Instead, you can create a local tag representing the last
+verified version of the config, and only update the tag after inspecting
+any new content.
+
+For example:
+
+ # initially, look at their suggested config
+ git show origin/master:shared-config
+
+ # if it looks good to you, point a local ref at it
+ git tag config origin/master
+ git config include.ref config:shared-config
+
+ # much later, fetch any changes and examine them
+ git fetch origin
+ git diff config origin/master -- shared-config
+
+ # If the changes look OK, update your local version
+ git tag -f config origin/master
Variables
~~~~~~~~~
diff --git a/config.c b/config.c
index 49a3d1a..c41fb3b 100644
--- a/config.c
+++ b/config.c
@@ -941,7 +941,7 @@ static int handle_path_include(const char *path, void *data)
*/
if (!is_absolute_path(path)) {
char *slash;
- if (!cf)
+ if (!cf || !cf->f)
return error("relative config includes must come from files");
strbuf_addstr(&buf, absolute_path(cf->name));
slash = find_last_dir_sep(buf.buf);
@@ -958,6 +958,27 @@ static int handle_path_include(const char *path, void *data)
return ret;
}
+static int handle_ref_include(const char *ref, void *data)
+{
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ enum object_type type;
+ int ret;
+
+ if (get_sha1(ref, sha1))
+ return 0;
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return error("unable to read include ref '%s'", ref);
+ if (type != OBJ_BLOB)
+ return error("include ref '%s' is not a blob", ref);
+
+ ret = git_config_from_buffer(git_config_include, data, ref, buf, size);
+ free(buf);
+ return ret;
+}
+
int git_config_include(const char *name, const char *value, void *vdata)
{
const struct git_config_include_data *data = vdata;
@@ -978,6 +999,8 @@ int git_config_include(const char *name, const char *value, void *vdata)
if (!strcmp(type, "path"))
ret = handle_path_include(value, vdata);
+ else if (!strcmp(type, "ref"))
+ ret = handle_ref_include(value, vdata);
return ret;
}
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 4db3091..31d3b9b 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -95,4 +95,42 @@ test_expect_success 'relative includes from command line fail' '
test_must_fail git -c include.path=one config test.one
'
+test_expect_success 'include from ref' '
+ echo "[test]one = 1" >one &&
+ git add one &&
+ git commit -m one &&
+ rm one &&
+ echo "[include]ref = HEAD:one" >base &&
+ echo 1 >expect &&
+ git config -f base test.one >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'relative file include from ref fails' '
+ echo "[test]two = 2" >two &&
+ echo "[include]path = two" >one &&
+ git add one &&
+ git commit -m one &&
+ echo "[include]ref = HEAD:one" >base &&
+ test_must_fail git config -f base test.two
+'
+
+test_expect_success 'non-existent include refs are ignored' '
+ cat >base <<-\EOF &&
+ [include]ref = my-missing-config-branch:foo.cfg
+ [test]value = yes
+ EOF
+ echo yes >expect &&
+ git config -f base test.value >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'non-blob include refs fail' '
+ cat >base <<-\EOF &&
+ [include]ref = HEAD
+ [test]value = yes
+ EOF
+ test_must_fail git config -f base test.value
+'
+
test_done
--
1.7.9.rc2.293.gaae2
^ permalink raw reply related
* Re: Git svn migration does not work because fatal git checkout updating paths is incompatible with switching branches
From: Christine Bauers @ 2012-01-26 8:50 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1327518563.31804.82.camel@centaur.lab.cmartin.tk>
Am 25.01.2012 20:09, schrieb Carlos Martín Nieto:
> On Wed, 2012-01-25 at 19:04 +0100, Christine Bauers wrote:
>> Hi there,
>>
>> I´m trying to migrate a repository from svn to git which branches and
>> tags with the following migration script:
>>
>> git svn clone --no-metadata --stdlayout --A ../users.txt
>> svn://host/svn/project/subproject subproject
>>
>> cd subproject
>> git config svn.authorsfile ../../users.txt
>> git svn fetch
>>
>> git checkout -b branch1 remotes/branch1
>> git checkout -b branch2 remotes/branch2
>> git checkout -b branch3 remotes/branch3
>>
>> git checkout -b src_v1 remotes/tags/src
>> git checkout master
>> git tag src src_v1
>> git branch -D src_v1
>>
>> git checkout -b WebContent_v1 remotes/tags/WebContent
>> git checkout master
>> git tag WebContent WebContent_v1
>> git branch -D WebContent_v1
>>
>> and get the follwoing errors:
>>
>> W: Ignoring error from SVN, path probably does not exist: (160013):
>> Filesystem has no item: Datei nicht gefunden: Revision 8966, Pfad
>> »subproject«
>> W: Do not be alarmed at the above message git-svn is just searching
>> aggressively for old history.
>> This may take a while on large repositories
>> fatal: git checkout: updating paths is incompatible with switching branches.
>> Did you intend to checkout 'remotes/branch1' which can not be resolved
>> as commit?
>> fatal: git checkout: updating paths is incompatible with switching branches.
>> Did you intend to checkout 'remotes/branch2 which can not be resolved as
>> commit?
>> fatal: git checkout: updating paths is incompatible with switching branches.
>> Did you intend to checkout 'remotes/branch3' which can not be resolved
>> as commit?
>> fatal: git checkout: updating paths is incompatible with switching branches.
>> Did you intend to checkout 'remotes/tags/src' which can not be resolved
>> as commit?
>> error: pathspec 'master' did not match any file(s) known to git.
>> fatal: Failed to resolve 'src_v1' as a valid ref.
>> error: branch 'src_v1' not found.
>> fatal: git checkout: updating paths is incompatible with switching branches.
>> Did you intend to checkout 'remotes/tags/WebContent' which can not be
>> resolved as commit?
>> error: pathspec 'master' did not match any file(s) known to git.
>> fatal: Failed to resolve 'WebContent_v1' as a valid ref.
>> error: branch 'WebContent_v1' not found.
>>
>> How do I solve this problem?
> First try to figure out where the problem happens. It could be that
> git-svn isn't recognising the branches properly, or that the layout
> isn't what it expects or any number of things.
>
> What layout does the repo have? Does it correspond to what git-svn is
> expecting? All those error messages come from the fact that you're
> telling git some starting points that it can't find. Make sure those
> exist and they have the name you're giving. What does `git branch -a`
> say? You're presumably not giving us the real names, so we can't tell if
> there are problems there.
>
> If you're looking to migrate completely, something like
> svn-dump-fast-export ( https://github.com/barrbrain/svn-dump-fast-export
> ) might get you there better.
>
> cmn
Thanks for your answer. I would say the problem happens while cloning the project, because git branch -a and git branch -r says nothing. The question is why aren´t there any branches? Here is the structure of the project:
marketplace
braches
lyth_dev
meinbestand_suche
umkreis_suche
tags
src
WebContent
trunk
src
WebContent
trunk_112233
src
WebContent
And here again the script:
git svn clone --no-metadata --stdlayout --A ../users.txt svn://host/svn/projects/marketplace marketplace
cd marketplace
git config svn.authorsfile ../../users.txt
git svn fetch
#Checkout Branches
git checkout -b lyth_dev remotes/lyth_dev
git checkout -b meinbestand_suche remotes/meinbestand_suche
git checkout -b umkreis_suche remotes/umkreis_suche
#Checkout der tags
git checkout -b src_v1 remotes/tags/src
git checkout master
git tag src src_v1
git branch -D src_v1
git checkout -b WebContent_v1 remotes/tags/WebContent
git checkout master
git tag WebContent WebContent_v1
git branch -D WebContent_v1
Is there something wrong with this script? Or does the errors maybe occurs because there is a trunk_112233. The log file says the following:
Initialized empty Git repository in c:/project/marketplace/.git/
Checked through r8445
Checked through r8545
Checked through r8645
Checked through r8745
Checked through r8845
Checked through r8945
Checked through r8968
Checked through r8968
And that´s all. It says nothing about references.
Do you have any ideas?
Thanks
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Johannes Sixt @ 2012-01-26 9:16 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120126073752.GA30474@sigill.intra.peff.net>
Am 1/26/2012 8:37, schrieb Jeff King:
> This patch introduces an include directive for config files.
Nice. I haven't had a need for it, yet, but the concept looks good.
> +test_expect_success 'recursive relative paths' '
> + mkdir subdir &&
> + echo "[test]three = 3" >subdir/three &&
> + echo "[include]path = three" >subdir/two &&
> + echo "[include]path = subdir/two" >base &&
> + echo 3 >expect &&
> + git config -f base test.three >actual &&
> + test_cmp expect actual
> +'
Isn't it rather "chained relative paths"? Recursive would be if I write
[include]path = .gitconfig
in my ~/.gitconfig. What happens in this case?
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/4] config: allow including config from repository blobs
From: Johannes Sixt @ 2012-01-26 9:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120126074208.GD30474@sigill.intra.peff.net>
Am 1/26/2012 8:42, schrieb Jeff King:
> +static int handle_ref_include(const char *ref, void *data)
> +{
> + unsigned char sha1[20];
> + char *buf;
> + unsigned long size;
> + enum object_type type;
> + int ret;
> +
> + if (get_sha1(ref, sha1))
> + return 0;
> + buf = read_sha1_file(sha1, &type, &size);
> + if (!buf)
> + return error("unable to read include ref '%s'", ref);
> + if (type != OBJ_BLOB)
> + return error("include ref '%s' is not a blob", ref);
> +
> + ret = git_config_from_buffer(git_config_include, data, ref, buf, size);
> + free(buf);
> + return ret;
> +}
What happens if a ref cannot be resolved, for example due to repository
corruption? Does git just emit an error and then carries on, or does it
always die? Can I run at least git-fsck in such a case?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Stephen Bash @ 2012-01-26 13:51 UTC (permalink / raw)
To: Jeff King
Cc: Conrad Irwin, git, Nguyen Thai Ngoc Duy, Dov Grobgeld,
Junio C Hamano
In-Reply-To: <20120125214625.GA4666@sigill.intra.peff.net>
----- Original Message -----
> From: "Jeff King" <peff@peff.net>
> Sent: Wednesday, January 25, 2012 4:46:26 PM
> Subject: Re: [PATCH] Don't search files with an unset "grep" attribute
>
> ... snip ...
>
> So if this was all spelled:
>
> $ cat .gitattributes
> *.pdf filetype=pdf
> $ cat .git/config
> [filetype "pdf"]
> binary = true
> textconv = pdf2txt
>
> I think it would be a no-brainer that those type attributes should
> apply to "git grep".
Looking at this purely as a user, what difference/advantage would that bring versus
$ cat .gitattributes
*.pdf binary=true textconv=pdf2text
or
$ cat .gitattributes
[attr]pdf binary=true textconv=pdf2text
*.pdf pdf
(admittedly I have no clue if gitattributes actually supports anything like this)
I guess my point is as a user, I've gravitated to "gitattributes is about files in my repo, gitconfig is about Git's behavior" (though this is a grey area).
To partially answer my own question: one advantage of putting the filetype information in a config file is it allows system- and user-wide filetype settings. In my personal experience I've always handled that information on a per-repository basis, but that doesn't mean everyone would want to.
Thanks,
Stephen
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-26 14:33 UTC (permalink / raw)
To: git
In-Reply-To: <1327530594.31804.87.camel@centaur.lab.cmartin.tk>
Thanks ...
I really appreciate your time.
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-26 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20120126T144828-400@post.gmane.org>
that doesn't seem to change the path :(
which git => /usr/bin/git
version still points to the old one :(
This is my current path that I changed, as you told me to do...
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/git/bin
^ permalink raw reply
* Re: git svn dcommit sends to wrong branch
From: badgerhardy @ 2012-01-26 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <877h0yz269.fsf@thomas.inf.ethz.ch>
Thomas Rast wrote
>
> Victor Engmark <victor.engmark@> writes:
>
> The rule is that the commits go to the branch named in the git-svn-id
> line of the most recent first-parent ancestor of HEAD.
>
> You can find the "base" commit in question with
>
> git log -1 --first-parent --grep=^git-svn-id:
>
>> And more importantly, how do I "replay" my commits on trunk?
>
> You need to rebase the commits on trunk, and (very important) strip the
> git-svn-id lines from their messages. If you only had a handful of
> commits, your best bet is to use something like
>
> git checkout -b newbranch
> git rebase -i --onto svn/trunk svn/branch_name # or whatever git-svn
> named the remote branches
> # edit all the 'pick' into 'reword'
> # in every commit message editor that pops up, remove the git-svn-id
> line
>
> gitk # make sure that you like the resulting history!
> git svn dcommit
>
I had the same problem and have followed these instructions (thanks!). I now
have a 'newbranch' that will correctly dcommit to the svn trunk. What
happens to the git 'master'? Is this recoverable or do I need to delete it
and rename the 'newbranch' as master?
Thanks,
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-dcommit-sends-to-wrong-branch-tp7172744p7227251.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Michael Haggerty @ 2012-01-26 16:45 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Conrad Irwin, git, Nguyen Thai Ngoc Duy,
Dov Grobgeld
In-Reply-To: <20120125214625.GA4666@sigill.intra.peff.net>
On 01/25/2012 10:46 PM, Jeff King wrote:
> But what I'm not sure I agree with is that the idea of "I don't want to
> include path X in my grep" maps to "just mark the file as binary".
Anybody who wants this policy can simply set
[attr]binary -diff -text -grep
If they want finer granularity, they can adjust the settings for
particular file types or for particular files.
> But should I mark everything in compat/nedmalloc as binary? I don't
> think so. I _do_ want to see changes in nedmalloc in "git log" or "git
> diff". They don't bother me because they're infrequent, and we still
> want to produce regular text patches for the list when they come up. But
> because nedmalloc contains a lot of lines of code (even though they
> don't change a lot), it happens to produce a lot of uninteresting
> matches when grepping.
I think decisions such as whether to include an imported module in "git
diff" output is a personal preference and should not be decided at the
level of the git project. The in-tree .gitattributes files should, by
and large, just *describe* the files and leave it to users to associate
policies with the tags (or at least make it possible for users to
override the policies) via .git/info/attributes. For example, the
repository could set an "external=nedmalloc" attribute on all files
under compat/nedmalloc, and users could themselves configure a macro
"[attr]external -diff -grep" (or maybe something like
"[attr]external=nedmalloc -diff -grep") if that is their preference.
> It would be nice to be able to treat them differently in the cases you
> wanted to, but not _have_ to do so. Attribute macros can almost
> implement this. You could add "-grep" to binary. But you can't (as far
> as I know) do "macro=foo" to handle arbitrary diff drivers. I suspect we
> could extend the rules to allow macros that take an argument and pass it
> to their constituent attributes.
Is it really common to want to use the same argument on multiple macros
without also wanting to set other things specifically? If not, then
there is not much reason to complicate macros with argument support.
For example, I do something like
[attr]type-python type=python text diff=python check-ws
*.py type-python
[attr]type-makefile type=makefile text diff check-ws -check-tab
Makefile.* type-makefile
for the main file types in my repository, and it is not very cumbersome.
"type-python" and "type=python" seem redundant but they are not.
"type-python" is needed so that it can be used as a macro.
"type=python" makes it easier to inquire about the type of a file using
something like "git check-attr type -- PATH" rather than having to
inquire about each possible type-* attribute. It might be nice to
support a slightly extended macro definition syntax like
[attr]type=python text diff=python check-ws
*.py type=python
[attr]type=makefile text diff check-ws -check-tab
Makefile.* type=makefile
(i.e., macros that are only triggered for particular values of an
attribute).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git version not changed after installing new version
From: Holger Hellmuth @ 2012-01-26 16:52 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120126T161101-463@post.gmane.org>
On 26.01.2012 16:13, freefly wrote:
> that doesn't seem to change the path :(
>
> which git => /usr/bin/git
>
> version still points to the old one :(
>
> This is my current path that I changed, as you told me to do...
>
> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/git/bin
Put /usr/local/git/bin in front (it is easy to overlook the "git/" in
there as software often uses /usr/local/bin)
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Jeff King @ 2012-01-26 16:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4F2119E6.8010109@viscovery.net>
On Thu, Jan 26, 2012 at 10:16:22AM +0100, Johannes Sixt wrote:
> > +test_expect_success 'recursive relative paths' '
> > + mkdir subdir &&
> > + echo "[test]three = 3" >subdir/three &&
> > + echo "[include]path = three" >subdir/two &&
> > + echo "[include]path = subdir/two" >base &&
> > + echo 3 >expect &&
> > + git config -f base test.three >actual &&
> > + test_cmp expect actual
> > +'
>
> Isn't it rather "chained relative paths"? Recursive would be if I write
>
> [include]path = .gitconfig
>
> in my ~/.gitconfig. What happens in this case?
Good point. I used "recursive" because it is recursing in the include
function within git, but obviously from the user's perspective, it is
not a recursion.
And no, I didn't do any cycle detection. We could either do:
1. Record some canonical name for each source we look at (probably
realpath() for files, and the sha1 for refs), and don't descend
into already-seen sources.
2. Simply provide a maximum depth, and don't include beyond it.
The latter is much simpler to implement, but I think the former is a
little nicer for the user.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] config: allow including config from repository blobs
From: Jeff King @ 2012-01-26 17:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4F211C0C.7060400@viscovery.net>
On Thu, Jan 26, 2012 at 10:25:32AM +0100, Johannes Sixt wrote:
> Am 1/26/2012 8:42, schrieb Jeff King:
> > +static int handle_ref_include(const char *ref, void *data)
> > +{
> > + unsigned char sha1[20];
> > + char *buf;
> > + unsigned long size;
> > + enum object_type type;
> > + int ret;
> > +
> > + if (get_sha1(ref, sha1))
> > + return 0;
> > + buf = read_sha1_file(sha1, &type, &size);
> > + if (!buf)
> > + return error("unable to read include ref '%s'", ref);
> > + if (type != OBJ_BLOB)
> > + return error("include ref '%s' is not a blob", ref);
> > +
> > + ret = git_config_from_buffer(git_config_include, data, ref, buf, size);
> > + free(buf);
> > + return ret;
> > +}
>
> What happens if a ref cannot be resolved, for example due to repository
> corruption? Does git just emit an error and then carries on, or does it
> always die? Can I run at least git-fsck in such a case?
Names which do not resolve are explicitly ignored, because I wanted to
flexibility in specifying the includes. E.g., you might say put:
[include]
ref = refs/config
in your ~/.gitconfig, and then only use the feature in some of your
repositories (I'm not sure if that is a good idea yet in practice or
not. But as I said before, I think of this is a building block, and I'd
like people to experiment and see if it fills their needs).
Obviously the trade-off is that we would silently ignore a typo in the
object name.
However, I did explicitly return an error for a failure to find a sha1,
or a non-blob sha1, as those are more severe configuration errors (where
the former is basically repository corruption). We only return an error
here, but git_config will eventually die() because of it, noting the
file and line number where the include happened[1].
It's then up to you to fix the config file before you can continue using
git. You can do so by hand, but I think using "git config" to do so will
not work; even though it correctly does not expand includes while
writing, the git wrapper incidentally reads the config before actually
running the config command.
We already have similar problems where setting a bool option to a
non-bool value will cause many git commands git to die (e.g., try
setting "color.ui" to "foo"). But it's less often an issue, because
unless the config option you have messed up is very basic (like
core.bare), you can still run "git config".
So it's certainly recoverable if you are comfortable editing the config
file. But we could also make it a little friendlier by turning those
errors into warnings, at the minor cost of making errors less
noticeable.
-Peff
[1] The error reporting just shows the source of the deepest file,
because git_parse_file will actually call die(). So if I have a
.git/config that includes a ref that includes another ref that has
an error, I see only:
$ git config foo.value
error: include ref 'HEAD:subdir' is not a blob
fatal: bad config file line 5 in HEAD:config
But solving the problem without git is hard. I know the problem is
in the ref, but I can't edit the ref. The source of the include
chain has to come from a file I can edit outside of git (since we
always start from the files), but I'm not told which file included
it.
So it would be a little nicer to say something like:
error: include ref 'HEAD:subdir' is not a blob (at HEAD:config, line 5)
error: included file 'HEAD:config' had errors at .git/config, line 9
fatal: unable to parse configuration
which shows the complete trail, and you know to edit .git/config. In
practice, I don't know if it is much of an issue. There are only 3
places that git actually reads config from, and it is likely that
you just edited one.
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Jeff King @ 2012-01-26 17:29 UTC (permalink / raw)
To: Stephen Bash
Cc: Conrad Irwin, git, Nguyen Thai Ngoc Duy, Dov Grobgeld,
Junio C Hamano
In-Reply-To: <1af46e50-fdc5-47b8-af36-d070d91dd954@mail>
On Thu, Jan 26, 2012 at 08:51:52AM -0500, Stephen Bash wrote:
> > $ cat .gitattributes
> > *.pdf filetype=pdf
> > $ cat .git/config
> > [filetype "pdf"]
> > binary = true
> > textconv = pdf2txt
>
> Looking at this purely as a user, what difference/advantage would that bring versus
>
> $ cat .gitattributes
> *.pdf binary=true textconv=pdf2text
For "binary", probably not much. But for textconv, it is all about the
split between attributes and config, as mentioned below:
> To partially answer my own question: one advantage of putting the
> filetype information in a config file is it allows system- and
> user-wide filetype settings. In my personal experience I've always
> handled that information on a per-repository basis, but that doesn't
> mean everyone would want to.
Right. Setting things system-wide instead of per-repo is one advantage.
But more important is that attributes are not per-repo, but rather
"per-project". They get committed, and everybody who works on the
project shares them.
In your example, the gitattributes get committed, and the project is
mandating "you _will_ use pdf2text to view diffs of these files". But
that may not be appropriate for everybody who clones. Somebody may have
a different pdf-to-text converter. Somebody may simply have pdf2txt at a
different path, or need different options. Or somebody may want to skip
it altogether and use an external diff command, or even just see the
files as binary.
By splitting the information across the two files, the project gets to
say "this file is of type pdf", and then each user gets to decide "how
do I want to diff pdf files?"
-Peff
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-26 17:52 UTC (permalink / raw)
To: git
In-Reply-To: <4F2184DC.6070804@ira.uka.de>
> Put /usr/local/git/bin in front (it is easy to overlook the "git/" in
> there as software often uses /usr/local/bin)
That worked. Thank you very much.
^ permalink raw reply
* How to reorganize git tree
From: Alan Edwards @ 2012-01-26 18:35 UTC (permalink / raw)
To: git
I was new to git about a year ago and created a git directory
structure containing several different projects like:
/source/web_server1/project1
/source/web_server1/project2
/source/web_server1/project3
/source/web_server1/project4
/source/web_server2/project5
/source/web_server2/project6
where my massive .git repository is:
/source/.git (containing all the projects on all the web servers....
Oops!) There seems to be lots of "loose objects".
Somewhere along the way I figured out that this probably wasn't a good
idea and I ended up making a git repository under one of the projects:
/source/web_server1/project4/.git
Not sure if that was the best decision either. I've already checked in
changes to the /source/web_server1/project4/.git repository for
project4 and I've checked in changes to project2 into the /source/.git
repository.
Of course I now realize the errors of my way and would like to restructure.
the only changes that have been checked into the big upper level
repository are changes for project2. Is it possible to carve out
those changes from the /source/.git repository and create a new
/source/web_server1/project2/.git repository?
Maybe the way to deal with this is to remove the other directories
from the /source/.git repository and leave project2 there.
Any one have any suggestions?
I'm not sure if I'm posting this in the right place (I'm at work and
they don't allow access to many places and I don't have access to the
news group).
Thanks!
-Alan Edwards
kae at xnet dot com (my home email address)
^ permalink raw reply
* Re: How to reorganize git tree
From: Ben Walton @ 2012-01-26 18:57 UTC (permalink / raw)
To: Alan Edwards; +Cc: git
In-Reply-To: <20120126133505.it34vehs0044o848@webmail.xnet.com>
Excerpts from Alan Edwards's message of Thu Jan 26 13:35:05 -0500 2012:
Hi Alan,
> Any one have any suggestions?
I think that git filter-branch is going to be your friend here. I
won't prescribe the details as you should definitely read and
understand the docs for this one, but things like
--subdirectory-filter and/or --tree-filter will be of great use to
you, I think.
Hope this helps.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: [PATCH] docs: minor grammar fixes for v1.7.9 release notes
From: Junio C Hamano @ 2012-01-26 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120125222002.GA6309@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Easier to view with --color-words, of course.
Thanks ;-)
> ... (I notice you mostly include features and not bug-fixes, which I
> assume is to keep the list to a readable length).
Actually my intention regarding fixes are:
- never mention follow-up fixes to new topics merged since v1.7.8 at all;
- omit mentioning trivial fixes that not many people would be bitten by
and actually be hurt in real life (i.e. typo in an error message); and
- make sure as many fixes are covered in "Fixes since v1.7.8" section.
So "keep the list short" is only one-third of the motivation.
^ permalink raw reply
* Re: [PATCH] docs: minor grammar fixes for v1.7.9 release notes
From: Jeff King @ 2012-01-26 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr8e2s3n.fsf@alter.siamese.dyndns.org>
On Thu, Jan 26, 2012 at 11:15:08AM -0800, Junio C Hamano wrote:
> > ... (I notice you mostly include features and not bug-fixes, which I
> > assume is to keep the list to a readable length).
>
> Actually my intention regarding fixes are:
>
> - never mention follow-up fixes to new topics merged since v1.7.8 at all;
>
> - omit mentioning trivial fixes that not many people would be bitten by
> and actually be hurt in real life (i.e. typo in an error message); and
>
> - make sure as many fixes are covered in "Fixes since v1.7.8" section.
>
> So "keep the list short" is only one-third of the motivation.
That makes sense.
I was specifically thinking of 02f7914 (remote-curl: don't pass back
fake refs), because "git push --mirror" failing is an often-reported bug
for github (and the solution is to upgrade your git client). But looking
again, I see that the fix was actually in v1.7.8.2, so it is included by
the "...and all of the fixes in the maintenance releases" text.
In general, it seems like most of our fixes go onto the maintenance
track, so the "fixes" section of a major release ends up being empty.
Which I think is a good thing.
-Peff
^ permalink raw reply
* Re: [PATCH 5/5] run-command: Error out if interpreter not found
From: Junio C Hamano @ 2012-01-26 19:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frans Klaver, Jonathan Nieder, git, Junio C. Hamano
In-Reply-To: <4F205028.4060606@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> No thanks. IMHO, this is already too much code for too little gain.
Thanks for bringing a bit of sanity. You have already said it "In which
way is git different from other tools that execvp other programs?" earlier
(http://thread.gmane.org/gmane.comp.version-control.git/171755/focus=171848)
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Junio C Hamano @ 2012-01-26 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20120126165456.GA5278@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> And no, I didn't do any cycle detection. We could either do:
>
> 1. Record some canonical name for each source we look at (probably
> realpath() for files, and the sha1 for refs), and don't descend
> into already-seen sources.
>
> 2. Simply provide a maximum depth, and don't include beyond it.
>
> The latter is much simpler to implement, but I think the former is a
> little nicer for the user.
Another thing I wondered after reading this patch was that it will be a
rather common "mistake" to include the same file twice, one in ~/.gitconfig
and then another in project specific .git/config, or more likely, people
start using useful ones in ~their/.gitconfig, and then the site administrator
by popular demand adding the same include in /etc/gitconfig to retroactively
cause the same file included twice for them.
Your first alternative solution should solve this case nicely as well, I
would think.
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Junio C Hamano @ 2012-01-26 20:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120126073752.GA30474@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Include directives are turned on for regular git config
> parsing (i.e., when you call git_config()), as well as for
> lookups via the "git config" program. They are not turned on
> in other cases, including:
>
> 1. Parsing of other config-like files, like .gitmodules.
> There isn't a real need, and I'd rather be conservative
> and avoid unnecessary incompatibility or confusion.
This is a good design decision, I think, but I am not sure where this "we
do not let gitmodules to honor inclusion" is implemented in this patch. I
would have expected a patch to "git-submodule.sh" that adds --no-includes
where it invokes "git config"?
> +Includes
> +~~~~~~~~
> +
> +You can include one config file from another by setting the special
> +`include.path` variable to the name of the file to be included. The
> +included file is expanded immediately, as if its contents had been
> +found at the location of the include directive.
I cannot offer better wording, but the first reaction I had to this was
"Eh, if I include a file A that includes another file B, to which config
file the '[include] path = B' directive found in file A relative to?"
Logically it should be relative to A, and I think your implementation
makes it so, but the above "as if its contents had been found at..."
sounds as if it should be the same as writing '[include] path = B' in the
original config file that included A.
By the way, I was a bit surprised that you did not have to add the source
stacking to git_config_from_file().
It was added in 924aaf3 (config.c: Make git_config() work correctly when
called recursively, 2011-06-16) to address the situation where
git_config() ends up calling git_config() recursively. My gut feeling is
that logically that issue shouldn't be limited to configuration that is
coming from file, which in turn makes me suspect that the source stacking
may be better in one level higher than git_config_from_file() so that the
ones coming from parameters could also be treated as a different kind of
source to read configuration from.
But in practice, including from the command line (i.e. -c include.path=...)
is somewhat crazy and we probably would not want to support it, so...
^ permalink raw reply
* Re: [PATCH 4/4] config: allow including config from repository blobs
From: Junio C Hamano @ 2012-01-26 21:14 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120126074208.GD30474@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> +You can also include configuration from a blob stored in your repository
> +by setting the special `include.ref` variable to the name of an object
> +containing your configuration data (in the same format as a regular
> +config file).
Hmm, the concept is surely *fun*, but is this really worth it?
With this, projects could include README that says something like this:
When working with our project, we would suggest using some tweaks
to the configuration file. For your convenience, a copy of it
already exists in the clone of your repository, and all you have
to do is to run this in your repository:
$ git config include.ref 4774acaf6657efed
We may update the set of recommended tweaks from time to time, so
watch this README file for such updates, and re-run the above command
with the updated blob object name as needed.
Note: if you are paranoid and suspect that the project might
give you trojan horse, you could inspect the recommended
tweaks first before including them, like this:
$ git cat-file -p 4774acaf6657efed
The blob will be included in the repository and the most natural way for
such a project to arrange things is to keep it together with the source
tree, perhaps in a separate hierarchy, say "dev_tools/std_gitconfig" or
something. Without the update in patches 3 and 4, the project should be
able to update the above for its participants with minimum fuss, e.g.
diff --git a/README b/README
index af31555..203d255 100644
--- a/README
+++ b/README
@@ -3,14 +3,15 @@
already exists in the clone of your repository, and all you have
to do is to run this in your repository:
- $ git config include.ref 4774acaf6657efed
+ $ cp dev_tools/std_gitconfig .git/std_gitconfig
+ $ git config include.path std_gitconfig
We may update the set of recommended tweaks from time to time, so
- watch this README file for such updates, and re-run the above command
- with the updated blob object name as needed.
+ watch "git log -p dev_tools/std_gitconfig" for such updates and
+ update your .git/std_gitconfig as needed.
Note: if you are paranoid and suspect that the project might
give you trojan horse, you could inspect the recommended
tweaks first before including them, like this:
- $ git cat-file -p 4774acaf6657efed
+ $ less dev_tools/std_gitconfig
^ permalink raw reply related
* Re: [PATCH] git-completion: workaround zsh COMPREPLY bug
From: Junio C Hamano @ 2012-01-26 22:00 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Matthieu Moy
In-Reply-To: <1327455422-22340-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> zsh adds a backslash (foo\ ) for each item in the COMPREPLY array if IFS
> doesn't contain spaces. This issue has been reported[1], but there is no
> solution yet.
> ...
> Once zsh is fixed, we should conditionally disable this workaround to
> have the same benefits as bash users.
>
> [1] http://www.zsh.org/mla/workers/2012/msg00053.html
> [2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=2e25dfb8fd38dbef0a306282ffab1d343ce3ad8d
That 2e25dfb8 only says:
Rocky Bernstein: 29135 (plus tweaks): compgen -W in bash completion
without any explanation, which is not very useful.
Do you have a bug tracker ID or something for [1] above, with which I can
amend the patch as Matthieu suggests?
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Jeff King @ 2012-01-26 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vmx9a2o23.fsf@alter.siamese.dyndns.org>
On Thu, Jan 26, 2012 at 12:42:28PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > And no, I didn't do any cycle detection. We could either do:
> >
> > 1. Record some canonical name for each source we look at (probably
> > realpath() for files, and the sha1 for refs), and don't descend
> > into already-seen sources.
> >
> > 2. Simply provide a maximum depth, and don't include beyond it.
> >
> > The latter is much simpler to implement, but I think the former is a
> > little nicer for the user.
>
> Another thing I wondered after reading this patch was that it will be a
> rather common "mistake" to include the same file twice, one in ~/.gitconfig
> and then another in project specific .git/config, or more likely, people
> start using useful ones in ~their/.gitconfig, and then the site administrator
> by popular demand adding the same include in /etc/gitconfig to retroactively
> cause the same file included twice for them.
>
> Your first alternative solution should solve this case nicely as well, I
> would think.
Agreed. I'll implement that, then.
There's a slight complication with when to clear the "I have seen this"
mark for each source. If you are interested only in breaking cycles,
then obviously you can just clear the marks as you pop the stack. But if
you want to stop repeated inclusion down different branches of the
include tree, you need to keep the marks until you're done (e.g., the
same file referenced by .git/config and ~/.gitconfig). But you do still
need to clear them, because we repeatedly call git_config with different
callback functions, and we need to re-parse each time.
I think it should be sufficient to make the marks live through
git_config(), and get cleared after that (so all of .git/config,
~/.gitconfig, and /etc/gitconfig will only load a given include once,
but another call to git_config will load it again).
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox