* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 8:22 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vfxj3vos2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> But in other cases, it silently gives you the wrong answer. For
>> example, consider a history like:
>>
>> C--D
>> /
>> A--B
>> \
>> E--F
>>
>> now let's suppose I have everything except 'E'. If I ask for
>>
>> git rev-list F..D
>>
>> then it will not realize that A and B are uninteresting, and I will get
>> A-B-C-D. I think it is much better for git to complain loudly that it
>> could not compute the correct answer.
>
> Fair enough. I think we can resurrect the conditional and the traversal
> option revs->ignore_missing_negative only for this hunk in my [2/2] patch
> to support that use case.
> ...
Nah, I take that back.
Even the original code does not consider this case an error.
If you really want that, the revision machinery needs major surgery, as I
already noted that the design of mark_parents_uninteresting() wants to
treat a missing uninteresting commit as a non-error event.
^ permalink raw reply
* Re: feature needed imap-send pass as cli switch
From: David Aguilar @ 2009-01-28 8:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901272318i707b66a0ja20f97df6fe95c73@mail.gmail.com>
On Tue, Jan 27, 2009 at 11:18 PM, Caleb Cushing <xenoterracide@gmail.com> wrote:
> I tend to have my .gitconfig shared on github with a bunch of other
> config files and this has been ok, until submitting a patch here I
> needed to use imap-send, and the only way I see in the documentation
Are you sending patches through gmail? If so, check out:
http://git.or.cz/gitwiki/GitTips#head-a015948617d9becbdc9836776f96ad244ba87cb8
You can add .msmtprc to your .gitignore and keep it chmod 600.
Sure, it's cheating -- instead of keeping the data in .gitconfig we're
now keeping it in .mstmprc, but maybe it's a suitable workaround?
> is to put my email password in .gitconfig, obviously I can't push this
> up to my remote as I usually do. I'd like to see an option to pass the
> password on the cli, either as an input prompt or as just an argument
> to an option, or both. I think storing it in the config file is a
> security risk, storing passwords in plaintext is just bad practice.
>
> if it's already possible could someone share how with me? and perhaps
> patch the documentation to include how.
> --
> Caleb Cushing
>
> http://xenoterracide.blogspot.com
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
David
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Junio C Hamano @ 2009-01-28 8:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <498008BA.2000201@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
>> I use this trick in my valgrind series:
>>
>> ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
>> test 0 = "$(cat exit.code)"
>
> Ah, using a file as temporary storage? Why not simply
>
> $PROGRAM > data &&
> $OTHER_PROGRAM < data
>
> Hm? ;)
Because too much cleverness often blinds clever minds.
Care to reroll with the simpler, dumber but clearer version?
^ permalink raw reply
* git clone ssh:// auth failiure
From: Arya, Manish Kumar @ 2009-01-28 8:28 UTC (permalink / raw)
To: git
Hi,
root@dcb0:~# git clone ssh://localhost/~/testproject manish
Initialized empty Git repository in /home/marya/manish/.git/
Password:
Password:
Password:
Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
fatal: The remote end hung up unexpectedly
though I am providing correct ssh password but its not working.
ne help guys ?
-Manish
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Charles Bailey @ 2009-01-28 8:47 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Junio C Hamano, git, Nanako Shiraishi
In-Reply-To: <81bfc67a0901272256t726bf206k351bb6c8b2778bd5@mail.gmail.com>
On Wed, Jan 28, 2009 at 01:56:47AM -0500, Caleb Cushing wrote:
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..575fbb2 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -177,8 +177,24 @@ merge_file () {
> describe_file "$local_mode" "local" "$LOCAL"
> describe_file "$remote_mode" "remote" "$REMOTE"
> if "$prompt" = true; then
> - printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
> - read ans
> + while true; do
> + printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
> + "$merge_tool"
> + read ans
> + case "$ans" in
> + [mM]*|"")
> + break
> + ;;
> + [sS]*)
> + cleanup_temp_files
> + return 0
> + ;;
> + [aA]*)
> + cleanup_temp_files
> + exit 0
> + ;;
> + esac
> + done
This patch does now apply for me, so I've given it a longer look. It
does roughly what I expect, but I can't help feeling that the change
isn't in the best place.
Currently, whatever the prompt, the merge tool will always be run so
it makes sense (or at least there is no negative) in creating the
temporary files before running the merge tool.
With this change, it would seem to be more logical to ask whether the
merge tool is to be run before creating the temporary files, removing
the need for them to be cleaned up if the answer is no. I think that
this would be cleaner overall.
At the same time, however, it might be worth refactoring the
merge_file function as the same criticism could probably levelled at
the code paths that perform symlink and deleted file merges and these
paths would probably now share much more of the logic and behaviour of
a normal file merge.
Trying out this refactoring and adding the option to choose local or
remote file versions without running the merge tool has been on my
todo list for a while, but I might actually have a go at it this
weekend if nobody beats me to it.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: git clone ssh:// auth failiure
From: Steven Noonan @ 2009-01-28 8:50 UTC (permalink / raw)
To: Arya, Manish Kumar; +Cc: git
In-Reply-To: <197294.49807.qm@web35708.mail.mud.yahoo.com>
On Wed, Jan 28, 2009 at 12:28 AM, Arya, Manish Kumar <m.arya@yahoo.com> wrote:
> Hi,
>
> root@dcb0:~# git clone ssh://localhost/~/testproject manish
> Initialized empty Git repository in /home/marya/manish/.git/
> Password:
> Password:
> Password:
> Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
> fatal: The remote end hung up unexpectedly
>
> though I am providing correct ssh password but its not working.
>
> ne help guys ?
>
> -Manish
>
This appears to be more likely a problem with your OpenSSH config than with git.
- Steven
^ permalink raw reply
* Current git-svn and svn props state
From: Edward Z. Yang @ 2009-01-28 9:19 UTC (permalink / raw)
To: git
Hello all,
I was wondering what the current support by git-svn for Subversion
properties was.
Cheers,
Edward
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Jeff King @ 2009-01-28 9:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vbptrvo0m.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 12:22:01AM -0800, Junio C Hamano wrote:
> Nah, I take that back.
>
> Even the original code does not consider this case an error.
>
> If you really want that, the revision machinery needs major surgery, as I
> already noted that the design of mark_parents_uninteresting() wants to
> treat a missing uninteresting commit as a non-error event.
Hrm. Never mind my concern, then. I was worried that we were losing some
existing corruption checks, but it seems they are not there in the first
place.
-Peff
^ permalink raw reply
* git {pull,push} fails without stdin
From: Gustav Hållberg @ 2009-01-28 9:27 UTC (permalink / raw)
To: git
This was seen in git 1.6.0.2...
I want to run "git push" in an automated system and, as there's no
sensible stdin to use, I close fd 0 before exec'ing.
However, it does not work:
sh$ git push <&-
fatal: read error (Bad file descriptor)
compared to:
sh$ git push
Everything up-to-date
The same thing happens with "git pull", but not the other git commands
I tried (in a far-from-exhaustive search).
It's trivial to work around (e.g., use /dev/null as stdin), but it
would be more convenient if it just worked :-)
- Gustav
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-28 9:48 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <BAD975AD-323D-4278-8405-0B57E7202797@gmail.com>
2009/1/28 Perry Smith <pedzsan@gmail.com>:
> Sorry... I thought "out of tree" was a universal term.
No, my mistake, I didn't think about what you meant.
> About 90% of the open source configure / autoconf code out there can do this
> with. The other 10% you can not. I like it because when things die, its easier to
> grep around the source tree and I blow away the build directory and start back over and
> I know that I'm starting fresh.
Even if you're only building git, unless disc space is tight, I'd
probably recommend cloning the git.git repository, then you can either
use make clean or git clean, plus it makes updating to
latest/arbitrary versions easier. Anyway, I don't think your setup is
wrong.
> Yea, part of my larger quest is to start a web site to provide AIX builds
> of open source images as installp images. I have not added iconv to the
> mix yet because I fear bad interactions with GNU's and AIX's. In theory,
> AIX's commands should use AIX's library but it would not surprise me if there are
> a few AIX applications that are not built properly.
A pity package distribution for AIX is so fragmented, but when IBM had
the ball, they dropped it. Mail me if you want links to other existing
sites who might appreciate contributed builds.
> I assume the GIT_SKIP_TESTS is done:
It's documented in test/README
> I just tried setting SHELL_PATH (and exporting it) and the make test gets
> into the second batch and then fails two tests. ... now test 10 of t0001.sh
> fails because test_cmp can not be found.
>
> Is that a GNU tool? (I didn't see it in git or coreutils.)
As Peff said, there's a wrapper around either diff -u or a user
supplied comparison tool (e.g. cmp) set in GIT_TEST_CMP. Setting it to
cmp works fine on AIX if you don't have a diff which takes -u on your
PATH.
As (at the moment) you need bash, gcc, gmake and ginstall to build,
test and (maybe) run all parts of git on AIX, I haven't set up a clean
environment to try and flush out any other quirks to get git to
build/test/run on a stock AIX with no GNU tools installed. For obvious
reasons such AIX machines being used for dev purposes are (I believe)
rare.
Mike
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 9:50 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Charles Bailey, git, Nanako Shiraishi
In-Reply-To: <402731c90901280004l29382eaanedfdfcca75529468@mail.gmail.com>
> Also, my example has quit instead of abort for two reasons (the first
> one is silly)
> 1. skip rhymes with quit, so it reads very nicely out loud
> 2. consistency with git add --interactive
> 3. less typos (q and s are diagonal on qwerty, s and a are adjacent)
> (okay, that last one is silly too)
I chose abort because it's used in other places in mergetool (for same
purpose). I'm not opposed to cleaning up or making it more consistent
with other utilities though. but perhaps that's for another patch...
> slightly off-topic:
> If we're looking at cleaning up mergetool a bit would you all mind a
> separate patch to convert it to using hard tabs throughout, just like
> git-rebase.sh?
in an earlier thread... I complained loudly about the mixing of tabs
and spaces, it should be banned imho, causes nothing but problems.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* [PATCH v2] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-28 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3af3vnti.fsf@gitster.siamese.dyndns.org>
From: Johannes Sixt <j6t@kdbg.org>
The last test case checks whether unpacked objects receive the time stamp
of the pack file. Due to different implementations of stat(2) by MSYS and
our version in compat/mingw.c, the test fails in about half of the test
runs.
Note the following facts:
- The test uses perl's -M operator to compare the time stamps. Since we
depend on MSYS perl, the result of this operator is based on MSYS's
implementation of the stat(2) call.
- NTFS on Windows records fractional seconds.
- The MSYS implementation of stat(2) *rounds* fractional seconds to full
seconds instead of truncating them. This becomes obvious by comparing the
modification times reported by 'ls --full-time $f' and 'stat $f' for
various files $f.
- Our implementation of stat(2) in compat/mingw.c *truncates* to full
seconds.
The consequence of this is that
- add_packed_git() picks up a truncated whole second modification time
from the pack file time stamp, which is then used for the loose objects,
while the pack file retains its time stamp in fractional seconds;
- but the test case compared the pack file's rounded modification times
to the loose objects' truncated modification times.
And half of the time the rounded modification time is not the same as its
truncated modification time.
The fix is that we replace perl by 'test-chmtime -v +0', which prints the
truncated whole-second mtime without modifying it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Junio C Hamano schrieb:
> Care to reroll with the simpler, dumber but clearer version?
OK. This time I use an intermediate file and dquotes around $t.
-- Hannes
t/t7701-repack-unpack-unreachable.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index 63a8225..5babdf2 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -50,12 +50,10 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '
compare_mtimes ()
{
- perl -e 'my $reference = shift;
- foreach my $file (@ARGV) {
- exit(1) unless(-f $file && -M $file == -M $reference);
- }
- exit(0);
- ' -- "$@"
+ read tref rest &&
+ while read t rest; do
+ test "$tref" = "$t" || break
+ done
}
test_expect_success '-A without -d option leaves unreachable objects packed' '
@@ -87,7 +85,9 @@ test_expect_success 'unpacked objects receive timestamp of pack file' '
tmppack=".git/objects/pack/tmp_pack" &&
ln "$packfile" "$tmppack" &&
git repack -A -l -d &&
- compare_mtimes "$tmppack" "$fsha1path" "$csha1path" "$tsha1path"
+ test-chmtime -v +0 "$tmppack" "$fsha1path" "$csha1path" "$tsha1path" \
+ > mtimes &&
+ compare_mtimes < mtimes
'
test_done
--
1.6.1.1.1203.g5882
^ permalink raw reply related
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 9:53 UTC (permalink / raw)
To: Charles Bailey; +Cc: Junio C Hamano, git, Nanako Shiraishi
In-Reply-To: <20090128084756.GA28493@hashpling.org>
> With this change, it would seem to be more logical to ask whether the
> merge tool is to be run before creating the temporary files, removing
> the need for them to be cleaned up if the answer is no. I think that
> this would be cleaner overall.
I agree, but to be honest, I couldn't get the logic wrapped around my
head, so I did it this way. refactoring does seem to be the best idea,
but I don't understand enough of it yet to do so.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200901280247.25317.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 2:47 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 28 Jan 2009, Junio C Hamano wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>> > When PATH_INFO is defined,
>
> I other words: when using PATH_INFO gitweb URL
Notice that gitweb accepts PATH_INFO even whe it's not set to produce them
>> > static files such as the default CSS or the
>> > shortcut icon are not accessible beyond the summary page (e.g. in
>> > shortlog or commit view).
>
> To be more exact: if static files, such as the default CSS (and also
> other stylesheets, if defined), the gitweb favicon / shortcut icon,
> or the gitweb logo locations (URIs) are defined using relative URL
> with relative path (and default Makefile rule to generate gitweb.cgi
> uses basenames like 'gitweb.css', which are relative paths) _THEN_
> those static files are not accessible beyond 'summary' and projects
> list view (e.g. in 'shortlog' or 'commit' view).
I'll rewrite the commit message.
>> >
>> > Fix this by adding a <base> tag pointing to the script's own URL.
>
> Which defines base URL for all relative links in gitweb.
(is this one really necessary)
> /Note that this makes the document hierarchy non-portable, but I don't
> think we care.../
In what sense it becomes non-portable?
>> > + if ($ENV{'PATH_INFO'}) {
>> > + print "<base href=\"$my_url\" />\n";
>> > + }
>>
>> Perhaps this is a stupid question, but is $my_url already safe to include
>> in the output without any further quoting at this point in the codepath?
>
> Hmmmm... to be safe we probably should use either esc_url($my_url) here
> (like in git_feed subroutine).
I"ll do that.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git clone ssh:// auth failiure
From: Johannes Gilger @ 2009-01-28 10:06 UTC (permalink / raw)
To: git
In-Reply-To: <197294.49807.qm@web35708.mail.mud.yahoo.com>
On 2009-01-28, Arya, Manish Kumar <m.arya@yahoo.com> wrote:
> root@dcb0:~# git clone ssh://localhost/~/testproject manish
You are aware that youre calling ssh as root, and that ssh will try to
login to localhost as user "root"? A lot of sshd installations do not
allow this by default.
> Permission denied
> (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
This is an ssh-error, has nothing to do with git
Greetings, Jojo (from a Nokia N810, yuk)
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* (beginner) git rm
From: Zabre @ 2009-01-28 10:11 UTC (permalink / raw)
To: git
Hi,
I am learning git and there is something I don't get : why a file deleted in
a branch gets also deleted in my master?
(For the moment I'm only working locally, no remote repository)
I have a master branch containing 4 text files called a.txt , b.txt , c.txt
, d.txt . (in HEAD)
I create a new branch from there (masters HEAD) and go to this new branch.
$ git branch new
$ git checkout new
I delete one file in the new branch
$ git rm d.txt
$ ls
a.txt b.txt c.txt
Then I go back to the master branch and list the files there
$ git checkout master
$ls
a.txt b.txt c.txt
I have not modified the master branch, why is d.txt deleted there also?
There must be something I did not understand in git behaviour (something to
do with the index?)
Thank you for your help.
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231416.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Sverre Rabbelier @ 2009-01-28 10:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <7vhc3kxdwm.fsf@gitster.siamese.dyndns.org>
Heya,
On Wed, Jan 28, 2009 at 05:17, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> + test $# = 0 && test -t 0 && usage
Awesome! Thanks for looking into this :).
> Sorry to be dense. Why isn't your patch the above single liner?
I hope you two work this out soon so it gets into maint.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: (beginner) git rm
From: Peter Krefting @ 2009-01-28 10:36 UTC (permalink / raw)
To: Zabre; +Cc: Git Mailing List
In-Reply-To: <1233137498146-2231416.post@n2.nabble.com>
Zabre:
> I delete one file in the new branch
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
Here you have not yet committed the change, so the change is only in
the staging area. You need to
git commit
to create a commit on your branch.
> Then I go back to the master branch and list the files there
> $ git checkout master
Since you have not yet made any commits to your branch, master and new
both point to the same commit, meaning that this is does nothing but
changes which branch you are committing to.
> $ls
> a.txt b.txt c.txt
You are in the same place as you were a moment ago, but you have told
Git that you want to commit the removal to master instead of new.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Is the stgit project still alive?
From: Catalin Marinas @ 2009-01-28 10:37 UTC (permalink / raw)
To: J Robert Ray; +Cc: Git Mailing List
In-Reply-To: <20090128-041237.sv13413.72217@gna.org>
(I cc'ed the git list as well for the information)
2009/1/28 J Robert Ray <jrobertray@gmail.com>:
> The project website appears to have died.
I noticed this as well. I was hosting the website at freezend.com and
they seem to have problems:
http://www.freewebspace.net/forums/showthread.php?p=1049536
I moved it somewhere else yesterday and http://www.procode.org/ works
now but I still have to transfer the StGit files as well, sometime
this week.
The project page is fine - https://gna.org/projects/stgit/ - and
developing activity going on (I was just too busy to fix some of the
bugs logged and release a new version;we'll hopefully get one in
February).
--
Catalin
^ permalink raw reply
* [PATCHv4 2/2] gitweb: webserver config for PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1233139832-24124-1-git-send-email-giuseppe.bilotta@gmail.com>
Document some possible Apache configurations when the path_info feature
is enabled in gitweb.
---
So I decided to document the best way to set up the web server with the
path_info feature. I particularly like the second trick, although I haven't
found a way to make git-daemon accept both git://git.example.com/project and
git://git.example.com/project.git when the project dirs don't have the .git
extensions (e.g. /pub/git/project instead of /pub/git/project.git)
gitweb/README | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 825162a..52ad88b 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -322,6 +322,82 @@ something like the following in your gitweb.conf (or gitweb_config.perl) file:
$home_link = "/";
+PATH_INFO usage
+-----------------------
+If you enable PATH_INFO usage in gitweb by putting
+
+ $feature{'pathinfo'}{'default'} = [1];
+
+in your gitweb.conf, it is possible to set up your server so that it
+consumes and produces URLs in the form
+
+http://git.example.com/project.git/shortlog/sometag
+
+by using a configuration such as the following, that assumes that
+/var/www/gitweb is the DocumentRoot of your webserver, and that it
+contains the gitweb.cgi script and complementary static files
+(stylesheet, favicon):
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The rewrite rule guarantees that existing static files will be properly
+served, whereas any other URL will be passed to gitweb as PATH_INFO
+parameter.
+
+Notice that in this case you don't need special settings for
+@stylesheets, $my_uri and $home_link, but you lose "dumb client" access
+to your project .git dirs. A possible workaround for the latter is the
+following: in your project root dir (e.g. /pub/git) have the projects
+named without a .git extension (e.g. /pub/git/project instead of
+/pub/git/project.git) and configure Apache as follows:
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ AliasMatch ^(/.*?)(\.git)(/.*)? /pub/git$1$3
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The additional AliasMatch makes it so that
+
+http://git.example.com/project.git
+
+will give raw access to the project's git dir (so that the project can
+be cloned), while
+
+http://git.example.com/project
+
+will provide human-friendly gitweb access.
+
+
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
--
1.5.6.5
^ permalink raw reply related
* [PATCHv4 1/2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When gitweb is invoked with PATH_INFO and links to static files such as
the CSS and favicon/shortcut icon are relative URLs with relative paths
(as is the case when using the default Makefile), these files are not
accessible beyond the project list and summary page (e.g. in shortlog or
commit view).
Fix this by adding a <base> tag pointing to the script's own URL, that
ensure that all relative paths will be based on this.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..f7aaf9a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,11 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we
+# set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ print "<base href='".esc_url($my_url)."' />\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Re: (beginner) git rm
From: Zabre @ 2009-01-28 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0901281133380.645@ds9.cixit.se>
Peter Krefting wrote:
>
> Here you have not yet committed the change, so the change is only in
> the staging area. You need to
>
> git commit
>
> to create a commit on your branch.
>
Thank you Peter.
I've just done a hard reset and redid it the right way. It worked as
expected.
$ git checkout new
$ rm d.txt
$ git rm d.txt
$ git commit
I am a little bit confused regarding rm : first I did a simple "rm" but git
would not commit, so I had to "git rm" for the index to be modified and have
something to commit. Is this the right way to do things?
Another question would be : instead of doing a hard reset (I might have
other changes in the index that I don't want to loose) is it possible to
remove only one "delete action" from the index?
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231622.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: (beginner) git rm
From: Tomas Carnecky @ 2009-01-28 11:37 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233140751523-2231622.post@n2.nabble.com>
On 01/28/2009 12:05 PM, Zabre wrote:
> Another question would be : instead of doing a hard reset (I might have
> other changes in the index that I don't want to loose) is it possible to
> remove only one "delete action" from the index?
Do you mean 'undelete' a file? git checkout d.txt - That restores the
file in the working tree and resets the index just for that file.
tom
^ permalink raw reply
* Re: (beginner) git rm
From: Zabre @ 2009-01-28 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <49804385.908@dbservice.com>
Tomas Carnecky wrote:
>
> Do you mean 'undelete' a file? git checkout d.txt - That restores the
> file in the working tree and resets the index just for that file.
>
Hi Tom,
(thank you for your interest in my newbie problems)
yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
But I did not manage to apply your solution succesfully :
$ git rm d.txt
$ ls
a.txt b.txt c.txt
$ git status
# On branch new
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: d.txt
#
$ git checkout d.txt
error: pathspec 'mamma.txt' did not match any file(s) known to git.
Did you forget to 'git add'?
So it did not work but I've just noticed that unstage tip given by the
status command, and I did the following (which worked)
$ git reset HEAD d.txt
d.txt: needs update
$ ls
a.txt b.txt c.txt
$ git checkout d.txt
$ ls
a.txt b.txt c.txt d.txt
Reading the git reset help file gives me the feeling I should use this with
caution... It looks like you can somehow modify the change history.
Anyway these two commands helped me change the index the way I wanted.
Please tell me if this might somehow go wrong in another situation.
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231849.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: (beginner) git rm
From: Tomas Carnecky @ 2009-01-28 12:19 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233144045221-2231849.post@n2.nabble.com>
On 01/28/2009 01:00 PM, Zabre wrote:
>
> Tomas Carnecky wrote:
>> Do you mean 'undelete' a file? git checkout d.txt - That restores the
>> file in the working tree and resets the index just for that file.
>>
>
> Hi Tom,
> (thank you for your interest in my newbie problems)
>
> yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
> But I did not manage to apply your solution succesfully :
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
> $ git status
> # On branch new
> # Changes to be committed:
> # (use "git reset HEAD<file>..." to unstage)
> #
> # deleted: d.txt
> #
> $ git checkout d.txt
> error: pathspec 'mamma.txt' did not match any file(s) known to git.
> Did you forget to 'git add'?
Oops, sorry. git checkout HEAD -- d.txt
You have to tell which version of d.txt you want. In your case the
version in HEAD.
tom
^ 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