* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-10 5:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pavel Roskin, git
In-Reply-To: <7vu0hzw9sx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> - Multiple -m options was actually a feature of my version of the patch.
>
> Ah, OK.
I said "OK" and thought about it again. While thinking about
what is the right inter-message-piece separator for multiple -m
parameters (you use "\n"), I got a headache. I decided to keep
what is already there after all ;-).
I'll push things out tonight and expect to tag things tomorrow
late afternoon to declare 0.99.4
^ permalink raw reply
* Re: gitweb - feature request
From: Ian Campbell @ 2005-08-10 5:53 UTC (permalink / raw)
To: Kay Sievers; +Cc: Sam Ravnborg, git
In-Reply-To: <20050809195818.GA19284@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
On Tue, 2005-08-09 at 21:58 +0200, Kay Sievers wrote:
> I was hoping people that want stuff like this would use a RSS reader. :)
I used to subscribe to the kernel RSS feed (using blam) but I found I
was only getting the most recent 20 commits, which wasn't much good when
a big batch went in because I would miss some. Has this been fixed or
was it something I was doing wrong?
Ian.
--
Ian Campbell
hipatitis:
Terminal coolness.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cannot install git RPM
From: Wolfgang Denk @ 2005-08-10 7:46 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20050810003012.GB22778@mythryan2.michonline.com>
In message <20050810003012.GB22778@mythryan2.michonline.com> you wrote:
>
> > The problematic one is git-send-email-script.
>
> Yup. I'll take the blame for that one - I forget how inclusive the
> Debian packaging is compared to the other distributions.
Actually this may be more of a problem with Fedora Core / RedHat
dependency generation and checking.
As far as the RPM *build* is concerned this looks pretty harmless to
me:
BuildRequires: zlib-devel, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
...
Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
But the RPM itself seems to contain additional information about
required packages:
# rpm -q --requires -p /usr/local/RPMS/i386/git-core-0.99.3-1.i386.rpm
/bin/sh
/usr/bin/env
/usr/bin/perl
diffutils
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libcrypto.so.4
libcurl.so.2
libssl.so.4
libz.so.1
mktemp >= 1.5
perl(Data::Dumper)
perl(Email::Valid)
perl(File::Basename)
perl(File::Path)
perl(File::Spec)
perl(File::Temp)
perl(Getopt::Long)
perl(Getopt::Std)
perl(IO::Pipe)
perl(IO::Socket)
perl(Mail::Sendmail)
perl(POSIX)
perl(Term::ReadLine)
perl(Time::Local)
perl(strict)
perl(warnings)
rcs
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rsync
sh-utils
It's then the "perl(Email::Valid)" and "perl(Mail::Sendmail)" depen-
dencies which cause problems. I installed all perl packages and
modules I was able to find in the standard FC places, but this did
not solve the problem. Maybe this is actually a bug in Fedora Core ?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim"
- Edsgar W. Dijkstra
^ permalink raw reply
* Re: gitweb - feature request
From: Mitchell Blank Jr @ 2005-08-10 8:31 UTC (permalink / raw)
To: Ian Campbell; +Cc: Kay Sievers, git
In-Reply-To: <1123653220.1183.26.camel@azathoth.hellion.org.uk>
Ian Campbell wrote:
> I used to subscribe to the kernel RSS feed (using blam) but I found I
> was only getting the most recent 20 commits, which wasn't much good when
> a big batch went in because I would miss some.
Yes, I have that problem too. It appears to be just the way that gitweb
works - look at the "git_rss" function in the source:
ftp://ftp.kernel.org/pub/software/scm/gitweb/gitweb.cgi
Kay -- is there any chance of fixing this? I love reading the kernel
commits via RSS but this makes it a lot less usable than it could be.
Really it should return all commits within, say, the last 36 hours so as
long as your aggregator polls reasonably often you won't miss anyhing.
The other thing on my wishlish is diffstat -- sometimes the commit messages
can be a little ambiguous and just adding what files were changed would
help alot. For commits that touch a large number of files maybe it could
just show the files that changed the most like:
net/bar.c | 412 ++++++++++++-----
drivers/char/foo.c | 354 +-------------
arch/baz/boot.S | 99 ++++----
[16 other files changed]
Other than that though I really love gitweb and the RSS support is a
great touch. It really makes tracking kernel commits painless.
-Mitch
^ permalink raw reply
* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Horst von Brand @ 2005-08-10 2:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Pavel Roskin, git
In-Reply-To: <7vd5onvydk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> True. My bad old habit.
> >
> > An elegant method to do that:
> >
> > case --some-long-option in "$1"*) ..; esac
>
> You are almost correct, but you need to realize that I generate
> that long "case -s|--s|--so|--som|..." chain using a script that
> takes all potential option names as its arguments, and makes
> case arms that contain only unambiguous ones, so that I can
> handle --some-long-option and --some-other-long-option sensibly.
My head spins....
Isn't it easier to just use getopt(1)?
> Also you forgot to grok --some-option-with-args=* in your
> version ;-).
Please stop! I'm dizzy already!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Johannes Schindelin @ 2005-08-10 12:52 UTC (permalink / raw)
To: Horst von Brand; +Cc: Junio C Hamano, Pavel Roskin, git
In-Reply-To: <200508100220.j7A2KNWb005040@laptop11.inf.utfsm.cl>
Hi,
On Tue, 9 Aug 2005, Horst von Brand wrote:
> Isn't it easier to just use getopt(1)?
Only if GNU getopt is available. On Mac OS X, only the BSD version is
installed by default, which does not handle long options at all.
> Please stop! I'm dizzy already!
:-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] cg-cat [was: Re: Newbie question: equiv of: cvs co -p <filename> ? ]
From: John Ellson @ 2005-08-10 14:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508091725120.3258@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Linus Torvalds wrote:
>
> On Tue, 9 Aug 2005, John Ellson wrote:
>
>>I hacked this:
> No. ...
> So you could do something like ...
> (totally untested)
>
> Linus
Thanks Linus, also Rene and Johannes.
I applied a bit of polish and testing and now I'm ready to offer
my first contribution to cogito.
cg-cat [-r rev] FILE
I hope that this is useful to others.
Signed-off-by: John Ellson <ellson@research.att.com>
---
[-- Attachment #2: patch0.patch --]
[-- Type: text/x-patch, Size: 1549 bytes --]
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -14,11 +14,11 @@ INSTALL?=install
SCRIPT= commit-id tree-id parent-id cg-add cg-admin-lsobj cg-admin-uncommit \
cg-branch-add cg-branch-ls cg-reset cg-clone cg-commit cg-diff \
cg-export cg-help cg-init cg-log cg-merge cg-mkpatch cg-patch \
cg-pull cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update \
- cg cg-admin-ls cg-push cg-branch-chg
+ cg cg-admin-ls cg-push cg-branch-chg cg-cat
LIB_SCRIPT=cg-Xlib cg-Xmergefile cg-Xnormid
GEN_SCRIPT= cg-version
diff --git a/cg-cat b/cg-cat
new file mode 100755
--- /dev/null
+++ b/cg-cat
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# Cat a file(s) by filename from a GIT repository.
+
+# Initiated from a request from: erg@research.att.com
+# for an equivalent to "cvs co -p <filename>"
+# Question posted with really bad initial solution: ellson@research.att.com
+# Suggestions offered by: Johannes.Schindelin@gmx.de
+# rene.scharfe@lsrfire.ath.cx
+# This solution based on posting from: torvalds@osdl.org
+# Polish and test by: ellson@research.att.com
+
+USAGE="cg-cat [-r rev] FILE"
+
+. ${COGITO_LIB}cg-Xlib
+
+default=HEAD
+while optparse; do
+ if optparse -r; then
+ default="$OPTARG"
+ else
+ optfail
+ fi
+done
+
+[ "$ARGS" ] || usage
+
+git-ls-tree $(git-rev-parse --default $default "${ARGS[@]}") |
+ while read mode type sha name
+ do
+ case "$type" in
+ blob)
+ git-cat-file blob "$sha"
+ ;;
+ tree)
+ git-ls-tree "$sha"
+ ;;
+ *)
+ exit 1
+ ;;
+ esac
+ done
^ permalink raw reply
* Re: kernel.org git web interface
From: Sam Ravnborg @ 2005-08-10 16:23 UTC (permalink / raw)
To: Hubert Tonneau, git; +Cc: linux-kernel
In-Reply-To: <05BEHQE11@briare1.heliogroup.fr>
Hi Hubert.
git@vger.kernel.org is a better place to request this.
So I have included them in to:
Sam
On Wed, Aug 10, 2005 at 03:59:02PM +0000, Hubert Tonneau wrote:
> The 'V' column on http://www.kernel.org/ is very convienient to review what
> has changed in a new kernel (files list, then simple clic diff access to the
> selected file).
>
> Now, the git changelog is also interesting (provides overall explaination),
> but it's harder to use because the changes stream is so dense.
>
> So, what would be helpfull for reviewers is the ability to view the git
> changelog of only the changes that touch a given file.
> I mean when we select the 'V' column, have two links per modified file,
> one displaying the diff has it currently does, and the other displaying
> the git changes as 'C' column does, but filtered with only changes that
> touch the selected file.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Cannot install git RPM
From: Chris Wright @ 2005-08-10 16:23 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810074607.30803353C46@atlas.denx.de>
* Wolfgang Denk (wd@denx.de) wrote:
> It's then the "perl(Email::Valid)" and "perl(Mail::Sendmail)" depen-
> dencies which cause problems. I installed all perl packages and
> modules I was able to find in the standard FC places, but this did
> not solve the problem. Maybe this is actually a bug in Fedora Core ?
No, you probably missed the earlier thread on this. It's not a bug,
those are real dependencies which rpm automagically discovers (along
with things like shared library dependencies). The issue is the
git-send-email-script uses Mail/Sendmail.pm and Email/Valid.pm which
aren't part of standard install. Your choices are to grab the relevant
packages, do an install with --nodeps (and know that
git-send-email-script will not work), make a subpackage for that script
so it can have its own dependencies, or move that script to elsewhere
so it's not scanned for depenedency info.
thanks,
-chris
^ permalink raw reply
* Re: Cannot install git RPM
From: Sam Ravnborg @ 2005-08-10 16:32 UTC (permalink / raw)
To: Chris Wright; +Cc: Wolfgang Denk, Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810162307.GE8041@shell0.pdx.osdl.net>
On Wed, Aug 10, 2005 at 09:23:07AM -0700, Chris Wright wrote:
> * Wolfgang Denk (wd@denx.de) wrote:
> > It's then the "perl(Email::Valid)" and "perl(Mail::Sendmail)" depen-
> > dencies which cause problems. I installed all perl packages and
> > modules I was able to find in the standard FC places, but this did
> > not solve the problem. Maybe this is actually a bug in Fedora Core ?
>
> No, you probably missed the earlier thread on this. It's not a bug,
> those are real dependencies which rpm automagically discovers (along
> with things like shared library dependencies). The issue is the
> git-send-email-script uses Mail/Sendmail.pm and Email/Valid.pm which
> aren't part of standard install.
Not knowing perl at all I wonder if some more widespread used packages
can replace the above two?
I recall having trouble locating them myself when I first tried Greg's
send-a-lot-of-mails script.
Sam
^ permalink raw reply
* Re: Cannot install git RPM
From: Chris Wright @ 2005-08-10 16:32 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Chris Wright, Wolfgang Denk, Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810163202.GA11131@mars.ravnborg.org>
* Sam Ravnborg (sam@ravnborg.org) wrote:
> Not knowing perl at all I wonder if some more widespread used packages
> can replace the above two?
> I recall having trouble locating them myself when I first tried Greg's
> send-a-lot-of-mails script.
I'm not too sure, but I too abandoned (well, rewrote in sh) some email
scripts from Greg due to that dependency ;-)
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Darrin Thompson @ 2005-08-09 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, Johannes Schindelin, git
In-Reply-To: <200508081141.23242.Josef.Weidendorfer@gmx.de>
On Mon, 2005-08-08 at 11:41 +0200, Josef Weidendorfer wrote:
> Perhaps we should call it "remoterefs/" instead?
>
How about .git/peers/ ?
--
Darrin
^ permalink raw reply
* Re: [PATCH] Fix git-rev-parse's parent handling
From: Junio C Hamano @ 2005-08-10 17:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508100506260.11734@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> git-rev-parse HEAD^1 would fail,
Thanks. Time to find a brown paper bag ;-).
^ permalink raw reply
* [PATCH] git-tag-script tag message commandline option
From: Chris Wright @ 2005-08-10 18:06 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050809000442.GD8041@shell0.pdx.osdl.net>
[resend more clearly identified as patch]
Apparently I was under a rock sleeping when git-tag-script changed to no
longer take input from stdin. So my script which did:
TAG=$(echo "$TAG_MSG" | git-tag-script $RELEASE)
echo $TAG > .git/refs/tags/$RELEASE
Is broken in two ways. First it's no longer building an annotated tag,
second it creaets a zero length file .git/refs/tags/$RELEASE. Second
issue is trivial to fix in my script. First one needs some change in the
tag script. Below is a simple patch for a stab at fixing. Thoughts?
thanks,
-chris
--
Allow users to create a tag message by passing message on command line
instead of requiring an $EDITOR session.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -4,13 +4,14 @@
. git-sh-setup-script || die "Not a git archive"
usage () {
- echo >&2 "Usage: git-tag-script [-a | -s] [-f] tagname"
+ echo >&2 "Usage: git-tag-script [-a | -s] [-f] [-m "tag message"] tagname"
exit 1
}
annotate=
signed=
force=
+message=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -24,6 +25,11 @@ do
-f)
force=1
;;
+ -m)
+ annotate=1
+ shift
+ message="$1"
+ ;;
-*)
usage
;;
@@ -48,10 +54,14 @@ tagger=$(git-var GIT_COMMITTER_IDENT) ||
trap 'rm -f .tmp-tag* .tagmsg .editmsg' 0
if [ "$annotate" ]; then
- ( echo "#"
- echo "# Write a tag message"
- echo "#" ) > .editmsg
- ${VISUAL:-${EDITOR:-vi}} .editmsg || exit
+ if [ -z "$message" ]; then
+ ( echo "#"
+ echo "# Write a tag message"
+ echo "#" ) > .editmsg
+ ${VISUAL:-${EDITOR:-vi}} .editmsg || exit
+ else
+ echo "$message" > .editmsg
+ fi
grep -v '^#' < .editmsg | git-stripspace > .tagmsg
^ permalink raw reply
* [PATCH] -x (no-exclude) option for cg-status
From: Pavel Roskin @ 2005-08-10 18:42 UTC (permalink / raw)
To: Petr Baudis, git
Hello!
I'm trying to reimplement my cg-clean script so that it reuses more code
from other utilities. This patch makes it possible to call cg-status
from cg-clean.
This patch adds the "-x" option that instructs cg-status not to ignore
any files. Also, the code has been changed to add standard includes in
a loop.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-status b/cg-status
--- a/cg-status
+++ b/cg-status
@@ -34,6 +34,9 @@
# -w::
# Show the working tree file list.
#
+# -x::
+# Don't exclude any files from listing.
+#
# FILES
# -----
# $GIT_DIR/exclude::
@@ -53,11 +56,14 @@ USAGE="cg-status [-g] [-w]"
gitstatus=
workstatus=
+noexclude=
while optparse; do
if optparse -g; then
gitstatus=1
elif optparse -w; then
workstatus=1
+ elif optparse -x; then
+ noexclude=1
else
optfail
fi
@@ -116,18 +122,21 @@ fi
if [ "$workstatus" ]; then
- EXCLUDEFILE=$_git/exclude
EXCLUDE=
- if [ -f $EXCLUDEFILE ]; then
- EXCLUDE="$EXCLUDE --exclude-from=$EXCLUDEFILE"
+ if [ -z "$noexclude" ]; then
+ EXCLUDEFILE=$_git/exclude
+ for excl in '*.[ao]' '.*' tags '*~' '#*' ',,merge*'; do
+ EXCLUDE="$EXCLUDE --exclude=$excl"
+ done
+ if [ -f $EXCLUDEFILE ]; then
+ EXCLUDE="$EXCLUDE --exclude-from=$EXCLUDEFILE"
+ fi
+ EXCLUDE="$EXCLUDE --exclude-per-directory=.gitignore"
fi
git-update-cache --refresh > /dev/null
- git-ls-files --others --exclude='*.[ao]' --exclude='.*' --exclude=tags \
- --exclude='*~' --exclude='#*' \
- --exclude=',,merge*' $EXCLUDE \
- --exclude-per-directory=.gitignore |
+ git-ls-files --others $EXCLUDE |
{ if [ "$_git_relpath" ]; then sed -n "s|^$_git_relpath||p"; else cat; fi } |
sed 's,^,? ,'
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Cannot install git RPM
From: Wolfgang Denk @ 2005-08-10 19:44 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Chris Wright, Wolfgang Denk, Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810163202.GA11131@mars.ravnborg.org>
In message <20050810163202.GA11131@mars.ravnborg.org> you wrote:
>
> Not knowing perl at all I wonder if some more widespread used packages
> can replace the above two?
Installation of the required modules from the CPAN is trivial. It
should be documented somewhere, though.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
^ permalink raw reply
* Re: Cannot install git RPM
From: Wolfgang Denk @ 2005-08-10 19:44 UTC (permalink / raw)
To: Chris Wright; +Cc: Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810162307.GE8041@shell0.pdx.osdl.net>
In message <20050810162307.GE8041@shell0.pdx.osdl.net> you wrote:
> * Wolfgang Denk (wd@denx.de) wrote:
> > It's then the "perl(Email::Valid)" and "perl(Mail::Sendmail)" depen-
> > dencies which cause problems. I installed all perl packages and
> > modules I was able to find in the standard FC places, but this did
> > not solve the problem. Maybe this is actually a bug in Fedora Core ?
>
> No, you probably missed the earlier thread on this. It's not a bug,
> those are real dependencies which rpm automagically discovers (along
> with things like shared library dependencies). The issue is the
> git-send-email-script uses Mail/Sendmail.pm and Email/Valid.pm which
> aren't part of standard install. Your choices are to grab the relevant
They are not only not part of a standard installation, but:
o I was not able to find any perl modules in the whole Fedora Core
distribution that satisfied these dependencies.
o Manually installing Email::Valid and Mail::Sendmail (plus the
required prerequisites) from CPAN worked find, but RPM still
complains.
> packages, do an install with --nodeps (and know that
That's what I did.
> git-send-email-script will not work), make a subpackage for that script
But it will work, as the required Perl modules are installed.
My problem is that I cannot satisfy the dependencies in a way which
gets visible to RPM. And this is where I feel this is a bug in Fedora
Core. But probably I'm just too dumb.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A mouse is an elephant built by the Japanese.
^ permalink raw reply
* Re: Cannot install git RPM
From: Chris Wright @ 2005-08-10 19:57 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Chris Wright, Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050810194458.1F1F5353C12@atlas.denx.de>
* Wolfgang Denk (wd@denx.de) wrote:
> My problem is that I cannot satisfy the dependencies in a way which
> gets visible to RPM. And this is where I feel this is a bug in Fedora
> Core. But probably I'm just too dumb.
No, it's just lack of good support. Try rpm.pbone.net, they are there.
^ permalink raw reply
* Re: Cannot install git RPM
From: Junio C Hamano @ 2005-08-10 20:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Sam Ravnborg, Chris Wright, Ryan Anderson, git
In-Reply-To: <20050810194459.8584D353C12@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes replying to Sam Ravnborg:
> In message <20050810163202.GA11131@mars.ravnborg.org> you wrote:
>>
>> Not knowing perl at all I wonder if some more widespread used packages
>> can replace the above two?
>
> Installation of the required modules from the CPAN is trivial. It
> should be documented somewhere, though.
I would appreciate a patch for RPM building after 0.99.4, but
the tentative solution for 0.99.4 (and current "master" branch
since last night) is to ship the problematic program as part of
the sources under "contrib" status, but not install nor include
in the resulting binary package.
The dependency list for the RPM built from the tip of "rc"
branch now reads like this (thanks Chris for teaching me how to
get this information). This will hopefully be the one that
becomes the official 0.99.4.
$ rpm -qp ~/rpms/RPMS/i386/git-core-0.99.4-1.i386.rpm --requires
/bin/sh
/usr/bin/env
/usr/bin/perl
diffutils
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libcrypto.so.4
libcurl.so.3
libssl.so.4
libz.so.1
mktemp >= 1.5
perl(File::Basename)
perl(File::Path)
perl(File::Spec)
perl(File::Temp)
perl(Getopt::Std)
perl(IO::Pipe)
perl(IO::Socket)
perl(POSIX)
perl(Time::Local)
perl(strict)
perl(warnings)
rcs
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rsync
sh-utils
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Matthias Urlichs @ 2005-08-10 21:15 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> For Debian, we recommend lib*-*-perl packages. Do we need to recommend
> perl itself as well, or is it the case that things that are covered with
> the automatic dependency chain need not be listed?
No, yes. ;-)
What happens if the lib*-perl packages are not installed? If some scripts
break, that's a Bad Thing, and would require those packages to be moved to
Depends:.
> Earlier I said that
> the Debian side is reasonably accurate to the best of my knowledge, but I
> would appreciate it if somebody ran lintian on it.
Will do.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"I say we take off; nuke the site from orbit. It's the only way to be sure."
- Corporal Hicks, in "Aliens"
^ permalink raw reply
* Re: Template files location
From: Matthias Urlichs @ 2005-08-10 22:03 UTC (permalink / raw)
To: git
In-Reply-To: <42F3A6E5.2070502@gmail.com>
Hi, A Large Angry SCM wrote:
> Rather than changing the default install location in such a way as to make
> half the user unhappy, make everybody (un)happy by removing the default
> and forcing it to be specified when make is executed.
Lots of stuff installs to /usr/local if not stated otherwise.
I don't see why git should be different.
Why make *everybody* unhappy if we can avoid it?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Grain grows best in shit
-- U. K. LeGuin
^ permalink raw reply
* [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-10 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2005.08.10.21.15.41.143251@smurf.noris.de>
Debian packaging fixes for 0.99.4:
- Add a debian/changelog entry.
- Split gitk off to its own package;
it needs tk installed, but nothing else does.
- Refer to GPL properly, don't install COPYING.
- Fix maintainer.
- Use dh_movefiles instead of dh_install;
we don't want to list everything *except* gitk.
---
More Lintian warnings (not fixed by this patch):
W: git-core: binary-without-manpage git-LOTS
W: git-tk: binary-without-manpage gitk
Debian *really* dislikes exec tricks:
E: git-tk: shell-script-fails-syntax-check ./usr/bin/gitk
git-parse-remote is not an executable script and therefore
does *not* belong in /usr/bin:
W: git-core: executable-not-elf-or-script ./usr/bin/git-parse-remote
Do we need any newer features of diff? If not => drop from Depends:.
E: git-core: depends-on-essential-package-without-using-version depends: diff
---
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.4-1) unstable; urgency=low
+
+ * Lots and lots of changes.
+
+ -- Matthias Urlichs <smurf@debian.org> Wed, 10 Aug 2005 23:18:34 +0200
+
git-core (0.99-2) unstable; urgency=low
* Conflict with the GNU Interactive Tools package, which also installs
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: git-core
Section: devel
Priority: optional
-Maintainer: Linus Torvalds <torvalds@osdl.org>
+Maintainer: Junio C Hamano <junkio@cox.net>
Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc > 6.0.3, xmlto, debhelper (>= 4.0.0)
Standards-Version: 3.6.1
@@ -15,5 +15,11 @@ Description: The git content addressable
and flexible filesystem-based database designed to store directory trees
with regard to their history. The top layer is a SCM-like tool which
enables human beings to work with the database in a manner to a degree
- similar to other SCM tools (like CVS, BitKeeper or Monotone).
+ similar to other SCM tools.
+
+Package: git-tk
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
+Description: The git content addressable filesystem, GUI add-on
+ This package contains 'gitk', the git revision tree visualizer
diff --git a/debian/copyright b/debian/copyright
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,3 +1,19 @@
-License:
+This package was downloaded from ftp.kernel.org:/INSERT_PATH_HERE
-GPL v2 (see COPYING for details)
+Upstream Author: Linus Torvalds and many others
+
+Copyright:
+
+ Copyright 2005, Linus Torvalds and others.
+
+ This file is free software; as a special exception the author gives
+ unlimited permission to copy and/or distribute it, with or without
+ modifications, as long as this notice is preserved.
+
+ This file is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+This program is free-software released under the terms of the GNU Public
+License, version 2.0. Please check /usr/share/common-licenses/GPL for
+more information.
diff --git a/debian/docs b/debian/docs
--- a/debian/docs
+++ b/debian/docs
@@ -1,3 +1 @@
README
-COPYING
-
diff --git a/debian/git-core.files b/debian/git-core.files
new file mode 100644
--- /dev/null
+++ b/debian/git-core.files
@@ -0,0 +1 @@
+/usr
diff --git a/debian/git-core.install b/debian/git-core.install
deleted file mode 100644
--- a/debian/git-core.install
+++ /dev/null
@@ -1 +0,0 @@
-*
diff --git a/debian/git-tk.files b/debian/git-tk.files
new file mode 100644
--- /dev/null
+++ b/debian/git-tk.files
@@ -0,0 +1 @@
+/usr/bin/gitk
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -61,7 +61,9 @@ install: build
mkdir -p $(DOC_DESTDIR)
find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
- dh_install --list-missing --sourcedir=$(DESTDIR)
+ dh_movefiles -p git-tk
+ dh_movefiles -p git-core
+ find debian/tmp -type d -o -print | sed -e 's/^/? /'
binary: build install
dh_testdir
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Any false value is gonna be fairly boring in Perl, mathematicians
notwithstanding.
-- Larry Wall in <199707300650.XAA05515@wall.org>
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Martin Langhoff @ 2005-08-10 22:56 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.10.22.11.25.242201@smurf.noris.de>
On 8/11/05, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Debian packaging fixes for 0.99.4:
Is this anywhere in the archive?
cheers,
martin
^ permalink raw reply
* GIT v0.99.4
From: Junio C Hamano @ 2005-08-10 23:02 UTC (permalink / raw)
To: git
Thanks a lot to everybody who sent in usability enhancements and
bugfixes.
Updates since v0.99.3:
- HTTP transport can pull from a packed repository.
- RPM and Debian packages are hopefully usable out of the box.
- Read-only operations on read-only repository should work better.
- Commit and tag takes the message from the command line with -m.
- Shortlog does not show things in reverse anymore.
- Many commands now natively know SHA1 expressions (e.g. HEAD^^2).
- Push can update remote refs that have different names from local.
- Comes with the latest gitk.
- A new command "git revert"
- A bulk e-mailer (not installed by default).
- Hopefully less leaky and less buggy.
^ permalink raw reply
* Speed up git-merge-base a lot
From: Linus Torvalds @ 2005-08-10 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In commit 4f7eb2e5a351e0d1f19fd4eab7e92834cc4528c2 I fixed git-merge-base
getting confused by datestamps that caused it to traverse things in a
non-obvious order.
However, my fix was a very brute-force one, and it had some really
horrible implications for more complex trees with lots of parallell
development. It might end up traversing all the way to the root commit.
Now, normally that isn't that horrible: it's used mainly for merging, and
the bad cases really tend to happen fairly rarely, so if it takes a few
seconds, we're not in too bad shape.
However, gitk will also do the git-merge-base for every merge it shows,
because it basically re-does the trivial merge in order to show the
"interesting" parts. And there we'd really like the result to be
instantaneous.
This patch does that by walking the tree more completely, and using the
same heuristic as git-rev-list to decide "ok, the rest is uninteresting".
In one - hopefully fairly extreme - case, it made a git-merge-base go from
just under five seconds(!) to a tenth of a second on my machine.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -2,6 +2,22 @@
#include "cache.h"
#include "commit.h"
+#define PARENT1 1
+#define PARENT2 2
+#define UNINTERESTING 4
+
+static int interesting(struct commit_list *list)
+{
+ while (list) {
+ struct commit *commit = list->item;
+ list = list->next;
+ if (commit->object.flags & UNINTERESTING)
+ continue;
+ return 1;
+ }
+ return 0;
+}
+
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
@@ -18,19 +34,18 @@ static struct commit *common_ancestor(st
insert_by_date(rev1, &list);
insert_by_date(rev2, &list);
- while (list) {
+ while (interesting(list)) {
struct commit *commit = list->item;
struct commit_list *tmp = list, *parents;
- int flags = commit->object.flags & 3;
+ int flags = commit->object.flags & 7;
list = list->next;
free(tmp);
- switch (flags) {
- case 3:
+ if (flags == 3) {
insert_by_date(commit, &result);
- continue;
- case 0:
- die("git-merge-base: commit without either parent?");
+
+ /* Mark children of a found merge uninteresting */
+ flags |= UNINTERESTING;
}
parents = commit->parents;
while (parents) {
^ 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