* Re: Symbolic refs and the git protocol?
From: Sitaram Chamarty @ 2011-09-26 14:23 UTC (permalink / raw)
To: Avi Kivity; +Cc: Git Mailing List, John Hawley
In-Reply-To: <CAMK1S_g1Co8vogBuObQVsr+nT09urYs+qifJn1X+eGrkgUQZCA@mail.gmail.com>
On Sun, Sep 25, 2011 at 7:40 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Sun, Sep 25, 2011 at 7:18 PM, Avi Kivity <avi@redhat.com> wrote:
>> On 09/25/2011 04:42 PM, Sitaram Chamarty wrote:
>>>
>>> On Sun, Sep 25, 2011 at 6:47 PM, Avi Kivity<avi@redhat.com> wrote:
>>> > With the old kernel.org setup, practically the only think I needed to
>>> > do on
>>> > the server itself is the 'git symbolic-ref' command (used to point
>>> > refs/heads/linux-next at the correct stream).
>>> >
>>> > Now it looks like kernel.org will no longer offer shell access. Is it
>>> > possible to support symbolic-ref via 'git push'?
>>>
>>> Can I assume you mean specifically for HEAD, as in 'git symbolic-ref
>>> HEAD refs/heads/some-branch'?
>>
>> No, I use them for ordinary branches, for example
>>
>> git symbolic-ref refs/heads/linux-next refs/heads/kvm-updates/3.2
>>
>> from this point on, any update to kvm-updates/3.2 will be reflected in the
>> linux-next ref.
>>
>>> Although gitolite disables shell access by design, it provides several
>>> (optionally installed) features to allow specific shell commands to be
>>> executed. One such command is "set-head", which does exactly what you
>>> ask. You run it like 'ssh git@server set-head reponame.git
>>> refs/heads/foo' and it ends up running 'git symbolic-ref HEAD
>>> refs/heads/foo' in the repo.
>>>
>>> I realise that does not answer "can it be done via git push" but I
>>> thought it might help...
>>
>> Well, if set-head can be extended a bit, it would suit me perfectly.
>
> no reason it can't; shorn of all the argument/access checking, it's a
> very simple shell script
Done.
https://github.com/sitaramc/gitolite/commit/a2fd597c51a086a0f7298c1641337faa0f296a62
I like this much better actually, so thanks for the idea.
^ permalink raw reply
* Re: subversion-perl missing
From: Michael J Gruber @ 2011-09-26 14:18 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: git
In-Reply-To: <4E80811B.4030309@gjlay.de>
Georg-Johann Lay venit, vidit, dixit 26.09.2011 15:41:
> Michael J Gruber schrieb:
>> Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
>>> Hi, I just downloaded git and built from source, version is
>>>
>>> git version 1.7.6.4
>>>
>>> I am particularly interested in git-svn, but running it I get complaints
>>>
>>> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
>>> Can't locate SVN/Core.pm in @INC (@INC contains:
>>> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>>> /usr/local/lib/perl5/site_perl/5.10.0
>>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
>>> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>>> /usr/lib/perl5/site_perl/5.10.0
>>> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
>>> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
>>> /usr/local/libexec/git-core/git-svn line 42
>>>
>>> I found out that a module like subversion-perl is missing, but installing it
>>> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
>>
>> So, where did you get your svn from? If you compiled it yourself, you
>> should rebuild it with the perl bindings. Make sure you note where you
>> install this to - you may have to adjust your PERL5LIB.
>
> Hi Michael
>
> svn identifies itself as
>
> > svn --version
>
> svn, version 1.6.2 (r37639)
> compiled Jun 19 2009, 12:21:15
>
> Copyright (C) 2000-2009 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
> This product includes software developed by CollabNet (http://www.Collab.Net/).
>
> The following repository access (RA) modules are available:
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
> - handles 'http' scheme
> - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
>
> and its installed in
>
> > which svn
>
> /usr/bin/svn
>
> > echo $PERL5LIB
>
> <empty>
>
> so looks like plain vanilla installation/build.
>
> Is "perl bindings" the "subversion-perl" package (which likes to downgrade my
> svn upon installing in yast)?
Yes, subversion-perl are the perl bindings, and if your distro has
mismatching versions of subversion and subversion perl, then they have a
problem, sorry :|
> Is it a part of SVN (couln't find it there) or of perl?
>
> > perl --version says:
>
> This is perl, v5.10.0 built for i586-linux-thread-multi
>
> Copyright 1987-2007, Larry Wall
> ...
>
>>> Thus, being no admin and no perl guy, I am stuck now and am asking here for
>>> some kind help, being very well aware that it's not a git issue but just about
>>> getting some prerequisite for git.
>>>
>>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>>> proceed.
>>>
>>> Many thanks,
>>>
>>> Johann
>
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jakub Narebski @ 2011-09-26 14:14 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Jay Soffian, Junio C Hamano,
git discussion list
In-Reply-To: <20110926110552.GA20796@sigill.intra.peff.net>
Jeff King wrote:
> On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:
> > While we are on the topic of config settings, I have often thought that
> > it would be nice for git's default settings to be set via a
> > well-commented config file, installed along with git, rather than via
> > values compiled into the code. This file and Documentation/config.txt
> > could be generated from a single source file as part of the build
> > process.
>
> I think that can be a nice piece of documentation, but there may be some
> complications. I seem to recall that there may be one or two options
> whose builtin values cannot be replicated via config (i.e., the "unset"
> state means something). But I may be misremembering.
>
> However, I'm not sure what you mean by "rather than via values compiled
> into the code". Would you somehow generate code that sets the default
> according to your master file? Would git fail to start if the file is
> missing? Or if a specific config option is missing? How would you track
> that?
There is also problem that it would screw up Git deprecation policy.
* new behavior is introduced, with a knob that defaults to off
* after some time knob starts to default to on
* git uses new feature by default
With Git creating config file with state of config variables frozen at
the state of repository creation this would be not possible.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Scott Chacon @ 2011-09-26 14:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjnnt5vg.fsf@alter.siamese.dyndns.org>
Hey,
On Fri, Sep 23, 2011 at 12:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> It just occurred to me that https://github.com/git/git repository might be
> the one you are talking about, but that repository is not even mine. The
> page at https://github.com/git says git@logicalawesome.com is its contact
> person.
>
> I _suspect_ it is set up to mirror from my k.org repository and obviously
> nothing is updated from that route for the past few weeks. It is correct
> to say "html branch in that repository is no longer updated", but I cannot
> do anything about that repository ;-).
git/git is a mirror I set up from k.org years ago for git-scm.com. I
believe you've been a collaborator on it for a while now, so you can
push to it if you'd like. The mirroring system is down since k.org
died and I've since moved it off the host I had been using to Heroku,
so I can't do the mirroring that way anymore. If you want to push to
it I'll leave it there, otherwise I'll reroot your repo to be the head
of the GitHub network instead.
^ permalink raw reply
* [PATCH] git-remote rename should match whole string when renaming remote ref directory
From: Benny Halevy @ 2011-09-26 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Benny Halevy
From: Benny Halevy <bhalevy@tonian.com>
Otherwise, with two remotes: test, test-2
git remote rename test test-
ends up with:
.git/refs/remotes/test-
.git/refs/remotes/test--2
Signed-off-by: Benny Halevy <bhalevy@tonian.com>
---
By the way, I also see the old names as empty directories in .git/refs/remotes
not sure if that's a bug or a feature... :)
Benny
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index f2a9c26..5443e71 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -571,7 +571,7 @@ static int read_remote_branches(const char *refname,
const char *symref;
strbuf_addf(&buf, "refs/remotes/%s", rename->old);
- if (!prefixcmp(refname, buf.buf)) {
+ if (!strcmp(refname, buf.buf)) {
item = string_list_append(rename->remote_branches, xstrdup(refname));
symref = resolve_ref(refname, orig_sha1, 1, &flag);
if (flag & REF_ISSYMREF)
--
1.7.7.rc3.dirty
^ permalink raw reply related
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-26 13:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E807829.7050609@drmicha.warpmail.net>
Michael J Gruber schrieb:
> Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
>> Hi, I just downloaded git and built from source, version is
>>
>> git version 1.7.6.4
>>
>> I am particularly interested in git-svn, but running it I get complaints
>>
>> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
>> Can't locate SVN/Core.pm in @INC (@INC contains:
>> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>> /usr/local/lib/perl5/site_perl/5.10.0
>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
>> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>> /usr/lib/perl5/site_perl/5.10.0
>> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
>> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
>> /usr/local/libexec/git-core/git-svn line 42
>>
>> I found out that a module like subversion-perl is missing, but installing it
>> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
>
> So, where did you get your svn from? If you compiled it yourself, you
> should rebuild it with the perl bindings. Make sure you note where you
> install this to - you may have to adjust your PERL5LIB.
Hi Michael
svn identifies itself as
> svn --version
svn, version 1.6.2 (r37639)
compiled Jun 19 2009, 12:21:15
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
and its installed in
> which svn
/usr/bin/svn
> echo $PERL5LIB
<empty>
so looks like plain vanilla installation/build.
Is "perl bindings" the "subversion-perl" package (which likes to downgrade my
svn upon installing in yast)?
Is it a part of SVN (couln't find it there) or of perl?
> perl --version says:
This is perl, v5.10.0 built for i586-linux-thread-multi
Copyright 1987-2007, Larry Wall
...
>> Thus, being no admin and no perl guy, I am stuck now and am asking here for
>> some kind help, being very well aware that it's not a git issue but just about
>> getting some prerequisite for git.
>>
>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>> proceed.
>>
>> Many thanks,
>>
>> Johann
^ permalink raw reply
* Re: subversion-perl missing
From: Michael J Gruber @ 2011-09-26 13:03 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: git
In-Reply-To: <4E8066AB.7000208@gjlay.de>
Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
> Hi, I just downloaded git and built from source, version is
>
> git version 1.7.6.4
>
> I am particularly interested in git-svn, but running it I get complaints
>
> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
> Can't locate SVN/Core.pm in @INC (@INC contains:
> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
> /usr/local/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
> /usr/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
> /usr/local/libexec/git-core/git-svn line 42
>
> I found out that a module like subversion-perl is missing, but installing it
> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
So, where did you get your svn from? If you compiled it yourself, you
should rebuild it with the perl bindings. Make sure you note where you
install this to - you may have to adjust your PERL5LIB.
> Thus, being no admin and no perl guy, I am stuck now and am asking here for
> some kind help, being very well aware that it's not a git issue but just about
> getting some prerequisite for git.
>
> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
> that in subversion.tigris.org, so that I am stuck and need some hints on how to
> proceed.
>
> Many thanks,
>
> Johann
^ permalink raw reply
* [PATCH 2/2] templates/hooks--*: don't refer to contrib hooks
From: Gerrit Pape @ 2011-09-26 12:59 UTC (permalink / raw)
To: Junio C Hamano, git
Simplify the sample post-receive hook to not refer to some location of a
contrib hook that might be installed in different locations on different
systems. Instead simply provide a sample file that does nothing just as
the post-commit sample hook.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
templates/hooks--post-receive.sample | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
index 7a83e17..5b1771f 100755
--- a/templates/hooks--post-receive.sample
+++ b/templates/hooks--post-receive.sample
@@ -2,14 +2,6 @@
#
# An example hook script for the "post-receive" event.
#
-# The "post-receive" script is run after receive-pack has accepted a pack
-# and the repository has been updated. It is passed arguments in through
-# stdin in the form
-# <oldrev> <newrev> <refname>
-# For example:
-# aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
-#
-# see contrib/hooks/ for a sample, or uncomment the next line and
-# rename the file to "post-receive".
+# To enable this hook, rename this file to "post-receive".
-#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
+: Nothing
--
1.7.6.3
^ permalink raw reply related
* [PATCH 1/2] contrib/hooks: adapt comment about Debian install location for contrib hooks
From: Gerrit Pape @ 2011-09-26 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr53b578t.fsf@alter.siamese.dyndns.org>
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Tue, Sep 20, 2011 at 12:44:18PM -0700, Junio C Hamano wrote:
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -11,11 +11,11 @@
> > # will have put this somewhere standard. You should make this
> > script
> > # executable then link to it in the repository you would like to
> > use it in.
> > # For example, on debian the hook is stored in
> > -# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
> > +# /usr/share/git-core/contrib/hooks/post-receive-email:
> > #
> > # chmod a+x post-receive-email
> > # cd /path/to/your/repository.git
> > -# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email
> > hooks/post-receive
> > +# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email
> > hooks/post-receive
>
> This one I do not have any problem with; the leading text makes it
> very
> clear that this is an example that is specific to Debian and that is
> good enough to signal readers that they may have to look elsewhere if
> they
> are on a different distribution.
>
Ok, thanks. I stripped this patch to just touch this file.
Regards, Gerrit.
contrib/hooks/post-receive-email | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index fa6d41a..ba077c1 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -11,11 +11,11 @@
# will have put this somewhere standard. You should make this script
# executable then link to it in the repository you would like to use it in.
# For example, on debian the hook is stored in
-# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# /usr/share/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
-# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
+# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
# This hook script assumes it is enabled on the central repository of a
# project, with all users pushing only to it and not between each other. It
--
1.7.6.3
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Ævar Arnfjörð Bjarmason @ 2011-09-26 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linux Kernel
In-Reply-To: <7vhb42su6f.fsf@alter.siamese.dyndns.org>
On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
> Also the following public repositories all have a copy of the v1.7.7-rc3
> tag and the master branch that the tag points at:
The 1.7.7-rc* series still doesn't compile on older Red Hat machines
because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
in it.
Could you please include that in the final 1.7.7? It would be a PITA
to have to work around that.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Christian Couder @ 2011-09-26 12:41 UTC (permalink / raw)
To: Martin Fick; +Cc: git, Christian Couder
In-Reply-To: <201109251443.28243.mfick@codeaurora.org>
On Sun, Sep 25, 2011 at 10:43 PM, Martin Fick <mfick@codeaurora.org> wrote:
> A coworker of mine pointed out to me that a simple
>
> git checkout
>
> can also take rather long periods of time > 3 mins when run
> on a repo with ~100K refs.
Are all these refs packed?
> While this is not massive like the other problem I reported,
> it still seems like it is more than one would expect. So, I
> tried an older version of git, and to my surprise/delight,
> it was much faster (.2s). So, I bisected this issue also,
> and it seems that the "offending" commit is
> 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
>
> commit 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07
> Author: Christian Couder <chriscool@tuxfamily.org>
> Date: Fri Jan 23 10:06:53 2009 +0100
>
> replace_object: add mechanism to replace objects found
> in "refs/replace/"
[...]
> Now, I suspect this commit is desirable, but I was hoping
> that perhaps a look at it might inspire someone to find an
> obvious problem with it.
I don't think there is an obvious problem with it, but it would be
nice if you could dig a bit deeper.
The first thing that could take a lot of time is the call to
for_each_replace_ref() in this function:
+static void prepare_replace_object(void)
+{
+ static int replace_object_prepared;
+
+ if (replace_object_prepared)
+ return;
+
+ for_each_replace_ref(register_replace_ref, NULL);
+ replace_object_prepared = 1;
+}
Another thing is calling replace_object_pos() repeatedly in
lookup_replace_object().
Thanks,
Christian.
^ permalink raw reply
* Re: config-file includes
From: Jeff King @ 2011-09-26 12:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: git, Michael Haggerty, Jay Soffian, Junio C Hamano,
Jakub Narebski
In-Reply-To: <CACsJy8BAVRAct=sxTpZ+b-ft1OjbY9oZG6uEXrcsTXw3CXnwSg@mail.gmail.com>
On Mon, Sep 26, 2011 at 08:45:58PM +1000, Nguyen Thai Ngoc Duy wrote:
> > You could extend this to look in refs, with something like:
> >
> > [include]
> > ref = meta:config
> >
> > which would resolve meta:config to a blob and examine it (i.e., it would
> > look at refs/heads/meta).
>
> I had something similar [1], although I disregarded worktree content
> completely.
Thanks, I had totally missed that thread.
Maybe it wasn't clear from my proposal, but I intend to disregard the
worktree entirely, too. The include.path was about including stuff from
the local filesystem, not necessarily your worktree.
> One thing about this meta thing is fsck/prune must dig in
> config file in order not to accidentally remove something config file
> refers to.
It is only a connectivity problem if you put a raw sha1 in the config.
It seems much more sensible to me to use a real ref. That solves the
fsck issue, and it makes it easier to manipulate the contents using git.
> Another thing is, what if I want to exclude certain part of the included config?
git show origin/meta:config ;# review upstream
git checkout meta origin/meta
$EDITOR config
git commit -a -m 'tweak my config based on upstream'
git config include.ref meta:config
[weeks later]
git fetch ;# oh, new config from upstream
git log -p origin/meta@{1}...origin/meta ;# looks good to me
git checkout meta
git merge origin/meta
Junio raised a good point in the thread you referenced: why is this any
better than the project just shipping a "./setup-config" script that you
run (and re-run when there is an update). Two things I can think of:
1. Carrying it in the project tree (as opposed to a separate ref) is
annoying. It bloats your project tree, and any changes you make
get tangled up in the changes you're making to the project itself.
To me, they're logically separate entities.
You can still keep a separate "meta" ref that has the setup-config
script in it, though. That wouldn't need git support at all.
But...
2. Using a script to deploy the config makes it annoying to track
changes. If I make local tweaks to what upstream suggests for the
config, I would want those tracked by git. And when upstream makes
a change, I want to do a 3-way merge. So either my script must be
clever in deploying, or I must never touch the deployed .git/config
file, and instead edit the setup-config script. Even then, how does
it handle changes in .git/config that happen naturally (e.g.,
branch config written by git).
If we had even a mechanism to include regular files, you could do
something like:
# make our local tweaked version of config
git checkout meta
$EDITOR config
git commit -a -m 'tweak config based on upstream'
# now deploy it
cp config .git/tracked-config
# and reference it
git config include.path tracked-config
# Weeks later, update and redeploy. Don't touch tracked-config in
# the meantime, as your changes will be overwritten (or copy it
# back after checkout, commit changes, then pull)
git checkout meta
git pull
cp config .git/tracked-config
which is really quite similar to the "include.ref" I showed earlier,
except you can skip the annoying "deploy" step. Which is a minor
convenience if you are actually keeping your own local config branch,
and a slightly larger one if you want to do the dangerous "just look at
origin/meta for config" thing.
> > [1] I want conditional inclusion because sometimes the rules for config
> > entries changes from version to version. For example, I have
> > pager.diff set to a script in my ~/.gitconfig. But older versions of
> > git don't understand non-boolean values and barf. I'd really like to
> > do something like:
> >
> > [include-ifdef "has-pager-scripts"]
> > path = ~/.gitconfig-pager
> >
> > where "has-pager-scripts" would be a magic flag compiled into git
> > versions that understand that config.
>
> But how far would you go with conditional expressions?
I agree it could become hairy in the general case. That's why I called
it "include-ifdef" and not "include-if". That would serve my use case. I
have no desire to support
[include-if "2 + 2 >= 4"]
-Peff
^ permalink raw reply
* subversion-perl missing
From: Georg-Johann Lay @ 2011-09-26 11:48 UTC (permalink / raw)
To: git
Hi, I just downloaded git and built from source, version is
git version 1.7.6.4
I am particularly interested in git-svn, but running it I get complaints
Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
Can't locate SVN/Core.pm in @INC (@INC contains:
/usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.0
/usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
/usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.10.0
/usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
/usr/local/libexec/git-core/git-svn line 42
I found out that a module like subversion-perl is missing, but installing it
via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
Thus, being no admin and no perl guy, I am stuck now and am asking here for
some kind help, being very well aware that it's not a git issue but just about
getting some prerequisite for git.
Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
that in subversion.tigris.org, so that I am stuck and need some hints on how to
proceed.
Many thanks,
Johann
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-26 11:05 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <4E7DB916.6010606@alum.mit.edu>
On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:
> > But once you've verified that the config looks OK and turned this option
> > on, how do you protect yourself from malicious config entering the repo
> > through a fetch?
>
> For most software projects, the user does
>
> git pull
> make
>
> daily. There is nothing that a nasty .gitconfig can do that can't be
> done more easily by a nasty Makefile (or anything else in the build
> process). The moment I pull from Junio's repository and run a build
> without having personally done a full code review first, I've given
> Junio complete pownership of my account. For projects in which I invest
> such trust, "core.useTreeConfig=true" would be a convenience that does
> not appreciably increase my risk.
True. I think it would be nice for their to be a less risky option, too,
though. Which was part of the motivation in my earlier proposal for
specifying a ref that contains config. Then you can ignore it, track
your own local config which is derived from upstream, or do the easy but
dangerous thing of just using the remote tracking ref directly.
> There are obviously config options that should not be versioned. These
> should not be stored in the tree. (Perhaps they should be stored in
> another branch, as you suggested.) But there's no need to prevent
> people from versioning *any* config options just because they shouldn't
> version *all* of them.
Do you have an example of a config option whose old value should be
respected when looking at an old version? In general, the split between
attributes and config was meant to split what is tied to a specific
version, and what should apply to all versions. We may not have followed
that in all cases, but if so, the right solution may actually be
migrating the functionality into .gitattributes.
> While we are on the topic of config settings, I have often thought that
> it would be nice for git's default settings to be set via a
> well-commented config file, installed along with git, rather than via
> values compiled into the code. This file and Documentation/config.txt
> could be generated from a single source file as part of the build
> process.
I think that can be a nice piece of documentation, but there may be some
complications. I seem to recall that there may be one or two options
whose builtin values cannot be replicated via config (i.e., the "unset"
state means something). But I may be misremembering.
However, I'm not sure what you mean by "rather than via values compiled
into the code". Would you somehow generate code that sets the default
according to your master file? Would git fail to start if the file is
missing? Or if a specific config option is missing? How would you track
that?
-Peff
^ permalink raw reply
* Re: config-file includes
From: Nguyen Thai Ngoc Duy @ 2011-09-26 10:45 UTC (permalink / raw)
To: Jeff King
Cc: git, Michael Haggerty, Jay Soffian, Junio C Hamano,
Jakub Narebski
In-Reply-To: <20110923195829.GA27677@sigill.intra.peff.net>
On Sat, Sep 24, 2011 at 5:58 AM, Jeff King <peff@peff.net> wrote:
> Here's one solution I've given a little thought to. Comments welcome.
>
> I've sometimes wanted an "include" mechanism in git config files.
> Partially to just keep things tidier, partially to avoid
> cutting-and-pasting between some repo-specific config, and partially
> because I'd like a conditional inclusion mechanism[1]. I was thinking of
> something that would be syntactically compatible but semantically
> meaningless in current versions of git, like:
>
> [include]
> path = /some/file
> path = /some/other/file
> path = ~/some/file/in/your/homedir
>
> You could extend this to look in refs, with something like:
>
> [include]
> ref = meta:config
>
> which would resolve meta:config to a blob and examine it (i.e., it would
> look at refs/heads/meta).
I had something similar [1], although I disregarded worktree content
completely. One thing about this meta thing is fsck/prune must dig in
config file in order not to accidentally remove something config file
refers to.
Another thing is, what if I want to exclude certain part of the included config?
[1] http://thread.gmane.org/gmane.comp.version-control.git/163285/focus=163288
> [1] I want conditional inclusion because sometimes the rules for config
> entries changes from version to version. For example, I have
> pager.diff set to a script in my ~/.gitconfig. But older versions of
> git don't understand non-boolean values and barf. I'd really like to
> do something like:
>
> [include-ifdef "has-pager-scripts"]
> path = ~/.gitconfig-pager
>
> where "has-pager-scripts" would be a magic flag compiled into git
> versions that understand that config.
But how far would you go with conditional expressions?
--
Duy
^ permalink raw reply
* Re: Test message to Git mailing list
From: Alexey Shumkin @ 2011-09-26 10:21 UTC (permalink / raw)
To: Shumkin Alexey; +Cc: git@vger.kernel.org
In-Reply-To: <CAEFUfsHK20GivxtJpZZnFRfiTM9TZDtbrJs==U-woV=o7gniYQ@mail.gmail.com>
Replied from claws-mail
> Test message body
>
> P.S. previous messages from this account did not delivered
^ permalink raw reply
* Test message to Git mailing list
From: Alexey Shumkin @ 2011-09-26 10:16 UTC (permalink / raw)
To: git @ vger . kernel . org; +Cc: Shumkin Alexey, zapped
From: Shumkin Alexey <Alex.Crezoff@gmail.com>
Test message body
P.S. previous messages from this account did not delivered
^ permalink raw reply
* Test message to Git mailing list
From: Shumkin Alexey @ 2011-09-26 10:08 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: zapped
Test message body
P.S. previous messages from this account did not delivered
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Thomas Rast @ 2011-09-26 9:10 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Ramkumar Ramachandra, Junio C Hamano, Francis Moreau,
Michael J Gruber, git
In-Reply-To: <alpine.DEB.2.00.1109242148570.24369@debian>
Martin von Zweigbergk wrote:
>
> If I understand correctly, [rebase --root] was introduced to solve
> exactly the same reason problem that made Francis start this thread
> -- to avoid re-applying patches that are already in $onto.
Not quite; I wrote it because at the time, there was no way to
transplant git history onto a git-svn "make empty subdir" commit for
later dcommitting. So the main point was really
> After my patches (that are not yet ready) that calculate revisions as
> "git cherry $onto $orig_head $upstream", I don't think there should be
> any need for the --root flag. The only place the flag is checked now
> (in my current work tree, that is) is when deciding how to interpret
> the remaining arguments. Although I have not tried (temporarily)
> rewriting all the test cases from
>
> git rebase --root --onto upstream branch
>
> to
>
> git rebase upstream branch
>
> , I think it should work. What do you think, Thomas?
I still think it would be natural for a user to want a way to say "all
the way back to the root commit". At least for me the "full" rebase
invocation is
git rebase --onto onto base branch
In that mindset it comes natural to replace 'base' with --root if you
want to go all the way.
Maybe I don't trust rebase enough to do what I want ;-)
> I saw that
> "--root" is also passed to the hook. Should that value be passed to
> the hook also when the old base is not explicitly a root (by "rebase
> --root"), but only implicitly so (by an $onto that is disjoint from
> $branch)?
I think I did it that way because if you use --root, the base/upstream
argument is missing, and the hook needs to know that.
If the user specifies an upstream that is disjoint from the branch
itself, the hook gets the upstream argument and can presumably work it
out from there. So you could perhaps save the hook some trouble if
you *know* that it's a disjoint rebase, but I wouldn't spend too much
time on that.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Could someone give me a copy of git internal api document?
From: Tay Ray Chuan @ 2011-09-26 8:42 UTC (permalink / raw)
To: Michael Schubert; +Cc: 徐迪, Git 邮件列表
In-Reply-To: <4E802872.2010906@elegosoft.com>
2011/9/26 Michael Schubert <mschub@elegosoft.com>:
> On 09/26/2011 09:11 AM, 徐迪 wrote:
>> I am reading code of git recently, and i want to know some internal
>> api in git, so i googled "git internal api", and result is
>> http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
>> but kernel.org was down for maintenance, and i have no idea when it
>> will recover, could someone give me a mirror url or post me a copy of
>> it?
>
> If you got the code, you should have Documentation/technical in your
> source tree.?
If you prefer the generated HTML output:
https://git-core.googlecode.com/git-history/html/technical/api-index.html
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git svn clone issues with buddypress subversion repository
From: Michael J Gruber @ 2011-09-26 8:13 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <CAM1C4G=o_Q5scdv=Jk3ou-3OjnZiukZV3nz0NJR7CTaKLbB2jw@mail.gmail.com>
Anand Kumria venit, vidit, dixit 24.09.2011 18:50:
> Hi,
>
> I'm trying:
>
> % git svn clone -s http://svn.buddypress.org/trunk/ buddypress
Please try
git svn clone -s http://svn.buddypress.org/ buddypress
By saying "-s", you make git-svn look in trunk, branches and tags
subdirs of the URL that you specify, i.e. trunk/trunk etc. with your
command line.
Or, omit "-s" if you want the trunk branch only.
> Initialized empty Git repository in
> /home/anand/Projects/wordpress/buddypress/.git/
> Using higher level of URL: http://svn.buddypress.org/trunk =>
> http://svn.buddypress.org
>
> % git --version
> git version 1.7.0.4
>
> And at the end, git svn appears to successfull complete but nothing
> has occurred. I'm successfully using 'git svn' against other
> repositories with no problem, just wondering if anyone else has come
> across this.
>
> % find buddypress
> buddypress
> buddypress/.git
> [omitted]
> buddypress/.git/svn
> buddypress/.git/svn/refs
> buddypress/.git/svn/refs/remotes
> buddypress/.git/svn/refs/remotes/git-svn
> buddypress/.git/svn/refs/remotes/trunk
> buddypress/.git/svn/refs/remotes/trunk/.rev_map.cdf35c40-ae34-48e0-9cc9-0c9da1808c22
> buddypress/.git/svn/.metadata
>
> % cat buddypress/.git/svn/.metadata
> ; This file is used internally by git-svn
> ; You should not have to edit it
> [svn-remote "svn"]
> reposRoot = http://svn.buddypress.org
> uuid = cdf35c40-ae34-48e0-9cc9-0c9da1808c22
> branches-maxRev = 5188
> tags-maxRev = 5188
Contents of .git/config would be more helpful in general. We don't need
it in this case, but looking at it might have given you the clue
(trunk/trunk).
Michael
^ permalink raw reply
* Re: Could someone give me a copy of git internal api document?
From: Michael Schubert @ 2011-09-26 7:23 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqREFHdqFGR9c_3hFJy6KxUaXLnaY9R+4K04mL42-KY-Kg@mail.gmail.com>
On 09/26/2011 09:11 AM, 徐迪 wrote:
> I am reading code of git recently, and i want to know some internal
> api in git, so i googled "git internal api", and result is
> http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
> but kernel.org was down for maintenance, and i have no idea when it
> will recover, could someone give me a mirror url or post me a copy of
> it?
If you got the code, you should have Documentation/technical in your
source tree.?
Alternate repository source:
http://repo.or.cz/w/alt-git.git
Documentation/technical on GitHub:
https://github.com/gitster/git/tree/master/Documentation/technical
^ permalink raw reply
* Could someone give me a copy of git internal api document?
From: 徐迪 @ 2011-09-26 7:11 UTC (permalink / raw)
To: Git 邮件列表
I am reading code of git recently, and i want to know some internal
api in git, so i googled "git internal api", and result is
http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
but kernel.org was down for maintenance, and i have no idea when it
will recover, could someone give me a mirror url or post me a copy of
it?
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-26 4:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Jay Soffian, git discussion list, Jakub Narebski
In-Reply-To: <7vwrcwq70k.fsf@alter.siamese.dyndns.org>
On 09/26/2011 06:09 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 09/24/2011 08:15 AM, Jeff King wrote:
>> For most software projects, the user does
>>
>> git pull
>> make
>>
>> daily. There is nothing that a nasty .gitconfig can do that can't be
>> done more easily by a nasty Makefile (or anything else in the build
>> process). The moment I pull from Junio's repository and run a build
>> without having personally done a full code review first, I've given
>> Junio complete pownership of my account.
>
> I suspect that argument is somewhat leaky.
>
> Will I be the _only_ one you will be pulling from? What if I were not so
> careful and relay a contaminated in-tree configuration file (which I would
> never use myself) to trusting downstream users like you?
I'm not saying that trusting in-tree configuration files makes sense for
everybody, and in the open-source world one must be very careful about
doing so. But I think that among closely-cooperating groups (e.g.,
personal projects, many projects in industry) (1) we don't pull from
outside the group and (2) we are forced to trust each other pretty
completely anyway. So I think that there are many sane use-cases for
giving users the opportunity to "bless" an in-tree config.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-26 4:09 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jeff King, Jay Soffian, git discussion list, Jakub Narebski
In-Reply-To: <4E7DB916.6010606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 09/24/2011 08:15 AM, Jeff King wrote:
> For most software projects, the user does
>
> git pull
> make
>
> daily. There is nothing that a nasty .gitconfig can do that can't be
> done more easily by a nasty Makefile (or anything else in the build
> process). The moment I pull from Junio's repository and run a build
> without having personally done a full code review first, I've given
> Junio complete pownership of my account.
I suspect that argument is somewhat leaky.
Will I be the _only_ one you will be pulling from? What if I were not so
careful and relay a contaminated in-tree configuration file (which I would
never use myself) to trusting downstream users like you?
>> I'm not sure it makes sense to have it in the tree at all. For
>> attributes it makes sense, because you are annotating a path at a
>> _specific_ revision. But config is often much more meta- than that.
>> Take textconv for an example. The gitattributes say "foo.pdf should use
>> the 'pdf' diff driver". That makes sense to go in a revision. But the
>> config will say "pdf files can be converted to text using
>> /usr/bin/pdftotext". That is not something that is tied to the revision
>> at all, and should exist outside of any revision. I.e., whether I am
>> doing a "git show" on the HEAD, or on some ancient commit, I would want
>> to use the same value, not whatever tool I used to convert PDFs years
>> ago.
I agree 100% with Peff on this point. What pdfviewer is configured to be
used for my repository is tied closely to what I happen to have installed
on my box that I use that repository on. This is not by accident but by
design why attributes only specify what _kind_ of payload is in the path,
and leave it up to the config to say _how_ to handle each kind of payload
on the box).
^ 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