* UI: git-tag should support -F as well
From: Han-Wen Nienhuys @ 2006-12-21 11:52 UTC (permalink / raw)
To: git
Working on a little darcs2git script, I found the following inconsistency
git-commit supports -m and -F
git-tag supports only -m
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2006-12-21 11:53 UTC (permalink / raw)
To: Jay Cliburn; +Cc: git
In-Reply-To: <4589FD9E.2010000@bellsouth.net>
Jay Cliburn wrote:
> Jeff Garzik wrote:
>> I refreshed my git intro/cookbook for kernel hackers, at
>> http://linux.yyz.us/git-howto.html
>>
>> This describes most of the commands I use in day-to-day kernel
>> hacking. Let me know if there are glaring errors or missing key
>> commands.
>
> Thanks for doing this. I've referred to your previous page rather often
> as I grope around trying to learn git and hack a vendor driver for
> submittal into the mainline kernel.
>
> One thing that baffled me was how to use git to create a "kitchen sink"
> diff that would produce my entire driver suitable for submittal to lkml
> for review. This probably isn't needed very often, but for new driver
> submittals it's important to know how to do it. Francois Romieu showed
> me how (assume the new driver branch is named "driver"):
>
> $ git diff $(git merge-base master driver)..driver
>
> As a beginner, this command continues to be utterly non-intuitive to me,
> but it works. There may be other ways to do it, too.
>
> The point is, I think you should add instructions on your cookbook that
> address how to produce such a "kitchen sink" diff if you're submitting a
> brand new driver to lkml. (Obviously I don't know what such a diff is
> actually called.)
You inflict upon yourself all sorts of pain if you keep updating
'master', but don't merge that into 'driver'. Typically you want to
rebase after updating master:
git checkout driver
git rebase master
# build and test
git prune
or merge master into your current branch:
git checkout driver
git pull . master
# build and test
That way, you are GUARANTEED that
git diff master..driver
will result in a diff that you can send upstream.
One moral of this story, as (I think) Linus mentioned, don't update
'master' too frequently. That's one key lesson of distributed
programming. Unless the upstream kernel has a key API change or bug fix
you need, just pretend the outside world does not exist, and hack away
on your driver.
Jeff
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Duncan Mak @ 2006-12-21 11:59 UTC (permalink / raw)
To: git
In-Reply-To: <emdr6v$9ma$1@sea.gmane.org>
Fix vc-git.el to not cd into a non-existent directory.
---
contrib/emacs/vc-git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
base 54851157acf707eb953eada2a84830897dde5c1d
last c2af9380cd8ec0170b9b251c0ee8a5efa63bac87
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 8b6361922fd6e6a2fcd9acb20fd54f5b645b36f0..b3c8040dd766c9b15e1d0a9247b6343fdf0a8caf
100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -58,7 +58,7 @@
(with-temp-buffer
(let* ((dir (file-name-directory file))
(name (file-relative-name file dir)))
- (when dir (cd dir))
+ (when (file-exists-p dir) (cd dir))
(and (ignore-errors (eq 0 (call-process "git" nil '(t nil) nil
"ls-files" "-c" "-z" "--" name)))
(let ((str (buffer-string)))
(and (> (length str) (length name))
--
1.4.4.1
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Francis Moreau @ 2006-12-21 12:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jay Cliburn, git, Jeff Garzik
Hi,
[ sorry for breaking up the thread but I'd like to fully
understand that point and I just subscribed to git mail
list... ]
Linus Torvalds wrote:
>
> On Wed, 20 Dec 2006, Jay Cliburn wrote:
>> $ git diff $(git merge-base master driver)..driver
>
> Be careful. This ONLY works if you don't have criss-cross merges etc, so
> you need to be somewhat careful about it. If you end up having a complex
> merge history between the origin branch and your development tree, things
> will stop working
>
> So it's actually worth understanding what the above does.
>
> Here's the picture to keep in mind: you started off with something like
> this:
>
> <- older newer ->
>
> ..--A---B---C---D
>
> where the top commit was D, and you started doing your own work off there.
> However, the tree you are tracking (doing "git fetch origin" or somethng)
> ALSO continues, so soon enough you'll have a history that looks like
>
> <- older newer ->
>
> ..--A---B---C---D---E---F---G---H <-"origin"
> \
> --X---Y---Z <- your "driver" branch"
>
> where your work is the "X-Y-Z" sequence.
>
> How, the reason you must NOT do
>
> git diff origin..driver
>
> or something like that, is that it will LITERALLY do a diff between those
> two heads. And while that is a perfectly normal diff, it's not what you
> want: it's the diff between the up-stream work and yours, and it will show
> that a lot of work has _not_ happened in your branch (all the E-F-G-H
> stuff), and then you've added some work (X-Y-Z).
I must really miss something but is a diff between origin and driver heads
achieved by:
$ git diff driver origin
instead of:
$ git diff origin..driver
?
>From the git-rev-list documentation I can read that:
git-rev-list origin..driver == git-rev-list driver ^origin
I assume it's still true for git-diff. And the documentation says that
the above command "lists all the commits which are included in driver,
but not in origin".
So all commits included in driver are: (A-B-C-D-X-Y-Z)
all commits included in origin are: (A-B-C-D-E-F-G-H)
All the commits which are included in driver, but not in origin are:
(X-Y-Z), which is definitely not what you claimed.
I know that I'm wrong, so please shed some light in my stupid brain.
--
Francis
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Alexander Litvinov @ 2006-12-21 13:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emdorr$kt$1@sea.gmane.org>
В сообщении от Thursday 21 December 2006 16:52 Jakub Narebski написал(a):
> > May we can add new header into commit with commit text encoding ?
>
> I think it should be repository-wide decision. And we have
> i18n.commitEncoding configuration variable (perhaps it should be propagated
> on clone?).
I would disagree with you. Is is not hard to imagine international project
managed by git. We [developers] can start to use utf-8 or similar universal
encoding but it is not easy sometimes. Fir example, not long ago all russian
linux machines has LANG set to ru_RU.KOI8-R, now it tend to be ru_RU.UTF-8.
It will not big surprise to me if developr from China or Japan use something
very unusual. And just imagine one developer using Windows and Cygwin - ha ha
ha, try to ask him to change the encoding :-)
The easiest way for git is just to store commit encoding and let tool for
history browsing deal with encoding. Or as it does now - simply ignore all
encodings at all and work with bytes not chars. But at this case history
browsing tool must have some magic knowlage about encoding taken from
air :-). Or from config file that cover most used encodings.
Alexander Litvinov.
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Jakub Narebski @ 2006-12-21 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <200612211905.27555.litvinov2004@gmail.com>
Alexander Litvinov wrote:
> ? ????????? ?? Thursday 21 December 2006 16:52 Jakub Narebski ???????(a):
>>> May we can add new header into commit with commit text encoding ?
>>
>> I think it should be repository-wide decision. And we have
>> i18n.commitEncoding configuration variable (perhaps it should be propagated
>> on clone?).
>
> I would disagree with you. Is is not hard to imagine international project
> managed by git. We [developers] can start to use utf-8 or similar universal
> encoding but it is not easy sometimes. Fir example, not long ago all russian
> linux machines has LANG set to ru_RU.KOI8-R, now it tend to be ru_RU.UTF-8.
> It will not big surprise to me if developr from China or Japan use something
> very unusual. And just imagine one developer using Windows and Cygwin - ha ha
> ha, try to ask him to change the encoding :-)
>
> The easiest way for git is just to store commit encoding and let tool for
> history browsing deal with encoding. Or as it does now - simply ignore all
> encodings at all and work with bytes not chars. But at this case history
> browsing tool must have some magic knowlage about encoding taken from
> air :-). Or from config file that cover most used encodings.
Perhaps it is time to resurrect idea about "note" header in commit object?
It could be used to store charset for those commits which doesn't use
default charset...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git 1.4.4.2 is giving the following errors...
From: Eric Blake @ 2006-12-21 13:03 UTC (permalink / raw)
To: srinivas naga vutukuri; +Cc: git
In-Reply-To: <ace3f33d0612202115p3fedb169pf235c4556f2eef57@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to srinivas naga vutukuri on 12/20/2006 10:15 PM:
> Hi,
>
> I am new to git.
>> From the web site downloaded the 1.4.4.2 source and compiled on the
> cygwin environment.
Why not download the pre-compiled git 1.4.4.3 from cygwin, rather than
building it yourself?
> when am trying as an example to use the git,
>
> ------------------------------------snip----------------------------------------------------------
>
> sh-3.2$ git clone git://git.kernel.org/pub/scm/git/git.git
> : command not foundclone: line 7:
I wonder if you are suffering from corrupted line endings. If your
scripts end up with DOS line endings, but you execute them on a cygwin
binary mount, then bash will happily treat those \r as literal characters
rather than ignored whitespace (similarly to how bash behaves on Linux
with \r characters, except that on Linux, people tend to not use DOS line
endings).
- --
Life is short - so eat dessert first!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFioY/84KuGfSFAYARAiNEAJ942dcJyv4v2uYWd5NI7y43JeL9FQCeMMyH
GGOX9k8mTra+K19nxv9qqDw=
=RWS0
-----END PGP SIGNATURE-----
^ permalink raw reply
* t5000-tar-tree.sh failing
From: Uwe Kleine-König @ 2006-12-21 13:37 UTC (permalink / raw)
To: git
Hello,
when I run make test, I get:
*** t5000-tar-tree.sh ***
Initialized empty Git repository in .git/
* ok 1: populate workdir
* ok 2: add files to repository
* ok 3: git-tar-tree
* ok 4: validate file modification time
* ok 5: git-get-tar-commit-id
* ok 6: extract tar archive
* ok 7: validate filenames
* ok 8: validate file contents
* ok 9: git-tar-tree with prefix
* ok 10: extract tar archive with prefix
* ok 11: validate filenames with prefix
* ok 12: validate file contents with prefix
* ok 13: git-archive --format=zip
* FAIL 14: extract ZIP archive
(mkdir d && cd d && $UNZIP ../d.zip)
* FAIL 15: validate filenames
(cd d/a && find .) | sort >d.lst &&
diff a.lst d.lst
* FAIL 16: validate file contents
diff -r a d/a
* ok 17: git-archive --format=zip with prefix
* FAIL 18: extract ZIP archive with prefix
(mkdir e && cd e && $UNZIP ../e.zip)
* FAIL 19: validate filenames with prefix
(cd e/prefix/a && find .) | sort >e.lst &&
diff a.lst e.lst
* FAIL 20: validate file contents with prefix
diff -r a e/prefix/a
* failed 6 among 20 test(s)
I think the problem is:
zeisberg@cepheus:~/gsrc/git$ unzip
bash: unzip: command not found
Probably the subversion tests suffer the same (for svn instead of
unzip).
Do we want the tests to depend on all that or would it be sensible to
output a warning that a program is missing? Or maybe introduce test
"13.5: check is unzip is available". Then it would be more obvious for
the tester what went wrong?
Best regards
Uwe
--
Uwe Kleine-König
primes where sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]; \
primes = map head (iterate sieve [2..])
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Uwe Kleine-König @ 2006-12-21 13:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emdorr$kt$1@sea.gmane.org>
Hello,
Jakub Narebski wrote:
> Alexander Litvinov wrote:
>
> >>> What do you think about a patch that makes git-commit-tree call iconv on
> >>> its input to get it to UTF-8 (or any other charset).
> >>
> >> We had this discussion over and over again. Last time (I think) was here:
> >> http://article.gmane.org/gmane.comp.version-control.git/11710
> >> Summary: we do not want to force the use of utf8.
> >
> > May we can add new header into commit with commit text encoding ?
>
> I think it should be repository-wide decision. And we have
> i18n.commitEncoding configuration variable
The disadvantage from a repository-wide decision is that you cannot
change it after a while.
I didn't know that variable, but I think as it exists,
git-commit-tree should iconv the commit message from local to
i18n.commitEncoding before writing it.
Moreover I like the idea of a new header for commits specifing the
encoding. Git could default to the handling as it is now (i.e. just
bytes) if the header is missing.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Francois Romieu @ 2006-12-21 13:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <4589F9B1.2020405@garzik.org>
Jeff Garzik <jeff@garzik.org> :
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
o 'git whatchanged shnortz' can probably be replaced with
'git log -- schnortz' so there is one command less to remember.
o "Display changes since last git-update-index:"
Fine but you have not told the reader what git-update-index is.
--
Ueimor
^ permalink raw reply
* Re: t5000-tar-tree.sh failing
From: Johannes Schindelin @ 2006-12-21 14:00 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20061221133746.GA13751@cepheus>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 592 bytes --]
Hi,
On Thu, 21 Dec 2006, Uwe Kleine-König wrote:
> [...]
> * FAIL 14: extract ZIP archive
> (mkdir d && cd d && $UNZIP ../d.zip)
> [...]
>
> I think the problem is:
>
> zeisberg@cepheus:~/gsrc/git$ unzip
> bash: unzip: command not found
Yep. That's the problem.
> Probably the subversion tests suffer the same (for svn instead of
> unzip).
>
> Do we want the tests to depend on all that or would it be sensible to
> output a warning that a program is missing?
Why not enclose the tests in a
if unzip -h >/dev/null 2>/dev/null; then
# all these tests
fi
Hmm?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-tag: support -F <file> option
From: Johannes Schindelin @ 2006-12-21 14:13 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <emdsi9$ecm$1@sea.gmane.org>
This imitates the behaviour of git-commit.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Thu, 21 Dec 2006, Han-Wen Nienhuys wrote:
> Working on a little darcs2git script, I found the following
> inconsistency
>
> git-commit supports -m and -F
> git-tag supports only -m
How about this?
Documentation/git-tag.txt | 6 +++++-
git-tag.sh | 11 +++++++++++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 45476c2..48b82b8 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,8 @@ git-tag - Create a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <name> [<head>]
+'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg> | -F <file>]
+ <name> [<head>]
'git-tag' -l [<pattern>]
DESCRIPTION
@@ -60,6 +61,9 @@ OPTIONS
-m <msg>::
Use the given tag message (instead of prompting)
+-F <file>::
+ Take the tag message from the given file. Use '-' to
+ read the message from the standard input.
Author
------
diff --git a/git-tag.sh b/git-tag.sh
index d53f94c..36cd6aa 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -45,6 +45,17 @@ do
message_given=1
fi
;;
+ -F)
+ annotate=1
+ shift
+ if test "$#" = "0"; then
+ die "error: option -F needs an argument"
+ exit 2
+ else
+ message="$(cat "$1")"
+ message_given=1
+ fi
+ ;;
-u)
annotate=1
signed=1
--
1.4.4.3.g0ba4
^ permalink raw reply related
* git-add,& "file vanishing" -> need git-add again?
From: David Tweed @ 2006-12-21 14:13 UTC (permalink / raw)
To: git, git
Hi, I'm working on using git for chronological backups (think selective P9 venti),
which I've almost got working. (I know I'm using git for something it wasn't
designed for, and is arguably perverse.) I've been trying to figure out why files which "ought"
to be tracked weren't in the database in certain commits and I think I've figured out why.
Can someone confirm the following: with the set of operations
git-init-db
....
git-add path/to/fileX
git-commit -a -m blah <1>
..... changes to things including fileX and commits
[file X vanishes from the tree being tracked, but nothing mentioned to git] <2>
..... changes to things and commits
[file X reappears in the tree being tracked]
<3>
git-commit -a -m blah <4>
the git trees from <1> to <2> all contain fileX, even if its contents haven't changed. Between
<2> and <4> the git tree doesn't contain fileX (perfectly properly). From <4> onwards fileX
still doesn't appear in the git trees recorded from the working directory even though fileX is
there again. If I want fileX tracked I have to explicitly git-add it again
at <3>. (Ie, git-commit -a when it detects a file have vanished from the working tree removes
it from the files git will look at in future for changes to commit.)
Is it also correct that this behaviour ("forget" about a tracked file when it disappear from the
working tree in a commit) would be difficult to change without major surgery to git?
Would there be any problems with git-add'ing every file you want the tree to track before every
commit?
(I'm currently working on code to keep track of things that have ever been tracked, and whether
they're currently in the tree, in my scripts outside git but obviously partially duplicating stuff git
has in its datastructures has the potential for subtle bugs when they diverge.)
Long story:
---------------
I'm trying to move a snapshotting-style system from my personal hack-job to git. As well as
manual snapshots there's a cron job that runs every hour to snapshot stuff. Consequently
there will be "automatic commits" when you wouldn't have made one if you were doing normal
source control, eg, after you've wrongly deleted a file and before you've noticed & restored it
from the database an automatic commit can come in (and even more kinky situations you
don't want to know about) and so sees the file "gone".
Sidenote: I'm moving the database from the old format to the new one by repeatedly unpacking
the old database for snapshot X, git-add'ing any file names which have _never_ been in any snapshot
before, git-commit -a, git-tag, then remove all the files unpacked by the
old database and move onto snapshot X+1. This takes less than a second per snapshot. I understand
this shouldn't be a problem but just to let people know the timestamps on the files aren't what
would be expected.
Many thanks for any insight,
cheers, dave tweed
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* Re: t5000-tar-tree.sh failing
From: Brian Gernhardt @ 2006-12-21 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.63.0612211458360.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Dec 21, 2006, at 9:00 AM, Johannes Schindelin wrote:
>
> Why not enclose the tests in a
>
> if unzip -h >/dev/null 2>/dev/null; then
>
> # all these tests
>
> fi
>
> Hmm?
Several other test frameworks provide a "skip" method to indicate why
we've skipped something. We could do something similar...
if skip 'unzip -h' 'tests need unzip'; then
# unzip tests
fi
skip() {
# Have not checked to see if this is anything resembling working code
if eval $1 > /dev/null 2>&1; then
true
else
echo "* skipping tests: $2" 1>&2
false
fi
}
Mostly so that skipped tests are obvious, provide a reason, and have
a standardized display format. Again, too busy in actual work to try
to do this myself right now, but might hack at it this afternoon if
nobody else (hopefully someone more fluent in shell than I am) does.
~~ Brian
^ permalink raw reply
* [PATCH] git-reset --hard: tell the user what the HEAD was reset to
From: Johannes Schindelin @ 2006-12-21 14:26 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <emcf17$esj$1@sea.gmane.org>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Wed, 20 Dec 2006, Han-Wen Nienhuys wrote:
> It would be nice if git-reset printed
>
> HEAD is now <sha1> - <excerpt of commit message>
This patch does that, but only for --reset.
Without reset, HEAD is _not_ changed, just the contents of the
working directory and/or the index.
git-reset.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index 8d95e37..2379db0 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -86,7 +86,12 @@ update_ref_status=$?
case "$reset_type" in
--hard )
- ;; # Nothing else to do
+ test $update_ref_status = 0 && {
+ echo -n "HEAD is now at "
+ GIT_PAGER= git log --max-count=1 --pretty=oneline \
+ --abbrev-commit HEAD
+ }
+ ;;
--soft )
;; # Nothing else to do
--mixed )
--
1.4.4.3.gdb8fb-dirty
^ permalink raw reply related
* gitweb: Version independent mod_perl woes
From: Jakub Narebski @ 2006-12-21 17:07 UTC (permalink / raw)
To: git
I try to make gitweb run under mod_perl without need to set up CGI
environmental variables, and without need to parse headers. I try to do
this in such a way that one will be able to run gitweb under mod_cgi
(as an ordinary CGI script), under mod_perl 1.0 Apache::registry and
under mod_perl 2.0 ModPerl::Registry without changes.
I'm trying to do the first part (running without need for SetupEnv),
but I'm encountering some strange errors and I'm stumped.
I have taken the version independent initialization from
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version
-- >8 --
# Set the constant MP_GEN to 0 if mod_perl is not available,
# to 1 if running under mod_perl 1.0
# and 2 for mod_perl 2.0
use constant MP_GEN => $ENV{'MOD_PERL'}
? { ( exists $ENV{'MOD_PERL_API_VERSION'} and
$ENV{'MOD_PERL_API_VERSION'} >= 2 ) ? 2 : 1 }
: 0;
# use appropriate mod_perl modules (conditional use)
BEGIN {
if (MP_GEN == 2) {
require Apache2::RequestRec;
require Apache2::ServerRec;
require Apache2::Response;
require Apache2::Const;
import Apache2::RequestRec;
import Apache2::ServerRec;
Apache2::Const->import(-compile => qw(:common :http));
} elsif (MP_GEN == 1) {
require Apache;
require Apache::Constants;
import Apache;
Apache::Constants->import(qw(:common :http));
}
}
# mod_perl request
my $r;
$r = shift @_ if MP_GEN;
-- >8 --
Then later I try to use mod_perl rather than $ENV{'SERVER_NAME'}
-- >8 --
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = "++GITWEB_SITENAME++"
|| (($r ? $r->server()->server_hostname() : $ENV{'SERVER_NAME'})
|| "Untitled") . " Git";
-- >8 --
but I'm encountering the following error:
Can't locate object method "server_hostname" via package "Apache2::ServerRec"
at /var/www/perl/gitweb/gitweb.cgi line 83.
What is strange from time to time it _works_.
Can anyone tell me what I'm doing wrong?
--
Jakub Narebski
Poland
^ permalink raw reply
* git-svn question
From: Joseph Carrafa @ 2006-12-21 17:34 UTC (permalink / raw)
To: git
In-Reply-To: <f2e8061d0612210927p2d18adb4u995ce16702fc3b08@mail.gmail.com>
I have a question concerning using git with an svn repo. I have a
local git repo that was created with git svn init
$SVNROOT/branches/2.2.0. we moved the svn branch to
$SVNROOT/branches/2.3.0. how can i change my local git repo to commit
to the new svn branch, $SVNROOT/branches/2.3.0?
Thanks
-Joe
^ permalink raw reply
* Re: gitweb: Version independent mod_perl woes
From: Jakub Narebski @ 2006-12-21 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <200612211807.54668.jnareb@gmail.com>
> Can anyone tell me what I'm doing wrong?
Ah, I forgot to add:
Apache 2.0.54 (httpd-2.0.54-10.3)
mod_perl 2.0.1 (mod_perl-2.0.1-1.fc4)
Perl 5.8.6 (perl-5.8.6-24)
$Apache2::RequestRec::VERSION = 2.000001
$Apache2::ServerRec::VERSION = 2.000001
-- >8 -- [fragment of httpd.conf] ---
Alias /perl "/var/www/perl"
<Directory "/var/www/perl">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options Indexes FollowSymlinks +ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
-- >8 --
P.S. The goal is for gitweb to work with
PerlOptions -SetupEnv -ParseHeaders
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: gitweb: Version independent mod_perl woes
From: Jakub Narebski @ 2006-12-21 18:09 UTC (permalink / raw)
To: git
In-Reply-To: <200612211807.54668.jnareb@gmail.com>
Jakub Narebski wrote:
> -- >8 --
> # Set the constant MP_GEN to 0 if mod_perl is not available,
> # to 1 if running under mod_perl 1.0
> # and 2 for mod_perl 2.0
> use constant MP_GEN => $ENV{'MOD_PERL'}
> ? { ( exists $ENV{'MOD_PERL_API_VERSION'} and
> $ENV{'MOD_PERL_API_VERSION'} >= 2 ) ? 2 : 1 }
> : 0;
Actually, the error was here. It works like expected for
use constant {
MP_GEN => ($ENV{'MOD_PERL'}
? ( exists $ENV{'MOD_PERL_API_VERSION'} and
$ENV{'MOD_PERL_API_VERSION'} >= 2 ) ? 2 : 1
: 0),
};
> # use appropriate mod_perl modules (conditional use)
> BEGIN {
> if (MP_GEN == 2) {
> require Apache2::RequestRec;
> require Apache2::ServerRec;
> require Apache2::Response;
> require Apache2::Const;
> import Apache2::RequestRec;
> import Apache2::ServerRec;
> Apache2::Const->import(-compile => qw(:common :http));
> } elsif (MP_GEN == 1) {
> require Apache;
> require Apache::Constants;
> import Apache;
> Apache::Constants->import(qw(:common :http));
> }
> }
>
> # mod_perl request
> my $r;
> $r = shift @_ if MP_GEN;
> -- >8 --
Sorry for the noise.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: specify charset for commits
From: Junio C Hamano @ 2006-12-21 18:19 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Johannes Schindelin, Uwe Kleine-König, git
In-Reply-To: <200612211623.14236.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> writes:
> May we can add new header into commit with commit text encoding ?
I do not think we want to change the commit header, nor we would
want to re-encode, but I can see two possible improvements:
(1) git-am should default to -u; this was suggested on the list
long time ago, but is an incompatible change. v1.5.0 we
can afford to be incompatible to make it more usable and
safer.
(2) update commit-tree to reject non utf-8 log messages and
author/committer names when i18n.commitEncoding is _NOT_
set, or set to utf-8.
Maybe later we can use encoding validation routines for
other encodings by checking i18n.commitEncoding, but at the
minimum the above would be safe enough for recommended UTF-8
only cases.
^ permalink raw reply
* Re: git-svn question
From: Seth Falcon @ 2006-12-21 18:21 UTC (permalink / raw)
To: Joseph Carrafa; +Cc: git
In-Reply-To: <f2e8061d0612210934m2f147a1bl55d7152cc85f6f3e@mail.gmail.com>
"Joseph Carrafa" <carrafaj@gmail.com> writes:
> I have a question concerning using git with an svn repo. I have a
> local git repo that was created with git svn init
> $SVNROOT/branches/2.2.0. we moved the svn branch to
> $SVNROOT/branches/2.3.0. how can i change my local git repo to commit
> to the new svn branch, $SVNROOT/branches/2.3.0?
See this thread:
http://article.gmane.org/gmane.comp.version-control.git/33715/match=seth+falcon
And read the Advanced Example: Tracking a Reorganized Repository in
the git-svn man page.
+ seth
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Linus Torvalds @ 2006-12-21 18:23 UTC (permalink / raw)
To: Francis Moreau; +Cc: Jay Cliburn, git, Jeff Garzik
In-Reply-To: <38b2ab8a0612210424o4ec5fcd5kb5086c52ccd76491@mail.gmail.com>
On Thu, 21 Dec 2006, Francis Moreau wrote:
>
> I must really miss something but is a diff between origin and driver heads
> achieved by:
>
> $ git diff driver origin
>
> instead of:
>
> $ git diff origin..driver
No.
git diff origin driver
and
git diff origin..driver
is exactly the same thing.
> From the git-rev-list documentation I can read that:
>
> git-rev-list origin..driver == git-rev-list driver ^origin
Correct. However, "git diff" is very aware of things like "^origin", and
understands that
git diff driver ^origin
is the same thing as saying "I want what is in driver, but not in origin",
so it needs to switch the arguments.
In short, for git diff (and ONLY) git diff, all of these are the same:
git diff a..b
git diff a b
git diff b ^a
[ ADDITIONALLY git diff _also_ has a magic special case of
git diff a b ^c
which actually means the same as "git diff c..a" (and "b" is
totally ignored). That may sound strange, but it's because the
expression "a...b" means "b a --not $(git-merge-base a b)", and so what
you actually WANT is that if you do
git diff a...b
you should get "diff from merge-base to b", so when "a...b" expands to
"b a ^merge-base", then git understands that if it gets that stange
command line with THREE commits, and one of them is negated, you really
wanted the diff from the negated one to the first one ]
It basically all boils down to:
"git diff" is special
exactly because unlike almost ALL other git commands, "git diff" does not
work on a _list_ of commits, it only works on two end-points. That means
that the "list operations" actually end up meaning something else for git
diff than they do for "git log" and friends.
Linus
^ permalink raw reply
* Re: specify charset for commits
From: Nicolas Pitre @ 2006-12-21 18:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alexander Litvinov, Johannes Schindelin, Uwe Kleine-König,
git
In-Reply-To: <7vejqtaz7q.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
> > May we can add new header into commit with commit text encoding ?
>
> I do not think we want to change the commit header, nor we would
> want to re-encode, but I can see two possible improvements:
>
> (1) git-am should default to -u; this was suggested on the list
> long time ago, but is an incompatible change. v1.5.0 we
> can afford to be incompatible to make it more usable and
> safer.
>
> (2) update commit-tree to reject non utf-8 log messages and
> author/committer names when i18n.commitEncoding is _NOT_
> set, or set to utf-8.
This would be a good thing, both of them actually.
The Linux kernel already contains different charsets for author full
name and/or commit messages making git-log output a mix of encodings
already. And sometimes this inconsistency comes from the _same_ author.
Nicolas
^ permalink raw reply
* Re: t5000-tar-tree.sh failing
From: Uwe Kleine-Koenig @ 2006-12-21 18:59 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, git
In-Reply-To: <9A725DAA-FAA8-4779-A73D-ED117CC068C1@silverinsanity.com>
Hello,
Brian Gernhardt wrote:
> Several other test frameworks provide a "skip" method to indicate why
> we've skipped something. We could do something similar...
>
> if skip 'unzip -h' 'tests need unzip'; then
> # unzip tests
> fi
>
> skip() {
> # Have not checked to see if this is anything resembling working code
> if eval $1 > /dev/null 2>&1; then
> true
> else
> echo "* skipping tests: $2" 1>&2
> false
> fi
> }
>
> Mostly so that skipped tests are obvious, provide a reason, and have
> a standardized display format. Again, too busy in actual work to try
> to do this myself right now, but might hack at it this afternoon if
> nobody else (hopefully someone more fluent in shell than I am) does.
I'm not sure if (in this case) a missing unzip should be as silent as
you suggest. The danger is, that s.o. makes a change, runs `make test`
and is then conviced that nothing broke. So I think that the test
should fail, but with a more descriptive error than it is now.
The downside is, you need unzip, svn, what ever more to run the test
suite.
Best regards
Uwe
--
Uwe Kleine-Koenig
http://www.google.com/search?q=gigabyte+in+bit
^ permalink raw reply
* Re: specify charset for commits
From: Uwe Kleine-König @ 2006-12-21 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, Johannes Schindelin, git
In-Reply-To: <7vejqtaz7q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
> > May we can add new header into commit with commit text encoding ?
>
> I do not think we want to change the commit header, nor we would
> want to re-encode, but I can see two possible improvements:
>
> (1) git-am should default to -u; this was suggested on the list
> long time ago, but is an incompatible change. v1.5.0 we
> can afford to be incompatible to make it more usable and
> safer.
>
> (2) update commit-tree to reject non utf-8 log messages and
> author/committer names when i18n.commitEncoding is _NOT_
> set, or set to utf-8.
>
> Maybe later we can use encoding validation routines for
> other encodings by checking i18n.commitEncoding, but at the
> minimum the above would be safe enough for recommended UTF-8
> only cases.
As I only want to use UTF-8 both suggestions are fine for me.
Is there a generic way to check an encoding? (I don't know if there is
an encoding that can encode everything. If so, we could use iconv -f
$enc -t superencoding. Until now I thought UTF-8 can do, but in the
post Johannes pointed out, you (Junio) implyed that it cannot.)
Best regards
Uwe
--
Uwe Kleine-König
dd if=/proc/self/exe bs=1 skip=1 count=3 2>/dev/null
^ 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