* 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
* Re: [RFC] Cache negative delta pairs
From: Junio C Hamano @ 2006-06-29 22:22 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:
> 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;
> +
> + /*
I think you meant to return 0 from here though. -1 means "do
not use this pair and do not bother try improving it with the
remaining candidates".
^ permalink raw reply
* Re: [RFC] Cache negative delta pairs
From: Jakub Narebski @ 2006-06-29 22:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v4py4y7wo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> [...] For example, we currently do
> not delta OpenOffice documents (*.odt, *.odp, etc) very well.
> If one has a repository that tracks the history of "file.odp",
> we know each revision of "file.odp" would not delta against any
> other version anyway, and could skip attempting to deltify them.
Perhaps we should steal Mercurial idea of EncodeDecodeFilter, and store
OpenOffice documents, Mozilla extensions, Java packages in object store as
uncompressed archive, and checkout them to working area in original format.
All diff should be of course done on in-repository (after-filter) format.
The original example at
http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
talks about archives (zip files) and unix2dos endline convention conversion.
Perhaps for OpenOffice and Mozilla we would need to use [external] XML-aware
diff, too...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: rebasing trouble
From: Junio C Hamano @ 2006-06-29 22:34 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060629215725.GI14287@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> 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?)
Think of it as a replacement of cherry-picking series of patches
from remotely related branches.
For example, I maintain two public branches "master" and
"next", the former is supposed to be quite stable and the latter
to contain sane proposed updates that need to be proven before
graduating to "master".
Sometimes I get patches that I have to apply on top of "next"
because of textual dependency, but the changes are worthwhile to
have it in "master" earlier than the changes the other series
depends on.
o---o---o---o---o master
\
o---o---o---o---o next
\
o---o---o good
$ git checkout good
$ git rebase --onto master next
o---o---o---o---o master
| \
| o---o---o good
\
o---o---o---o---o next
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-29 22:44 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, Matthias Lederhofer
In-Reply-To: <20060629222009.GA9310@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
> Hello,
>
>> *AND* more than one pattern. (something I miss in normal grep)
>
> so do I.
So do I.
I am wondering if we would rather want to do something like
expression `find` command let's you build. In other words:
git grep --extended-expression '(' 'foo' -o 'bar' ')' -a 'frotz'
might be what we would eventually want. And I have this nagging
suspicion that if we allow to say something like this
git grep --and -e a -e b
right now, it would make it more cumbersome (read: backward
compatibility wart) to support both styles later.
I could be talked into
git grep -e a -a -e b
but that would already be building that expression engine, so...
^ permalink raw reply
* Re: [PATCH 2/2] Rename man1 and man7 variables to man1dir and man7dir
From: Junio C Hamano @ 2006-06-29 22:45 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e81gim$cf7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> 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?
Thanks. Will do.
^ permalink raw reply
* Re: Improved three-way blob merging code
From: Alex Riesen @ 2006-06-29 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.64.0606291028010.12404@g5.osdl.org>
Linus Torvalds, Thu, Jun 29, 2006 19:45:20 +0200:
> IOW, what I'd like git-merge-tree to do is to be able to at a minimum say:
>
> - will a merge succeed cleanly, and if not, show me where the problem
> spots are.
> - what will the result of the merge look like.
>
> because that's actually what a downstream developer wants to do. He'd just
> do
>
> git fetch linus
> git show-changes linus..my-branch
>
> which would basically be the preparatory thing for sending me an email
> saying "please merge 'my-branch', and you'll see this".
it's a "git show-merge linus..my-branch" :)
> Now, obviously, I think that there's a _lot_ of overlap between doing this
> and actually doing the merge itself, so hopefully the things I do will at
> least have some things in common and perhaps help you do the proper
> recursive merger.
I certanly hope so: only the last pass of the recursive merge seem to
really need the index. It's use in all the previuos recursions looks
more like abuse.
^ permalink raw reply
* Re: CFT: merge-recursive in C (updated)
From: Alex Riesen @ 2006-06-29 23:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0606291945200.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Thu, Jun 29, 2006 20:40:46 +0200:
> > >
> > > When diff-index and diff-files compare a tree entry or an index
> > > entry with a file in the working tree, they do not compute the
> > > blob hash value for the file in the working tree. 0{40} is used
> > > on the RHS in such a case. When the working tree file matches
> > > the corresponding index entry, then we know RHS matches what is
> > > in the index, so both sides have the blob hash value.
> >
> > Ok. Am I correct in the assumption, that if the file in working tree has
> > the same SHA1 as LHS, than the next "git-update-index --refresh" will
> > remove the entry from git-diff-index output?
> > This is what actually happens, if I do "git-update-index --refresh", so I
> > suspect that I have an SHA1 update gone missing somewhere.
>
> I think the problem is more like this (in ce_match_stat_basic()):
>
> if (ce->ce_mtime.sec != htonl(st->st_mtime))
> changed |= MTIME_CHANGED;
> if (ce->ce_ctime.sec != htonl(st->st_ctime))
> changed |= CTIME_CHANGED;
>
> If you update with --index-info, the mtime and ctime is not updated
> from the file in the working directory.
Oh, I see. I was under impression git-diff-index does not use mtime/ctime.
Thought it was just mode+sha between treeish and index.
$ man git-diff-index
git-diff-index <tree-ish>
compares the <tree-ish> and the files on the filesystem.
git-diff-index --cached <tree-ish>
compares the <tree-ish> and the index.
So it does compare treeish ad index, but only if explicitly told so.
Pity, there seem to be no way to update the times in --index-info
protocol yet. Maybe it'll be even never needed, after cache functions
gone libraries.
> All the more a reason to go forward with direct calls to read_cache() and
> write_cache(). At the moment, my plan is
>
> - trivially split the read_cache() code into read_cache()/read_cache_from(),
> - introduce flush_cache(),
> - trivially rewrite add_file_to_cache(), and add_cache_info() from
> builtin-update-index.c, move that to read-tree.c, too, and
> - throw out the pipe to git-update-index from merge-recursive.c
> altogether.
>
> This should be less intrusive than it sounds: with the introduction of
> read_cache_from() it should be trivial to handle the problem of different
> index files.
>
> We have to put a lock_file on the index file at the start, and write the
> index file at the end.
>
Yes, very nice plan, all by itself :)
^ permalink raw reply
* Re: rebasing trouble
From: J. Bruce Fields @ 2006-06-29 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkrfoaky.fsf@assigned-by-dhcp.cox.net>
On Thu, Jun 29, 2006 at 03:34:21PM -0700, Junio C Hamano wrote:
> For example, I maintain two public branches "master" and
> "next", the former is supposed to be quite stable and the latter
> to contain sane proposed updates that need to be proven before
> graduating to "master".
>
> Sometimes I get patches that I have to apply on top of "next"
> because of textual dependency, but the changes are worthwhile to
> have it in "master" earlier than the changes the other series
> depends on.
>
> o---o---o---o---o master
> \
> o---o---o---o---o next
> \
> o---o---o good
>
> $ git checkout good
> $ git rebase --onto master next
>
> o---o---o---o---o master
> | \
> | o---o---o good
> \
> o---o---o---o---o next
>
OK, so you're saying "take everything in good but not in next, and try to apply
it to master."
I don't know why I find that syntax so counterintuitive. Something like
git checkout -b newgood master
git cherry-pick next..good
would seem more obvious. But I think this has been discussed before. OK,
thanks for the explanation.
--b.
^ permalink raw reply
* Re: [PATCH] Makefile: set USE_PIC on Linux x86_64 for linking with Git.pm
From: Pavel Roskin @ 2006-06-30 0:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e81jr5$l1c$1@sea.gmane.org>
Hi, Jakub!
I don't have the newsgroup access, so I'm copying to the mailing list
instead.
On Fri, 2006-06-30 at 00:22 +0200, Jakub Narebski wrote:
> If I remember correctly everybody agreed that autoconf is least evil of the
> whole autotools package.
Sort of. Some people were less dismissive than others.
> pasky suggested to write ./configure script by
> hand on #git...
That's probably not a good idea. Autoconf can do this very well if used
correctly. And I'm ready to help when it comes to correctness.
> 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
The problem with optional support is that you suddenly have two
alternative mechanisms to adjust the build to the system, and both
should be kept in a working condition. But it's a good first step.
> 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.
The link doesn't show the "@" characters correctly. Maybe somebody
could establish a git repository? Ideally, the autoconf changes should
go to one of the Git branches.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] move get_merge_bases() to core lib; use it in merge-recursive
From: Alex Riesen @ 2006-06-30 0:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606292050380.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Thu, Jun 29, 2006 21:06:56 +0200:
>
> Okay. Convinced.
>
> I tested my patch again, and like Alex said, a test fails. But I tested on
> top of Alex's latest merge-recursive patch, which has that nasty
> update-index bug, and that is the reason for the test to fail.
>
> 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.
>
Just for reference, I'll repost all my patches again, somewhat
consolidated. Your merge_base patches can be applied on top of that
series.
^ 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