* Re: Newbie to git
From: Junio C Hamano @ 2009-12-28 2:18 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <ecddd9ed719d3d854b2248970cdb9cdf@192.168.1.222>
<mysql.jorge@decimal.pt> writes:
> Hi Andreas,
If you are addressing Andreas, why does your mail have:
To: <git@vger.kernel.org>
Cc: <git@vger.kernel.org>
and no other addressee???
> not i have:
> /home/apache/gitprojects/mydir.git
>
> created with: git init --base mydir.git
>
> Now, inside here, what should i do to create my projects:
>
> mkdir myproject1
> cd myproject1
> git init
> touch a.txt
> git add .
> git commit -m "1st commit"
>
> am i correct or not really?
You created "myproject1" somewhere you started "mkdir" in (perhaps in
$HOME?) [*1*] and that project tracks a single file "a.txt"; you are
correct if that was what you wanted to do.
The new repository "myproject1" doesn't have any relation to the bare
repository at /home/apache/gitprojects/mydir.git/ you created earlier.
The next steps I recommend new people are:
(1) push into the public repository, by doing:
cd myproject1
git push /home/apache/gitprojects/mydir.git/ master
(2) make sure push went correctly by trying to clone from there:
cd ..
mv myproject1 myproject1.old
git clone /home/apache/gitprojects/mydir.git/ myproject1
(3) check if the clone is what you expect
diff myproject1.old/a.txt myproject1/a.txt
(4) once satisfied, remove the old one
rm -fr myproject1.old
And keep working in the myproject1 repository from there on.
[Footnote]
*1* If you started that "mkdir" somewhere else you may want to remove it
and redo that step, especially if you did so inside that bare repository
you created earlier, i.e. /home/apache/gitprojects/mydir.git directory.
You don't want to have it there.
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan @ 2009-12-28 4:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091227211557.GC609@spearce.org>
On Sun, Dec 27, 2009 at 4:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
>> Smart-http may be an attactive and easy way for people to setup git
>> hosting on shared servers whose primary web server configuration they
>> do not control. To facilite this, provide an example of how it may be
>> done.
> ...
>> + \~/public_html/cgi-bin/.htaccess:
>> ++
>> +----------------------------------------------------------------
>> +SetHandler cgi-script
>> +Options +SymLinksIfOwnerMatch
>> +SetEnv GIT_PROJECT_ROOT /home/$username/devel
>> +----------------------------------------------------------------
>
> At this point, isn't this just easier?
>
> mkdir ~/public_html/git
> vi ~/public_html/git/.htaccess
>
> SetEnv GIT_PROJECT_ROOT /home/$username/devel
> ScriptAlias / /usr/libexec/git-core/git-http-backend/
Yes, that would be perfect. But ScriptAlias is only valid in the
"server config" or "virtual host" contexts which is why the
symlink/copy executable convolutions might be needed. Can you see a
simpler way around it?
Thanks,
Tarmigan
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Tarmigan @ 2009-12-28 4:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <20091227211033.GB609@spearce.org>
On Sun, Dec 27, 2009 at 4:10 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
>> Similar to how git-daemon checks whether a repository is OK to be
>> exported, smart-http should also check. This check can be satisfied
>> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
>> may be set to export all repositories, or the individual repository
>> may have the file git-daemon-export-ok.
>>
>> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> I really think this and 1/2 should be squashed together, in which
> case you can apply my ACK to the entire thing.
Great, thanks for the ACK.
Squashing sounds good to me, I just split it so someone could verify
that the tests fail first if they want.
I've been thinking that the not_found() to a forbidden() instead.
Thoughts? I'll send out a unified patch with that change in a reply.
Thanks,
Tarmigan
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan @ 2009-12-28 4:18 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <be6fef0d0912261919m7b175c4fh532ad05a713d86c7@mail.gmail.com>
On Sat, Dec 26, 2009 at 10:19 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> -All of the following examples map 'http://$hostname/git/foo/bar.git'
>> -to '/var/www/git/foo/bar.git'.
>> +Unless otherwise noted, the following examples map
>> +'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
>
> This rephrase seems to be unrelated (to providing an example of
> serving smart http).
I think this change is related because previously all the examples
provided the same mapping. With the new example with a different
mapping, the "_All_ of the following" is no longer true.
>> @@ -144,6 +144,42 @@ ScriptAliasMatch \
>> ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
>> ----------------------------------------------------------------
>>
>> +In the following example, a repository at
>> +'/home/$username/devel/foo/bar.git' will be accessible at
>> +'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
>> +
>> +From UserDir on Apache 2.x::
>> + One way to configure 'git-http-backend' to execute and serve
>> + from a user directory (for example, on a shared hosting
>> + provider), is to have a symbolic link that points from the cgi
>> + directory to the 'git-http-backend' executable in libexec. The
>> + advantage of the symblic link is that any updates to the
>
> s/symblic/symbolic
> s/update/updates/.
Thanks.
> At this point, the user dealing with the "easy" case (ie. the user
> just symlinks the shared git installation and doesn't have to create
> symlinks in his own home directory) should have enough configuration
> details without having to read any further. So, you could tell the
> user about the symlinks to create and the configuration lines in
> .htaccess.
>
> It might also be a good idea to start a new paragraph for the "hard"
> case, for better readability.
OK, these suggestions sound good to me. I'll send out an updated patch shortly.
Thanks,
Tarmigan
^ permalink raw reply
* Re: Set the repository as it was on an earlier commit
From: Sergio Belkin @ 2009-12-28 4:19 UTC (permalink / raw)
To: git
In-Reply-To: <vpqiqbt95e7.fsf@bauges.imag.fr>
2009/12/26 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Santi Béjar <santi@agolina.net> writes:
>
>> I don't know if it is possible with porcelain commands, but with
>> plumbing you can:
>>
>> # begin with a clean working dir
>> git read-tree B
>> git commit
>> git reset --hard
>
> I guess
>
> (at the root of the repo)
>
> git checkout B -- .
> # git status if you want to check.
> git commit
>
> does this. The "-- ." part of "git checkout" asks Git to checkout the
> files, but the path limiter prevents it from updating HEAD, so the
> HEAD still points to the tip of the branch.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
Sorry but really answer given by Steven was better, because last one
omit the case when B had less files that D for example...
Thanks everyone
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
^ permalink raw reply
* [PATCH] Smart-http: check if repository is OK to export before serving it
From: Tarmigan Casebolt @ 2009-12-28 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tarmigan Casebolt
In-Reply-To: <905315640912272007i8b4904dv2b93879789b453fb@mail.gmail.com>
Similar to how git-daemon checks whether a repository is OK to be
exported, smart-http should also check. This check can be satisfied
in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
may be set to export all repositories, or the individual repository
may have the file git-daemon-export-ok.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Documentation/git-http-backend.txt | 10 +++++++++
http-backend.c | 3 ++
t/lib-httpd/apache.conf | 5 ++++
t/t5560-http-backend.sh | 39 ++++++++++++++++++++++++++++++++++-
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..c8fe08a 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -18,6 +18,11 @@ The program supports clients fetching using both the smart HTTP protcol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol.
+It verifies that the directory has the magic file
+"git-daemon-export-ok", and it will refuse to export any git directory
+that hasn't explicitly been marked for export this way (unless the
+GIT_HTTP_EXPORT_ALL environmental variable is set).
+
By default, only the `upload-pack` service is enabled, which serves
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
@@ -70,6 +75,7 @@ Apache 2.x::
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
@@ -157,6 +163,10 @@ by the invoking web server, including:
* QUERY_STRING
* REQUEST_METHOD
+The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some
diff --git a/http-backend.c b/http-backend.c
index f729488..9de85cb 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -648,6 +648,9 @@ int main(int argc, char **argv)
setup_path();
if (!enter_repo(dir, 0))
not_found("Not a git repository: '%s'", dir);
+ if (!getenv("GIT_HTTP_EXPORT_ALL") &&
+ access("git-daemon-export-ok", F_OK) )
+ forbidden("Repository not exported: '%s'", dir);
git_config(http_config, NULL);
cmd->imp(cmd_arg);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0fe3fd0..4961505 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,8 +22,13 @@ Alias /dumb/ www/
<Location /smart/>
SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+ SetEnv GIT_HTTP_EXPORT_ALL
+</Location>
+<Location /smart_noexport/>
+ SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
</Location>
ScriptAlias /smart/ ${GIT_EXEC_PATH}/git-http-backend/
+ScriptAlias /smart_noexport/ ${GIT_EXEC_PATH}/git-http-backend/
<Directory ${GIT_EXEC_PATH}>
Options None
</Directory>
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index ed034bc..126f6d5 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -23,7 +23,7 @@ config() {
}
GET() {
- curl --include "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+ curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
tr '\015' Q <out |
sed '
s/Q$//
@@ -91,6 +91,20 @@ get_static_files() {
GET $IDX_URL "$1"
}
+SMART=smart_noexport
+test_expect_success 'no export by default' '
+ log_div "no git-daemon-export-ok"
+ get_static_files "403 Forbidden"
+'
+test_expect_success 'export if git-daemon-export-ok' '
+ log_div "git-daemon-export-ok"
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ touch git-daemon-export-ok
+ ) &&
+ get_static_files "200 OK"
+'
+
+SMART=smart
test_expect_success 'direct refs/heads/master not found' '
log_div "refs/heads/master"
GET refs/heads/master "404 Not Found"
@@ -145,7 +159,6 @@ test_expect_success 'http.receivepack false' '
GET info/refs?service=git-receive-pack "403 Forbidden" &&
POST git-receive-pack 0000 "403 Forbidden"
'
-
run_backend() {
REQUEST_METHOD=GET \
GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
@@ -179,6 +192,28 @@ test_expect_success 'http-backend blocks bad PATH_INFO' '
cat >exp <<EOF
+### no git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 403 -
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 403 -
+
+### git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 200
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 200
+
### refs/heads/master
###
GET /smart/repo.git/refs/heads/master HTTP/1.1 404 -
--
1.6.6.1.g8eede.dirty
^ permalink raw reply related
* [PATCH v2] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan Casebolt @ 2009-12-28 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tarmigan Casebolt, Tay Ray Chuan, Shawn O. Pearce
In-Reply-To: <905315640912272018r1282394fh62d37b5c9e91a234@mail.gmail.com>
Smart-http may be an attactive and easy way for people to setup git
hosting on shared servers whose primary web server configuration they
do not control. To facilite this, provide an example of how it may be
done.
cc: Tay Ray Chuan <rctay89@gmail.com>
cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Looking at the
s/update/updates/
suggestion again, I decided not to make that change because I think
the original is grammical even if a little bit awkward. The first
'updates' is the noun, so the verb should be 'update' without an 's'.
I also tried rephrasing that sentence completely, but did not end up
with something better. Suggestions welcome.
Documentation/git-http-backend.txt | 31 +++++++++++++++++++++++++++++--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..fdff2d3 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -60,8 +60,8 @@ automatically by the web server.
EXAMPLES
--------
-All of the following examples map 'http://$hostname/git/foo/bar.git'
-to '/var/www/git/foo/bar.git'.
+Unless otherwise noted, the following examples map
+'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
Apache 2.x::
Ensure mod_cgi, mod_alias, and mod_env are enabled, set
@@ -144,6 +144,33 @@ ScriptAliasMatch \
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+In the following example, a repository at
+'/home/$username/devel/foo/bar.git' will be accessible at
+'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
+
+From UserDir on Apache 2.x::
+ One way to configure 'git-http-backend' to execute and serve
+ from a user directory (for example, on a shared hosting
+ provider), is to have a symbolic link named 'git' that points
+ from the cgi directory to the 'git-http-backend' executable in
+ libexec. The advantage of the symbolic link is that any updates
+ to the installed version of 'git-http-backend' also update the
+ version that is run in the userdir.
++
+----------------------------------------------------------------
+SetHandler cgi-script
+Options +SymLinksIfOwnerMatch
+SetEnv GIT_PROJECT_ROOT /home/$username/devel
+----------------------------------------------------------------
++
+Also add any needed authentication to the .htaccess file as discussed
+in earlier examples.
++
+If the web server does not follow any symbolic links, the
+'git-http-backend' executable may be copied into the cgi-bin directory
+and renamed to 'git' to acheive the same effect, but it will also need
+to be manually updated whenever a new version of 'git-http-backend' is
+installed.
ENVIRONMENT
-----------
--
1.6.6.1.g8eede.dirty
^ permalink raw reply related
* Fwd: Set the repository as it was on an earlier commit
From: Sergio Belkin @ 2009-12-28 5:18 UTC (permalink / raw)
To: git
In-Reply-To: <8c6f7f450912272019t4b9c721dt2630a8d32607013e@mail.gmail.com>
Ooops I wanted to say Santi answer was the best
---------- Forwarded message ----------
From: Sergio Belkin <sebelk@gmail.com>
Date: 2009/12/28
Subject: Re: Set the repository as it was on an earlier commit
To: git@vger.kernel.org
2009/12/26 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Santi Béjar <santi@agolina.net> writes:
>
>> I don't know if it is possible with porcelain commands, but with
>> plumbing you can:
>>
>> # begin with a clean working dir
>> git read-tree B
>> git commit
>> git reset --hard
>
> I guess
>
> (at the root of the repo)
>
> git checkout B -- .
> # git status if you want to check.
> git commit
>
> does this. The "-- ." part of "git checkout" asks Git to checkout the
> files, but the path limiter prevents it from updating HEAD, so the
> HEAD still points to the tip of the branch.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
Sorry but really answer given by Steven was better, because last one
omit the case when B had less files that D for example...
Thanks everyone
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
^ permalink raw reply
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Nguyen Thai Ngoc Duy @ 2009-12-28 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <7viqbsw2vn.fsf@alter.siamese.dyndns.org>
On 12/28/09, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > According to config.txt:
> >> core.worktree::
> >> Set the path to the working tree. The value will not be
> >> used in combination with repositories found automatically in
> >> a .git directory (i.e. $GIT_DIR is not set).
> >
> > This behavior was changed after e90fdc3 (Clean up work-tree handling -
> > 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> > 2007-12-05). If core.worktree is set, even if git_dir automatically
> > found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> > core.worktree. This makes core.worktree effective even if GIT_DIR is
> > not set, in contrast to config.txt.
> >
> > This patch makes sure it only checks for core.worktree if GIT_DIR is set.
>
>
> The work-tree area got too complicated over time for a small Panda brain
> to grasp, so let me think aloud here.
>
> ...
>
> Given these background, I am not sure the "fix" is addressing the right
> issue. What does it mean to have "core.worktree" in a configuration file,
> but that configuration file was found in a "git directory" that was found
> thorough the repository discovery process due to lack of $GIT_DIR? There
> are only two cases I can see:
>
> - The user is in the "git directory" itself, which is bare (iow,
> /srv/git/proj.git in the above example). This is not the case the
> documentation snippet you quoted is about, and I don't think your patch
> changes (nor should change) the behaviour for;
>
> - The "git directory" is a ".git/" subdirectory of some work tree, and
> the value of core.worktree may or may not match that work tree. This
> is the case the documentation talks about, and your patch addresses.
>
> For the former case, while I don't see much point, we do seem to support
> this use case (continuing the example scenario):
>
> $ unset GIT_DIR GIT_WORK_TREE
> $ cd /srv/git/proj.git
> $ git checkout -b newbranch master
>
> We find that "." is our "git directory", and through its config file, we
> know core.worktree points at /scratch/proj/, and the checkout updates
> files over there, not in /srv/git/proj.git/. While it is not obvious why
> anybody finds this useful to me, I think the behaviour makes _some_ sense,
> and I don't think your patch breaks it by changing the behaviour for this
> case [*1*].
>
> The latter, unless core.worktree matches the parent directory of the "git
> directory" in question, seems to me a misconfiguration and nothing else.
> Shouldn't it be diagnosed as an error, instead of matching the
> documentation to the letter?
I had not read that part of the documentation until Robin pointed out
and always thought core.worktree was in effect if set. I thought the
author intention was not to let core.worktree get in the way if not
requested, but given that the worktree is moved to somewhere else
already, that does not make sense as it could use parent directory of
the "git directory" as worktree (unless core.worktree matches the
parent directory as you said). Probably best fixing documentation.
--
Duy
^ permalink raw reply
* [PATCH] Documentation: always respect core.worktree if set
From: Nguyễn Thái Ngọc Duy @ 2009-12-28 5:55 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <fcaeb9bf0912272141j1def76e7v6f581636188e65f0@mail.gmail.com>
In the beginning, there was GIT_DIR environment variable. We had a very
simple semantics:
- When there is no GIT_DIR environment variable:
- if "." is a "git directory", i.e. it has the set of git things like
refs/, objects/ and HEAD, then you are working in a bare repository.
- if ./.git exists and it is a "git directory", then "." is the top of
the work tree;
- otherwise, try the parent directory of "." for the second rule
repeatedly to find the git directory and the top of the work tree.
- When there is GIT_DIR environment variable:
- $GIT_DIR is (and must be) the "git directory" and "." is the top of
the work tree.
People wanted to have a work tree that is at a location totally unrelated
to where the "git directory" and setting $GIT_DIR at runtime was the only
way to do so, but that restricted them to work only at the top of the work
tree. $GIT_WORK_TREE was invented as a way to say "this is the top of the
work tree". So that people can do something like:
$ GIT_DIR=/srv/git/proj.git GIT_WORK_TREE=/scratch/proj
$ export GIT_DIR GIT_WORK_TREE
$ cd $GIT_WORK_TREE/Documentation
$ edit; git diff; git commit -a; ...
Because the facility was meant to allow separation of "git directory" and
its associated work tree, and not meant to allow more than one work trees
sharing the same "git directory" (which does not make any sense, as there
is only one index in "git directory" that describes the state of the work
tree), it was an unnecessary nuisanse that you had to set two environment
variables. core.worktree was invented---by recording the location of the
work tree in the config file in the "git directory", the above can be made
into this:
$ GIT_DIR=/srv/git/proj.git
$ cd /scratch/proj/Documentation
$ edit; git diff; git commit -a; ...
According to the current documentation, if GIT_DIR is not set,
core.worktree is not respected, and the parent directory of the "git
directory" may be used as worktree. This case, unless core.worktree
matches the parent directory of the "git directory" in question, seems
a misconfiguration and nothing else. So remove this part of the
documentation.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Junio may find the description highly familiar :) only slightly modified
at the end
Documentation/config.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7d10a21..4b3d568 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -297,9 +297,7 @@ false), while all other repositories are assumed to be bare (bare
= true).
core.worktree::
- Set the path to the working tree. The value will not be
- used in combination with repositories found automatically in
- a .git directory (i.e. $GIT_DIR is not set).
+ Set the path to the working tree.
This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option. It can be
a absolute path or relative path to the directory specified by
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Junio C Hamano @ 2009-12-28 9:16 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1261979704-30074-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> In the beginning, there was GIT_DIR environment variable, with a very
> simple semantics:
> ...
(Omitted an explanation of how GIT_DIR and core.worktree work together).
> According to the current documentation, if GIT_DIR is not set,
> core.worktree is not respected, and the parent directory of the "git
> directory" may be used as worktree. This case, unless core.worktree
> matches the parent directory of the "git directory" in question, seems
> a misconfiguration and nothing else. So remove this part of the
> documentation.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Junio may find the description highly familiar :) only slightly modified
> at the end
I found it familiar, but I didn't see how that earlier part leads to the
conclusion in, or even gives a necessary background information for, the
last paragraph. Perhaps you omitted something in the middle that was more
relevant? If so, I would suggest omiting the earlier part, whose purpose
was to prepare readers for that middle part, as well.
And I don't think the claim your last paragraph makes is consistent with
what the patch does at all.
Removing the "it will be ignored" from the documentation is a good change
only in the sense that it makes the document closer to reality, but "it is
a misconfiguration" is not a good justification of the change.
A documentation-only patch that can be justitifed by "a misconfiguration"
claim would probably read like this:
The value of core.worktree in a ".git/config" is honored even when
it differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn
users about it. Also, drop the part of the documentation that
incorrectly claimed that we ignore such a misconfigured value.
---
core.worktree::
Set the path to the root of the work tree. Note that this
is honored even when set in a configuration file in a
".git" subdirectory of a directory, and its value differs
from the latter directory (e.g. "/path/to/.git/config" has
core.worktree set to "/different/path"), which is most
likely a misconfiguration. Running git commands in
"/path/to" directory will still use "/different/path" as
the root of the work tree and can cause great confusion to
the users.
Your earlier patch took a different approach to the misconfiguration. "It
is an error, so we silently _ignore_". It is a valid thing to say, but
the "silently" part is not friendly to the user and we would probably want
to diagnose and warn. That is what I originally meant.
^ permalink raw reply
* Re: [Squash PATCH] fprintf(stderr, "Warning...") -> warning("...")
From: Junio C Hamano @ 2009-12-28 9:24 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261651279-29041-1-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> ---
> transport-helper.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> This fixes the small nit about fprintf(stderr, "Warning: ") by using
> warning() API.
>
> It can be appiled on top of "Support remote helpers implementing smart
> transports" or squashed to it.
Thanks; will squash but with two minor touch-ups:
- warning() adds its own terminating LF so we need to drop it from the caller;
- being able to grep for an error/warning message is more important than
keeping the source line strictly shorter than 80-columns.
> diff --git a/transport-helper.c b/transport-helper.c
> index 55427df..8c8ca8e 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -420,11 +420,10 @@ static int process_connect_service(struct transport *transport,
> if (strcmp(name, exec)) {
> r = set_helper_option(transport, "servpath", exec);
> if (r > 0)
> - fprintf(stderr, "Warning: Setting remote service path "
> - "not supported by protocol.\n");
> + warning("Setting remote service path not supported "
> + "by protocol.\n");
> else if (r < 0)
> - fprintf(stderr, "Warning: Invalid remote service "
> - "path.\n");
> + warning("Invalid remote service path.\n");
> }
>
> if (data->connect)
> --
> 1.6.6.3.gaa2e1
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #05; Mon, 28)
From: Junio C Hamano @ 2009-12-28 9:57 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
--------------------------------------------------
[Graduated to "master"]
* sr/vcs-helper (2009-12-07) 14 commits
(merged to 'next' on 2009-12-07 at 8f041bc)
+ tests: handle NO_PYTHON setting
(merged to 'next' on 2009-12-03 at e45b562)
+ builtin-push: don't access freed transport->url
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jk/1.7.0-status (2009-12-11) 16 commits
(merged to 'next' on 2009-12-24 at e9929b3)
+ status/commit: do not suggest "reset HEAD <path>" while merging
+ commit/status: "git add <path>" is not necessarily how to resolve
+ commit/status: check $GIT_DIR/MERGE_HEAD only once
(merged to 'next' on 2009-12-08 at 9b57d84)
+ t7508-status: test all modes with color
+ t7508-status: status --porcelain ignores relative paths setting
(merged to 'next' on 2009-12-07 at 7723acf)
+ status: reduce duplicated setup code
+ status: disable color for porcelain format
(merged to 'next' on 2009-12-05 at 44dcefd)
+ status -s: obey color.status
+ builtin-commit: refactor short-status code into wt-status.c
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
--------------------------------------------------
[New Topics]
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
* js/filter-branch-prime (2009-12-15) 1 commit
- filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
- tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
- octopus: remove dead code
- octopus: reenable fast-forward merges
- octopus: make merge process simpler to follow
* il/exec-error-report (2009-12-24) 2 commits
- Improve transport helper exec failure reporting
- Report exec errors from run-command
--------------------------------------------------
[Cooking]
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2009-12-24 at ff4d1d4)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
* bg/maint-add-all-doc (2009-12-07) 4 commits
- squash! rm documentation--also mention add-u where we mention commit-a
- git-rm doc: Describe how to sync index & work tree
- git-add/rm doc: Consistently back-quote
- Documentation: 'git add -A' can remove files
I didn't like the existing documentation for "add -u" myself (especially
because I wrote the initial version) and this neatly fix it as well.
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-01) 3 commits
(merged to 'next' on 2009-12-07 at f08d447)
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-14) 22 commits
(merged to 'next' on 2009-12-24 at 1fa9ff3)
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[Ejected]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong.
* jc/grep-full-tree (2009-11-24) 1 commit
. grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
* cc/reset-more (2009-12-08) 6 commits
. Documentation: reset: add some tables to describe the different options
. Documentation: reset: describe new "--keep-local-changes" option
. reset: add test cases for "--keep-local-changes" option
. reset: add option "--keep-local-changes" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
The documentation is much clearer than the previous round in describing
what it does, but I find it a bit unclear in describing what it is _good_
for (iow, scenarios and use cases).
Breaks 'pu' and does not pass test on its own yet.
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-28 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wcnx2lq.fsf@alter.siamese.dyndns.org>
> If you are addressing Andreas, why does your mail have:
>
> To: <git@vger.kernel.org>
> Cc: <git@vger.kernel.org>
>
> and no other addressee???
My error, sorry :)
> You created "myproject1" somewhere you started "mkdir" in (perhaps in
> $HOME?) [*1*] and that project tracks a single file "a.txt"; you are
> correct if that was what you wanted to do.
>
> The new repository "myproject1" doesn't have any relation to the bare
> repository at /home/apache/gitprojects/mydir.git/ you created earlier.
> The next steps I recommend new people are:
>
> (1) push into the public repository, by doing:
>
> cd myproject1
> git push /home/apache/gitprojects/mydir.git/ master
>
> (2) make sure push went correctly by trying to clone from there:
>
> cd ..
> mv myproject1 myproject1.old
> git clone /home/apache/gitprojects/mydir.git/ myproject1
>
> (3) check if the clone is what you expect
>
> diff myproject1.old/a.txt myproject1/a.txt
>
> (4) once satisfied, remove the old one
>
> rm -fr myproject1.old
>
> And keep working in the myproject1 repository from there on.
Thank you, i understood, i believe i really did. did that test and it's
OK.
But let me reask in another way:
I want to setup the git server, to accept new branch's created in a remote
place that will be push'ed to it, please correct me, 'cause i'm doing
something wrong and i don't know what yet.
- setup git server to run with:
/usr/lib/git-core/git-daemon --reuseaddr --syslog --export-all
--enable=receive-pack --verbose --base-path=/home/apache/gitprojects
- created directory /home/apache/gitprojects
- git init --bare /home/apache/gitprojects
- what will be my link on the remote? "git://192.168.1.206" just?
- From now on, how can I have access to push projects that exist on other
machine?
Sorry for the questions... they are newbie!
Jorge,
^ permalink raw reply
* [PATCH] Allow git to use any HTTP authentication method.
From: Lénaïc Huard @ 2009-12-28 10:54 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 1113 bytes --]
Hello,
As I need to access some of my git repositories behind a corporate company
firewall, I use the http access method. And, as I don't want my passwords to be
sent in clear text over the network, I have configured my web server to use «
Digest » authentication instead of the old « Basic » authentication.
This authentication method is now well handled by modern software.
Unfortunately, current git version only handles « Basic » authentication.
When attempting to access my repository, I get the following error message:
error: The requested URL returned error: 401 while accessing
http://XXX@YYY.ZZ/test.git/info/refs
The web server, on its side, has refused the transaction because of the wrong
authentication method used:
Digest: client used wrong authentication scheme `Basic': /test.git/info/refs
The attached patch makes git configure libcurl to negotiate the most suitable
HTTP authentication method.
Thanks to that patch, I manage to clone and fetch my git repository hosted on
my web server requesting an authentication through the « Digest » method.
Lénaïc.
[-- Attachment #2: 0001-Allow-git-to-use-any-HTTP-authentication-method.patch --]
[-- Type: text/x-patch, Size: 966 bytes --]
From 2acab3ae894c3ea835279a864e654e1c5e956e80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?L=C3=A9na=C3=AFc=20Huard?= <lenaic@lhuard.fr.eu.org>
Date: Mon, 28 Dec 2009 10:52:35 +0100
Subject: [PATCH] Allow git to use any HTTP authentication method.
By default, libcurl performs "Basic" HTTP authentication.
This method transmits passwords in clear text.
libcurl needs some settings in order to use a safest HTTP authentication
method like "Digest" for example.
---
http.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index ed6414a..2d9df76 100644
--- a/http.c
+++ b/http.c
@@ -233,6 +233,10 @@ static CURL *get_curl_handle(void)
init_curl_http_auth(result);
+#if LIBCURL_VERSION_NUM >= 0x070a06
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+#endif
+
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
if (has_cert_password())
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Martin Storsjö @ 2009-12-28 12:09 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: git
In-Reply-To: <200912281154.09442.lenaic@lhuard.fr.eu.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 582 bytes --]
Hi Lénaïc,
On Mon, 28 Dec 2009, Lénaïc Huard wrote:
> The attached patch makes git configure libcurl to negotiate the most suitable
> HTTP authentication method.
> Thanks to that patch, I manage to clone and fetch my git repository hosted on
> my web server requesting an authentication through the « Digest » method.
Something similar has already been queued for inclusion, and is available
in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
The patch available there requires you to set http.authAny for the libcurl
option to be enabled.
// Martin
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Tay Ray Chuan @ 2009-12-28 12:12 UTC (permalink / raw)
To: Martin Storsjö; +Cc: Lénaïc Huard, git
In-Reply-To: <alpine.DEB.2.00.0912281406210.5582@cone.home.martin.st>
Hi,
On Mon, Dec 28, 2009 at 8:09 PM, Martin Storsjö <martin@martin.st> wrote:
> Hi Lénaďc,
>
> On Mon, 28 Dec 2009, Lénaďc Huard wrote:
>
>> The attached patch makes git configure libcurl to negotiate the most suitable
>> HTTP authentication method.
>> Thanks to that patch, I manage to clone and fetch my git repository hosted on
>> my web server requesting an authentication through the « Digest » method.
>
> Something similar has already been queued for inclusion, and is available
> in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
> The patch available there requires you to set http.authAny for the libcurl
> option to be enabled.
...or setting the environment variable GIT_HTTP_AUTH_ANY.
(by the way, Martin was referring to setting http.authAny in your git
configuration.)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Matthieu Moy @ 2009-12-28 12:37 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: git
In-Reply-To: <200912281154.09442.lenaic@lhuard.fr.eu.org>
Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
> The attached patch makes git configure libcurl to negotiate the most suitable
> HTTP authentication method.
Thanks for your contribution.
Read other people's reply about the need for this patch.
Other than that, please read git/Documentation/SubmittingPatches in
Git's source code. In short: inline patches, don't attach them, and
use Signed-Off-By to acknowledge that your patch can be legally
included in Git's official version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Need some help with git rebase
From: Sylvain RABOT @ 2009-12-28 13:33 UTC (permalink / raw)
To: git
Hello everybody,
I'm trying to backport a feature branch which is based on the master
branch into another branch also based on master but older :
a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o 12.72.1
This is what I would like :
a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1
And this is what I get with git rebase --onto 12.72.1 master feature
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1
Can you exlain to me what I need to do to get what I expect.
Best regards.
--
Sylvain
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Shawn O. Pearce @ 2009-12-28 15:37 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Martin Storsj?, L?na?c Huard, git
In-Reply-To: <be6fef0d0912280412w58401f10n972f9198144cd580@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Mon, Dec 28, 2009 at 8:09 PM, Martin Storsj?? <martin@martin.st> wrote:
> > On Mon, 28 Dec 2009, L??na??c Huard wrote:
> >
> >> The attached patch makes git configure libcurl to negotiate the most suitable
> >> HTTP authentication method.
...
> > Something similar has already been queued for inclusion, and is available
> > in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
> > The patch available there requires you to set http.authAny for the libcurl
> > option to be enabled.
Uh, stupid question, but why must we enable this option? I don't
have to enable something in my browser before I use digest auth to
visit a website, why do I need to enable it in git?
How does one use git clone with an http:// URL with digest
authentication? Its not obvious to the user that you would need
to first export an obtuse environment variable to get something
that should Just Work(tm).
Yes, I realize you may need to perform an extra HTTP request to
start the transaction, but why aren't we doing that? Isn't it only
1 additional request to discover the desired authentication method?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Martin Storsjö @ 2009-12-28 15:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tay Ray Chuan, L?na?c Huard, git
In-Reply-To: <20091228153701.GA2252@spearce.org>
On Mon, 28 Dec 2009, Shawn O. Pearce wrote:
> Uh, stupid question, but why must we enable this option? I don't
> have to enable something in my browser before I use digest auth to
> visit a website, why do I need to enable it in git?
>
> How does one use git clone with an http:// URL with digest
> authentication? Its not obvious to the user that you would need
> to first export an obtuse environment variable to get something
> that should Just Work(tm).
>
> Yes, I realize you may need to perform an extra HTTP request to
> start the transaction, but why aren't we doing that? Isn't it only
> 1 additional request to discover the desired authentication method?
Initially when I added support for this, curl sessions weren't reused, so
every single request had to be duplicated if authentication was used,
adding quite a bit of overhead.
Now that sessions are reused properly, I tend to agree that this should be
enabled automatically.
Any other opinions on this, Tay or Junio?
Should I send in a new patch that removes the http.authAny option and
always enables this, or send a rewritten version of the patch that already
is in 'next'?
// Martin
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Shawn O. Pearce @ 2009-12-28 15:53 UTC (permalink / raw)
To: Martin Storsj?; +Cc: Tay Ray Chuan, L?na?c Huard, git
In-Reply-To: <alpine.DEB.2.00.0912281745540.5582@cone.home.martin.st>
Martin Storsj? <martin@martin.st> wrote:
> Initially when I added support for this, curl sessions weren't reused, so
> every single request had to be duplicated if authentication was used,
> adding quite a bit of overhead.
>
> Now that sessions are reused properly, I tend to agree that this should be
> enabled automatically.
Oh, that makes sense, thanks for the explanation.
> Should I send in a new patch that removes the http.authAny option and
> always enables this, or send a rewritten version of the patch that already
> is in 'next'?
I'm not Junio, but I would suggest sending in a new patch series,
and asking Junio politely to revert the one that is currently in
next before merging in the new series.
If we really are killing http.authAny before it hits master, there
is no reason for it to appear in the final project history.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Shawn O. Pearce @ 2009-12-28 15:59 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <905315640912272007i8b4904dv2b93879789b453fb@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> wrote:
> On Sun, Dec 27, 2009 at 4:10 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> >> Similar to how git-daemon checks whether a repository is OK to be
> >> exported, smart-http should also check. ?This check can be satisfied
> >> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> >> may be set to export all repositories, or the individual repository
> >> may have the file git-daemon-export-ok.
...
> I've been thinking that the not_found() to a forbidden() instead.
Oh. Interesting question.
Because you can't resolve the access error by authenticating to
the server, we may actually want to just return not_found() here
with a message in the log of "Repository not exported: '%s'".
That would mirror the behavior of git-daemon.
--
Shawn.
^ permalink raw reply
* [PATCH RESEND] git gui: Use git diff --submodule when available
From: Jens Lehmann @ 2009-12-28 16:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano
Changed the use of submodule summary to diff --submodule because the
implementation in C is much faster than the submodule script. Also a test
has been added to make sure that the underlying git supports the diff
option --submodule (which was introduced in 1.6.6).
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-gui/lib/diff.tcl | 21 +++++++++------------
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/git-gui/lib/diff.tcl b/git-gui/lib/diff.tcl
index bd5d189..0623e3e 100644
--- a/git-gui/lib/diff.tcl
+++ b/git-gui/lib/diff.tcl
@@ -281,6 +281,14 @@ proc start_show_diff {cont_info {add_opts {}}} {
}
}
+ if {[git-version >= "1.6.6"]} {
+ if {[string match {160000 *} [lindex $s 2]]
+ || [string match {160000 *} [lindex $s 3]]} {
+ set is_submodule_diff 1
+ lappend cmd --submodule
+ }
+ }
+
lappend cmd -p
lappend cmd --no-color
if {$repo_config(gui.diffcontext) >= 1} {
@@ -296,16 +304,6 @@ proc start_show_diff {cont_info {add_opts {}}} {
lappend cmd $path
}
- if {[string match {160000 *} [lindex $s 2]]
- || [string match {160000 *} [lindex $s 3]]} {
- set is_submodule_diff 1
- if {$w eq $ui_index} {
- set cmd [list submodule summary --cached -- $path]
- } else {
- set cmd [list submodule summary --files -- $path]
- }
- }
-
if {[catch {set fd [eval git_read --nice $cmd]} err]} {
set diff_active 0
unlock_index
@@ -387,8 +385,7 @@ proc read_diff {fd cont_info} {
}
} elseif {$is_submodule_diff} {
if {$line == ""} continue
- if {[regexp {^\* } $line]} {
- set line [string replace $line 0 1 {Submodule }]
+ if {[regexp {^Submodule } $line]} {
set tags d_@
} else {
set op [string range $line 0 2]
--
1.6.6.rc2.274.g2cee7
^ permalink raw reply related
* Re: Newbie to git
From: Eugene Sajine @ 2009-12-28 16:51 UTC (permalink / raw)
To: mysql.jorge; +Cc: Junio C Hamano, git
In-Reply-To: <7a0ae9cb57a1bc55653872ab254ea922@192.168.1.222>
On Mon, Dec 28, 2009 at 5:34 AM, <mysql.jorge@decimal.pt> wrote:
>> If you are addressing Andreas, why does your mail have:
>>
>> To: <git@vger.kernel.org>
>> Cc: <git@vger.kernel.org>
>>
>> and no other addressee???
>
> My error, sorry :)
>
>> You created "myproject1" somewhere you started "mkdir" in (perhaps in
>> $HOME?) [*1*] and that project tracks a single file "a.txt"; you are
>> correct if that was what you wanted to do.
>>
>> The new repository "myproject1" doesn't have any relation to the bare
>> repository at /home/apache/gitprojects/mydir.git/ you created earlier.
>> The next steps I recommend new people are:
>>
>> (1) push into the public repository, by doing:
>>
>> cd myproject1
>> git push /home/apache/gitprojects/mydir.git/ master
>>
>> (2) make sure push went correctly by trying to clone from there:
>>
>> cd ..
>> mv myproject1 myproject1.old
>> git clone /home/apache/gitprojects/mydir.git/ myproject1
>>
>> (3) check if the clone is what you expect
>>
>> diff myproject1.old/a.txt myproject1/a.txt
>>
>> (4) once satisfied, remove the old one
>>
>> rm -fr myproject1.old
>>
>> And keep working in the myproject1 repository from there on.
>
> Thank you, i understood, i believe i really did. did that test and it's
> OK.
> But let me reask in another way:
>
> I want to setup the git server, to accept new branch's created in a remote
> place that will be push'ed to it, please correct me, 'cause i'm doing
> something wrong and i don't know what yet.
>
> - setup git server to run with:
> /usr/lib/git-core/git-daemon --reuseaddr --syslog --export-all
> --enable=receive-pack --verbose --base-path=/home/apache/gitprojects
>
> - created directory /home/apache/gitprojects
> - git init --bare /home/apache/gitprojects
>
> - what will be my link on the remote? "git://192.168.1.206" just?
> - From now on, how can I have access to push projects that exist on other
> machine?
>
> Sorry for the questions... they are newbie!
> Jorge,
Your /home/apache/gitprojects is a folder where your git repositories
are supposed to be placed.
Your Git repository = your project.
By running a git daemon the way you do - you say that you are going to
serve all repositories from /home/apache/gitprojects.
Bare repo = repo without working copy - the one which contains only
history and git objects (imagine it to be only .git folder from normal
repo) Therefore for bare repos there is a naming convention so they
have .git extension, while normal repo doesn't. So, myProject.git is
server based bare repo, while myProject is a local repo.
Finally you have /home/apache/gitprojects/myProject.git
The URL to clone from there will be - should be shown to you by CGIT
if you have everything correctly set up
git://192.168.1.206/myProject.git
Hope that helps,
Eugene
^ 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