* 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
* Re: Finding all commits which modify a file
From: Junio C Hamano @ 2012-01-26 22:42 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Santi Béjar, Linus Torvalds, git
In-Reply-To: <30433.38.96.167.131.1327508582.squirrel@mail.lo-cal.org>
"Neal Groothuis" <ngroot@lo-cal.org> writes:
> Is there a situation where checking for TREESAMEness before simplification
> is desirable and checking after would not be?
When you do not want to see a side branch that does not contribute to the
end result at all, obviously ;-). Outside that situation, before or after
should not make a difference, I would think.
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Jeff King @ 2012-01-26 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <20120126222532.GA12855@sigill.intra.peff.net>
On Thu, Jan 26, 2012 at 05:25:32PM -0500, Jeff King wrote:
> 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).
Ugh, actually it's a little trickier. Because a git_config callback can
call git_config again, we want one set of marks per git_config
invocation, but we need to handle two simultaneous invocations. But I
think it's OK. We can stuff the data into the "git_config_include_data",
which has the proper scope.
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Jeff King @ 2012-01-26 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vipjy2nbi.fsf@alter.siamese.dyndns.org>
On Thu, Jan 26, 2012 at 12:58:25PM -0800, Junio C Hamano wrote:
> 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"?
My goal was to leave git_config_from_file untouched, so that the code in
submodule.c:gitmodules_config would work without modification. And that
works, obviously.
However, I didn't think about the fact that git-submodule.sh would be
calling git-config separately, and that is accidentally changed by my
patch. Even if we changed git-submodule to use "git config
--no-includes" that would break any third-party scripts that use "git
config" to read git-like files.
But it would be nice for callers doing "git config foo.bar" to get the
includes by default. So maybe the right rule is:
1. In C:
a. git_config() respects includes automatically.
b. other callers do not do so automatically (e.g., gitmodules via
submodule.c).
(i.e., what is implemented by this patch)
2. Callers of git-config:
a. respect includes for lookup that checks all of the "normal"
config spots in sequence: .git/config, ~/.gitconfig, and
/etc/gitconfig. These are the shell equivalent of calling
git_config().
b. when we are looking in a specific file (via GIT_CONFIG or "git
config -f"), do not respect includes (but allow --includes if
the caller chooses). This specific file may be something like
.gitmodules. Or perhaps somebody is saying "no, I really just
want to know what is in _this_ file, not what the config
ecosystem tells me in general".
And then because of 1a and 2a, most programs should Just Work without
any changes, but because of 1b and 2b, any special uses will have to
decide manually whether they would want to allow includes.
Does that make sense?
> > +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.
Yes, it is relative to A. Anything else would be insane (because it
would mean "A" has to care about who is including it).
I had a similar thought while writing it, but hoped the sentence after
(that you snipped) would make it clear. But I see the "as if..." can be
ambiguous (because it's only mostly "as if"). I started trying to write
something like "with the exception of further includes, which..." but I
think that is just getting more confusing.
How about:
The included file is processed immediately, before any other
directives from the surrounding file.
What I wanted to make clear there is the ordering, which sometimes
matters.
> 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.
Yeah. I remembered discussing that patch with Ramsay a few months ago,
and I was pleased that it just worked in this case.
> 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.
I do factor it out in the second patch. I also considered how
git_config_from_parameters doesn't share the same source marking. But it
follows a completely different code-path, as its syntax is totally
different. So there's really not much point in adding to the config_file
stack (if you had another source that could be included from a file, you
would want to mention it in the stack. But the command-line parameters
must always be the "root" of the stack, so it's sufficient to simply
have a NULL stack to mark that).
> 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...
Actually, I made sure it works, and it's in the tests. It even complains
if you use a relative path (I thought about using $PWD, but that is too
insane, as git changes the working directory behind the scenes).
The one use I think is to bundle a bunch of related config options, and
then turn them on selectively. So you _could_ do:
cat >>~/.bashrc <<-\EOF
FOO_OPTIONS="-c foo.one=1 -c foo.two=2"
EOF
# without FOO
git blah
# with FOO
git $FOO_OPTIONS blah
but with this patch, you can do:
cat >~/.gitconfig.foo <<-\EOF
[foo]
one = 1
two = 2
EOF
git -c include.path=$HOME/.gitconfig.foo blah
which to my mind is a little more natural. I don't personally plan on
using it, but it was easy to implement (in fact, I'd have to write to
disallow it, since the include magic is in the callback handler).
-Peff
^ permalink raw reply
* Re: make install rewrites source files
From: Clemens Buchacher @ 2012-01-26 22:52 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: Junio C Hamano, git
In-Reply-To: <hbf.20120123j61g@bombur.uio.no>
On Mon, Jan 23, 2012 at 09:57:51PM +0100, Hallvard Breien Furuseth wrote:
>
> 'profile-all' makes 'all' with different CFLAGS from those in
> Makefile.
How about removing the profile-all target and making it a build option
instead? To enable it, do the usual:
echo PROFILE_BUILD=YesPlease >> config.mak
echo prefix=... >> config.mak
make
su make install
In the Makefile, we would have
ifdef PROFILE_BUILD
all:
$(MAKE) CFLAGS=... -fprofile-generate ... all-one
$(MAKE) CFLAGS=... -fprofile-use ... all-one
else
all: all-one
endif
and each previous instance of 'all' replaced with 'all-one'.
Clemens
^ permalink raw reply
* Re: [PATCH 4/4] config: allow including config from repository blobs
From: Jeff King @ 2012-01-26 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbopq2mk9.fsf@alter.siamese.dyndns.org>
On Thu, Jan 26, 2012 at 01:14:46PM -0800, Junio C Hamano wrote:
> 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?
> [you could just tell people to copy the file into .git]
Yes, that does work. I liked the idea of putting it in the repo, though,
because it means you can actually _track_ the contents, including any
local changes you make.
So yeah, if you are just going to copy it once, or even periodically, it
is not that big an advantage. And the example I gave using "git tag" did
just that. But I also wanted to allow more complex things, like this:
# clone and inspect
git clone git://example.com/project.git
cd project
git show origin:devtools/std_gitconfig
# well, that looks pretty good. But I'd like to tweak something.
git checkout -b config origin
$EDITOR devtools/std_gitconfig
git commit -a -m "drop the foo option, which I hate"
# OK, let's use it now.
git config include.ref config:devtools/std_gitconfig
# Weeks pass. Somebody else updates the std_gitconfig.
git fetch
# let's inspect the changes
git checkout config
git diff @{u} -- devtools/std_gitconfig
# looks good, let's merge (not copy!) them in
git merge @{u}
This is obviously an advanced thing to be doing. But it's cool to me,
because even if you aren't working on a shared project, it is a means of
versioning your config.
-Peff
^ permalink raw reply
* Re: How to reorganize git tree
From: Jakub Narebski @ 2012-01-26 23:27 UTC (permalink / raw)
To: Ben Walton; +Cc: Alan Edwards, git
In-Reply-To: <1327604128-sup-1697@pinkfloyd.chass.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> 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.
Third-party git-subtree tool can also help here, I think.
--
Jakub Narebski
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: David Barr @ 2012-01-26 23:47 UTC (permalink / raw)
To: Scott Chacon
Cc: Brian Gernhardt, david, Ramkumar Ramachandra, git, Junio C Hamano,
Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <CAP2yMaLHK2md=MHFmV--R6rmr4q3XuZxqsb2fUszMhssx3GDoA@mail.gmail.com>
>>>> 3. What are your thoughts on lib'ifying Git so that others can call
>>>> into it using an API?
>>>
>>> This is something that everyone agrees would be a good thing. There have been many people who have started projects to do so, but they have all stalled.
>>
>> I believe libgit2 is still under active development.
>>
>> http://libgit2.github.com
>>
>
> Yes, GitHub alone actually has 2 full time employees and 1 contractor
> who are entirely dedicated to the project. It also ships with the
> GitHub for Mac product, so it's used in production by tens of
> thousands every day. If any of you want to get involved, you can check
> out the mailing list (libgit2@librelist.org) or (probably more
> usefully) the GitHub project page:
>
> https://github.com/libgit2/libgit2
>
> Open tickets, contribute code, review PRs, etc.
I'm thinking libgit2 is where git features that have stablised are formalised.
On the other hand, git-core is where features are incubated.
I would like to see fast-import ported to libgit2 when it stabilises ;)
After giving my talk, I feel compelled to reroll the historic vcs-svn series.
I'm pushing as I go to my GitHub account:
https://github.com/barrbrain/git/commits/svn-fe-reroll
--
David Barr
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Ævar Arnfjörð Bjarmason @ 2012-01-27 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120126073752.GA30474@sigill.intra.peff.net>
On Thu, Jan 26, 2012 at 08:37, Jeff King <peff@peff.net> wrote:
> This patch introduces an include directive for config files.
> It looks like:
>
> [include]
> path = /path/to/file
Very nice, I'd been meaning to resurrect my gitconfig.d series, and
this series implements a lot of the structural changes needed for that
sort of thing.
What do you think of an option (e.g. include.gitconfig_d = true) that
would cause git to look in:
/etc/gitconfig.d/*
~/.gitconfig.d/*
.git/config.d/*
As well as the usual:
/etc/gitconfig
~/.gitconfig
.git/config
It would make including third-party config easy since you could just
symlink it in, and it would follow the convention of a lot of other
programs that have a foo and a foo.d directory.
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: Jonathan Nieder @ 2012-01-27 0:10 UTC (permalink / raw)
To: David Barr
Cc: Scott Chacon, Brian Gernhardt, david, Ramkumar Ramachandra, git,
Junio C Hamano, Dmitry Ivankov
In-Reply-To: <CAFfmPPPvpbsYz9cjN6OspivCN3dbuPGOU7fyaVdnic3D4V855w@mail.gmail.com>
Hi,
David Barr wrote:
> After giving my talk, I feel compelled to reroll the historic vcs-svn series.
> I'm pushing as I go to my GitHub account:
>
> https://github.com/barrbrain/git/commits/svn-fe-reroll
Just some quick notes to save some time:
All the commits on the
git://repo.or.cz/git/jrn.git svn-fe
branch were known-good in the sense that they seemed sane enough to
build on and I do not think they need any reorganization or other
work. Maybe that could help bootstrap your efforts?
The svn-fe-pu branch includes some other patches: some optimizations
which are probably safe, the demo helper that allows "git clone
svn-alpha::<url>", some transport-helper patches to support the
latter, and so on. They are not vetted. If anyone sends patches from
that branch, or any other patch for that matter, to the list and cc-s
me, I'll be happy to review them. Here's a shortlog for convenience:
David Barr (2):
fast-import: allow object_table to grow dynamically
fast-import: allow atom_table to grow dynamically
Dmitry Ivankov (2):
Arrange a backflow pipe from fast-importer to remote helper stdin
Add alpha version of remote-svn helper
Jonathan Nieder (12):
work around ISO C incompatibility between data and function pointers
ensure initializer elements are computable at load time
enums: omit trailing comma for portability
notes: avoid C99-style comment
notes merge: eliminate OUTPUT macro
make sure initializers are computable at load time
fast-import: allow branch_table to grow dynamically
fast-import: use DIV_ROUND_UP
svn-fe: add a program that generates a notes-to-svn-revs mapping
svn-fe: do not rely on /bin/env utility to launch remote helper
svn-fe: use tabs to indent in remote helper script
remaining warnings
Test results from the svn-fe branch would be interesting. I am
particularly nervous about asking Junio to pull changes to
contrib/svn-fe that might break it at the same time as making the
interface changes needed for support of the "svnadmin dump
--incremental" format without much testing since it would be painful
to back them out. But probably that's moot, since after this long
while there still hasn't been anyone testing it.
Jonathan
^ permalink raw reply
* Re: [PATCH 1/4] config: add include directive
From: Jeff King @ 2012-01-27 0:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX5_qjC6WZsZ9hKvSR5vQJPs=jgWn-R4EnWZGVq+RvjRyg@mail.gmail.com>
On Fri, Jan 27, 2012 at 01:02:52AM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jan 26, 2012 at 08:37, Jeff King <peff@peff.net> wrote:
> > This patch introduces an include directive for config files.
> > It looks like:
> >
> > [include]
> > path = /path/to/file
>
> Very nice, I'd been meaning to resurrect my gitconfig.d series, and
> this series implements a lot of the structural changes needed for that
> sort of thing.
Yeah, that seems like a reasonable thing to do. It could make life
easier for package managers (I think the only reason it has not come up
much is that there simply isn't a lot of third-party git config).
> What do you think of an option (e.g. include.gitconfig_d = true) that
> would cause git to look in:
>
> /etc/gitconfig.d/*
> ~/.gitconfig.d/*
> .git/config.d/*
Hmm. Is that really worth having an option? I.e., why not just always
check those directories?
I could see having
[include]
dir = /path/to/gitconfig.d
for non-standard directories, though (or perhaps even simpler, the
"path" directive should auto-detect a file versus a directory. Similarly
the "ref" form could detect and expand a tree).
-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