* Re: Prepare "git-merge-tree" for future work
From: Junio C Hamano @ 2006-06-30 2:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606281401540.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I punted on trying to use the proper git diff interfaces (they are very
> tightly tied into the "diff_filespec" model - Junio, it might be nice if
> there was some way to use them in a setting where that isn't necessarily
> as natural).
I am not quite sure what you mean. You have a sets of
filepairs, each of which is a pair of filespec, each of which
describes the blob. And diff is about comparing them, possibly
after running rename detection, pickaxe filtering and such. If
the merge-tree's internal representation for each blob is more
efficient or easier to use we could switch to use it as an
improved implementation of filespec but I do not think that is
what you meant, because I suspect that approach does not break
diff from the "model". Care to elaborate a bit more please?
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Linus Torvalds @ 2006-06-30 2:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: Michal Ludvig, linux-crypto, git
In-Reply-To: <20060630013627.GA27527@gondor.apana.org.au>
On Fri, 30 Jun 2006, Herbert Xu wrote:
>
> On Fri, Jun 30, 2006 at 01:18:24PM +1200, Michal Ludvig wrote:
> >
> > just a quick question: how can I create a patch with all changes in
> > cryptodev-2.6 tree against tag v2.6.16 in Linus tree? I've got
> > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> > cloned here and want to extract all your commits in this tree since
> > 2.6.16. Is there a way to do it in Git/Cogito?
>
> OK, it's easier if you break this into three problems.
>
> You start by getting all the changes merged right after 2.6.16. This
> can be done by locating the merge changeset in Linus's tree. It looks
> like this:
Actually, there are certainly other, potentially easier, ways to do this.
It depends a bit on what Michal wants, though. Since the current trees
(both mine and the cryptodev tree) have been merging things back and
forth, it's _not_ as easy as just saying "pick all commits that exist in
one branch but not the other", but depending on what Michal wants to do,
git gives other ways to prune out just the info he wants.
The easiest by far is if you only care about a certain sub-directory.
Then, assuming the branch "crypto" is the top-most commit of the cryptodev
repo, just do
git diff v2.6.16..crypto -- crypto/
and that will give you a diff of all the changes since v2.6.16 inside that
subdirectory. That may or may not be sufficient and what Michal wants.
Now, the cryptodev-2.6.git tree doesn't even contain the v2.6.16 tags, but
you can fix that by just doing
git fetch --tags git://git.kernel.org//pub/scm/linux/kernel/git/torvalds/linux-2.6
even if your clone is actually from just the cryptodev-2.6 archive.
Alternatively, if you want to see the individual changes, you can just do
git log -p --full-diff v2.6.16..crypto -- crypto/
which shows you all the commits that changed the crypto/ subdirectory, AND
it shows the other changes those same commits did to other subdirectories
too (which is usually something you want in a case like this).
Finally, what you can also do is that instead of matching for stuff that
changed the crypto/ subdirectory, you could try to match commits where the
committer is somebody special, eg Herbert Xu. We don't have that kind of
thing automated, but here's one way to do it:
git-rev-list --header v2.6.16..crypto |
grep -z 'committer Herbert Xu' |
tr '\0' '\n' |
sed -n '/^[a-f0-9][a-f0-9]*$/p' |
git diff-tree --pretty -p --stdin |
less -S
where the "git-rev-list --header | grep -z" part picks out any commits
committed by Herbert, the "tr '\0' '\n' | sed -n" part then picks up just
the commit ID's from those lines, and the "git-diff-tree" part then shows
those commits as diffs.
(The above should really be quite possible to shorten as
git log -p --committer="Herbert Xu"
but we don't actually support git-rev-list doing matching on
committer/author names - although it should be easy to do in case somebody
wants to have a small git project to get their toes wet, hint hint)
Linus
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 2:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejx7oa3x.fsf@assigned-by-dhcp.cox.net>
So here is my proposal how extended expressions would work:
extended expressions have three operators:
AND, OR (binary), NOT (unary)
extended expressions do not need an extra option. They will be usable
by adding operators between the expressions; a default operator is
used if no operator is specified. The default operator is by default
OR because currently multiple patterns are combined by OR.
OR and AND have precedence, so there are two possibilities, I'd take
the first one.
1. OR, AND:
This will make it easier to read because OR can be skipped:
pat1 pat2 AND pat3 pat4
= pat1 OR pat2 AND pat3 OR pat4
= (pat1 OR pat2) AND (pat3 OR pat4)
2. AND, OR:
This is a bit more logic if you think of AND as * and OR as +.
Parenthesis may be used to explicitly override the default precedence.
With this setup we can add an option -FOO (I don't now how to call it,
it is the --and from the patch) which changes the default operator and
the precedence. With -FOO you'd get AND as default operator and
precedence AND, OR. Without this option it was easy to write the
formula in a conjungtive form (conjunction of disjunctions), now it is
easy to write a disjunctive form (disjunction of conjunctions):
pat1 pat2 OR pat3 pat4
= pat1 AND pat2 OR pat3 AND pat4
= (pat1 AND pat2) OR (pat3 AND pat4)
With all this as plan for extended expressions we may also introduce
-FOO now with exactly the behaviour of --and in my patch because
currently no explicit operators and parenthesis are allowed, so only
the default operator may be used and -FOO would change the default
operator.
A short example:
(pat1 AND pat2 AND pat3) OR pat4
could be written as
-FOO pat1 pat2 pat3 OR pat4
which is imho quite readable.
So the next problem are names for the options. We would need
- AND: between patterns
- OR: between patterns
- NOT: before a pattern
- FOO: change default operator and precedence
Unfortunately -o, -a, -n are taken and I think the options should be
unique even though they are only allowed at certain positions of the
argument list. I'll think about it a bit, perhaps someone else has a
good idea. FOO should not be named --and imo but I don't have any idea
for a good name atm.
^ permalink raw reply
* Re: Prepare "git-merge-tree" for future work
From: Linus Torvalds @ 2006-06-30 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejx7mmaj.fsf@assigned-by-dhcp.cox.net>
On Thu, 29 Jun 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > I punted on trying to use the proper git diff interfaces (they are very
> > tightly tied into the "diff_filespec" model - Junio, it might be nice if
> > there was some way to use them in a setting where that isn't necessarily
> > as natural).
>
> I am not quite sure what you mean.
For what I wanted to do, I didn't see an easy way to add/populate a new
filespec. It was easier to just use the raw libxdiff interfaces, but
that's really just because I know the interfaces.
In contrast, the ones to diff_filespec I've never really used, and I did
not want to compare blob objects, I very much wanted to compare in-memory
buffers (_and_ potentially blobs).
So if you can show an easy example of how to populate a set of filespec
pairs (not with blobs - with in-memory generated data) and insert them
onto the lists, that would be good.
In fact, maybe you can show me what git-merge-tree needs to do..
Hint hint.
Linus
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Herbert Xu @ 2006-06-30 2:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michal Ludvig, linux-crypto, git
In-Reply-To: <Pine.LNX.4.64.0606291904250.12404@g5.osdl.org>
On Thu, Jun 29, 2006 at 07:25:01PM -0700, Linus Torvalds wrote:
>
> The easiest by far is if you only care about a certain sub-directory.
> Then, assuming the branch "crypto" is the top-most commit of the cryptodev
> repo, just do
>
> git diff v2.6.16..crypto -- crypto/
Yes, you should always do something like this when backporting to make
sure that you haven't missed patches merged in ways that you didn't
anticipate.
Although I'm not aware of any such patches in the time frame that Michal
has in mind.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Linus Torvalds @ 2006-06-30 2:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: Michal Ludvig, linux-crypto, git
In-Reply-To: <20060630023228.GA28850@gondor.apana.org.au>
On Fri, 30 Jun 2006, Herbert Xu wrote:
> On Thu, Jun 29, 2006 at 07:25:01PM -0700, Linus Torvalds wrote:
> >
> > The easiest by far is if you only care about a certain sub-directory.
> > Then, assuming the branch "crypto" is the top-most commit of the cryptodev
> > repo, just do
> >
> > git diff v2.6.16..crypto -- crypto/
>
> Yes, you should always do something like this when backporting to make
> sure that you haven't missed patches merged in ways that you didn't
> anticipate.
>
> Although I'm not aware of any such patches in the time frame that Michal
> has in mind.
Note that this is why
git log -p --full-diff v2.6.16.. crypto/
is so great. It will show everything that touched that subdirectory, along
with the incidentals. I think that in this case, that's exactly what
Michal wants.
Linus
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Michal Ludvig @ 2006-06-30 3:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Herbert Xu, linux-crypto, git
In-Reply-To: <Pine.LNX.4.64.0606291943010.12404@g5.osdl.org>
Linus Torvalds wrote:
> Note that this is why
>
> git log -p --full-diff v2.6.16.. crypto/
>
> is so great. It will show everything that touched that subdirectory, along
> with the incidentals. I think that in this case, that's exactly what
> Michal wants.
Exactly!
I just want to have the latest greatest CryptoAPI on 2.6.16, it's that
simple ;-)
Thanks both for a quick response
Michal
^ permalink raw reply
* [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Nicolas Pitre @ 2006-06-30 3:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtazobkw.fsf@assigned-by-dhcp.cox.net>
Without this there would never be a chance to improve packing for
previously undeltified objects.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Thu, 29 Jun 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Thu, 29 Jun 2006, Linus Torvalds wrote:
> >
> >>
> >>
> >> On Thu, 29 Jun 2006, Nicolas Pitre wrote:
> >> >
> >> > On Thu, 29 Jun 2006, Linus Torvalds wrote:
> >> >
> >> > > Instead of having a separate cache, wouldn't it be much better to just
> >> > > take the hint from the previous pack-file?
> >> >
> >> > DOH! ;-)
> >>
> >> Btw, I think this could do with a flag to turn it on/off (but probably
> >> default to on).
> >
> > I think it should simply be coupled with the --no-reuse-delta flag.
>
> I agree that makes sense.
So here it is.
diff --git a/pack-objects.c b/pack-objects.c
index 6e17676..47da33b 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -989,9 +989,10 @@ static int try_delta(struct unpacked *tr
/*
* We do not bother to try a delta that we discarded
- * on an earlier try.
+ * on an earlier try, but only when reusing delta data.
*/
- if (trg_entry->in_pack && trg_entry->in_pack == src_entry->in_pack)
+ if (!no_reuse_delta && trg_entry->in_pack &&
+ trg_entry->in_pack == src_entry->in_pack)
return 0;
/*
^ permalink raw reply related
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 4:13 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fw8hS-00023y-FY@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> OR and AND have precedence, so there are two possibilities, I'd take
> the first one.
> 1. OR, AND:
> This will make it easier to read because OR can be skipped:
> pat1 pat2 AND pat3 pat4
> = pat1 OR pat2 AND pat3 OR pat4
> = (pat1 OR pat2) AND (pat3 OR pat4)
> 2. AND, OR:
> This is a bit more logic if you think of AND as * and OR as +.
> ... FOO should not be named --and imo but I don't have any idea
> for a good name atm.
I personally feel FOO should not even exist. An option that
covers the entire expression to make operator precedence in it
sounds quite evil.
I would say make --and bind tighter than --or and use
parentheses as needed. Making --or optional sounds fine as that
would make the default "multiple -e" case similar to what GNU
grep does without any --and nor --or.
^ permalink raw reply
* Abstract out accesses to object hash array
From: Linus Torvalds @ 2006-06-30 4:38 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
There are a few special places where some programs accessed the object
hash array directly, which bothered me because I wanted to play with some
simple re-organizations.
So this patch makes the object hash array data structures all entirely
local to object.c, and the few users who wanted to look at it now get to
use a function to query how many object index entries there can be, and to
actually access the array.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
It turns out that "lookup_object()" and "memcmp()" are the two hottest
routines by far in git-rev-list, and the problem is that the object array
grows pretty big. On its own, the object array would generally fit pretty
well in the CPU caches, but when it ends up only containing a pointer, and
we then do a memory compare on the result, the CPU cache ends up being
toast.
Now, the object array actually has two bits free, and I was going to hide
two bits of the SHA1 name in there, allowing me to avoid doing a memcmp()
for 75% of the collision cases.
Sadly, my crazy evil scheme doesn't actually help (the hashes work so well
that we have comparatively few collisions), but this cleanup seemed a
worthwhile result of my temporary insanity.
diff --git a/fsck-objects.c b/fsck-objects.c
index 769bb2a..ef54a8a 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -60,12 +60,13 @@ static int objwarning(struct object *obj
static void check_connectivity(void)
{
- int i;
+ int i, max;
/* Look up all the requirements, warn about missing objects.. */
- for (i = 0; i < obj_allocs; i++) {
+ max = get_max_object_index();
+ for (i = 0; i < max; i++) {
const struct object_refs *refs;
- struct object *obj = objs[i];
+ struct object *obj = get_indexed_object(i);
if (!obj)
continue;
diff --git a/name-rev.c b/name-rev.c
index 3a5ac35..6a23f2d 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -234,12 +234,15 @@ #define ishex(x) (isdigit((x)) || ((x) >
fwrite(p_start, p - p_start, 1, stdout);
}
} else if (all) {
- int i;
+ int i, max;
- for (i = 0; i < obj_allocs; i++)
- if (objs[i])
- printf("%s %s\n", sha1_to_hex(objs[i]->sha1),
- get_rev_name(objs[i]));
+ max = get_max_object_index();
+ for (i = 0; i < max; i++) {
+ struct object * obj = get_indexed_object(i);
+ if (!obj)
+ continue;
+ printf("%s %s\n", sha1_to_hex(obj->sha1), get_rev_name(obj));
+ }
} else {
int i;
for (i = 0; i < revs.nr; i++)
diff --git a/object.c b/object.c
index 37784ce..31c77ea 100644
--- a/object.c
+++ b/object.c
@@ -5,9 +5,18 @@ #include "tree.h"
#include "commit.h"
#include "tag.h"
-struct object **objs;
-static int nr_objs;
-int obj_allocs;
+static struct object **objs;
+static int nr_objs, obj_allocs;
+
+unsigned int get_max_object_index(void)
+{
+ return obj_allocs;
+}
+
+struct object *get_indexed_object(unsigned int idx)
+{
+ return objs[idx];
+}
const char *type_names[] = {
"none", "blob", "tree", "commit", "bad"
diff --git a/object.h b/object.h
index 6f23a9a..e0125e1 100644
--- a/object.h
+++ b/object.h
@@ -40,10 +40,11 @@ struct object {
};
extern int track_object_refs;
-extern int obj_allocs;
-extern struct object **objs;
extern const char *type_names[];
+extern unsigned int get_max_object_index(void);
+extern struct object *get_indexed_object(unsigned int);
+
static inline const char *typename(unsigned int type)
{
return type_names[type > TYPE_TAG ? TYPE_BAD : type];
^ permalink raw reply related
* Re: GIt.xs merge status
From: Pavel Roskin @ 2006-06-30 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vmzbvmny4.fsf_-_@assigned-by-dhcp.cox.net>
On Thu, 2006-06-29 at 18:28 -0700, Junio C Hamano wrote:
> Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio
> error: Installed (but unpackaged) file(s) found:
> /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so
I guess all this perl stuff should be in a separate module perl-Git to
comply with Red Hat conventions. This would make git-core depend on
perl-Git, but it's OK.
Error.pm is already provided by perl-Error. If we require perl(Error)
for building, it won't be installed. Actually, probing for Error.pm is
incorrect, so I'm fixing it.
Git.bs, .packlist and perllocal.pod should be removed - that's what
other Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that
"site_perl" becomes "vendor_perl".
While hacking that, I have wound that "--without doc" is broken in pu,
so I'm fixing it as well. The patches will be sent shortly.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH 2/3] Delete manuals if compiling without docs
From: Pavel Roskin @ 2006-06-30 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <20060630050923.701.37665.stgit@dv.roinet.com>
From: Pavel Roskin <proski@gnu.org>
Otherwise, rpm would complain about unpacked files.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
git.spec.in | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 8ccd256..b8feda3 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -86,6 +86,8 @@ make %{_smp_mflags} DESTDIR=$RPM_BUILD_R
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
%if %{!?_without_docs:1}0
(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+%else
+rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
%clean
^ permalink raw reply related
* [PATCH 1/3] Fix probing for already installed Error.pm
From: Pavel Roskin @ 2006-06-30 5:09 UTC (permalink / raw)
To: git
From: Pavel Roskin <proski@gnu.org>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
perl/Makefile.PL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index d401a66..b3fbb73 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -12,7 +12,7 @@ my %pm = ('Git.pm' => '$(INST_LIBDIR)/Gi
# We come with our own bundled Error.pm. It's not in the set of default
# Perl modules so install it if it's not available on the system yet.
-eval { require 'Error' };
+eval { require Error };
if ($@) {
$pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}
^ permalink raw reply related
* [PATCH 3/3] Make perl interface a separate package
From: Pavel Roskin @ 2006-06-30 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <20060630050923.701.37665.stgit@dv.roinet.com>
From: Pavel Roskin <proski@gnu.org>
Install it as a vendor package. Remove .packlist, perllocal.pod,
Git.bs. Require perl(Error) for building so that our Error.pm is not
installed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
git.spec.in | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index b8feda3..6d90034 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -9,7 +9,7 @@ URL: http://kernel.org/pub/software/sc
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk
+Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk, perl-Git
%description
This is a stupid (but extremely fast) directory content manager. It
@@ -70,6 +70,16 @@ Requires: git-core = %{version}-%{
%description -n gitk
Git revision tree visualiser ('gitk')
+%package -n perl-Git
+Summary: Perl interface to Git
+Group: Development/Libraries
+Requires: git-core = %{version}-%{release}
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+BuildRequires: perl(Error)
+
+%description -n perl-Git
+Perl interface to Git
+
%prep
%setup -q
@@ -80,10 +90,14 @@ make %{_smp_mflags} CFLAGS="$RPM_OPT_FLA
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
+ prefix=%{_prefix} mandir=%{_mandir} INSTALLDIRS=vendor \
install %{!?_without_docs: install-doc}
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
+find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
+find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
+(find $RPM_BUILD_ROOT%{perl_vendorarch} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%else
@@ -131,6 +145,9 @@ # These are no files in the root package
%{!?_without_docs: %{_mandir}/man1/*gitk*.1*}
%{!?_without_docs: %doc Documentation/*gitk*.html }
+%files -n perl-Git -f perl-files
+%defattr(-,root,root)
+
%files core -f bin-man-doc-files
%defattr(-,root,root)
%{_datadir}/git-core/
^ permalink raw reply related
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Michal Ludvig @ 2006-06-30 5:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Herbert Xu, linux-crypto, git
In-Reply-To: <Pine.LNX.4.64.0606291943010.12404@g5.osdl.org>
Linus Torvalds wrote:
> git log -p --full-diff v2.6.16.. crypto/
Can I somehow get the result in a reverse order, i.e. oldest commits first?
As it is the patch conflicts on files that were changed multiple times
since 2.6.16 :-(
Will see if patchutils can help me somehow...
Michal
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Linus Torvalds @ 2006-06-30 6:20 UTC (permalink / raw)
To: Michal Ludvig; +Cc: Herbert Xu, linux-crypto, git
In-Reply-To: <44A4BA6D.5010006@logix.cz>
On Fri, 30 Jun 2006, Michal Ludvig wrote:
>
> Linus Torvalds wrote:
>
> > git log -p --full-diff v2.6.16.. crypto/
>
> Can I somehow get the result in a reverse order, i.e. oldest commits first?
Not that way, no. "git log" generates the data on-the-fly, so a simple
"git log" will always give most recent first.
However, you can do this
git log --pretty=oneline v2.6.16.. crypto/
to generate a list of commits, one per line. Then, reverse that list
("tac" is your friend), and feed it back to "git-diff-tree --stdin
--pretty -p" to get the diffs.
So
git log --pretty=oneline v2.6.16.. crypto/ |
tac |
git-diff-tree --stdin --pretty -p
should do what you want.
Of course, the patches (to other files than the crypt/ subdirectory) may
still clash due to changes that are unrelated to the crypto changes. That
is unavoidable, and you'll just have to fix that up by hand.
Linus
^ permalink raw reply
* Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree
From: Junio C Hamano @ 2006-06-30 6:28 UTC (permalink / raw)
To: Michal Ludvig; +Cc: git
In-Reply-To: <44A4BA6D.5010006@logix.cz>
Michal Ludvig <michal@logix.cz> writes:
> Linus Torvalds wrote:
>
>> git log -p --full-diff v2.6.16.. crypto/
>
> Can I somehow get the result in a reverse order, i.e. oldest commits first?
Two ways:
git format-patch -o patches-output/ --full-diff v2.6.16.. crypto/
would give you one file a patch in patches-output directory,
numbered.
git format-patch --stdout --full-diff v2.6.16.. crypto/
would give you a single stream of the above to the standard output.
^ permalink raw reply
* Re: Git.xs merge status
From: Junio C Hamano @ 2006-06-30 7:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, hpa
In-Reply-To: <1151644101.10496.22.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> I guess all this perl stuff should be in a separate module perl-Git to
> comply with Red Hat conventions. This would make git-core depend on
> perl-Git, but it's OK.
>
> Error.pm is already provided by perl-Error. If we require perl(Error)
> for building, it won't be installed. Actually, probing for Error.pm is
> incorrect, so I'm fixing it.
>
> Git.bs, .packlist and perllocal.pod should be removed - that's what
> other Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that
> "site_perl" becomes "vendor_perl".
>
> While hacking that, I have wound that "--without doc" is broken in pu,
> so I'm fixing it as well. The patches will be sent shortly.
Thanks.
The kernel.org machine I am using for testing does not seem to
have perl-Error installed, and I suspect Pasky arranged to ship
our own Error.pm for people building git from source because the
package is not so widely installed. I guess I should ask the
admins there before I can build perl-Git RPMs for release.
I am doing this preparation not for the upcoming 1.4.1 but later
than that -- perhaps way later than that -- so there is no rush.
^ permalink raw reply
* Re: [PATCH 4/4] save another call to git-update-index
From: Alex Riesen @ 2006-06-30 7:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> FYI I've been just battling this pipe for a couple of hours. The first
> steps were easy, but since I wanted to do it incrementally, the index has
> to be written every so often, and I seem not to be able to get that right.
>
Are you sure? Does something use the index between starting update-index
pipe and pclose?
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Junio C Hamano @ 2006-06-30 7:28 UTC (permalink / raw)
To: Pavel Roskin, Petr Baudis; +Cc: git
In-Reply-To: <20060630050923.701.37665.stgit@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
> index d401a66..b3fbb73 100644
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -12,7 +12,7 @@ my %pm = ('Git.pm' => '$(INST_LIBDIR)/Gi
>
> # We come with our own bundled Error.pm. It's not in the set of default
> # Perl modules so install it if it's not available on the system yet.
> -eval { require 'Error' };
> +eval { require Error };
> if ($@) {
> $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
> }
The syntax updates is correct, but this is still wrong, I am
afraid.
It is trying to see if we need to install the Error.pm we ship
just in case the system does not have Error.pm available. But
this script is run in perl/ directory where we have that private
copy of Error.pm, so "require Error" always succeeds, eh, at
least after you fixed the above syntax error X-<.
^ permalink raw reply
* Re: Git.xs merge status
From: Pavel Roskin @ 2006-06-30 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, hpa
In-Reply-To: <7vlkrfkt6q.fsf_-_@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano <junkio@cox.net>:
> The kernel.org machine I am using for testing does not seem to
> have perl-Error installed, and I suspect Pasky arranged to ship
> our own Error.pm for people building git from source because the
> package is not so widely installed. I guess I should ask the
> admins there before I can build perl-Git RPMs for release.
It's better than to have conflicting packages (perl-Git and perl-Error). The
build requirement can be relaxed if needed (either by finding and removing
Error* after the install or by adding another flag to Makefile.PL), but I think
it's logical to have it because perl-Error would be needed by git-core anyway.
Another solution would be to arrange Error.pm to be installed and used as
Git::Error, but that would be a case of code duplication.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Junio C Hamano @ 2006-06-30 7:40 UTC (permalink / raw)
To: Pavel Roskin, Petr Baudis; +Cc: git
In-Reply-To: <7vfyhnksqf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Pavel Roskin <proski@gnu.org> writes:
>
>> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
>> index d401a66..b3fbb73 100644
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -12,7 +12,7 @@ my %pm = ('Git.pm' => '$(INST_LIBDIR)/Gi
>>
>> # We come with our own bundled Error.pm. It's not in the set of default
>> # Perl modules so install it if it's not available on the system yet.
>> -eval { require 'Error' };
>> +eval { require Error };
>> if ($@) {
>> $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
>> }
>
> The syntax updates is correct, but this is still wrong, I am
> afraid.
>
> It is trying to see if we need to install the Error.pm we ship
> just in case the system does not have Error.pm available. But
> this script is run in perl/ directory where we have that private
> copy of Error.pm, so "require Error" always succeeds, eh, at
> least after you fixed the above syntax error X-<.
That is, we would want something like this.
diff --git a/perl/Error.pm b/perl/private-Error.pm
similarity index 100%
rename from perl/Error.pm
rename to perl/private-Error.pm
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index b3fbb73..25ae54a 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -14,7 +14,7 @@ # We come with our own bundled Error.pm.
# Perl modules so install it if it's not available on the system yet.
eval { require Error };
if ($@) {
- $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
+ $pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}
WriteMakefile(
^ permalink raw reply related
* Re: [PATCH 2/4] make filepairs detachable
From: Alex Riesen @ 2006-06-30 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Johannes Schindelin
In-Reply-To: <7vy7vfmoit.fsf@assigned-by-dhcp.cox.net>
On 6/30/06, Junio C Hamano <junkio@cox.net> wrote:
>
> > Actually, just make sure diff_flush does not crash for diff queue
> > entries which were cleared.
>
> Somehow I really feel uneasy about this one. I think it is the
> responsibility of the one who mangles the queue to adjust the
> entries and count consistent.
>
That's what I get after being exposed to double-linked lists for
too long: I begin to think it's fine to take whatever I want.
The pairs are actually exactly what I need, so I take them.
I think I just have to encapsulate it nicely, i.e.:
struct diff_filepair *diff_queued_detach(int pos)
{
struct diff_filepair *pair = NULL;
if (pos < diff_queued_diff.nr) {
diff_queued_diff.queue[pos];
if (diff_queued_diff.nr - pos > 1)
memmove(pair->queue + pos, pair->queue + pos + 1,
diff_queued_diff.nr - pos - 1);
diff_queued_diff.nr--;
}
return pair;
}
BTW, is there any chance we get the struct diff_filepair's
double-linked? They don't seem to be sorted. Will increase
the memory footprint, though.
^ permalink raw reply
* Re: [PATCH/RFH] Racy GIT (part #3)
From: Uwe Zeisberger @ 2006-06-30 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2zpr6k.fsf@assigned-by-dhcp.cox.net>
Hello,
Junio C Hamano wrote:
> Does everybody have "cp -p" to preserve the file timestamps on
> his/her platform? I am assuming this is safe (it is in POSIX),
> but please raise hand if that is not a case for you.
Solaris[1] has two different "cp"s[2].
From cp(1):
[...] [/usr/bin/cp] does not fail if unable to preserve extended
attributes, modification and access time, or permission modes.
[...] [/usr/xpg4/bin/cp] does not fail if unable to preserve
extended attributes. If unable to duplicate the modification
and access time or the permission modes, cp prints a diagnostic
message to stderr and return a non-zero exit status.
There is yet an other difference when -@ is specified. The complete man
page can be found at docs.sun.com[2].
Best regards
Uwe
[1] in my case Solaris 10 = SunOS 5.10 and Solaris 9 = SunOS 5.9
[2] http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9dm?a=view
--
Uwe Zeisberger
http://www.google.com/search?q=0+degree+Celsius+in+kelvin
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2zmgbu.fsf@assigned-by-dhcp.cox.net>
(Junio: please reply to this one, forgot the Cc in the first one :/)
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > OR and AND have precedence, so there are two possibilities, I'd take
> > the first one.
> > 1. OR, AND:
> > This will make it easier to read because OR can be skipped:
> > pat1 pat2 AND pat3 pat4
> > = pat1 OR pat2 AND pat3 OR pat4
> > = (pat1 OR pat2) AND (pat3 OR pat4)
> > 2. AND, OR:
> > This is a bit more logic if you think of AND as * and OR as +.
>
> > ... FOO should not be named --and imo but I don't have any idea
> > for a good name atm.
>
> I personally feel FOO should not even exist. An option that
> covers the entire expression to make operator precedence in it
> sounds quite evil.
>
> I would say make --and bind tighter than --or and use parentheses as
> needed.
Ok, perhaps changing operator precedence is a bit much. What do you
think of that then:
Operator precedence AND, OR. The FOO options changes the default
operator to AND. This also seems quite natural if you think of
AND as * and OR as +:
A B + C D = A * B + C * D = (A * B) + (C * D)
A few examples to get an impression how the command line could look
like:
A OR B OR (C AND D) => A B C AND D
(A OR B OR C) AND D => (A B C) AND D
A AND B AND (C OR D) => -FOO A B (C OR D)
(A AND B AND C) OR D => -FOO A B C OR D
Perhaps we even could use options which are similar to * and +, for
example:
- -* and -+ (-* should not be expanded often but is annoying anyway)
- -. and -+
- -t and -p (A -t B is A times B, A -p B is A plus B)
> Making --or optional sounds fine as that
> would make the default "multiple -e" case similar to what GNU
> grep does without any --and nor --or.
That's exactly what I was thinking about: make extended expressions
compatible to current grep options. This will confuse less people and
there is no need for an extra option to activate this.
^ 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