* Re: GIT 0.99.9
From: Wolfgang Denk @ 2005-10-30 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvezesyhi.fsf@assigned-by-dhcp.cox.net>
In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> I hate it when somebody tells me "it works for me", but I cannot
> help you here, sorry. I'm no rpm expert and the "make rpm" rule
> seems to work for me.
Which environment (Linux distribution) did you test this on? I tried
Fedora Core 2 and 4, both with the same result. I get the same
problem when building from the git source tree or when using the
source RPM.
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 person with one watch knows what time it is; a person with two
watches is never sure. Proverb
^ permalink raw reply
* Re: GIT 0.99.9
From: Wolfgang Denk @ 2005-10-30 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvezesyhi.fsf@assigned-by-dhcp.cox.net>
In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> > "make rpm" does not work for me:
>
> I hate it when somebody tells me "it works for me", but I cannot
> help you here, sorry. I'm no rpm expert and the "make rpm" rule
> seems to work for me.
OK, I found the problem. The key part is this:
[current directory: .../usr/share/git-core/templates/]
(cd blt && tar cf - .) | \
(cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
I have CDPATH set in my shell environment, and bash outputs the
pathname of the new working directory on stdout; this gets piped
together with the tarball to the "tar xf -", and the second tar
complains that the directory name comes unexpected. Test:
-> cd /usr/local/BUILD/git-core-0.99.9/templates
-> cd blt
/usr/local/BUILD/git-core-0.99.9/templates/blt
->
As a workaround I can simply unset CDPATH, and the build works fine.
A more robust build script woul make sure that CDPATH is not set.
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
Testing can show the presense of bugs, but not their absence.
-- Edsger Dijkstra
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Wolfgang Denk @ 2005-10-30 20:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43652934.8000308@zytor.com>
In message <43652934.8000308@zytor.com> you wrote:
> The Subversion importer Perl script breaks RPM generation. First of
Confirmed. Well, actually the RPM *build* works fine.
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.
It's when trying to install the RPM that we get:
error: Failed dependencies:
perl(v5.8.0) is needed by git-core-0.99.9-1.i386
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
"There are things that are so serious that you can only joke about
them" - Heisenberg
^ permalink raw reply
* Re: GIT 0.99.9
From: Junio C Hamano @ 2005-10-30 20:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20051030202322.A65D2353CD1@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>>
>> I hate it when somebody tells me "it works for me", but I cannot
>> help you here, sorry. I'm no rpm expert and the "make rpm" rule
>> seems to work for me.
>
> Which environment (Linux distribution) did you test this on? I tried
> Fedora Core 2 and 4, both with the same result. I get the same
> problem when building from the git source tree or when using the
> source RPM.
Whatever is running on kernel.org. I think I was once told they
run RH-EL but I do not have that e-mail now.
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: H. Peter Anvin @ 2005-10-30 20:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Git Mailing List
In-Reply-To: <20051030204034.849C5353E3E@atlas.denx.de>
Wolfgang Denk wrote:
> In message <43652934.8000308@zytor.com> you wrote:
>
>>The Subversion importer Perl script breaks RPM generation. First of
>
> Confirmed. Well, actually the RPM *build* works fine.
No, it doesn't. It runs to completion, but it produces the wrong output.
-hpa
^ permalink raw reply
* What are the correct arguments to git-svnimport?
From: Chris Shoemaker @ 2005-10-30 21:48 UTC (permalink / raw)
To: git
I was trying to test the git-svnimport script but I've been unable to
get it to run. The docs really aren't very clear about the correct
values of <SVN_repository_URL> and <path>, so maybe I've gotten them
wrong. Or maybe it just doesn't work.
I get tons of 'Unrecognized path: /project/trunk/...'
and I've tried various combinations of SVN_repository_URL and path:
SVN_repository_URL:
http://svn.myhost.com/repo
http://svn.myhost.com/repo/
http://svn.myhost.com/repo/project
http://svn.myhost.com/repo/project/
http://svn.myhost.com/repo/project/trunk
http://svn.myhost.com/repo/project/branches/mybranch
and <path>:
*nothing*
project
project/trunk
project/branches/mybranch
http://svn.myhost.com/repo/project
...etc...
Can someone who actually uses svn-import send me the command-line they
use? Thanks.
-chris
^ permalink raw reply
* Re: rev-list --sparse?
From: Linus Torvalds @ 2005-10-30 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v64rfxuwl.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, 30 Oct 2005, Junio C Hamano wrote:
>
> The --sparse flag does not seem to have much use either; not
> giving pathspec has the same effect.
No.
--sparse _does_ have effect, but it's subtler.
Try "--sparse" together with a pathspec. It will only do the merge
follow optimization.
Now, how useful is that? It's potentially useful as a way to "linearize
the history". For example, let's say that you wanted to simplify the
commit history for a project, and you only cared about the history of
certain files - but you do want all the other files to _exist_ in that
history.
So then you could do "git-rev-list --sparse HEAD -- filelist" and you'd
get the minimal history that is still relevant in those files. Any merges
that touch anything else than those files will becomes just regular diffs:
they'll have been linearized away.
Useful? Quite possibly not. But I felt that simplifying merges was
conceptually a very different operation from then compressing a linear
history.
Linus
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Junio C Hamano @ 2005-10-30 22:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43652934.8000308@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.
>
> I'm afraid I cannot update any of the kernel.org machines to 0.99.9
> until these problems have been cleaned up.
Fair enough. We'd work it around just like we handle
send-email.
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Ryan Anderson @ 2005-10-30 22:28 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, rpm-list
In-Reply-To: <43652934.8000308@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
H. Peter Anvin wrote:
> The Subversion importer Perl script breaks RPM generation. First of
> all, it introduces new module dependencies which don't exist in for
> example RHEL4. The easiest way to deal with that is probably to fork
> off the subversion exporter into a separate package, but the really bad
> one is:
>
> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.
If you change that to the traditional statement of "require 5.008;",
does it fix things up?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: GIT 0.99.9
From: Ryan Anderson @ 2005-10-30 22:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Junio C Hamano, git
In-Reply-To: <20051030203808.A535B353E3E@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
Wolfgang Denk wrote:
> As a workaround I can simply unset CDPATH, and the build works fine.
> A more robust build script woul make sure that CDPATH is not set.
Try setting CDPATH, but not exporting it in your shell startup
configuration.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [PATCH] Do not try installing SVNimport on RPM
From: Junio C Hamano @ 2005-10-30 22:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <7v1x22odka.fsf@assigned-by-dhcp.cox.net>
HPA reports that svnimport uses perl 5.8.4 and the syntax it
uses to require confuses rpmbuild. So let's try demoting the
problematic script just like we do with send-email.
Somebody should supply tested patches to split the package or
whatever is needed if they want to use these scripts on RPM
based systems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
"H. Peter Anvin" <hpa@zytor.com> writes:
> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.
>
> I'm afraid I cannot update any of the kernel.org machines to 0.99.9
> until these problems have been cleaned up.
Does this work for you?
Makefile | 10 ++++++++--
debian/changelog | 6 ++++++
debian/rules | 3 ++-
git.sh | 1 +
4 files changed, 17 insertions(+), 3 deletions(-)
applies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54
e217a63c79ad93b26cb816eede1baf34e27b1e61
diff --git a/Makefile b/Makefile
index 1163dda..c60fb6b 100644
--- a/Makefile
+++ b/Makefile
@@ -52,7 +52,7 @@
# DEFINES += -DUSE_STDEV
-GIT_VERSION = 0.99.9.GIT
+GIT_VERSION = 0.99.9a
CFLAGS = -g -O2 -Wall
ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
@@ -94,7 +94,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \
- git-findtags.perl git-svnimport.perl git-mv.perl
+ git-findtags.perl git-mv.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
@@ -142,6 +142,12 @@ else
GIT_LIST_TWEAK += -e '/^send-email$$/d'
endif
+ifdef WITH_SVNIMPORT
+ SCRIPT_PERL += git-svnimport.perl
+else
+ GIT_LIST_TWEAK += -e '/^svnimport$$/d'
+endif
+
LIB_FILE=libgit.a
LIB_H = \
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..5c5ba55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+ * GIT 0.99.9a
+
+ -- Junio C Hamano <junkio@cox.net> Sun, 30 Oct 2005 14:30:03 -0800
+
git-core (0.99.9-0) unstable; urgency=low
* GIT 0.99.9
diff --git a/debian/rules b/debian/rules
index 568d430..e6b6bad 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,8 +26,9 @@ else
endif
# We do have the requisite perl modules in the mainline, and
-# have no reason to shy away from this script.
+# have no reason to shy away from these scripts.
export WITH_SEND_EMAIL=YesPlease
+export WITH_SVNIMPORT=YesPlease
PREFIX := /usr
MANDIR := /usr/share/man/
diff --git a/git.sh b/git.sh
index 94940ae..cd800bc 100755
--- a/git.sh
+++ b/git.sh
@@ -70,6 +70,7 @@ send-email
shortlog
show-branch
status
+svnimport
tag
verify-tag
whatchanged
---
0.99.9.GIT
^ permalink raw reply related
* Re: GIT 0.99.9
From: Junio C Hamano @ 2005-10-30 22:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20051030203808.A535B353E3E@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> I have CDPATH set in my shell environment,...
I understand some people like CDPATH in their interactive
shells, but I do not see a good reason to export that to random
shell scripts you run from your interactive shell session.
We already have a workaround for this exact silliness in
git-sh-setup. Probably we also need to do this to our build
procedure, I guess. Sigh...
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Junio C Hamano @ 2005-10-30 23:01 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <436548F3.1030507@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
>> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>>
>> ... which RPM thinks means that you need a Perl module called v5.8.0
>> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
>> it nevertheless breaks at the moment.
>
> If you change that to the traditional statement of "require 5.008;",
> does it fix things up?
Ah, I like that better. Let me try that.
^ permalink raw reply
* Re: GIT 0.99.9
From: H. Peter Anvin @ 2005-10-30 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wolfgang Denk, git
In-Reply-To: <7v4q6ymx9w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I understand some people like CDPATH in their interactive
> shells, but I do not see a good reason to export that to random
> shell scripts you run from your interactive shell session.
>
No kidding. Having 'cd' output stuff to stdout is asking for a million
shell scripts to be broken.
-hpa
^ permalink raw reply
* Re: rev-list --sparse?
From: Junio C Hamano @ 2005-10-30 23:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510301337500.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Try "--sparse" together with a pathspec. It will only do the merge
> follow optimization.
Ah, I saw (paths && dense) everywhere but there indeed is one
that only checks paths to call merge simplification -- I missed
that part.
^ permalink raw reply
* Re: [PATCH] Do not try installing SVNimport on RPM
From: Junio C Hamano @ 2005-10-30 23:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43654F4B.30103@zytor.com>
This is based on Ryan's suggestion. Running 'rpm --requires'
on the resulting RPM seems to want these -- which I cannot
judge if this would be something that satisfies you. I'd push
it out if it is OK with you.
Also I do not see "use v5.8.0" you mentioned in a separate
message anywhere in the tree, so I am hoping that should be OK.
junio@hera:~/git(0)$ R=~/rpms/RPMS/i386/git-core-0.99.9a-1.i386.rpm
junio@hera:~/git(0)$ rpm -q -i -p $R --requires | grep 'perl '
/usr/bin/perl
perl >= 0:5.006
perl >= 0:5.008
junio@hera:~/git(0)$ exit
------------
[PATCH] Work around an RPM build problem.
The require statement at the top of git-svnimport seems to confuse
rpmbuild dependency generation. It uses the newer notation "v5.8.0",
and rpm ends up requiring "perl(v5.8.0)", while we would want it to
say something like "perl >= 0:5.008".
Ryan suggests old-style "require 5.008" might fix this problem, so
here it is.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-svnimport.perl | 2 +-
Makefile | 2 +-
debian/changelog | 6 ++++++
3 files changed, 8 insertions(+), 2 deletions(-)
applies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54
c846e15ee31b7226a715646f633fc1fdd2e14cd9
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 20a8572..45b6a19 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -10,7 +10,7 @@
# The head revision is on branch "origin" by default.
# You can change that with the '-o' option.
-require v5.8.0; # for shell-safe open("-|",LIST)
+require 5.008; # for shell-safe open("-|",LIST)
use strict;
use warnings;
use Getopt::Std;
diff --git a/Makefile b/Makefile
index 1163dda..5bb5108 100644
--- a/Makefile
+++ b/Makefile
@@ -52,7 +52,7 @@
# DEFINES += -DUSE_STDEV
-GIT_VERSION = 0.99.9.GIT
+GIT_VERSION = 0.99.9a
CFLAGS = -g -O2 -Wall
ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..7d18483 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+ * GIT 0.99.9a
+
+ -- Junio C Hamano <junkio@cox.net> Sun, 30 Oct 2005 15:03:32 -0800
+
git-core (0.99.9-0) unstable; urgency=low
* GIT 0.99.9
---
0.99.9.GIT
^ permalink raw reply related
* git versus CVS (versus bk)
From: walt @ 2005-10-31 1:50 UTC (permalink / raw)
To: git
My memory is playing tricks on me. I seem to remember running linux
in the 1980's, but the earliest kernel I can find on kernel.org is
dated 1994. Maybe I'm remembering xenix...dunno.
Anyway, I've been tracking Linus's kernel for many years -- long
before bitkeeper or git.
I know just enough to compile and run a kernel, but not enough to
be a software developer. And that is where my question comes from:
Could someone explain to me the shortcomings of CVS which prompted
the development of bk (and then git) -- in a way that a non-developer
like me can understand? Pretend that you are Albert Einstein, trying
to explain your theories to a ten-year-old -- this is always a useful
exercise for those of you who are drowning in micro-details!
I've already done some googling on this subject, but everything I've
found is drenched in those micro-details which make the subject
opaque to me.
Thanks for any pointers!
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Martin Langhoff @ 2005-10-31 1:59 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg>
On 10/31/05, walt <wa1ter@myrealbox.com> wrote:
> Could someone explain to me the shortcomings of CVS which prompted
> the development of bk (and then git) -- in a way that a non-developer
> like me can understand?
You need to understand the SCM "problem space" at least a little bit.
Can't cheat on that unfortunately.
The writeup at http://www.dwheeler.com/essays/scm.html is not perfect,
but should give you a bit of background. It barely covers git -- we
need to prod the author to update it ;)
martin
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: H. Peter Anvin @ 2005-10-31 2:03 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg>
walt wrote:
> My memory is playing tricks on me. I seem to remember running linux
> in the 1980's, but the earliest kernel I can find on kernel.org is
> dated 1994. Maybe I'm remembering xenix...dunno.
The very first version of Linux came out in 1991.
-hpa
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-10-31 2:35 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg>
On Sun, 30 Oct 2005, walt wrote:
>
> My memory is playing tricks on me. I seem to remember running linux
> in the 1980's, but the earliest kernel I can find on kernel.org is
> dated 1994. Maybe I'm remembering xenix...dunno.
-91 was the first version. It was usable (depending on your definition of
"usable" ;) in early -92.
> Could someone explain to me the shortcomings of CVS which prompted
> the development of bk (and then git) -- in a way that a non-developer
> like me can understand?
It's really not very easy to explain why CVS sucks. After all, sometimes
people who have used it for decades have a hard time understanding the
suckiness.
I've used CVS for "real work" at Transmeta, and hey, it worked well
enough. When you have groups of just a couple of tens of people max, and
very strict rules on how to do things, and you trust everybody, CVS works
fine. It starts to really show its problems whenever you need to work
remotely, but there are things you can do to make the pain less.
A lot of CVS people will tell you that it sucks because it can't do
renames, and because certain operations take forever (tagging etc). That's
only superficially true, and it is really a suckiness that comes from some
implementation issues.
SVN fixes (supposedly) those "implementation suckiness" issues. It does so
largely by doing a much better database, which allows it to do certain
things much more efficiently. Personally that part scares me, since I
think it's also a much more fragile setup and there's apparently been
people who lost their entire database to corruption (something that is
very hard to do with CVS, since the "database" is so weak), but that's a
different issue.
But the things that SVN fixes are not the things that really matter in the
end. SVN i sa better CVS, but it still has all the basic fundamental
problems. Namely the fact that it's centralized.
The problem with a centralized model is that there's one point of contact:
you can replicate the central database endlessly, but you can only really
modify it in one place. Which means that anybody who wants to modify
anything at all needs to have write access to that one repository.
Now, you can limit write access in various ways ("user xyz can only write
to these files"), but it still requires an a-priori trust network rather
than a dynamic one. So every single CVS project (and SVN does zero in this
regard) always ends up having politics around the question of who gets
commit privileges, and what the rules for them are.
So one of the worst downsides of CVS is _politics_. People, not
technology.
The other implication of centralization is the fact that it means that you
can't do any off-line work. You need to be able to access the central
database in order to do real work. You can replicate the repository and
try to take it with you and then back-port whatever changes you did when
you come back, but more commonly it means that when you go off with a
laptop, you're either in read-only mode, or you need to have an internet
connection whenever you want to do development. That's just nasty.
The upside of centralization is that a lot of things are easier. Easier to
think about, easier to get a stupid and straightforward idea working.
But if you have hundreds of developers, and you have a dynamic trust
network (I trust some people, they trust others, and we all tend to trust
people more or less depending on what they work on), the CVS model is
absolutely HORRID. It just doesn't work.
Git does all of that right. So did BK, for that matter. There's no
a-priori "these people can commit", because there's no central database.
There's no problem with off-line work, because every repository is totally
self-contained and independent of every other one.
Linus
^ permalink raw reply
* Re: GIT 0.99.9
From: Linus Torvalds @ 2005-10-31 2:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd5lnztav.fsf@assigned-by-dhcp.cox.net>
Btw,
one thing I'd like to see (maybe it already exists and I just have
overlooked it) is some kind of simple readme or something about the
different ways to limit the output of the various git commands.
I've several times been surprised to see people not realize that
"git-whatchanged" takes a file list to limit the files it is interested
in. I also suspect people don't realize that you can limit it by time and
version and file list, all at the same time.
IOW,
git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile
is a valid query: it basically asks for any change to the Makefile in
between versions v0.99.8..v0.99.9, _and_ within the last two weeks, and
asks to show it as a patch, with the shortened commit message.
Is it useful? The above exact line almost certainly isn't, but variations
on the above definitely are. And I suspect a lot of people never even
realized you could do something like that.
(The danger with date-based things is that something may be 4 months old,
but it only got _merged_ yesterday, so it may be new to _you_. And the
--since="2 weeks ago" will not show it, which can be surprising to people
who expect things that are new to _them_ to be shown).
The above limiters now work with "git log" and "gitk" too (they've worked
for a long time with "git-whatchanged", but only with the new git-rev-list
functionality does the name-limiting work for the other commands).
It would be good to make this more well-known, because a lot of people
probably end up using git not as developers, but just to follow what is
going on. And then the different limiters are some of the most important
parts (the date-one is likely the least important one, but limiting by
version and name is _very_ important).
Linus
^ permalink raw reply
* Re: GIT 0.99.9
From: Junio C Hamano @ 2005-10-31 3:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510301838110.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I've several times been surprised to see people not realize that
> "git-whatchanged" takes a file list to limit the files it is interested
> in. I also suspect people don't realize that you can limit it by time and
> version and file list, all at the same time.
> It would be good to make this more well-known, because a lot of people
> probably end up using git not as developers, but just to follow what is
> going on. And then the different limiters are some of the most important
> parts (the date-one is likely the least important one, but limiting by
> version and name is _very_ important).
I've somewhat updated git-rev-list documentation and tried to
categorize the options into commit selectors and presentation
modifiers. The documentation for commands you mentioned in your
message all talk about them describing only frequently used
options, and refer the user to rev-list documentation. I am not
sure this would be enough.
One good thing to have would be to add a section to Tutorial.
Currently we cover building a small project from scratch and
have the readers graduate when they learn basic commit swapping,
but we do not talk much about archaeology tools.
^ permalink raw reply
* Re: GIT 0.99.9
From: Linus Torvalds @ 2005-10-31 4:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4q6yl6wv.fsf@assigned-by-dhcp.cox.net>
On Sun, 30 Oct 2005, Junio C Hamano wrote:
>
> I've somewhat updated git-rev-list documentation and tried to
> categorize the options into commit selectors and presentation
> modifiers. The documentation for commands you mentioned in your
> message all talk about them describing only frequently used
> options, and refer the user to rev-list documentation. I am not
> sure this would be enough.
I don't think people really follow the links or think very abstractly at
all in the first place.
So I was thinking more of some explicit examples. I actually think every
command should have an example in the man-page, and hey, here's a patch to
start things off.
Of course, I'm not exactly "Mr Documentation", and I don't know that this
is the prettiest way to do this, but I checked that the resulting html and
man-page seems at least reasonable.
And hey, if the examples look like each other, that's just because I'm
also not "Mr Imagination".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
I think most people understand a lot better from practice than from
theory, and that an example of real usage is much more likely to make
people udnerstand a command than just listing what it can do.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 13a3998..9cac088 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -30,6 +30,24 @@ OPTIONS
Show only commits between the named two commits.
+Examples
+--------
+git log --no-merges::
+
+ Show the whole commit history, but skip any merges
+
+git log v2.6.12.. include/scsi drivers/scsi::
+
+ Show all commits since version 'v2.6.12' that changed any file
+ in the include/scsi or drivers/scsi subdirectories
+
+git log --since="2 weeks ago" -- gitk::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The "--" is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index e6f57d9..6c150b0 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -51,6 +51,20 @@ OPTIONS
However, it is not very useful in general, although it
*is* useful on a file-by-file basis.
+Examples
+--------
+git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+
+ Show as patches the commits since version 'v2.6.12' that changed
+ any file in the include/scsi or drivers/scsi subdirectories
+
+git-whatchanged --since="2 weeks ago" -- gitk::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The "--" is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e5ef6d6..eb126d7 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -24,6 +24,19 @@ OPTIONS
Some argument not yet documented.
+Examples
+--------
+gitk v2.6.12.. include/scsi drivers/scsi::
+
+ Show as the changes since version 'v2.6.12' that changed any
+ file in the include/scsi or drivers/scsi subdirectories
+
+gitk --since="2 weeks ago" -- gitk::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The "--" is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
Author
------
Written by Paul Mackerras <paulus@samba.org>
^ permalink raw reply related
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Junio C Hamano @ 2005-10-31 5:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43652934.8000308@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.
I took Ryan's suggestion and pushed 0.99.9a out. Does it make
RHEL4 happy?
^ permalink raw reply
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Chris Wright @ 2005-10-31 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vy84ajl4c.fsf@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
> >
> > ... which RPM thinks means that you need a Perl module called v5.8.0
> > which doesn't, of course, exist. This is arguably an rpmbuild bug, but
> > it nevertheless breaks at the moment.
>
> I took Ryan's suggestion and pushed 0.99.9a out. Does it make
> RHEL4 happy?
It's fine for FC3. Certain irony that git now effectively requires
subversion. I'm all for splitting these out, but have no time until
later in the week. BTW, mind pushing the tag?
thanks,
-chris
^ 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