* Re: Cygwin can't handle huge packfiles?
From: Jakub Narebski @ 2006-04-07 8:27 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd55ls24.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * pack-*.pack file has the following format:
[...]
> * pack-*.idx file has the following format:
[...]
Could you please put the information in parent post somewhere in
Documentation, for example Documentation/technical/pack-format.txt
(perhaps together with putting description of packing heuristic from
http://marc.theaimsgroup.com/?l=git&m=114134881923320 by Jon Loeliger in
Documentation/technical/pack-heuristics.txt even if it doesn't conform to
"serious documentation" standards)?
Thanks in advance
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* blame now knows -S
From: Junio C Hamano @ 2006-04-07 9:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Fredrik Kuivinen
I've made a few changes to "git blame" myself:
- fix breakage caused by recent revision walker reorganization;
- use built-in xdiff instead of spawning GNU diff;
- implement -S <ancestry-file> like annotate does.
Depending on the density of changes, it now appears that blame
is 10%-30% faster than annotate. I thought CVS emulator might
be interested to give it a whirl..
^ permalink raw reply
* Re: blame now knows -S
From: Junio C Hamano @ 2006-04-07 9:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Fredrik Kuivinen
In-Reply-To: <7v1ww9loon.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I've made a few changes to "git blame" myself:
>
> - fix breakage caused by recent revision walker reorganization;
> - use built-in xdiff instead of spawning GNU diff;
> - implement -S <ancestry-file> like annotate does.
>
> Depending on the density of changes, it now appears that blame
> is 10%-30% faster than annotate. I thought CVS emulator might
> be interested to give it a whirl..
Sorry, forgot to mention... The updated blame will be in "next",
not in "master" yet.
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Nicolas Pitre @ 2006-04-07 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kees-Jan Dijkzeul, Linus Torvalds
In-Reply-To: <7vhd55ls24.fsf@assigned-by-dhcp.cox.net>
On Fri, 7 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Mon, 3 Apr 2006, Linus Torvalds wrote:
> >>
> >> That said, I think git _does_ have problems with large pack-files. We have
> >> some 32-bit issues etc
> >
> > I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
> > the packfile data structure does. The index has 32-bit offsets into
> > individual pack-files.
> >
> > That's not hugely fundamental,...
>
> Linus _does_ understand what he means, but let me clarify and
> outline a possible future direction.
>
[...]
For the record, the delta code also has 32-bit limitations of its own
presently. It cannot encode a delta against a buffer which is larger
than 4GB.
I however made sure the byte 0 could be used as a prefix for future
encoding extensions, like 64-bit file offsets for example.
Nicolas
^ permalink raw reply
* Git is one year old today
From: Luck, Tony @ 2006-04-07 16:16 UTC (permalink / raw)
To: git
Happy birthday to git ... one year old today. Counting
the "birth" as the point at which Linus made the first commit
of the git sources into git:
commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
-Tony
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Junio C Hamano @ 2006-04-07 18:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604071002530.2215@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 7 Apr 2006, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@osdl.org> writes:
>>
>> > On Mon, 3 Apr 2006, Linus Torvalds wrote:
>> >>
>> >> That said, I think git _does_ have problems with large pack-files. We have
>> >> some 32-bit issues etc
>> >
>> > I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
>> > the packfile data structure does. The index has 32-bit offsets into
>> > individual pack-files.
>> >
>> > That's not hugely fundamental,...
>>
>> Linus _does_ understand what he means, but let me clarify and
>> outline a possible future direction.
>
> For the record, the delta code also has 32-bit limitations of its own
> presently. It cannot encode a delta against a buffer which is larger
> than 4GB.
>
> I however made sure the byte 0 could be used as a prefix for future
> encoding extensions, like 64-bit file offsets for example.
True the delta data representation, not just the "delta code",
has that limitation, but I do not think you issue "insert 0-byte
literal data" command from the deltifier side right now, so we
should be OK.
Maybe we would want to check (cmd == 0) case to detect delta
extension that we do not handle right now?
^ permalink raw reply
* Can't export whole repo as patches
From: Peter Baumann @ 2006-04-07 18:47 UTC (permalink / raw)
To: git
I'd like to export the whole history of a project of mine via patches
but I can't get the inital commit.
How can I get the inital commit as a patch?
That's what I tried:
git --version
git version 1.2.4 # debian sarge
mkdir /tmp/testrepo && cd /tmp/testrepo
git-init-db
echo a > a_file.txt
git-add a_file.txt
git-commit -a -m "a_file added"
echo b >> a_file.txt
git-commit -a -m "a_file modifed"
xp:/tmp/testrepo git-format-patch master~1
0001-a_file-modified.txt
cat 0001-a_file-modified.txt
From nobody Mon Sep 17 00:00:00 2001
From: Peter Baumann <peter.baumann@gmail.com>
Date: Fri Apr 7 12:20:54 2006 +0200
Subject: [PATCH] a_file modified
---
a_file.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
d8ceeed82a29004c066a98e0d390818e65fa9da7
diff --git a/a_file.txt b/a_file.txt
index 7898192..422c2b7 100644
--- a/a_file.txt
+++ b/a_file.txt
@@ -1 +1,2 @@
a
+b
--
1.2.4
As you can see, there is only a patch of the second commit. But it seems that
this behaviour is correct, because I asked for the diff between master^..master
Obviously, I wanted a way to get the diff of master~2..master.
Trying harder:
git-format-patch master~2
Not a valid rev master~2 (master~2..HEAD)
Any hint to the correct way is appreciated.
</me thinking loudly>
The best would be if git would have an implicit tag or branch called "init"
(name doesn't really matter) which is the root of an empty repository. In that case
one can do git-format-patch root..master and it would the right thing.
Greetings,
Peter Baumann
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Nicolas Pitre @ 2006-04-07 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd55jkz0.fsf@assigned-by-dhcp.cox.net>
On Fri, 7 Apr 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Fri, 7 Apr 2006, Junio C Hamano wrote:
> >
> >> Linus Torvalds <torvalds@osdl.org> writes:
> >>
> >> > On Mon, 3 Apr 2006, Linus Torvalds wrote:
> >> >>
> >> >> That said, I think git _does_ have problems with large pack-files. We have
> >> >> some 32-bit issues etc
> >> >
> >> > I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
> >> > the packfile data structure does. The index has 32-bit offsets into
> >> > individual pack-files.
> >> >
> >> > That's not hugely fundamental,...
> >>
> >> Linus _does_ understand what he means, but let me clarify and
> >> outline a possible future direction.
> >
> > For the record, the delta code also has 32-bit limitations of its own
> > presently. It cannot encode a delta against a buffer which is larger
> > than 4GB.
> >
> > I however made sure the byte 0 could be used as a prefix for future
> > encoding extensions, like 64-bit file offsets for example.
>
> True the delta data representation, not just the "delta code",
> has that limitation, but I do not think you issue "insert 0-byte
> literal data" command from the deltifier side right now, so we
> should be OK.
>
> Maybe we would want to check (cmd == 0) case to detect delta
> extension that we do not handle right now?
Good idea. Will send you a patch.
Nicolas
^ permalink raw reply
* Re: Can't export whole repo as patches
From: Junio C Hamano @ 2006-04-07 19:18 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20060407184701.GA6686@xp.machine.de>
Peter Baumann <peter.baumann@gmail.com> writes:
> How can I get the inital commit as a patch?
format-patch is designed to get a patch to send to upstream, and
does not handle the root commit. In your two revisions
repository, you could do something like this:
$ git diff-tree -p --root master~1
Or more in general:
$ git rev-list master |
git diff-tree --stdin --root --pretty=fuller -p
BTW, I've been meaning to add --pretty=patch to give
format-patch compatible output to diff-tree, but haven't got
around to actually do it. Another thing I've been meaning to do
is "git log --diff" which is more or less "git whatchanged".
^ permalink raw reply
* realloc
From: Morten Welinder @ 2006-04-07 20:11 UTC (permalink / raw)
To: GIT Mailing List
I could be wrong, but shouldn't
var = realloc (var, whatever);
be changed to call xrealloc? That, or assign to a different variable and check
for NULL.
This should affect the last four hits below.
M.
/scratch/welinder/git> grep -w realloc *.c
daemon.c: newlist = realloc(socklist, sizeof(int) *
(socknum + 1));
diff-delta.c: out = realloc(out, outsize);
git.c: cmdname = realloc(cmdname, cmdname_alloc * sizeof(*cmdname));
ls-files.c: which->excludes = realloc(which->excludes,
sha1_file.c: buf = realloc(buf, size);
^ permalink raw reply
* Re: realloc
From: Junio C Hamano @ 2006-04-07 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <118833cc0604071311v1da93f83n112cc2ea44552ca9@mail.gmail.com>
"Morten Welinder" <mwelinder@gmail.com> writes:
> I could be wrong, but shouldn't
>
> var = realloc (var, whatever);
>
> be changed to call xrealloc? That, or assign to a different variable and check
> for NULL.
>
> This should affect the last four hits below.
>
> M.
>
>
>
>
> /scratch/welinder/git> grep -w realloc *.c
> daemon.c: newlist = realloc(socklist, sizeof(int) *
> (socknum + 1));
> diff-delta.c: out = realloc(out, outsize);
> git.c: cmdname = realloc(cmdname, cmdname_alloc * sizeof(*cmdname));
> ls-files.c: which->excludes = realloc(which->excludes,
> sha1_file.c: buf = realloc(buf, size);
There is no excuse for not using xrealloc() in git.c,
ls-files.c, and sha1_file.c.
The diff-delta.c code wants to be independent from the rest of
git code, so it probably should check the returned value itself.
Historically to a certain degree daemon.c also wanted to be
independent from the rest of git, but I suspect it still is the
case (it uses small pieces from packet interface but that is
about it).
^ permalink raw reply
* [PATCH] Fix paths on FreeBSD by processing gitk like other scripts
From: Eric Anholt @ 2006-04-07 21:03 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]
The paths for python and tk are not /usr/bin for FreeBSD, so I moved
gitk to gitk.tk and added a rule to sed in the proper path to "wish" in
making gitk, and also added the appropriate default path for python.
--
Eric Anholt anholt@FreeBSD.org
eric@anholt.net eric.anholt@intel.com
[-- Attachment #1.2: git-freebsd.diff --]
[-- Type: text/x-patch, Size: 1635 bytes --]
diff --git a/.gitignore b/.gitignore
index b5959d6..e9d5a7b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -121,6 +121,7 @@ git-verify-tag
git-whatchanged
git-write-tree
git-core-*/?*
+gitk
test-date
test-delta
common-cmds.h
diff --git a/Makefile b/Makefile
index 3367b8c..de28dec 100644
--- a/Makefile
+++ b/Makefile
@@ -136,6 +136,9 @@ SCRIPT_PERL = \
SCRIPT_PYTHON = \
git-merge-recursive.py
+SCRIPT_TK = \
+ gitk.tk
+
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
@@ -174,6 +177,15 @@ # Backward compatibility -- to be remove
PROGRAMS += git-ssh-pull$X git-ssh-push$X
# Set paths to tools early so that they can be used for version tests.
+ifeq ($(uname_S),FreeBSD)
+ ifndef PYTHON_PATH
+ PYTHON_PATH = /usr/local/bin/python
+ endif
+ ifndef WISH_PATH
+ WISH_PATH = /usr/local/bin/wish8.4
+ endif
+endif
+
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
endif
@@ -183,6 +195,9 @@ endif
ifndef PYTHON_PATH
PYTHON_PATH = /usr/bin/python
endif
+ifndef WISH_PATH
+ WISH_PATH = wish
+endif
PYMODULES = \
gitMergeCommon.py
@@ -484,6 +499,12 @@ common-cmds.h: Documentation/git-*.txt
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
+ chmod +x $@
+
+$(patsubst %.tk,%,$(SCRIPT_TK)) : % : %.tk
+ rm -f $@
+ sed -e "s|exec wish|exec $(WISH_PATH)|" \
+ $@.tk >$@
chmod +x $@
git-cherry-pick: git-revert
diff --git a/gitk b/gitk.tk
similarity index 100%
rename from gitk
rename to gitk.tk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply related
* [ANNOUNCE] Stacked GIT 0.9
From: Catalin Marinas @ 2006-04-07 22:05 UTC (permalink / raw)
To: git
Stacked GIT 0.9 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
The main features in this release:
# Faster three-way merge by using 'git-read-tree --aggressive' and
dealing with conflicts internally (gitmergeonefile.py removed)
# StGIT repositories are now 'git prune'-safe
# 'show' command for displaying a given patch
# 'uncommit' command for reversing the effects of 'commit'
# '--series' option added to the 'import' command
# '--merged' option added to the 'push' and 'pull' commands to check
for patches merged upstream
# '--undo' option added to 'refresh'
# Patch refreshing can be done for individual files only
# '--stdout' option added to 'export'
# '--mbox' option added to 'mail'
# 'smtpdelay' configuration option for delays between messages sending
# $PAGER or the 'pager' configuration option used for the 'show' and
'diff' commands
# '--force' option removed from the 'new' command
# Bug fixes
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Fix the clone command failure
Fix the 'status --reset' for individual files
Remove the --force option for new
Allow patch refreshing for some files only
Use the GIT-specific environment as default
Check whether the file exists in the fold command
Add prune-safety to StGIT
Allow tag objects to be passed on the command line
Add --stdout option to export
Add --mbox option to the 'mail' command
Fix the e-mail address escaping
Fix the reset command to set HEAD to a proper id
Allow stg to be loaded in pydb and not run main()
Print a shorter usage message with the --help option
Add a merged upstream test for pull and push
Add --series to import
Cache the base_dir value for subsequent calls
Pass the --aggressive flag to git-read-tree
gitmergeonefile.py should use git.get_base_dir()
Deal with merge conflicts directly
Add the --patch option to export
Add the --strip option to import
Fix the patch name stripping in import
Update the TODO file
The gitmergeonefile config section is deprecated
Add the "smtpdelay" config option
Create stgit/basedir.py for determining the .git directory
Remove the checking for the default configuration values
Add extra headers to the e-mail messages
Add the '--undo' option to 'refresh'
Add a 'show' command
Remove the basedir exception throwing
Use a pager for diff and show commands
Use 'git-*' instead of 'git *'
Release 0.9
Chuck Lever:
"stg pull" says "popping all patches" even when it doesn't
Use a separate directory for patches under each branch subdir
Add an option to "stg branch" to convert the internal format
Karl Hasselström:
[PATCH 2/2] Add 'stg uncommit' command
Use --refid option even when sending a cover mail
Change the signature start string to "-- \n"
Update .git/refs/heads/base after patch deletion
Kirill Smelkov:
[trivial] fix spelling typos
Paolo 'Blaisorblade' Giarrusso:
Stgit - gitmergeonefile.py: handle removal vs. changes
Pass --directory to git-ls-files for stg status
Pavel Roskin:
stgit: typo fixes
Make tutorial a valid asciidoc article.
stg export: check if there are any patches to export
Treat "stg --help cmd" and "stg help cmd" like "stg cmd
Improve "stg uncommit" help text.
Sam Vilain:
common: parse 'email (name)' correctly
--
Catalin
^ permalink raw reply
* [ANNOUNCE] GIT 1.2.6
From: Junio C Hamano @ 2006-04-08 0:56 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.6.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.6-1.$arch.rpm (RPM)
These fixes are my birthday present to git ;-). I'll also do
the 1.3.0-rc3 tonight.
----------------------------------------------------------------
Changes since v1.2.5 are as follows:
Junio C Hamano:
parse_date(): fix parsing 03/10/2006
diff_flush(): leakfix.
count-delta: match get_delta_hdr_size() changes.
Nicolas Pitre:
check patch_delta bounds more carefully
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17.2
From: Petr Baudis @ 2006-04-08 1:06 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
to join the series of git-related announcements, Cogito-0.17.2, the next
maintenance release on the current stable (v0.17) branch of Cogito, the
human-friendly version control system on top of Git, is available now.
There are only very few changes, it looks that we are pretty stable:
Chris Wright:
cogito spec BuildRequires update
Dennis Stosberg:
cogito: Push tags over http
Petr Baudis:
Improved cg-version output (use cg-object-id -d)
cg-patch -c: Stop also at ^diff --git when slurping the commit message
Fixed embarassing cg-admin-rewritehist bug
Make cg-add/rm warnings less confusing: s/files/items/
cogito-0.17.2
P.S.: Visit us at #git @ FreeNode!
Happy hacking,
--
Petr "Stable Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: git/cogito suggestion: tags with descriptions
From: Petr Baudis @ 2006-04-08 2:35 UTC (permalink / raw)
To: Zack Brown; +Cc: Junio C Hamano, git
In-Reply-To: <20050912010051.GJ15630@pasky.or.cz>
Dear diary, on Mon, Sep 12, 2005 at 03:00:51AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Mon, Sep 05, 2005 at 11:24:31PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > I'm not sure. I'm not as familiar with the low-level git commands as I am with
> > cogito. But cogito has a -d option for giving a tag description. I guess what
> > would be closest to what I was thinking about would be this:
> >
> > $ cg-tag -d "First draft, everything in place." 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $ cg-tag-ls
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $
> >
> > or something like that. Currently when I do the above cg-tag command,
> > a subsequent cg-tag-ls gives just:
> >
> > $ cg-tag-ls
> > 0.1 f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> >
> > In fact, I probably wouldn't even be interested in seeing the actual hash key
> > unless I gave a special flag, maybe -f (for "full"):
> >
> > $ cg-tag-ls
> > 0.1 Initial idea complete
> > 0.3 First draft, everything in place.
> > $ cg-tag-ls -f
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
>
> That's a nice idea (except that I'd prefer -l). I'll implement this
> after cogito-0.14.
So, I did. ;-) (In the master branch now.) The format is slightly
different from the proposed one:
S cogito-0.16rc2 7766e3ba0664
S cogito-0.17 51392f2dd82a Poetic cogito-0.17.
S cogito-0.17rc1 7cb4d8972d5b Behold, cogito-0.17rc1! Plenty new features and cool stuff.
% cogito-0.8 f9f0459b5b39
% cogito-0.9 cc5517b4ea41
test 05862786175d
Object IDs are still shown, but abbreviated so they shouldn't get in the
way too much; the full first line is shown in the list output,
untrimmed. The initial flag column denotes signed tags by 'S', "direct
tags" (not pointing to a tag object) by '%' and broken tags by '!'.
P.S.: Also, cg-tag received a lot of improvements in the last two days.
Now features the same cool editor as cg-commit (but only if ran with
-e), -d was renamed to -m (but will stay aliased for quite some time),
cg-tag now also accepts multiple -m options for creating multi-paragraph
descriptions from the commandline, and bunch of other minor stuff was
implemented.
Thanks for the idea,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Script for automated historical Git tree grafting
From: Petr Baudis @ 2006-04-08 3:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: torvalds, linux-kernel, git
In-Reply-To: <20060406175246.3bd1c972.akpm@osdl.org>
Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> >
> > This script enables Git users to easily graft the historical Git tree
> > (Bitkeeper history import) to the current history.
>
> What impact will that have on the (already rather poor) performance of
> git-whatchanged, gitk, etc?
Negative. ;-)
I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
the whole tree should be roughly equally fast as it was before grafting,
but git-whatchanged on individual paths is _significantly_ slower.
That said, 1.3.0rc2 should already have Linus' optimization which should
fix or at least mitigate the performance hit on narrowed-down
git-whatchanged.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* GIT 1.3.0-rc3
From: Junio C Hamano @ 2006-04-08 8:07 UTC (permalink / raw)
To: git
I do not think there are any more remaining major issue for a
real 1.3.0, so here is hopefully the final round of rc. Testing,
fixing and polishing are appreciated.
Changes since v1.3.0-rc2 are as follows:
* documentation (Francis Daly, Jon Loeliger, Marco Roeland)
* add regexp to pickaxe (Petr Baudis)
* add git-clean (Pavel Roskin)
* cvsimport fix (Johannes Schindelin)
* svnimport fix (Karl Hasselström)
* imap-send updates (Mike McCormack)
* assorted build and porting fixes (Johannes Schindelin)
* gitk updates (Keith Packard, Mark Wooding, Paul Mackerras, Pavel Roskin
Rutger Nijlunsing, Stephen Rothwell)
* http-fetch can use PROPFIND in place of objects/info/packs (Nick Hengeveld)
* deltifier bounds safety (Nicolas Pitre)
* clone fix
* fix blame, broken by recent revision walker updates
* use built-in-xdiff in combine-diff
* use built-in-xdiff in blame
* support -S in blame
* diff_flush() memory leak fix when NO_OUTPUT
* make human-date parsing friendlier to our European friends.
* optimize thin-pack generation by pack-objects
^ permalink raw reply
* [ANNOUNCE] qgit-1.2rc1
From: Marco Costalba @ 2006-04-08 9:44 UTC (permalink / raw)
To: git; +Cc: linux-kernel
qgit is a very fast git GUI viewer with a lot of features .
The biggest new feature this time is *code range filtering*
Select a file and open the file/annotation viewer, then wait for
annotation finished and then select a history revision just to be sure
annotation info is displayed.
You will see the new 'filter' button (in annotation window tool
bar, not in main view tool bar) enabled. Press it and the file history
will be shrinked to show only revisions that modified the selected lines.
Selected code region is also highlighted for better browsing.
Filter button is a toggle button, so just press again it to release the filter.
NOTE NOTE: Range filtering it's _slippery_ code, there are a lot of
subtle details involved, so may be something it's still missing/bogous,
qgit-1.2rc1 it's here to let properly test before final release.
DOWNLOAD
Tarball is at
http://prdownloads.sourceforge.net/qgit/qgit-1.2rc1.tar.bz2?download
Git archive is at
http://digilander.libero.it/mcostalba/scm/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
To install from tarball use:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
CHANGELOG
- add support for code range filtering
- much improved graph for partial repos views. Use new --boundary
git-rev-list option
- pressing ESC in startup dialog make application to quit
- add support for quick open of latest visited repositories
- add support for launching an external diff viewer
- speed-up git commands execution using usleep() in external program launcher
- highlight filter matches in revision logs
- add git version compatibility check
- fix duplicated unapplied patches in StGIT when qgit is called with
--all option
- fix run from subdirectory regression
Marco
^ permalink raw reply
* Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 10:41 UTC (permalink / raw)
To: git
Hi,
I just accidentally reran "git-repack -a -d" on a repository, where I just
had run it. And I noticed a funny thing: Of about 4000 objects, it reused
all but 8. So I reran it, and it reused all but 2. I ran it once again,
and it reused all.
The really funny thing is: it created the same pack every time!
It is not critical, evidently, but I'd like to know what is causing this
rather undeterministic behaviour. (Before you ask: no, I did not make a
backup before running the tests, so I unfortunately cannot reproduce it).
Ciao,
Dscho
P.S.: This is the output:
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3391), reused 4241 (delta 3379)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4257 (delta 3391)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4259 (delta 3393)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.2rc1
From: Marco Costalba @ 2006-04-08 11:07 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550604080244y40b36292ja5cfecac28e1e749@mail.gmail.com>
On 4/8/06, Marco Costalba <mcostalba@gmail.com> wrote:
> qgit is a very fast git GUI viewer with a lot of features .
>
> The biggest new feature this time is *code range filtering*
>
Before hitting the warning pop-up about git version compatibility at
qgit launch,please note that a git with --boundary option support
is required.
git-rev-list --boundary has been merged after git-1.3.0.rc1, so better
upgrade git to latest upstream snapshot git-1.3.0rc3
Of course final qgit-1.2 will be out only _after_ released git-1.3.0
Marco
^ permalink raw reply
* Re: blame now knows -S
From: Fredrik Kuivinen @ 2006-04-08 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git, Fredrik Kuivinen
In-Reply-To: <7v1ww9loon.fsf@assigned-by-dhcp.cox.net>
On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> I've made a few changes to "git blame" myself:
>
> - fix breakage caused by recent revision walker reorganization;
> - use built-in xdiff instead of spawning GNU diff;
> - implement -S <ancestry-file> like annotate does.
>
> Depending on the density of changes, it now appears that blame
> is 10%-30% faster than annotate. I thought CVS emulator might
> be interested to give it a whirl..
>
Nice work!
There is another possible optimisation with respect to xdiff. Instead
of producing the diff on the xdiff side and parsing the diff in
blame.c, we could add another call back which just gets the relevant
information from the hunk header. I don't know how much we would gain
from this, but it might be worth a try.
- Fredrik
^ permalink raw reply
* Re: blame now knows -S
From: Marco Costalba @ 2006-04-08 13:53 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
On 4/8/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> > I've made a few changes to "git blame" myself:
> >
> > - fix breakage caused by recent revision walker reorganization;
> > - use built-in xdiff instead of spawning GNU diff;
> > - implement -S <ancestry-file> like annotate does.
> >
> > Depending on the density of changes, it now appears that blame
> > is 10%-30% faster than annotate. I thought CVS emulator might
> > be interested to give it a whirl..
> >
>
> Nice work!
>
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
>
If I can comment on this thread, I would like to note IMHO that given
the differences in
languages (C vs Perl) and the use of almost the same algorithm, just a
10%-30% in speed difference between blame and annotate it means that
any further optimization can gain little because the bottleneck is
elsewhere.
And I think is in getting the revision's history. Call it
git-rev-list, although both
blame and annotate use directly the library revision.h
After the new xdiff merge, git-rev-list accounts for almost whole the time.
Normally more then 80% in qgit.
Although the qgit annotation algorithm is different from both blame
and annotate I think
that a faster git-rev-list <path> or revison history walker as you may
want to call it it's a key
in really speed-up annotation stuff.
Marco
^ permalink raw reply
* [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Marco Roeland @ 2006-04-08 15:27 UTC (permalink / raw)
To: git; +Cc: Davide Libenzi
Compiling this module gave the following warnings (some double dutch!):
xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
A superficial tracking of their usage, without deeper knowledge about the
algorithm, indeed confirms that there are code paths on which these
variables will be used uninitialized. In practice these code paths might never
be reached, but then these fixes will not change the algorithm. If these
code paths are ever reached we now at least have a predictable outcome. And
should the very small performance impact of these initializations be
noticeable, then they should at least be replaced by comments why certain
code paths will never be reached.
Some extra initializations in this patch now fix the warnings.
---
xdiff/xdiffi.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
0b0bf00d67a66b3ef47862cc51b1d37763f4b99b
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index e81bca6..641362d 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -218,7 +218,7 @@ static long xdl_split(unsigned long cons
if (ec >= xenv->mxcost) {
long fbest, fbest1, bbest, bbest1;
- fbest = -1;
+ fbest = fbest1 = -1;
for (d = fmax; d >= fmin; d -= 2) {
i1 = XDL_MIN(kvdf[d], lim1);
i2 = i1 - d;
@@ -230,7 +230,7 @@ static long xdl_split(unsigned long cons
}
}
- bbest = XDL_LINE_MAX;
+ bbest = bbest1 = XDL_LINE_MAX;
for (d = bmax; d >= bmin; d -= 2) {
i1 = XDL_MAX(off1, kvdb[d]);
i2 = i1 - d;
@@ -296,6 +296,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
} else {
long ec;
xdpsplit_t spl;
+ spl.i1 = spl.i2 = 0;
/*
* Divide ...
--
1.3.0.rc3.gad0b
^ permalink raw reply related
* Re: [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Davide Libenzi @ 2006-04-08 17:18 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060408152720.GA11125@fiberbit.xs4all.nl>
On Sat, 8 Apr 2006, Marco Roeland wrote:
> Compiling this module gave the following warnings (some double dutch!):
>
> xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
> xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
> xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
>
> A superficial tracking of their usage, without deeper knowledge about the
> algorithm, indeed confirms that there are code paths on which these
> variables will be used uninitialized. In practice these code paths might never
> be reached, but then these fixes will not change the algorithm. If these
> code paths are ever reached we now at least have a predictable outcome. And
> should the very small performance impact of these initializations be
> noticeable, then they should at least be replaced by comments why certain
> code paths will never be reached.
These paths are never reached because of the way data is prepared before
and passed to the function. Unfortunately the compiler cannot know this.
Using them as -1 or XDL_LINE_MAX won't help either, since those are out of
domain values. You can leave it there and the algo won't suffer, or you
can relax a little the warning level when building the file.
- Davide
^ 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