* Re: rebasing trouble
From: Junio C Hamano @ 2006-06-29 20:04 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060629194723.GD14287@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> I must be missing something obvious:
>
> bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^
> bfields@puzzle:linux-2.6$ git-describe
> v2.6.17-rc6-g28df955
> bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin
> Nothing to do.
> bfields@puzzle:linux-2.6$ git-describe
> v2.6.17
>
> So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable
> isn't a subset of origin, so this doesn't make sense to me.
>
> The tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if
> it matters.
It matters of course. Where is the "origin"?
^ permalink raw reply
* [PATCH 1/2] Allow INSTALL, bindir, mandir to be set in main Makefile
From: Jakub Narebski @ 2006-06-29 20:11 UTC (permalink / raw)
To: git
Makefiles in subdirectories now use existing value of INSTALL, bindir,
mandir if it is set, allowing those to be set in main Makefile or in
included config.mak. Main Makefile exports variables which it sets.
Accidentally it renames bin to bindir in Documentation/Makefile
(should be bindir from start, but is unused, perhaps to be removed).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Series only because second patch in series depends textually on first,
even though changes are independent.
Documentation/Makefile | 4 ++--
Makefile | 2 ++
contrib/emacs/Makefile | 4 ++--
contrib/git-svn/Makefile | 4 ++--
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 2b0efe7..ca6b77d 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -25,8 +25,8 @@ DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT
DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
prefix?=$(HOME)
-bin=$(prefix)/bin
-mandir=$(prefix)/man
+bindir?=$(prefix)/bin
+mandir?=$(prefix)/man
man1=$(mandir)/man1
man7=$(mandir)/man7
# DESTDIR=
diff --git a/Makefile b/Makefile
index cde619c..b8fe669 100644
--- a/Makefile
+++ b/Makefile
@@ -100,6 +100,8 @@ template_dir = $(prefix)/share/git-core/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
+export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
+
CC = gcc
AR = ar
TAR = tar
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index d3619db..350846d 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -3,9 +3,9 @@ ## Build and install stuff
EMACS = emacs
ELC = git.elc vc-git.elc
-INSTALL = install
+INSTALL ?= install
INSTALL_ELC = $(INSTALL) -m 644
-prefix = $(HOME)
+prefix ?= $(HOME)
emacsdir = $(prefix)/share/emacs/site-lisp
all: $(ELC)
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index 7c20946..1a6585e 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -1,8 +1,8 @@
all: git-svn
prefix?=$(HOME)
-bindir=$(prefix)/bin
-mandir=$(prefix)/man
+bindir?=$(prefix)/bin
+mandir?=$(prefix)/man
man1=$(mandir)/man1
INSTALL?=install
doc_conf=../../Documentation/asciidoc.conf
--
1.4.0
^ permalink raw reply related
* [PATCH 2/2] Rename man1 and man7 variables to man1dir and man7dir
From: Jakub Narebski @ 2006-06-29 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <200606292211.28352.jnareb@gmail.com>
This patch renames man1 and man7 variables to man1dir and man7dir,
according to "Makefile Conventions: Variables for Installation
Directories" in make.info of GNU Make.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Depends on the earlier patch in "series" only via context
Documentation/Makefile | 10 +++++-----
contrib/git-svn/Makefile | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ca6b77d..cc83610 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -27,8 +27,8 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT
prefix?=$(HOME)
bindir?=$(prefix)/bin
mandir?=$(prefix)/man
-man1=$(mandir)/man1
-man7=$(mandir)/man7
+man1dir=$(mandir)/man1
+man7dir=$(mandir)/man7
# DESTDIR=
INSTALL?=install
@@ -52,9 +52,9 @@ man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
install: man
- $(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
- $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
- $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
+ $(INSTALL) -d -m755 $(DESTDIR)$(man1dir) $(DESTDIR)$(man7dir)
+ $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7dir)
#
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index 1a6585e..8cac688 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -3,7 +3,7 @@ all: git-svn
prefix?=$(HOME)
bindir?=$(prefix)/bin
mandir?=$(prefix)/man
-man1=$(mandir)/man1
+man1dir=$(mandir)/man1
INSTALL?=install
doc_conf=../../Documentation/asciidoc.conf
-include ../../config.mak
@@ -17,7 +17,7 @@ install: all
$(INSTALL) git-svn $(DESTDIR)$(bindir)
install-doc: doc
- $(INSTALL) git-svn.1 $(DESTDIR)$(man1)
+ $(INSTALL) git-svn.1 $(DESTDIR)$(man1dir)
doc: git-svn.1
git-svn.1 : git-svn.xml
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] Allow INSTALL, bindir, mandir to be set in main Makefile
From: Jakub Narebski @ 2006-06-29 20:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7vfrfc6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Part of autoconf series, but independent.
>
> I'd like to take something like this, independently from
> "optionally managing config.mak with autoconf" series.
>
>> Should probably be split into two patches:
>> * first with export + '?='
>> * second renaming man1 and man7 to man1dir and man7dir
>
> And I think it is probably a good idea to somehow keep people's
> configurations that have been overriding man1 and man7 if
> possible. Otherwise things would regress for them.
Done. Resent as two patch "series", starting with
Message-Id: <200606292211.28352.jnareb@gmail.com>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] Rename man1 and man7 variables to man1dir and man7dir
From: Junio C Hamano @ 2006-06-29 20:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200606292213.00726.jnareb@gmail.com>
Doesn't this break "make dist-doc" by _REMOVING_ make variables
man1 and man7, which I mentioned earlier?
^ permalink raw reply
* Re: rebasing trouble
From: J. Bruce Fields @ 2006-06-29 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5crranq.fsf@assigned-by-dhcp.cox.net>
On Thu, Jun 29, 2006 at 01:04:25PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > I must be missing something obvious:
> >
> > bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^
> > bfields@puzzle:linux-2.6$ git-describe
> > v2.6.17-rc6-g28df955
> > bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin
> > Nothing to do.
> > bfields@puzzle:linux-2.6$ git-describe
> > v2.6.17
> >
> > So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable
> > isn't a subset of origin, so this doesn't make sense to me.
> >
> > The tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if
> > it matters.
>
> It matters of course. Where is the "origin"?
I realized after I sent that that "origin" in that public repository actually
isn't the same as "origin" in the local repo that I'm working on. So I just
ran a GIT_DIR=. git-fetch there, and now both branches agree.
--b.
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Nicolas Pitre @ 2006-06-29 20:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060629195201.GA10786@coredump.intra.peff.net>
On Thu, 29 Jun 2006, Jeff King wrote:
> On Thu, Jun 29, 2006 at 03:04:15PM -0400, Nicolas Pitre wrote:
>
> > Right. Your use pattern is a special case that doesn't work well with
> > the whole window hash approach. I'd expect it to work beautifully with
> > the kernel repository though.
>
> I don't necessarily care about the kernel repository. It packs fine as
> it is, and you only waste 30 seconds on a repack checking deltas that
> could be avoided. I do care on my special repository where packing is
> virtually unusable and I can achieve a 45x speedup. Maybe my original
> caching is not worth it for the kernel and should be configurable,
> but obviously this window caching cannot REPLACE mine since it fails
> utterly for the one thing I wanted it for.
And I agreed with you already.
> That being said, I'm not sure that window caching is all that great for
> "normal" repos.
>
> Same test as before, but instead of simulating the commits, I merely
> looked at the window hashes produced by
> git-rev-list --objects master~$x
>
> For the git repo:
> x=0 tries 6698 windows
> x=0 and x=50 contain 5197 identical windows
> x=0 and x=100 contain 2484 identical windows
> x=0 and x=500 contain 455 identical windows
>
> For linux-2.6 repo:
> x=0 tries 57208 windows
> x=0 and x=50 contain 53677 identical windows
> x=0 and x=100 contain 52886 identical windows
> x=0 and x=500 contain 41196 identical windows
>
> Obviously the kernel repo is doing better, but x=500 is only 4 days ago.
> Trying with --before=2.weeks.ago yields only 31505 matches.
What does this prove? I fail to see the relation between those results
and a possible git-pack-objects improvement.
The negative delta cache concept is certainly attractive even for normal
repositories, especially for public servers, since when used in
conjonction with delta reuse it makes the creation of a pack basically
free. So I think this idea really has merits, as long as the cache
remains small.
Nicolas
^ permalink raw reply
* Re: rebasing trouble
From: J. Bruce Fields @ 2006-06-29 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060629202234.GE14287@fieldses.org>
On Thu, Jun 29, 2006 at 04:22:34PM -0400, bfields wrote:
> I realized after I sent that that "origin" in that public repository actually
> isn't the same as "origin" in the local repo that I'm working on. So I just
> ran a GIT_DIR=. git-fetch there, and now both branches agree.
By the way, I should also have said:
bfields@puzzle:git$ git --version
git version 1.4.1.rc2
--b.
^ permalink raw reply
* Re: [PATCH] move get_merge_bases() to core lib; use it in merge-recursive
From: Junio C Hamano @ 2006-06-29 20:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606292050380.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So, a few tests later, I am pretty sure that my patches do not break
> git-merge-base. I'll prepare another patch series which builds-in
> merge-base.
I'll take your two patches to refactor merge-base and to move
the bulk of the code to commit.c for now. Updated "next" coming
shortly.
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Linus Torvalds @ 2006-06-29 21:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291616480.1213@localhost.localdomain>
On Thu, 29 Jun 2006, Nicolas Pitre wrote:
>
> The negative delta cache concept is certainly attractive even for normal
> repositories, especially for public servers, since when used in
> conjonction with delta reuse it makes the creation of a pack basically
> free. So I think this idea really has merits, as long as the cache
> remains small.
I don't really see much of a point of this all.
Instead of having a separate cache, wouldn't it be much better to just
take the hint from the previous pack-file?
In the repacking window, if both objects we are looking at already came
from the same (old) pack-file, don't bother delta'ing them against each
other.
That means that we'll still always check for better deltas for (and
against!) _unpacked_ objects, but assuming incremental repacks, you'll
avoid the delta creation 99% of the time.
Ie somethng really simple like the appended.
Linus
---
diff --git a/pack-objects.c b/pack-objects.c
index bed2497..cea63e7 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -988,6 +988,13 @@ static int try_delta(struct unpacked *tr
return -1;
/*
+ * We do not bother to try a delta that we discarded
+ * on an earlier try
+ */
+ if (trg_entry->in_pack && trg_entry->in_pack == src_entry->in_pack)
+ return -1;
+
+ /*
* If the current object is at pack edge, take the depth the
* objects that depend on the current object into account --
* otherwise they would become too deep.
^ permalink raw reply related
* Re: [RFC] Cache negative delta pairs
From: Nicolas Pitre @ 2006-06-29 21:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291352110.12404@g5.osdl.org>
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! ;-)
Nicolas
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Junio C Hamano @ 2006-06-29 21:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Jeff King
In-Reply-To: <Pine.LNX.4.64.0606291616480.1213@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> The negative delta cache concept is certainly attractive even for normal
> repositories, especially for public servers, since when used in
> conjonction with delta reuse it makes the creation of a pack basically
> free. So I think this idea really has merits, as long as the cache
> remains small.
Yes, I agree it is very attractive.
One thing to watch out for is that we probably would not want to
let git-daemon write into public repositories. Which means that
use of negative cache should be strict "opt-in".
- "$GIT_DIR/delta-cache" is read but not necessarily is written
back when it exists; git-daemon uses it that way.
- The owner of the repository shouldn't have to tell the tool
to update the negative cache every time repack happens.
Which suggests that pack-objects.c can learn an option that
tells it to call delta_cache_save(), and we use it in
git-repack, perhaps like this:
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..b07ed9b 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -44,7 +44,7 @@ case ",$all_into_one," in
esac
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
name=$(git-rev-list --objects --all $rev_list 2>&1 |
- git-pack-objects --non-empty $pack_objects .tmp-pack) ||
+ git-pack-objects --update-delta-cache --non-empty $pack_objects .tmp-pack) ||
exit 1
if [ -z "$name" ]; then
echo Nothing new to pack.
diff --git a/pack-objects.c b/pack-objects.c
index bed2497..46b9775 100644
--- a/pack-objects.c
+++ b/pack-objects.c
...
@@ -1342,5 +1350,7 @@ int main(int argc, char **argv)
if (progress)
fprintf(stderr, "Total %d, written %d (delta %d), reused %d (delta %d)\n",
nr_result, written, written_delta, reused, reused_delta);
+ if (update_delta_cache)
+ delta_cache_save();
return 0;
}
^ permalink raw reply related
* [PATCH 2/2] Rename man1 and man7 variables to man1dir and man7dir
From: Jakub Narebski @ 2006-06-29 21:26 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wt7ra1h.fsf@assigned-by-dhcp.cox.net>
This patch renames man1 and man7 variables to man1dir and man7dir,
according to "Makefile Conventions: Variables for Installation
Directories" in make.info of GNU Make.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Doesn't this break "make dist-doc" by _REMOVING_ make variables
> man1 and man7, which I mentioned earlier?
This is corrected patch. I think I catched all occurences, but I cannot
do 'make dist-doc' because I haven't got asciidoc installed.
Could some kind soul check changes introduced by this patch, please?
P.S. This patch is sent from newsreader, not mail program. I hope
it doesn't mangle whitespaces in patch.
Documentation/Makefile | 10 +++++-----
Makefile | 4 ++--
contrib/git-svn/Makefile | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ca6b77d..cc83610 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -27,8 +27,8 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT
prefix?=$(HOME)
bindir?=$(prefix)/bin
mandir?=$(prefix)/man
-man1=$(mandir)/man1
-man7=$(mandir)/man7
+man1dir=$(mandir)/man1
+man7dir=$(mandir)/man7
# DESTDIR=
INSTALL?=install
@@ -52,9 +52,9 @@ man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
install: man
- $(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
- $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
- $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
+ $(INSTALL) -d -m755 $(DESTDIR)$(man1dir) $(DESTDIR)$(man7dir)
+ $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7dir)
#
diff --git a/Makefile b/Makefile
index b8fe669..ccd7c62 100644
--- a/Makefile
+++ b/Makefile
@@ -714,8 +714,8 @@ dist-doc:
rm -fr .doc-tmp-dir
mkdir .doc-tmp-dir .doc-tmp-dir/man1 .doc-tmp-dir/man7
$(MAKE) -C Documentation DESTDIR=./ \
- man1=../.doc-tmp-dir/man1 \
- man7=../.doc-tmp-dir/man7 \
+ man1dir=../.doc-tmp-dir/man1 \
+ man7dir=../.doc-tmp-dir/man7 \
install
cd .doc-tmp-dir && $(TAR) cf ../$(manpages).tar .
gzip -n -9 -f $(manpages).tar
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index 1a6585e..8cac688 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -3,7 +3,7 @@ all: git-svn
prefix?=$(HOME)
bindir?=$(prefix)/bin
mandir?=$(prefix)/man
-man1=$(mandir)/man1
+man1dir=$(mandir)/man1
INSTALL?=install
doc_conf=../../Documentation/asciidoc.conf
-include ../../config.mak
@@ -17,7 +17,7 @@ install: all
$(INSTALL) git-svn $(DESTDIR)$(bindir)
install-doc: doc
- $(INSTALL) git-svn.1 $(DESTDIR)$(man1)
+ $(INSTALL) git-svn.1 $(DESTDIR)$(man1dir)
doc: git-svn.1
git-svn.1 : git-svn.xml
--
1.4.0
^ permalink raw reply related
* Re: [RFC] Cache negative delta pairs
From: Linus Torvalds @ 2006-06-29 21:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291723060.1213@localhost.localdomain>
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).
The advantage of this patch is that it should guarantee that if everything
is already packed, a repack will basically keep the pack identical.
However, that is obviously also the dis-advantage, since it means that
repacking cannot improve packing. So adding a flag to say "please try to
incrementally improve the pack" might well be worth it, even if this new
behaviour would be the _default_.
Hmm? Jeff, does this work for your load?
Linus
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Jeff King @ 2006-06-29 21:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291352110.12404@g5.osdl.org>
On Thu, Jun 29, 2006 at 02:04:01PM -0700, 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?
I'd like to second Nicolas' "DOH!".
This drops my nasty load with roughly the same effect as the delta
cache, and it does the same for the kernel repo. And it doesn't consume
any extra disk space. Junio, please drop my delta-cache patch in favor
of Linus' patch.
-Peff
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Jeff King @ 2006-06-29 21:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291616480.1213@localhost.localdomain>
On Thu, Jun 29, 2006 at 04:24:01PM -0400, Nicolas Pitre wrote:
> > Obviously the kernel repo is doing better, but x=500 is only 4 days ago.
> > Trying with --before=2.weeks.ago yields only 31505 matches.
>
> What does this prove? I fail to see the relation between those results
> and a possible git-pack-objects improvement.
My point is that the window cache gets invalidated over time, whereas a
sha1 by sha1 cache doesn't. However, the point is moot, as I think
Linus has come up with a much better solution.
> The negative delta cache concept is certainly attractive even for normal
> repositories, especially for public servers, since when used in
> conjonction with delta reuse it makes the creation of a pack basically
> free. So I think this idea really has merits, as long as the cache
> remains small.
Yes, if you're talking about a situation in which you make many packs
for a given set of commits, then it does make more sense (what I was
really trying to eliminate was a 10 minute repack followed by another 10
minute repack to push to the server).
-Peff
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Jeff King @ 2006-06-29 21:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291428150.12404@g5.osdl.org>
On Thu, Jun 29, 2006 at 02:30:11PM -0700, Linus Torvalds wrote:
> However, that is obviously also the dis-advantage, since it means that
> repacking cannot improve packing. So adding a flag to say "please try to
> incrementally improve the pack" might well be worth it, even if this new
> behaviour would be the _default_.
We could tie the on/off to --no-reuse-delta, since you would mostly
want them at the same time. This disallows repacking over and over to
try to incrementally improve size. Do people actually do that?
> Hmm? Jeff, does this work for your load?
Yes, just as well as my original patch.
-Peff
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Nicolas Pitre @ 2006-06-29 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291428150.12404@g5.osdl.org>
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.
> The advantage of this patch is that it should guarantee that if everything
> is already packed, a repack will basically keep the pack identical.
>
> However, that is obviously also the dis-advantage, since it means that
> repacking cannot improve packing. So adding a flag to say "please try to
> incrementally improve the pack" might well be worth it, even if this new
> behaviour would be the _default_.
Actually, the delta reusing already prevents those deltas from being
improved. So your patch only extend this notion to the non-deltified
objects as well. And the way out is to provide the --no-reuse-delta
flag.
Nicolas
^ permalink raw reply
* [PATCH/RFH] Racy GIT (part #3)
From: Junio C Hamano @ 2006-06-29 21:50 UTC (permalink / raw)
To: git
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.
-- >8 --
Commit 29e4d3635709778bcc808dbad0477efad82f8d7e fixed the
underlying update-index races but git-commit was not careful
enough to preserve the index file timestamp when copying the
index file. This caused t3402 test to occasionally fail.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 7e50cf3..22c4ce8 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -29,7 +29,7 @@ THIS_INDEX="$GIT_DIR/index"
NEXT_INDEX="$GIT_DIR/next-index$$"
rm -f "$NEXT_INDEX"
save_index () {
- cp "$THIS_INDEX" "$NEXT_INDEX"
+ cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
report () {
--
1.4.1.rc2.g3257-dirty
^ permalink raw reply related
* Re: [RFC] Cache negative delta pairs
From: Junio C Hamano @ 2006-06-29 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606291352110.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Instead of having a separate cache, wouldn't it be much better to just
> take the hint from the previous pack-file?
>
> In the repacking window, if both objects we are looking at already came
> from the same (old) pack-file, don't bother delta'ing them against each
> other.
>
> That means that we'll still always check for better deltas for (and
> against!) _unpacked_ objects, but assuming incremental repacks, you'll
> avoid the delta creation 99% of the time.
I bow down before you.
No ugly special-case caching, just automatically "the right
thing", with very little overhead.
It just makes sense.
We have a winner.
;-)
^ permalink raw reply
* Re: rebasing trouble
From: J. Bruce Fields @ 2006-06-29 21:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060629194723.GD14287@fieldses.org>
On Thu, Jun 29, 2006 at 03:47:23PM -0400, J. Bruce Fields wrote:
> I must be missing something obvious:
>
> bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^
> bfields@puzzle:linux-2.6$ git-describe
> v2.6.17-rc6-g28df955
> bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin
> Nothing to do.
> bfields@puzzle:linux-2.6$ git-describe
> v2.6.17
>
> So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable
> isn't a subset of origin, so this doesn't make sense to me.
Oops, sorry, I lied; nfs-client-stable *is* a subset of origin, since Linus
merged it.
But it *isn't* a subset of v2.6.17.
So the semantics of git-rebase just aren't quite what I expected. It first
removes anything that isn't in the given upstream branch, *then* rebases to the
commit given after --onto. Which may mean it throws out some stuff that is in
the upstream branch even though it isn't yet included as of the given commit.
So what I really meant to do was just
git-rebase v2.6.17
And rereading the man page, I see that git-rebase was working exactly as
advertised. So I'm an idiot. In my defense, it is a little confusing: none of
the examples in the man page that use --onto actually need it, and the
"upstream" argument probably should be described as a commit or something
instead of a branch.
(What is --onto actually useful for?)
--b.
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Joel Becker @ 2006-06-29 21:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606291428150.12404@g5.osdl.org>
On Thu, Jun 29, 2006 at 02:30:11PM -0700, Linus Torvalds wrote:
> However, that is obviously also the dis-advantage, since it means that
> repacking cannot improve packing. So adding a flag to say "please try to
> incrementally improve the pack" might well be worth it, even if this new
> behaviour would be the _default_.
I nominate "--pack-me-harder".
Joel
--
"Behind every successful man there's a lot of unsuccessful years."
- Bob Brown
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Junio C Hamano @ 2006-06-29 22:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0606291743010.1213@localhost.localdomain>
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.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Thomas Glanzmann @ 2006-06-29 22:20 UTC (permalink / raw)
To: git; +Cc: Matthias Lederhofer
In-Reply-To: <E1FueYh-0004XE-Fg@moooo.ath.cx>
Hello,
> *AND* more than one pattern. (something I miss in normal grep)
so do I, is it possible to use git-grep outside of git for files that
are not in a repository? Or are there any grep implementations available
which bring this feature to me?
Thomas
^ permalink raw reply
* Re: [PATCH] Makefile: set USE_PIC on Linux x86_64 for linking with Git.pm
From: Jakub Narebski @ 2006-06-29 22:22 UTC (permalink / raw)
To: git
In-Reply-To: <1151527945.1619.17.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2006-06-28 at 21:21 +0200, Marco Roeland wrote:
>> I certainly do not know cases outside Linux where this might break on
>> x86-64. I just tried to limit it to the case I could test. But perhaps
>> someone with an x86-64 BSD or Solaris might try it?
>>
>> To paraphrase Dave Jones: I type 'make', it fails. Some 'git log' later
>> I realise I have to manually define 'USE_PIC'. Hey, why doesn't it work
>> automagically?
>
> Automagically? You should search the archives for "Autoconf". When I
> proposed using it, the hell broke loose. Now let me indulge in
> Schadenfreude :-)
If I remember correctly everybody agreed that autoconf is least evil of the
whole autotools package. pasky suggested to write ./configure script by
hand on #git...
I'm trying to do inobtrusive _optional_ autoconf support in the patch series
beginning with
Message-ID: <200606290301.51657.jnareb@gmail.com>
http://permalink.gmane.org/gmane.comp.version-control.git/22832
Please wait for the patch moving ./autoconf output away from config.mak
(as some people here requested), and do contribute! My autoconf/m4
experience is nonexistent (I'm learning it as I go). See comments in the
third [PATCH/RFC] in series.
BTW. patches are against master.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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