* [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Brandon Casey @ 2008-11-03 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <-RiFxYEd9Wiq2fWX74zYGUiEwrzLeoFDb1KuG3-Xo-s@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
By default, pack-objects creates a pack file with every object specified by
the user. There are two options which can be used to exclude objects which
are accessible by the repository.
1) --incremental
This excludes any object which already exists in an accessible pack.
2) --local
This excludes any object which exists in a non-local pack.
With this patch, both arguments also cause objects which exist in packs
marked with a .keep file to be excluded. Only the --local option requires
an explicit check for the .keep file. If the user doesn't want the objects
in a pack marked with .keep to be exclude, then the .keep file should be
removed.
Additionally, this fixes the repack bug which allowed porcelain repack to
create packs which contained objects already contained in existing packs
marked with a .keep file.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
builtin-pack-objects.c | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15b80db..8be9113 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
break;
if (incremental)
return 0;
- if (local && !p->pack_local)
+ if (local && (!p->pack_local || p->pack_keep))
return 0;
}
}
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 27af5ab..5b1cd05 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Shawn O. Pearce @ 2008-11-03 20:49 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Git Mailing List, Nicolas Pitre
In-Reply-To: <LSyxMgVV7zAWRvSezvxyUc6-kz2gK6MRVKonKSf1pAmdqO-jeuMFIw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> By default, pack-objects creates a pack file with every object specified by
> the user. There are two options which can be used to exclude objects which
> are accessible by the repository.
>
> 1) --incremental
> This excludes any object which already exists in an accessible pack.
>
> 2) --local
> This excludes any object which exists in a non-local pack.
>
> With this patch, both arguments also cause objects which exist in packs
> marked with a .keep file to be excluded. Only the --local option requires
> an explicit check for the .keep file. If the user doesn't want the objects
> in a pack marked with .keep to be exclude, then the .keep file should be
> removed.
>
> Additionally, this fixes the repack bug which allowed porcelain repack to
> create packs which contained objects already contained in existing packs
> marked with a .keep file.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
This one and the one before it (2/3):
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-pack-objects.c | 2 +-
> t/t7700-repack.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 15b80db..8be9113 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
> break;
> if (incremental)
> return 0;
> - if (local && !p->pack_local)
> + if (local && (!p->pack_local || p->pack_keep))
> return 0;
> }
> }
> diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
> index 27af5ab..5b1cd05 100755
> --- a/t/t7700-repack.sh
> +++ b/t/t7700-repack.sh
> @@ -4,7 +4,7 @@ test_description='git repack works correctly'
>
> . ./test-lib.sh
>
> -test_expect_failure 'objects in packs marked .keep are not repacked' '
> +test_expect_success 'objects in packs marked .keep are not repacked' '
> echo content1 > file1 &&
> echo content2 > file2 &&
> git add . &&
> --
> 1.6.0.3.552.g12334
>
--
Shawn.
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Pieter de Bie @ 2008-11-03 20:52 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: Nicolas Pitre, Matthieu Moy, Jakub Narebski, git
In-Reply-To: <f1d2d9ca0811031235w3581f7ffnc7380b4cb488e71a@mail.gmail.com>
On 3 nov 2008, at 21:35, Thanassis Tsiodras wrote:
> Any help/advice on what to try next would be most welcome...
Perhaps this is one of the cases that can be handled by the tellme-
more extension?
http://repo.or.cz/w/git.git?a=commitdiff;h=5a9574c0100d287a4f2729dbaa64d057a5ee02e7
- Pieter
^ permalink raw reply
* Re: [BUG] git log --walk-reflogs --pretty=oneline --all
From: Johannes Schindelin @ 2008-11-03 21:01 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0810300819r373ce1eeta335a39a0fcb77df@mail.gmail.com>
Hi,
On Thu, 30 Oct 2008, Leo Razoumov wrote:
> Take a test repository that already has several commits in it, do the
> following and watch the results:
>
> sh$ git reflog expire --expire=1.second.ago --all
> sh$ git log --walk-reflogs --pretty=oneline --all
Like so?
-- snip --
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index 5b24f05..d253067 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -216,4 +216,11 @@ test_expect_success 'delete' '
'
+test_expect_success 'expired' '
+
+ git reflog expire --expire=1.second.ago --all &&
+ git log --walk-reflogs --pretty=oneline --all
+
+'
+
test_done
-- snap --
> I am using git-1.6.0.2 and that's what I get
>
> sh$ git reflog expire --expire=1.second.ago --all
> sh$ git log --walk-reflogs --pretty=oneline --all
> 60684d9df4193d91ef679173ef211275b9ad457f
> 810948facab2268139a1d4aac1368282e5ef1a9a
> 56f321d71b1bf6180977e9e3ff23836350ea2921 020
> 9e7f5cfb0fa20c44747f3d9111ccf161a2892
> 6160d0084fb8b02c3c1b5f1dd835d921d53ec86a
> 84de8b17fcab52a9c00587b81eb043c8614b37c5 68762f
> c23396e88e8ef8a1497d4f340a1bd69fa4
> 96bb86bfdd5f506ef233608c2ca8d58a13c834dd
> 287c7e907cd41dba25454d5708262e73a80c2bbb 2fcde3a98
> 09755d33f4b4093b1f2ef319f7ebe36
> 8e5b9847a38905e9d921d231c712c54720a4de5a
> 6ecfbc2bde9b771fba56d4b85ad2952b4fe0405c 0b71dc288ac2
> af4a2670e608c22e26beee272fd0 455601d6f414e400bfabb6410074b6ebee2696e0
> e78e5c0b98dfd44cc9e1e5d56a1e094d295a7c97
>
> First of all, this log's content is next to zero. Secondly, all
> reflogs are already empty and I expected no output at all.
Well, in my test there was no output at all. Just as expected.
Maybe you can come up with a test script that reproduces your claims? But
maybe your Git version is substantially different from mine? Mine is
1.6.0.2.763.g72663.
Ciao,
Dscho
^ permalink raw reply related
* git clone over HTTP failing one time out of four
From: Bryan Larsen @ 2008-11-03 21:25 UTC (permalink / raw)
To: Git Mailing List
Given the discussion about HTTP clones on October 12th, this isn't a
huge surprise, but I thought I'd throw this out there.
I've been doing a large number of clones of
http://repo.or.cz/r/kdebase.git. Approximately 1 time in 4 this fails
with an error like:
error: Unable to find fdb3... under http://repo.or.cz/r/kdebase.git
Cannot obtain needed tree fdb3...
while processing commit 3ce5...
I assume that repo.or.cz has the post hooks properly set up to do
update-server-info. Perhaps more is needed?
kdebase.git is the largest tree I could find, so the clone takes a long
time to complete, and changes are being pushed regularly.
Bryan
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-11-03 21:42 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: Matthieu Moy, Jakub Narebski, git
In-Reply-To: <f1d2d9ca0811031235w3581f7ffnc7380b4cb488e71a@mail.gmail.com>
On Mon, 3 Nov 2008, Thanassis Tsiodras wrote:
> Despair...
>
> I just tested "git push --thin"...
> Doesn't work.
>
> It still sends the complete object, not a tiny pack as it could (should).
>
> But perhaps I now understand why:
>
> I run git-gc on both the remote end and the working end (before
> changing anything,
> i.e. with both repos being in sync - "git pull" and "git push" report all OK).
> I then noticed that on the remote side, .git/objects/pack had one big pack file,
> but on the local one I have two .pack files...!
>
> I proceeded to try (many combinations of params on) git-repack in a vain attempt
> to make my local repos also have one single .pack file (presumably, it
> should be able
> to exactly mirror the remote one, since it has the same objects inside
> it!). No way...
Please stop thinking that your repository layout has anything to do with
what is actually transferred on a push. It has not.
Here's a small test that you can do locally:
mkdir repo_a
mkdir repo_b
cd repo_a
git init
seq 1000000 > data
git add data
git commit -m "initial commit"
cd ../repo_b
git init
cd ../repo_a
git push ../repo_b master:master
Here you should see a line that says:
Writing objects: 100% (3/3), 2.01 MiB, done.
Therefore 2.1 MiB were transferred. Now let's continue:
echo "foo" >> data
git add data
git commit -m "second commit"
git push ../repo_b master:master
You should get:
Writing objects: 100% (3/3), 423 bytes, done.
And this means that you even don't need the --thin switch (which is
wrong -- this has been broken before but that's another story) for the
transfer to actually send only the difference and not the whole file
again. And note that none of those repositoryes actually contain any
pack as everything is still loose objects.
> I'm at a loss as to why the two repos are having different "pack
> representation" of the same objects
That's only because those objects entered each repositories in a
different way.
> and why git-gc and git-repack fail
> to create a single pack on my working side,
Maybe you have a .keep file in .git/objects/pack/ ? If so delete it and
run 'git repack -a -d'.
> but I'm guessing that this is why "git push --thin" fails to send
> small xdeltas...
Not at all.
Please provide a complete log of your tests and maybe we could find
something.
Nicolas
^ permalink raw reply
* Re: [PATCH 4/4] Add support for 'namespace' history simplification
From: Santi Béjar @ 2008-11-03 21:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Foster, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org>
On Mon, Nov 3, 2008 at 8:43 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon, 3 Nov 2008 11:25:46 -0800
> Subject: [PATCH 4/4] Add support for 'namespace' history simplification
>
> Maybe this is mis-named, but what it does is to simplify history not by
> the contents of the tree, but whether a commit has been named (ie it's
> referred to by some branch or tag) or not.
Maybe --simplify-refs, or --simplify-overview.
>
> This makes it possible to see the relationship between different named
> commits, without actually seeing any of the details.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>
> This is the actual real meat of the logic, and it's really trivial. The
> actual code is really just a simple
>
> if (simplify-by-namespace)
> return lookup_decoration(..) ? REV_TREE_DIFFERENT : REV_TREE_SAME;
I tried it once, but I had problems simplifying the merges, and it is trivial...
Not that it matters a lot, but if you try it on master you get some
extra merges without a ref like:
373a273 (Merge git-gui 0.11.0, 2008-08-17)
f44bc33 (Sync with 1.5.6.5, 2008-08-06)
Thanks,
Santi
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-03 21:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alexander Gavrilov, git
In-Reply-To: <200811032017.47652.jnareb@gmail.com>
Le Monday 03 November 2008 20:17:47 Jakub Narebski, vous avez écrit :
> Dnia poniedziałek 3. listopada 2008 19:44, Francis Galiegue napisał:
> > Le Monday 03 November 2008 19:18:56 Jakub Narebski, vous avez écrit :
>
> > > > Well, as far as Apache is concerned, it can do:
> > > >
> > > > * basic .htpasswd authentication,
> > > > * LDAP,
> > > > * PAM,
> > > > * SSL certificate check (via mod_ssl),
> > > > * probably others.
> > > >
> > > > Plenty of possibilities.
> > > [...]
> > >
> > > Well, the question is if Apache (and other web servers used with
> > > gitweb) can do authentication based on path_info or on query-string.
> > > Because it is encoded in gitweb (via $projectroot) where to find git
> > > repositories...
> > >
> >
> > Can you expand on path_info and query-string? Keep in mind that Apache
> > has mod_rewrite, which can rewrite URLs in any way before it gets
> > actually sent to the underlying program (whether it be a CGI or
> > anything else), even badly (or mischievously).
>
> What I mean here that the following example gitweb URLs
>
> http://example.com/gitweb.cgi?p=some/project.git;a=commit;h=HEAD
> http://example.com/gitweb.cgi/some/project.git/commit/HEAD
>
> with the following gitweb configuration
>
> $projectroot = /var/scm
>
> both refer to git repository (directory) at
>
> /var/scm/some/project.git
>
> Apache (or other web server) would have to somehow decide based on URL
> that it refers to some project, and based on project and authentication
> decide whether to grant access to it.
>
>
> What is more, and what cannot be done by web server alone, is that we
> would want to not show projects which you don't have access to in the
> 'projects_list' page, i.e. at
>
> http://example.com/gitweb.cgi
>
I see the point. Note that the second URL can be converted into the first one with mod_rewrite, and probably the first to the second as well.
As to what repository is accessible to whom, does gitweb really have an internal mechanism for this? Wouldn't it be "better" is privately accessible projects were available on another website to start with?
--
^ permalink raw reply
* Re: [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-03 22:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: drafnel, git, gitster, nico
In-Reply-To: <490F5E2E.2050207@op5.se>
Andreas Ericsson wrote:
> So long as "git repack -a" still creates a mega-pack, I'm fine with
> whatever.
I don't think it will after pack-objects is taught about .keep files, and
I don't think it will _now_ if all of your packs have .keep files.
'repack -a' will call pack-objects with either '--unpack=<packfile>' for
each pack file without a .keep file, or with '--unpacked --incremental' if
there are no pack files without .keep files.
In the first case, the modifications to pack-objects that I propose
will prevent objects that exist in local packs with .keep files
from being packed into the new pack.
In the second case, the --incremental option would have done the same thing.
So this inconsistency already existed, but will now be removed in favor of
honoring .keep files.
Mega-pack creation will become an "advanced operation" along the lines of:
git rev-list --objects --all | git pack-objects
-brandon
^ permalink raw reply
* Re: [PATCH 4/4] Add support for 'namespace' history simplification
From: Linus Torvalds @ 2008-11-03 22:05 UTC (permalink / raw)
To: Santi Béjar; +Cc: Brian Foster, Junio C Hamano, Git Mailing List
In-Reply-To: <adf1fd3d0811031345j4582e109jaf95aede0f33eff7@mail.gmail.com>
On Mon, 3 Nov 2008, Santi Béjar wrote:
>
> I tried it once, but I had problems simplifying the merges, and it is trivial...
It depends on the new --simplify-merges code which does that.
> Not that it matters a lot, but if you try it on master you get some
> extra merges without a ref like:
>
> 373a273 (Merge git-gui 0.11.0, 2008-08-17)
Umm? Your point is?
That merge itself doesn't have a ref, but it's required becase there are
refs along both legs of the merge - one side has the "gitgui-0.11.0" tag,
while the other has (for example) v16.0-rc3.
> f44bc33 (Sync with 1.5.6.5, 2008-08-06)
Again, the merge doesn't have a ref, but it's needed because there are
refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).
So no, --simplify-namespace in no way guarantees that all resulting
commits will have refs pointing to them, because it also needs to return
enough of the merges to make it a real and meaningful DAG.
The one thing I note is that when you have lots and lots of refs in the
gitk output, the gitk window itself becomes very ugly. I'd love to get rid
of the black line between the ref (tag or branch name) and the circle,
because with "gitk --simplify-namespace" it ends up looking like some kind
of insane "ladder" due to all those vertical lines.
And they really aren't necessary, and it would probably be better to just
make selecting a commit highlight the whole row (and thus avoid any
ambiguity between that highlighted commit message and the circle in the
graph it goes with if you have a very wide graph).
But I can't read tcl/tk enough to even figure out where it's being
painted.
Linus
^ permalink raw reply
* Re: [PATCH] Add autoconf tests for pthreads
From: Junio C Hamano @ 2008-11-03 22:07 UTC (permalink / raw)
To: david.syzdek; +Cc: git, jnareb
In-Reply-To: <1225736068-97988-1-git-send-email-david.syzdek@acsalaska.net>
david.syzdek@acsalaska.net writes:
> +# Define PTHREAD_LIBS to the linker flag used for Pthread support and define
> +# THREADED_DELTA_SEARCH if Pthreads are available.
This may affect platforms that do have pthread library but choose not to
use threaded delta search for whatever reason by suddenly turning it on.
Which arguably may be a good thing to do, but it is a change unrelated to
porting to FreeBSD.
> +AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> + [[#include <pthread.h>]],
> + [[pthread_mutex_t test_mutex;]]
> +)])
> +${CC} -pthread conftest.c -o conftest.o > /dev/null 2>&1
> +if test $? -eq 0;then
> + PTHREAD_LIBS="-pthread"
> + THREADED_DELTA_SEARCH=YesPlease
> +else
> + ${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
Maybe I am old fashioned, but having "-library" very near the beginning of
the command line and naming the final link product (i.e. not with -c) *.o
makes me go "Huh?" If it were written like this,
$CC -o conftest$ac_exeext conftest.c -lpthread
it might have been easier to swallow. I dunno.
^ permalink raw reply
* [PATCH v3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-03 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <muOuA1nLBoljLnZoguxeFeKt-8Q-I9Y3ljvxnLWLt9KyA8HwVtMa4Q@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Objects residing in pack files that have an associated .keep file are not
supposed to be repacked into new pack files, but they are.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Whoops, white space contaminated in two spots, this one fixes it.
-brandon
t/t7700-repack.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t7700-repack.sh
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
new file mode 100755
index 0000000..7aaff0b
--- /dev/null
+++ b/t/t7700-repack.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='git repack works correctly'
+
+. ./test-lib.sh
+
+test_expect_failure 'objects in packs marked .keep are not repacked' '
+ echo content1 > file1 &&
+ echo content2 > file2 &&
+ git add . &&
+ git commit -m initial_commit &&
+ # Create two packs
+ # The first pack will contain all of the objects except one
+ git rev-list --objects --all | grep -v file2 |
+ git pack-objects pack > /dev/null &&
+ # The second pack will contain the excluded object
+ packsha1=$(git rev-list --objects --all | grep file2 |
+ git pack-objects pack) &&
+ touch -r pack-$packsha1.pack pack-$packsha1.keep &&
+ objsha1=$(git verify-pack -v pack-$packsha1.idx | head -n 1 |
+ sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
+ mv pack-* .git/objects/pack/ &&
+ git repack -A -d -l &&
+ git prune-packed &&
+ for p in .git/objects/pack/*.idx; do
+ idx=$(basename $p)
+ test "pack-$packsha1.idx" = "$idx" && continue
+ if git verify-pack -v $p | egrep "^$objsha1"; then
+ found_duplicate_object=1
+ echo "DUPLICATE OBJECT FOUND"
+ break
+ fi
+ done &&
+ test -z "$found_duplicate_object"
+'
+
+test_done
+
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re: CRLF support bugs
From: Hannu Koivisto @ 2008-11-03 22:24 UTC (permalink / raw)
To: git; +Cc: Dmitry Potapov, Jeff King
In-Reply-To: <20081103164626.GG21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
>
> core.autocrlf was exactly meant to be set globally. Basically,
> it says what end-of-line should be on your system. It is strange
> to have it different for different repositories.
Maybe so from the point of view of what it was intended for, but
since there is nothing else that could be used to control end of
line conversion on a repository basis, it certainly doesn't feel
strange to me to use it like that.
When you clone & checkout, say, the official git repository on
Windows, are you comfortable doing it with core.autocrlf globally
set to true? Maybe you know it's fine to do that so you actually
are but I'm not. How about some other random free software
mainly-Unix project you would like to develop / build under
Windows? Even if text vs. binary autodetection worked perfectly
(and it doesn't), CRLF line ends may still be the wrong choice for
some project. I recall one such project and while admittedly the
situation with it may have changed since I last used it, that
doesn't change the point.
I certainly wouldn't want to have core.autocrlf globally set to
true on Windows. No automatic conversion is a much safer default.
I only want CRLF conversion to happen with projects that have
actually considered such checkouts and if necessary have been
carefully set up to support it by using .gitattributes.
>> I also observed this problem:
>>
>> # Pretend someone does this on Unix
>> mkdir test1
>> cd test1
>> git init
>> echo "*.c crlf" > .gitattributes
>> echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c
>
> The 'crlf' attribute means that the file should be treated as 'text'
> without applying heuristic. The correct ending for text files on Unix
> is '\n', not '\r\n'. So, you put a text file with incorrect ending,
> not surprisingly it causes problems for Windows users later.
It seems to me you are looking at this, too, from the technical
point of view. Yes, given the way CRLF support is implemented, the
end result was expected. But that doesn't mean it was ok from the
user's point of view. Consider usability instead. A user makes a
mistake and adds a file from a colleague who uses Windows without
first converting it. Are you really saying "so he made a mistake,
who cares if repository users face problems"? I think it's just
very bad usability that by making such a small mistake you cause
the system to end up in a state that doesn't make any sense,
i.e. git claims you have modifications right after clone & checkout
even though you haven't modified anything.
--
Hannu
^ permalink raw reply
* Re: [PATCH 4/4] Add support for 'namespace' history simplification
From: Santi Béjar @ 2008-11-03 22:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Foster, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811031358460.3419@nehalem.linux-foundation.org>
On Mon, Nov 3, 2008 at 11:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 3 Nov 2008, Santi Béjar wrote:
>>
>> I tried it once, but I had problems simplifying the merges, and it is trivial...
>
> It depends on the new --simplify-merges code which does that.
>
>> Not that it matters a lot, but if you try it on master you get some
>> extra merges without a ref like:
>>
>> 373a273 (Merge git-gui 0.11.0, 2008-08-17)
>
> Umm? Your point is?
>
> That merge itself doesn't have a ref, but it's required becase there are
> refs along both legs of the merge - one side has the "gitgui-0.11.0" tag,
> while the other has (for example) v16.0-rc3.
>
>> f44bc33 (Sync with 1.5.6.5, 2008-08-06)
>
> Again, the merge doesn't have a ref, but it's needed because there are
> refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).
>
> So no, --simplify-namespace in no way guarantees that all resulting
> commits will have refs pointing to them, because it also needs to return
> enough of the merges to make it a real and meaningful DAG.
I thought of it as "for each ref rewrite its parents to the
independent set of refs that are ancestors". So in the case of 373a273
(Merge git-gui 0.11.0, 2008-08-17), its parents (gitgui-0.11.0 and
v1.6.0-rc3) would be the parents of ea02eef (GIT 1.6.0, 2008-08-17).
Santi
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Thanassis Tsiodras @ 2008-11-03 22:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.00.0811031611060.13034@xanadu.home>
RESOLVED!!!
Finally...
What happened was actually quite reasonable, in hindsight...
As I said in the original mail, this was what I did:
cp version7.1.tar version7.2.tar
git add version7.2.tar
git commit -m "same data as old, so git will use old blob"
echo MAGICPLACE read below...
cp /path/to/work/realNewVersion7.2.tar version7.2.tar
git add version7.2.tar
git commit -m "and now, commit the really new version, so git can xdelta"
git push --thin
The problem was solved (that is, the "git push" became optimal,
when I added a "git push" right after the MAGICPLACE mark above...
In that way, the remote repo learned about the "dummy" commit that
referenced the old blob... and when I did the subsequent "git push"
at the end, the remote side could see that it already had this "dummy"
commit to "xdelta on", and that it only needed the delta...
Originally, when I used only one "git push --thin" at the end, the remote
side didn't have the "dummy" commit, so it probably said: "I can't
apply a delta, give me the full object".
Phew.
So it seems that if you must introduce a new file that is
very similar to an existing one (in my case, a new version
of software kept in an uncompressed .tar file),
you have to do what I did above to allow for optimal "git push"es:
that is:
1. Create the new filename by just copying the old
(so the old blob is used)
2. commit
3. PUSH
4. copy the real new file
5. commit
6. PUSH.
If you omit the middle PUSH in step 3, neither "git push", nor "git push --thin"
can realize that this new file can be "incrementally built" on the remote side
(even though git-gc totally squashes it in the pack).
Thanks to all the people who responded, and especially Nicolas...
Merci!
On 11/3/08, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 3 Nov 2008, Thanassis Tsiodras wrote:
>
>> Despair...
>>
>> I just tested "git push --thin"...
>> Doesn't work.
>>
>> It still sends the complete object, not a tiny pack as it could (should).
>>
>> But perhaps I now understand why:
>>
>> I run git-gc on both the remote end and the working end (before
>> changing anything,
>> i.e. with both repos being in sync - "git pull" and "git push" report all
>> OK).
>> I then noticed that on the remote side, .git/objects/pack had one big pack
>> file,
>> but on the local one I have two .pack files...!
>>
>> I proceeded to try (many combinations of params on) git-repack in a vain
>> attempt
>> to make my local repos also have one single .pack file (presumably, it
>> should be able
>> to exactly mirror the remote one, since it has the same objects inside
>> it!). No way...
>
> Please stop thinking that your repository layout has anything to do with
> what is actually transferred on a push. It has not.
>
> Here's a small test that you can do locally:
>
> mkdir repo_a
> mkdir repo_b
> cd repo_a
> git init
> seq 1000000 > data
> git add data
> git commit -m "initial commit"
> cd ../repo_b
> git init
> cd ../repo_a
> git push ../repo_b master:master
>
> Here you should see a line that says:
>
> Writing objects: 100% (3/3), 2.01 MiB, done.
>
> Therefore 2.1 MiB were transferred. Now let's continue:
>
> echo "foo" >> data
> git add data
> git commit -m "second commit"
> git push ../repo_b master:master
>
> You should get:
>
> Writing objects: 100% (3/3), 423 bytes, done.
>
> And this means that you even don't need the --thin switch (which is
> wrong -- this has been broken before but that's another story) for the
> transfer to actually send only the difference and not the whole file
> again. And note that none of those repositoryes actually contain any
> pack as everything is still loose objects.
>
>> I'm at a loss as to why the two repos are having different "pack
>> representation" of the same objects
>
> That's only because those objects entered each repositories in a
> different way.
>
>> and why git-gc and git-repack fail
>> to create a single pack on my working side,
>
> Maybe you have a .keep file in .git/objects/pack/ ? If so delete it and
> run 'git repack -a -d'.
>
>> but I'm guessing that this is why "git push --thin" fails to send
>> small xdeltas...
>
> Not at all.
>
> Please provide a complete log of your tests and maybe we could find
> something.
>
>
> Nicolas
>
--
What I gave, I have; what I spent, I had; what I kept, I lost. -Old Epitaph
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Jakub Narebski @ 2008-11-03 22:57 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <200811031943.30033.angavrilov@gmail.com>
Nice idea, but for now certainly an RFC
On Mon, 3 Nov 2008, Alexander Gavrilov wrote:
> Some environments may require selective limiting of read access to
> repositories. While even dumb http transport supports it through .htaccess
> files, gitweb currently does not implement discretionary access control.
>
> This patch adds a configuration-contolled check that matches simple
> 'Reguire user'/'Reguire group' lines in the .htaccess files with the
Typo: Reguire -> Require
> authenticated user name. Using group authentication requires specifying
> a path to the Apache group file in the configuration.
>
> Using .htaccess has an additional bonus that the same authentication
> data can be used both for gitweb and the dumb http transport.
I'm not sure if it wouldn't be a better solution to try to ask web
server to do authentication, for example in MOD_PERL case via $r
object (if I remember correctly)...
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> ---
>
> I also created a gitosis fork that can generate the necessary files:
>
> http://repo.or.cz/w/gitosis/httpauth.git
>
> -- Alexander
>
> gitweb/INSTALL | 14 ++++++++++
> gitweb/gitweb.perl | 68 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 79 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/INSTALL b/gitweb/INSTALL
> index 26967e2..0841db6 100644
> --- a/gitweb/INSTALL
> +++ b/gitweb/INSTALL
> @@ -166,6 +166,20 @@ Gitweb repositories
> shows repositories only if this file exists in its object database
> (if directory has the magic file named $export_ok).
>
> +- Finally, it is possible to use primitive .htaccess authentication by
> + enabling the $check_htaccess variable in the config file. Gitweb
> + recognizes the following htaccess commands:
> +
> + Require user name1 name2 ... # grant access to the listed users
> + Require group group1 group2 ... # grant access to the listed groups
> + Deny from all # deny unless overridden by a Require
> +
> + Access is granted if the currently authenticated user matches one
> + of the Require lines, or if the file does not contain any of the listed
> + commands, or if .htaccess does not exist. If the file exists but cannot
> + be opened, access is denied. To use group authentication you have to
> + point $auth_group_file to the group list in Apache format.
> +
> Generating projects list using gitweb
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 63c793e..4b962c3 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -98,6 +98,12 @@ our $export_ok = "++GITWEB_EXPORT_OK++";
> # only allow viewing of repositories also shown on the overview page
> our $strict_export = "++GITWEB_STRICT_EXPORT++";
>
> +# check basic authentication rules in .htaccess
> +our $check_htaccess = 0;
> +
> +# name of the file that lists groups for htaccess check
> +our $auth_group_file = "";
> +
> # list of git base URLs used for URL to where fetch project from,
> # i.e. full URL is "$git_base_url/$project"
> our @git_base_url_list = grep { $_ ne '' } ("++GITWEB_BASE_URL++");
> @@ -397,10 +403,64 @@ sub check_head_link {
> (-l $headfile && readlink($headfile) =~ /^refs\/heads\//));
> }
>
> +# set of htaccess groups for the current user
> +our %cur_auth_groups = ();
Why it is hash, and not list? What are the keys, and what are values?
> +
> +sub find_current_groups($$) {
Style: I think we prefer not using function prototypes.
> + my ($gfile, $user) = @_;
> + return () unless $gfile && $user;
Style: you can use simple "return" which means '()' in list context,
and 'undef' in scalar context.
So it could have been written as:
+ ($gfile && $user) or return;
But I'd rather someone better in Perl decided...
> +
> + my @groups;
> + open my $gf, $gfile or return ();
> +
> + while(<$gf>) {
> + next unless /^\s*(\S+)\s*:\s*(\S.*\S)\s*$/;
> + my ($grp, $usrs) = ($1, $2);
> + push @groups, $grp if grep { $_ eq $user } split (' ', $usrs);
Wouldn't it be better to use regexp match instead of this split+grep
pipeline?
> + }
> +
> + close $gf;
> + return @groups;
> +}
> +
> +sub check_htaccess_files($) {
Style: I think we prefer not using function prototypes.
This function lack description: where it tries to find '.htaccess'
files, what does it return, etc.
> + my ($dir) = @_;
> + my $user = $cgi->remote_user() || ' ';
Why "|| ' '" here?
> +
> + while (length $dir >= length $projectroot) {
> + my $file = "$dir/.htaccess";
> + next unless -e $file;
> + open my $htf, $file or return 0;
> +
> + my $ok = 0;
> + my $need_ok = 0;
> + while (<$htf>) {
> + if (/^\s*Require\s+user\s+(\S.*\S)\s*$/i) {
> + $ok++ if grep { $_ eq $user; } split (' ', $1);
> + $need_ok++;
> + } elsif (/^\s*Require\s+group\s+(\S.*\S)\s*$/i) {
> + $ok++ if grep { $cur_auth_groups{$_}; } split(' ', $1);
> + $need_ok++;
> + } elsif (/^\s*Deny\s+from\s+all\s*$/ix) {
> + $need_ok++;
> + }
> + }
> + close $htf;
> +
> + return $ok if $need_ok;
> + last;
> + } continue {
> + $dir =~ s/\/[^\/]*$// or last;
> + }
First, this loop is IMHO very hacky and unclean, using 'continue' block
(which is not very visible on first glance) to advance through loop.
Second, while this loop might be good for _single_ repository, it is
cleanly suboptimal in the case of 'projects_list' action... unless you
want to list projects which are not accessible (I think it is the case
for accessing static pages / static files).
Third, again there is split+grep (well, this is at least consistent).
> +
> + return 1;
> +}
> +
> sub check_export_ok {
> my ($dir) = @_;
> return (check_head_link($dir) &&
> - (!$export_ok || -e "$dir/$export_ok"));
> + (!$export_ok || -e "$dir/$export_ok") &&
> + (!$check_htaccess || check_htaccess_files($dir)));
> }
O.K. Nice and clean.
>
> # process alternate names for backward compatibility
> @@ -626,6 +686,9 @@ if (defined $action) {
> }
> }
>
> +# compute authenticated groups
> +$cur_auth_groups{$_}++ for find_current_groups($auth_group_file, $cgi->remote_user());
> +
This is a bit hacky. And I am not sure if its place should be here...
> # parameters which are pathnames
> our $project = $input_params{'project'};
> if (defined $project) {
> @@ -853,8 +916,7 @@ sub validate_project {
> my $input = shift || return undef;
> if (!validate_pathname($input) ||
> !(-d "$projectroot/$input") ||
> - !check_head_link("$projectroot/$input") ||
> - ($export_ok && !(-e "$projectroot/$input/$export_ok")) ||
> + !check_export_ok("$projectroot/$input") ||
> ($strict_export && !project_in_list($input))) {
> return undef;
> } else {
And this is independent change, and should be in separate patch...
...or should be dropped (I'd have to examine this code better).
> --
> 1.6.0.3.15.gb8d36
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-03 23:33 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081103092507.GD13930@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>> >> + * 'git push --matching' does what 'git push' does today (without
>> >> + explicit configuration)
>> >
>> > I think this is reasonable even without other changes, just to override
>> > any configuration.
>>
>> I don't. Can't you say "git push $there HEAD" these days? I vaguely
>> recall that there is a way to configure push that way for people too lazy
>> to type "origin HEAD" after "git push".
>
> Yes, but it's broken in the sense that if you're in a non matching
> branch it creates it remotely.
Ok, I agree that may be a problem.
But that would not change if you only changed the default behaviour from
matching to _this branch_. You need to also teach a new mode of operation
to send-pack/receive-pack pair, which is to "update the same branch as the
one I am on locally, but do not do anything if there is no such branch
over there". I do not think we have such a mode of operation currently.
By the way, didn't we add a feature to let you say "git push $there :"
which is to do what "git push --matching $there" would do?
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Junio C Hamano @ 2008-11-03 23:34 UTC (permalink / raw)
To: Pete Harlan; +Cc: Andy Parkins, git
In-Reply-To: <1225668059-12670-1-git-send-email-pgit@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
>
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> Acked-By: Andy Parkins <andyparkins@gmail.com>
> @@ -390,8 +396,13 @@ generate_update_branch_email()
>
> echo ""
> echo $LOGBEGIN
> - git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> - git rev-list --pretty --stdin $oldrev..$newrev
> + git rev-parse --not --branches |
> + grep -v $(git rev-parse $refname) |
> + git rev-list --stdin $oldrev..$newrev |
> + while read onerev
> + do
> + eval $(printf "$showrev" $onerev)
> + done
This would make the default "non-custom" case much less efficient. If we
really cared, perhaps we could do something like this...
git rev-parse --not --branches |
grep -v "^$(git-rev-parse --not $refname)\$" |
case "$using_custom_showrev" in
yes)
git rev-list --stdin $oldrev..$newrev |
while read onerev
do
done
;;
*)
git rev-list --pretty --stdin $oldrev..newrev
;;
esac
But I suspect we do not care too much about it.
Will apply as submitted. Thanks
^ permalink raw reply
* Re: [PATCH 4/4] Add support for 'namespace' history simplification
From: Robin Rosenberg @ 2008-11-03 22:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Foster, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org>
måndag 03 november 2008 20:43:00 skrev Linus Torvalds:
>
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon, 3 Nov 2008 11:25:46 -0800
> Subject: [PATCH 4/4] Add support for 'namespace' history simplification
>
> Maybe this is mis-named, but what it does is to simplify history not by
> the contents of the tree, but whether a commit has been named (ie it's
> referred to by some branch or tag) or not.
You could reuse the decoration term here, i.e. --simplify-decorated.
-- robin
^ permalink raw reply
* Re: error: non-monotonic index
From: Peter Teoh @ 2008-11-03 23:47 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081103085105.GA13930@artemis.corp>
Thank you Pierre,
I installed a new copy, now seemingly working, thanks a lot!!!
On Mon, Nov 3, 2008 at 4:51 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> On Mon, Nov 03, 2008 at 02:32:44AM +0000, Peter Teoh wrote:
>> I git pull and got errors, then git repack and pull again......the
>> error increased....what happened?
>
> what is your local git version and the remote one ?
>
> It's likely that your local git is not aware of packs v2 which is now
> default. You want to upgrade your local git, if you're on Debian etch,
> updates have been pushed in the last dot release. Or you can even use
> git-core from backports.org which is even more up to date (1.6.sth I
> guess).
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
>
--
Regards,
Peter Teoh
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-11-04 0:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v4p2ov0zt.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
On Mon, Nov 03, 2008 at 11:33:10PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:
> >> Jeff King <peff@peff.net> writes:
> >>
> >> >> + * 'git push --matching' does what 'git push' does today (without
> >> >> + explicit configuration)
> >> >
> >> > I think this is reasonable even without other changes, just to override
> >> > any configuration.
> >>
> >> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> >> recall that there is a way to configure push that way for people too lazy
> >> to type "origin HEAD" after "git push".
> >
> > Yes, but it's broken in the sense that if you're in a non matching
> > branch it creates it remotely.
>
> Ok, I agree that may be a problem.
>
> But that would not change if you only changed the default behaviour from
> matching to _this branch_. You need to also teach a new mode of operation
> to send-pack/receive-pack pair, which is to "update the same branch as the
> one I am on locally, but do not do anything if there is no such branch
> over there". I do not think we have such a mode of operation currently.
You're right.
> By the way, didn't we add a feature to let you say "git push $there :"
> which is to do what "git push --matching $there" would do?
I don't know, I thought git push --matching $remote would be the same as
git push $remote ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] push: fix local refs update if already up-to-date
From: Clemens Buchacher @ 2008-11-04 0:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
git push normally updates local refs only after a successful push. If the
remote already has the updates -- pushed indirectly through another repository,
for example -- we forget to update local tracking refs.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
The hashcpy for new_ref is now executed more often than absolutely
necessary. But this is not a critical path, right? So I decided to keep
things simple.
builtin-send-pack.c | 11 +++++------
t/t5516-fetch-push.sh | 18 ++++++++++++++++++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 910db92..66ad492 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -224,7 +224,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
{
struct refspec rs;
- if (ref->status != REF_STATUS_OK)
+ if (ref->status != REF_STATUS_OK && ref->status != REF_STATUS_UPTODATE)
return;
rs.src = ref->name;
@@ -438,15 +438,15 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
}
else
new_sha1 = ref->peer_ref->new_sha1;
+ hashcpy(ref->new_sha1, new_sha1);
-
- ref->deletion = is_null_sha1(new_sha1);
+ ref->deletion = is_null_sha1(ref->new_sha1);
if (ref->deletion && !allow_deleting_refs) {
ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
if (!ref->deletion &&
- !hashcmp(ref->old_sha1, new_sha1)) {
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
ref->status = REF_STATUS_UPTODATE;
continue;
}
@@ -474,14 +474,13 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
!ref->deletion &&
!is_null_sha1(ref->old_sha1) &&
(!has_sha1_file(ref->old_sha1)
- || !ref_newer(new_sha1, ref->old_sha1));
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
if (ref->nonfastforward && !ref->force && !args.force_update) {
ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
continue;
}
- hashcpy(ref->new_sha1, new_sha1);
if (!ref->deletion)
new_refs++;
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index f0030ad..d211f93 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -437,6 +437,24 @@ test_expect_success 'push updates local refs' '
'
+test_expect_success 'push updates local refs (2)' '
+
+ rm -rf parent child &&
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >foo && git add foo && git commit -m one) &&
+ git clone parent child1 &&
+ git clone parent child2 &&
+ (cd child1 &&
+ echo two >foo && git commit -a -m two &&
+ git push) &&
+ (cd child2 &&
+ git pull ../child1 master &&
+ git push &&
+ test $(git rev-parse master) = $(git rev-parse remotes/origin/master))
+
+'
+
test_expect_success 'push does not update local refs on failure' '
rm -rf parent child &&
--
1.6.0.3
^ permalink raw reply related
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Jakub Narebski @ 2008-11-04 0:24 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Alexander Gavrilov, git
In-Reply-To: <200811032259.03394.fg@one2team.net>
On Mon, 3 Nov 2008, Francis Galiegue wrote:
> Le Monday 03 November 2008 20:17:47 Jakub Narebski, vous avez écrit :
> > Dnia poniedziałek 3. listopada 2008 19:44, Francis Galiegue napisał:
> > > Le Monday 03 November 2008 19:18:56 Jakub Narebski, vous avez écrit :
> > > > Well, the question is if Apache (and other web servers used with
> > > > gitweb) can do authentication based on path_info or on query-string.
> > > > Because it is encoded in gitweb (via $projectroot) where to find git
> > > > repositories...
> > > >
> > >
> > > Can you expand on path_info and query-string? Keep in mind that Apache
> > > has mod_rewrite, which can rewrite URLs in any way before it gets
> > > actually sent to the underlying program (whether it be a CGI or
> > > anything else), even badly (or mischievously).
> >
> > What I mean here that the following example gitweb URLs
> >
> > http://example.com/gitweb.cgi?p=some/project.git;a=commit;h=HEAD
> > http://example.com/gitweb.cgi/some/project.git/commit/HEAD
> >
> > with the following gitweb configuration
> >
> > $projectroot = /var/scm
> >
> > both refer to git repository (directory) at
> >
> > /var/scm/some/project.git
> >
> > Apache (or other web server) would have to somehow decide based on URL
> > that it refers to some project, and based on project and authentication
> > decide whether to grant access to it.
> >
> >
> > What is more, and what cannot be done by web server alone, is that we
> > would want to not show projects which you don't have access to in the
> > 'projects_list' page, i.e. at
> >
> > http://example.com/gitweb.cgi
> >
On the other hand we can decide to display projects for which user
doesn't have access (via HTTP authentication) for, just like
directories in *Index* directive can be shown even if they cannot be
accessed.
> I see the point. Note that the second URL can be converted into the first
> one with mod_rewrite, and probably the first to the second as well.
>
> As to what repository is accessible to whom, does gitweb really have
> an internal mechanism for this? Wouldn't it be "better" is privately
> accessible projects were available on another website to start with?
The problem is that Apache has to decide whether to deny or grant access
based on URL, not on path in filesystem. Perhaps that is possible...
As to having in gitweb mechanism for this... even now gitweb supports
bare-bones access control in terms of $export_ok. BTW you can have
not displayed but still accessible.project
--
Jakub Narebski
Poland
^ permalink raw reply
* libxdiff and patience diff
From: Pierre Habouzit @ 2008-11-04 0:40 UTC (permalink / raw)
To: davidel; +Cc: Git ML
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
Hi Davide,
I've been working tonight, trying to make libxdiff support the patience
diff algorithm, but I've totally failed, because I _thought_ I
understood what xdl_split was doing, but it appears I don't.
[ For the readers playing at home, the patience diff algorithm is
explained after my sig. ]
What I did is to:
(1) add a flag to the xenv in xdl_split that says that I want a
patience "split".
(2) Then in xdl_split, if that bit is set, I compute the longest common
subsequence from the patience diff.
(3) for each split it computes I call xdl_recs_cmp on that interval.
What I thought it would achieve is that I force some boundaries at which
libxdiff _must_ resync. Though, it seems that for some reason it doesn't
work, probably because the "ha" stuff and the boundaries absolutely
don't work the way I thought it did.
So where is the place I should do that ? I suspect it should be
partly in xprepare.c but I'm a bit stuck right now.
Any pointer on how the stuff in xprepare.c and xdiffi.c work would help
greatly, it's really not self-evident to me :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Patience diff
=============
Basically, it's an algorithm that considers line from the left file A
and the right file B.
It searches for lines that are unique *IN* A and unique *IN* B as well.
Then using a clever O(n log log n) where n is that number of lines, you
extract the longer common sequence of those lines.
This defines two splits of file A and B. For each corresponding chunks,
you then reduce the lines matching at the beginning and the end, and
reiterate the algorithm on the interior of that space, until there are
_no_ unique lines at all, and then you apply a usual diff algorithm to
generate the diff in that final section.
http://alfedenzo.livejournal.com/170301.html has a nice visual
explanation of the fact, even if it forgets about the "zones" trimming
that helps for the efficiency. It's also often wrong to generate the
stacks in the order shown on the blog, because you recurse from the max
line to the min line, which is not the natural order to work on a diff.
But that's just a matter of "inverting" all the comparisons which is
pretty obvious to do.
The difference of output can be seen on http://glandium.org/blog/?p=120
where the patience diff picks the line
"include $(topsrcdir)/config/rules.mk"
as being unique on the left and the right file, hence will use it as
sync point rather than using it in a diff.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-04 0:44 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081104000207.GA29458@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
>> Ok, I agree that may be a problem.
>>
>> But that would not change if you only changed the default behaviour from
>> matching to _this branch_. You need to also teach a new mode of operation
>> to send-pack/receive-pack pair, which is to "update the same branch as the
>> one I am on locally, but do not do anything if there is no such branch
>> over there". I do not think we have such a mode of operation currently.
>
> You're right.
Perhaps "git push --no-create"?
In hindsight, _if_ we did not have to worry about backward compatibility
at all, I might agree that the way "git push" ought to work with least
surprise would be:
* "git push" is the same as "git push origin" (override 'origin' with
branch.$current_branch.remote);
* "git push $remote" is the same as "git push --no-create $remote HEAD"
(override 'HEAD' with remote.$remote.push);
* "git push $remote $any_non_empty_refspec" does what it is told without
configuration interfering.
Current behaviour satisfies the first one and the third one. Instead of
the second, the current behaviour is:
* "git push $remote" is the same as "git push $remote :" (override ':'
with remote.$remote.push).
>> By the way, didn't we add a feature to let you say "git push $there :"
>> which is to do what "git push --matching $there" would do?
>
> I don't know, I thought git push --matching $remote would be the same as
> git push $remote ?
I think the point of "push --matching" (or an explicit "push $there :") is
so that you can defeat what you configured. For example, you could have:
[branch "master"]
remote = gitster
[remote "gitster"]
url = gitster:/pub/git/git.git/
push = HEAD
And with such a configuration, "git push" or "git push gitster" would only
push to the current branch.
You can countermand with "push gitster master next", of course, but you
would need a way to ask for the matching from the command line without
listing all the names, hence you would say "push gitster :".
I think you meant to give the --matching option the same efffect. My
comment is that you do not need a new option, as we already have that
feature.
^ 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