* [ANNOUNCE] git-cola 1.3.4
From: David Aguilar @ 2008-12-25 23:36 UTC (permalink / raw)
To: git
The latest git-cola release v1.3.4 is available at the
usual places:
git-cola homepage:
http://cola.tuxfamily.org/
git-cola on github:
git clone git://github.com/davvid/git-cola.git
http://github.com/davvid/git-cola/tree/master
git-cola is a powerful git gui written in Python.
git-cola uses the PyQt4 gui toolkit and is supported on all
platforms where git is available, including Windows/msysgit.
The latest versions of git-cola sport a fresh new interface and
several new helpful dialogs. One of the newer git-cola dialogs
is the 'Commit Comparison' dialog which allows you to compare
arbitrary commits using standard merge tools (e.g. xxdiff).
git-cola uses a custom git command called git-difftool to
drive the merge tools. This is useful if you'd like
to use the functionality in your own scripts or from the
command line. I will post the current version of git-difftool
to the list for feedback and possible inclusion in the
git contrib/ area since it is a generally useful utility.
See the online documentation for more information.
---------------------------------------------------------------
Changes since v1.3.3 are as follows:
Barry Roberts (3):
Fix stash typo
Context menu items for Commits list
Speed up file identification
David Aguilar (15):
i18n: fix a few more places where we weren't unicode-safe
compare: reinstate the Commit -> Compare File... menu action
views: fix obsolete references to the old dockwidgets
diff gui: properly restore the scroll bar values on update
cola: pass --no-color to 'git diff' to avoid receiving ANSI sequences
controllers: fix a typo when restoring the scrollbar values on rescan
options dialog: fix some annoyances with the font handling
compare: fix an edge case when decreasing the number of log results
Use 'utf-8' instead of 'utf8' in core.encode()
models: call 'git update-index --refresh' in get_workdir_state()
rebase: list all branches in the branch chooser, not just local ones
INSTALL: remove references to the now unused 'file' command
win32: add a win32/ folder for storing all of the win32 hacks
INSTALL: fix a typo in the windows installation section
remote: add a rebase checkbox to the pull dialog
--
David
^ permalink raw reply
* Re: git rev-list with --name-status?
From: skillzero @ 2008-12-25 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vr63w84iy.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 25, 2008 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You seem to be referring to contrib/hooks/post-receive-email as "The
> script that comes with git". It does have customization possibility
> already implemented and documented:
>
> hooks.showrev
> The shell command used to format each revision in the email, with
> "%s" replaced with the commit id. Defaults to "git rev-list -1
> --pretty %s", displaying the commit id, author, date and log
> message. To list full patches separated by a blank line, you
> could set this to "git show -C %s; echo".
>
> ...
>
> I think you can use "git show --name-status %s; echo" instead, if you like
> the --name-status output.
Thanks, that's perfect. I was using an older version of
contrib/hooks/post-receive-email that didn't have hooks.showrev so I
didn't realize it already had support for what I wanted.
^ permalink raw reply
* Re: git rev-list with --name-status?
From: Junio C Hamano @ 2008-12-25 18:59 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812241453x4ae50362g4bcd3317e5be0429@mail.gmail.com>
skillzero@gmail.com writes:
> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> git rev-list --pretty --stdin $oldrev..$newrev
I should have noticed this earlier.
You seem to be referring to contrib/hooks/post-receive-email as "The
script that comes with git". It does have customization possibility
already implemented and documented:
hooks.showrev
The shell command used to format each revision in the email, with
"%s" replaced with the commit id. Defaults to "git rev-list -1
--pretty %s", displaying the commit id, author, date and log
message. To list full patches separated by a blank line, you
could set this to "git show -C %s; echo".
One of my day-job repositories has:
[hooks]
mailinglist = some-secret-project@day-job-domain.com
emailprefix = "[SOME-SECRET-PROJECT GIT] "
showrev = "git show --stat %s; echo"
I think you can use "git show --name-status %s; echo" instead, if you like
the --name-status output.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Pau Garcia i Quiles @ 2008-12-25 18:53 UTC (permalink / raw)
To: git
In-Reply-To: <20081225100033.GA8451@b2j>
On Thu, Dec 25, 2008 at 11:00 AM, bill lam <cbill.lam@gmail.com> wrote:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Works for me both in Hardy and Intrepid. If you have trouble building
from source, there are binary package for Hardy and Intrepid in my
PPA:
http://launchpad.net/~pgquiles/+archive
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Junio C Hamano @ 2008-12-25 18:50 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20081225102527.GB8451@b2j>
bill lam <cbill.lam@gmail.com> writes:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
I do not use configure myself (use of configure is entirely optional, and
it is not tested often and core developers do not touch that part very
much --- in a sense, use of autoconf is a second-class citizen in our
build process); it is plausible that it has broken checks for detecting
the need of NO_UINTMAX_T.
Relevant part of configure.ac reads like this:
# Define NO_UINTMAX_T if your platform does not have uintmax_t
AC_CHECK_TYPE(uintmax_t,
[NO_UINTMAX_T=],
[NO_UINTMAX_T=YesPlease],[
#include <inttypes.h>
])
AC_SUBST(NO_UINTMAX_T)
and I do not see anything suspicious there...
Running "./configure --verbose" might leave some clues in config.log; for
me on my primary development box (Debian on x86_64), the relevant part
passes the test (iow, inclusion of inttypes.h does give a working
uintmax_t type) like this:
configure:5709: checking for uintmax_t
configure:5742: cc -c -g -O2 conftest.c >&5
configure:5748: $? = 0
configure:5763: result: yes
^ permalink raw reply
* Re: git rev-list with --name-status?
From: demerphq @ 2008-12-25 18:24 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812241453x4ae50362g4bcd3317e5be0429@mail.gmail.com>
2008/12/24 <skillzero@gmail.com>:
> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> git rev-list --pretty --stdin $oldrev..$newrev
>
> I'd like to also include the output of --name-status so the email
> shows which files were changed by each commit (rather than just a
> summary at the end since our pushes sometimes have a lot of commits in
> them).
>
> git rev-list doesn't seem to support --name-status and git log doesn't
> seem to support --stdin. Is there a better way to do what I want?
I wrote the following shell script function which you can add to your
post-receive-mail script. Any git rev-list --pretty statements there
can have the --pretty removed and have their output redirected to
this, and you get what you want. An existing function changed to use
it follows. Theres probably prettier ways to do this, but hope it
helps. Id send a diff of the script as a whole except that its full of
other likely irrelevent changes.
Yves
# show_log_for_sha1s_on_std()
#
# take a list of sha1's on STDIN and print out their logs.
#
# if there are
#
# 0 commits output a notice saying there no changes in this update
#
# 1 commits - show the log only
#
# >1 commits - show log with --name-status output (list of files with
M/D/A type tags
# next to them for Modified Deleted and Added)
#
# This partly exists because we can't use --name-status with rev-list, and
# because we cant use --stdin with git log (even tho the docs might say
# otherwise in older gits). Although since we count SHA1's we can also do some
# special stuff like dealing with the 0/1/N commits differently.
show_log_for_sha1s_on_stdin()
{
perl -e'
chomp(my @sha1= <>);
if (!@sha1) {
print "No new revisions added by this update\n";
}
else {
my $ns= @sha1 > 1 ? " --name-status" : "";
for my $idx (0..$#sha1) {
print $idx ? "\n" : "" ,
`git-log --pretty$ns -1 $sha1[$idx]`;
}
}
'
}
generate_create_branch_email()
{
# This is a new branch and so oldrev is not valid
echo " at $newrev ($newrev_type)"
echo ""
echo $LOGBEGIN
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
# ref that were previously not accessible
# (see generate_update_branch_email for the explanation of this
# command)
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --stdin $newrev | show_log_for_sha1s_on_stdin
echo $LOGEND
}
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* RFE: git-import-dsc should support http-links
From: Rolf Leggewie @ 2008-12-25 14:51 UTC (permalink / raw)
To: git
Hi,
merry Christmas everyone. I hope this is the right place for this, I
looked around and it seemed to me it was, so here it goes.
It would be nice if the following just worked:
"git-import-dsc
http://ftp.de.debian.org/debian/pool/main/g/gnucash/gnucash_2.2.6-2.dsc"
Regards
Rolf
PS: How about some kind of official bug tracker for git?
^ permalink raw reply
* Re: [announce] gc
From: Stephen Haberman @ 2008-12-25 15:23 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Matthieu Moy, git
In-Reply-To: <e2b179460812230706p12e4f052v960f162e08011ae6@mail.gmail.com>
> > I'm a little cautious about using words like corporate/enterprise as
> > there is nothing exclusively "corporate/enterprise" about any of the
> > hooks in the project, we just happened to be on a corporate/enterprise
> > project when we came up with them.
>
> As the workflows these seem to support are centralised (as you say
> these apply equally well in some non-corporate / enterprise projects),
> how about git-central?
Ah, that's excellent. Thanks for the suggestion.
- Stephen
^ permalink raw reply
* Re: a few Topgit patches
From: martin f krafft @ 2008-12-25 14:58 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <20081223143035.GA24087@cassiopeia.tralala>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.12.23.1530 +0100]:
> I hacked using topgit for some time now, and found the following changes
> to topgit useful:
>
> Uwe Kleine-König (3):
> tg export: implement skipping empty patches for collapse driver
> tg export: Implement flattening patch paths for quilt mode
> tg export (quilt): Implement numbering the patches
They all look good. I am a bit concerned about the use of
single-letter options at this stage. tg-export is bound to grow, and
using them all up now might mean breaking compatibility later, when
a more common option needs e.g. -f, which has already been taken.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"oh what a tangled web we weave,
when first we practice to deceive.
but my how we improve the score,
as we practice more and more."
-- sir walter scott
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <49537197.1000805@lsrfire.ath.cx>
On Thu, 25 Dec 2008, René Scharfe wrote:
> configure seems to be confused. What happens if you take it out of the
> equation, i.e. run the following commands?
>
> $ make distclean
> $ make prefix=/usr
Thanks René! I followed your installation, deleted the old configure,
and it compiled successfully,
Happy holidays to everyone on mailing list!
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩104 李白 夜泊牛渚懷古
牛渚西江夜 青天無片雲 登舟望秋月 空憶謝將軍
余亦能高詠 斯人不可聞 明朝挂帆席 楓葉落紛紛
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Heikki Orsila @ 2008-12-25 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> * The packfile machinery hopefully is more robust when dealing with
> corrupt packs if redundant objects involved in the corruption are
> available elsewhere.
Has anyone written a summary of how Git's redundancy operates?
* What would be the probability for a single bit flip to corrupt the
repository?
* And what is the situation where a single bit flip can not corrupt the
database?
* When (which commands/functions) is error detection done?
Heikki
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: René Scharfe @ 2008-12-25 11:42 UTC (permalink / raw)
To: bill lam; +Cc: git, Junio C Hamano
In-Reply-To: <20081225102527.GB8451@b2j>
bill lam schrieb:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
>
> and this is the error logged.
>
> GIT_VERSION = 1.6.1
> * new build flags or prefix
> In file included from /usr/include/netinet/in.h:24,
> from git-compat-util.h:78,
> from builtin.h:4,
> from fast-import.c:142:
> /usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
> /usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
> fast-import.c: In function ‘parse_progress’:
> fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
> make: *** [fast-import.o] Error 1
>
> version of gcc:
> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
I don't get any error on Ubuntu 8.10 on x86_64 (but several of those
warnings about ignored return values), neither with the tar file nor a
cloned repository (in the former case I had to add a "make configure"
step, though).
Line 52 of /usr/include/stdint.h:
typedef unsigned int uint32_t;
Lines 134-136 of /usr/include/stdint.h:
#if __WORDSIZE == 64
typedef long int intmax_t;
typedef unsigned long int uintmax_t;
If you get to line 136, you probably are on a 64 bit installation, too,
correct?
configure seems to be confused. What happens if you take it out of the
equation, i.e. run the following commands?
$ make distclean
$ make prefix=/usr
René
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <7v3agca7fp.fsf@gitster.siamese.dyndns.org>
> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
> recent enough platform that ships with modern enough header files that
> define ANSI uintmax_t type?
No, I did not do anything on that,
make clean
./configure --prefix=/usr
make
and this is the error logged.
GIT_VERSION = 1.6.1
* new build flags or prefix
In file included from /usr/include/netinet/in.h:24,
from git-compat-util.h:78,
from builtin.h:4,
from fast-import.c:142:
/usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
/usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
fast-import.c: In function ‘parse_progress’:
fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
make: *** [fast-import.o] Error 1
version of gcc:
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩105 杜甫 月夜
今夜鄜州月 閨中只獨看 遙憐小兒女 未解憶長安
香霧雲鬟濕 清輝玉臂寒 何時倚虛幌 雙照淚痕乾
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Junio C Hamano @ 2008-12-25 10:13 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20081225100033.GA8451@b2j>
bill lam <cbill.lam@gmail.com> writes:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Nobody reported it since that was added about a month and half ago.
Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
recent enough platform that ships with modern enough header files that
define ANSI uintmax_t type?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
comment out the block (in the Makefile),
fdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
ndif
to make a successful compilation. Does it happen to me only?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩282 白居易 後宮詞
淚濕羅巾夢不成 夜深前殿按歌聲 紅顏未老恩先斷 斜倚薰籠坐到明
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Christian MICHON @ 2008-12-25 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 25, 2008 at 7:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release GIT 1.6.1 is available at the usual
> places:
>
a nice christmas gift indeed! thanks for making this release possible.
my best wishes to the list for xmas and incoming 2009!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] strbuf_readlink semantics update.
From: Junio C Hamano @ 2008-12-25 7:23 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, Linus Torvalds, git
In-Reply-To: <4952532F.5050704@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Pierre Habouzit schrieb:
>> On Tue, Dec 23, 2008 at 06:16:01PM +0000, Linus Torvalds wrote:
>>>
>>> On Tue, 23 Dec 2008, Pierre Habouzit wrote:
>>>> when readlink fails, the strbuf shall not be destroyed. It's not how
>>>> read_file_or_gitlink works for example.
>>> I disagree.
>>>
>>> This patch just makes things worse. Just leave the "strbuf_release()" in
>>> _one_ place.
> ...
> The "append or do nothing" rule is broken by strbuf_getline(), but I agree
> to your reasoning. How about refining this rule a bit to "do your thing
> and roll back changes if an error occurs"? I think it's not worth to undo
> allocation extensions, but making reverting first time allocations seems
> like a good idea. Something like this?
I think this is much better than Pierre's. Pierre's "if it is called
strbuf_*, it should always append" is a good uniformity to have in an API,
but making the caller suffer for clean-up is going backwards. The reason
we use strbuf when we can is so that the callers do not have to worry
about memory allocation issues too much.
^ permalink raw reply
* Re: [PATCH] handle_remote_ls_ctx can parsing href starting at http://
From: Junio C Hamano @ 2008-12-25 7:04 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1230021075-10113-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> The program call remote_ls() to get remote objects over http;
> handle_remote_ls_ctx() is used to parse it's response to populated
> "struct remote_ls_ctx" that is returned from remote_ls().
>
> The handle_remote_ls_ctx() function assumed that the server will
> returned local path in href field, but RFC 4918 demand of support full
> URI (http://localhost/repo.git for example).
>
> This resulted in push failure (git-http-push ask server
> PROPFIND /repo.git/alhost:8080/repo.git/refs/) when a server returned
> full URI.
Thanks.
Do you mean PROPFIND was made to that garbage with :8080 in it when the
server returned a full URI http://localhost/repo.git as in the example in
the previous paragraph, or are you using a different example here?
I am contemplating of munging your commit log message like this...
commit e1f33efe07b9a520505fccd71bea1292fc9448dd
Author: Kirill A. Korinskiy <catap@catap.ru>
Date: Tue Dec 23 11:31:15 2008 +0300
http-push: support full URI in handle_remote_ls_ctx()
The program calls remote_ls() to get list of files from the server over
HTTP; handle_remote_ls_ctx() is used to parse its response to populate
"struct remote_ls_ctx" that is returned from remote_ls().
The handle_remote_ls_ctx() function assumed that the server returns a
local path in href field, but RFC 4918 (14.7) demand of support full URI
(e.g. "http://localhost:8080/repo.git").
This resulted in push failure (e.g. git-http-push issues a PROPFIND
request to "/repo.git/alhost:8080/repo.git/refs/" to the server).
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2008-12-25 6:48 UTC (permalink / raw)
To: git
Welcome to git community.
This message talks about how git.git is managed, and how you can work
with it.
* IRC and Mailing list
Many active members of development community hang around on #git
IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
The development however is primarily done on the git mailing list
(git@vger.kernel.org). If you have patches, please send them to the
list, following Documentation/SubmittingPatches.
I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use. But I am obviously not
perfect. If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one.
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man". The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be. It also contains some helper scripts I use
to maintain git.
The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has
links to documentation of older releases.
The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested. It
is a good demonstration of how to use an update hook to automate
a task.
There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu". I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.
The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting. There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable. Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The
last such release was 1.6.1 done on Dec 24th 2008. You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off
from "master" at that point. Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it. The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.0.6.
New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however. Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository. I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.
The quality of topic branches are judged primarily by the mailing list
discussions. Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience". Luckily, most of them start out in
the latter, better shape.
The "next" branch is to merge and test topic branches in the
latter category. In general, the branch always contains the tip
of "master". It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage. I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.
The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.
After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics. The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master". An announcement will be made to warn
people about such a rebasing.
The "pu" (proposed updates) branch bundles all the remainder of
topic branches. The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general. By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable). Similarly to the above, I
do it with this:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release. There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.
Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines who your changes should
be sent to. As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.
Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:
- git-gui/ comes from Shawn Pearce's git-gui project:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the
current shape. Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:
- Linus on general design issues.
- Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe and Jeff King on general implementation issues.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong on git-svn.
- Simon Hausmann on git-p4.
- Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.
- J. Bruce Fields on documentaton issues.
- Johannes Schindelin, Johannes Sixt and others for their effort
to move things forward on the Windows front. Most of the fruits
from their porting efforts have been merged to the mainline git.git
repository in 1.6.0 release.
- People on non-Linux platforms for keeping their eyes on
portability; especially, Randal Schwartz, Theodore Ts'o,
Jason Riedy, Thomas Glanzmann, but countless others as well.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
I also keep a copy of it at http://members.cox.net/junkio/
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1
From: Junio C Hamano @ 2008-12-25 6:36 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.6.1 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also found in the
vicinity.
RPMS/$arch/git-*-1.6.1-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.6.1 Release Notes
========================
Updates since v1.6.0
--------------------
When some commands (e.g. "git log", "git diff") spawn pager internally, we
used to make the pager the parent process of the git command that produces
output. This meant that the exit status of the whole thing comes from the
pager, not the underlying git command. We swapped the order of the
processes around and you will see the exit code from the command from now
on.
(subsystems)
* gitk can call out to git-gui to view "git blame" output; git-gui in turn
can run gitk from its blame view.
* Various git-gui updates including updated translations.
* Various gitweb updates from repo.or.cz installation.
* Updates to emacs bindings.
(portability)
* A few test scripts used nonportable "grep" that did not work well on
some platforms, e.g. Solaris.
* Sample pre-auto-gc script has OS X support.
* Makefile has support for (ancient) FreeBSD 4.9.
(performance)
* Many operations that are lstat(3) heavy can be told to pre-execute
necessary lstat(3) in parallel before their main operations, which
potentially gives much improved performance for cold-cache cases or in
environments with weak metadata caching (e.g. NFS).
* The underlying diff machinery to produce textual output has been
optimized, which would result in faster "git blame" processing.
* Most of the test scripts (but not the ones that try to run servers)
can be run in parallel.
* Bash completion of refnames in a repository with massive number of
refs has been optimized.
* Cygwin port uses native stat/lstat implementations when applicable,
which leads to improved performance.
* "git push" pays attention to alternate repositories to avoid sending
unnecessary objects.
* "git svn" can rebuild an out-of-date rev_map file.
(usability, bells and whistles)
* When you mistype a command name, git helpfully suggests what it guesses
you might have meant to say. help.autocorrect configuration can be set
to a non-zero value to accept the suggestion when git can uniquely
guess.
* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
* "git add" gained a built-in synonym for people who want to say "stage
changes" instead of "add contents to the staging area" which amounts
to the same thing.
* "git apply" learned --include=paths option, similar to the existing
--exclude=paths option.
* "git bisect" is careful about a user mistake and suggests testing of
merge base first when good is not a strict ancestor of bad.
* "git bisect skip" can take a range of commits.
* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding
by default.
* "git check-attr --stdin" can check attributes for multiple paths.
* "git checkout --track origin/hack" used to be a syntax error. It now
DWIMs to create a corresponding local branch "hack", i.e. acts as if you
said "git checkout --track -b hack origin/hack".
* "git checkout --ours/--theirs" can be used to check out one side of a
conflicting merge during conflict resolution.
* "git checkout -m" can be used to recreate the initial conflicted state
during conflict resolution.
* "git cherry-pick" can also utilize rerere for conflict resolution.
* "git clone" learned to be verbose with -v
* "git commit --author=$name" can look up author name from existing
commits.
* output from "git commit" has been reworded in a more concise and yet
more informative way.
* "git count-objects" reports the on-disk footprint for packfiles and
their corresponding idx files.
* "git daemon" learned --max-connections=<count> option.
* "git daemon" exports REMOTE_ADDR to record client address, so that
spawned programs can act differently on it.
* "git describe --tags" favours closer lightweight tags than farther
annotated tags now.
* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
configuration option.
* "git diff" learned to put more sensible hunk headers for Python,
HTML and ObjC contents.
* "git diff" learned to vary the a/ vs b/ prefix depending on what are
being compared, controlled by diff.mnemonicprefix configuration.
* "git diff" learned --dirstat-by-file to count changed files, not number
of lines, when summarizing the global picture.
* "git diff" learned "textconv" filters --- a binary or hard-to-read
contents can be munged into human readable form and the difference
between the results of the conversion can be viewed (obviously this
cannot produce a patch that can be applied, so this is disabled in
format-patch among other things).
* "--cached" option to "git diff has an easier to remember synonym "--staged",
to ask "what is the difference between the given commit and the
contents staged in the index?"
* "git for-each-ref" learned "refname:short" token that gives an
unambiguously abbreviated refname.
* Auto-numbering of the subject lines is the default for "git
format-patch" now.
* "git grep" learned to accept -z similar to GNU grep.
* "git help" learned to use GIT_MAN_VIEWER environment variable before
using "man" program.
* "git imap-send" can optionally talk SSL.
* "git index-pack" is more careful against disk corruption while
completing a thin pack.
* "git log --check" and "git log --exit-code" passes their underlying diff
status with their exit status code.
* "git log" learned --simplify-merges, a milder variant of --full-history;
"gitk --simplify-merges" is easier to view than with --full-history.
* "git log" learned "--source" to show what ref each commit was reached
from.
* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
names of tags that point at the commit.
* "git merge --squash" and "git merge --no-ff" into an unborn branch are
noticed as user errors.
* "git merge -s $strategy" can use a custom built strategy if you have a
command "git-merge-$strategy" on your $PATH.
* "git pull" (and "git fetch") can be told to operate "-v"erbosely or
"-q"uietly.
* "git push" can be told to reject deletion of refs with receive.denyDeletes
configuration.
* "git rebase" honours pre-rebase hook; use --no-verify to bypass it.
* "git rebase -p" uses interactive rebase machinery now to preserve the merges.
* "git reflog expire branch" can be used in place of "git reflog expire
refs/heads/branch".
* "git remote show $remote" lists remote branches one-per-line now.
* "git send-email" can be given revision range instead of files and
maildirs on the command line, and automatically runs format-patch to
generate patches for the given revision range.
* "git submodule foreach" subcommand allows you to iterate over checked
out submodules.
* "git submodule sync" subcommands allows you to update the origin URL
recorded in submodule directories from the toplevel .gitmodules file.
* "git svn branch" can create new branches on the other end.
* "gitweb" can use more saner PATH_INFO based URL.
(internal)
* "git hash-object" learned to lie about the path being hashed, so that
correct gitattributes processing can be done while hashing contents
stored in a temporary file.
* various callers of git-merge-recursive avoid forking it as an external
process.
* Git class defined in "Git.pm" can be subclasses a bit more easily.
* We used to link GNU regex library as a compatibility layer for some
platforms, but it turns out it is not necessary on most of them.
* Some path handling routines used fixed number of buffers used alternately
but depending on the call depth, this arrangement led to hard to track
bugs. This issue is being addressed.
Fixes since v1.6.0
------------------
All of the fixes in v1.6.0.X maintenance series are included in this
release, unless otherwise noted.
* Porcelains implemented as shell scripts were utterly confused when you
entered to a subdirectory of a work tree from sideways, following a
symbolic link (this may need to be backported to older releases later).
* Tracking symbolic links would work better on filesystems whose lstat()
returns incorrect st_size value for them.
* "git add" and "git update-index" incorrectly allowed adding S/F when S
is a tracked symlink that points at a directory D that has a path F in
it (we still need to fix a similar nonsense when S is a submodule and F
is a path in it).
* "git am" after stopping at a broken patch lost --whitespace, -C, -p and
--3way options given from the command line initially.
* "git diff --stdin" used to take two trees on a line and compared them,
but we dropped support for such a use case long time ago. This has
been resurrected.
* "git filter-branch" failed to rewrite a tag name with slashes in it.
* "git http-push" did not understand URI scheme other than opaquelocktoken
when acquiring a lock from the server (this may need to be backported to
older releases later).
* After "git rebase -p" stopped with conflicts while replaying a merge,
"git rebase --continue" did not work (may need to be backported to older
releases).
* "git revert" records relative to which parent a revert was made when
reverting a merge. Together with new documentation that explains issues
around reverting a merge and merging from the updated branch later, this
hopefully will reduce user confusion (this may need to be backported to
older releases later).
* "git rm --cached" used to allow an empty blob that was added earlier to
be removed without --force, even when the file in the work tree has
since been modified.
* "git push --tags --all $there" failed with generic usage message without
telling saying these two options are incompatible.
* "git log --author/--committer" match used to potentially match the
timestamp part, exposing internal implementation detail. Also these did
not work with --fixed-strings match at all.
* "gitweb" did not mark non-ASCII characters imported from external HTML fragments
correctly.
^ permalink raw reply
* Re: Questions about repo and git submodule
From: Emily Ren @ 2008-12-25 6:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailinglist
In-Reply-To: <20081223152951.GB27865@spearce.org>
Hi Shawn,
Merry Christmas !
Thank you for your guide ! I've created git repository with submodules
with a simple script successfully.
Now I have another question, since my android repo will always sync
up from android.git.kernel.org, my git repository needs to be updated
accordingly. Is there a tool I can use to sync up from repo to git
repositoy ?
Thanks,
Emily
On Tue, Dec 23, 2008 at 11:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Emily Ren <lingyan.ren@gmail.com> wrote:
>>
>> I have some questions about android repo and git submodule.
>>
>> I created a repo repository with below commands:
>> 1. repo init -u git://android.git.kernel.org/platform/manifest.git
>> 2. repo initialized in /android
>>
>> 1. The android dir is not a git repository,
>
> Correct, it is not a git repository. The repo tool does not use
> git submodules. The top level of a repo client has a ".repo/"
> directory with metadata, not a ".git/" directory. The table of
> contents (the subprojects) is stored in XML files under ".repo/".
>
> <aside>
> I actually fought against the XML format for repo's manifest, but
> others felt it was suitable. And then walked away from the project
> after Android open-sourced its code tree. Leaving me to maintain it.
> I see a file format simplification in the future for repo.
> </aside>
>
>> if other people clone my
>> android code, how does it work?
>
> Sadly this isn't supported correctly. You can't initialize one
> repo client from another, even though you can git clone one git
> repository from any other. Its a bug in repo's design. The data
> under ".repo/projects/" isn't laid out correctly to permit reuse
> of one repo client to initialize another.
>
> Its something I keep meaning to fix, but its going to take some
> real effort.
>
> In the mean time, there is a "--mirror" flag to repo init
> which can be used to clone everything into bare repositories.
> Those bare repositories can be published for others to repo init
> from, though you need to customize the manifest.git:default.xml
> so that the embedded URL refers back to your server and not
> android.git.kernel.org. Yet another thing I want to fix.
>
>> 2. I want to make android dir to be a git repository, is it workable
>> that I create submodule for each subdirectory in another directory? Is
>> there a script for it?
>
> You might be able to do something like this:
>
> cd /android
> git init
> repo forall -c 'cd /android && git submodule add `pwd`'
>
> Also, you might want to consider asking questions related to repo
> on the repo-discuss@googlegroups.com mailing list. There's a lot
> more repo users there than on the git mailing list, and they have
> started to come up with their own "tips n tricks".
>
> --
> Shawn.
>
^ permalink raw reply
* Re: git rev-list with --name-status?
From: Junio C Hamano @ 2008-12-25 3:24 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812241453x4ae50362g4bcd3317e5be0429@mail.gmail.com>
skillzero@gmail.com writes:
> I'd like to also include the output of --name-status so the email
> shows which files were changed by each commit (rather than just a
> summary at the end since our pushes sometimes have a lot of commits in
> them).
>
> git rev-list doesn't seem to support --name-status and git log doesn't
> seem to support --stdin. Is there a better way to do what I want?
The plumbing rev-list never runs diff internally.
Depending on what you want, "git log --stat" or "git log --name-only" or
even "git log --name-status -B -C" may serve you nicely.
"Depending on what you want" is the key phrase that indicates that what
you are asking for would be most likely found in Porcelains, not plumbing.
Even though there is not much reason to _avoid_ using "log" these days,
you could do your own scripting for whatever reason; perhaps you feel like
it would be a more macho thing to do (which isn't), perhaps you want more
customization than options supported by the stock "log" Porcelain gives
you.
In olden days, people scripted around plumbing, partly because the
Porcelains were implemented that way, and partly because the choices the
Porcelains back then gave you was limited than what we have now. Your
script may look like this:
git-rev-list --parents $range |
while read commit parents
do
... do whatever you want with them ...
done
or
git-rev-list --pretty --parents $range |
perl -e '
while (<>) {
if (/^commit /../^$/) {
if (/^commit (\S+)(.*)?/) {
... we have a new commit; flush what
... you accumulated for the previous one.
... and prepare for this commit.
... $1 is the commit, $2 has parents you
... can further split
}
... do "header" things here ...
next;
}
s/^ //;
... do "log" things here ...
}
... flush what you accumulated for the last commit.
'
^ permalink raw reply
* [JGIT PATCH 19/23] Allow more direct access to determine isWritten
From: Shawn O. Pearce @ 2008-12-25 2:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1230171079-17156-19-git-send-email-spearce@spearce.org>
This gives the JVM a better chance to inline the isWritten method
when writing a pack file out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/PackWriter.java | 2 +-
.../spearce/jgit/transport/PackedObjectInfo.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index bb889e8..50d06c2 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -932,7 +932,7 @@ boolean isDeltaRepresentation() {
* @return true if object is already written; false otherwise.
*/
boolean isWritten() {
- return getOffset() != 0;
+ return offset != 0;
}
PackedObjectLoader getReuseLoader() {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/PackedObjectInfo.java b/org.spearce.jgit/src/org/spearce/jgit/transport/PackedObjectInfo.java
index f37f421..045b795 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/PackedObjectInfo.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/PackedObjectInfo.java
@@ -49,7 +49,7 @@
* objects from the pack. This extension of ObjectId includes the offset.
*/
public class PackedObjectInfo extends ObjectId {
- private long offset;
+ protected long offset;
private int crc;
--
1.6.1.rc4.301.g5497a
^ permalink raw reply related
* [JGIT PATCH 16/23] Defer parsing of the ObjectId while walking a PackIndex Iterator
From: Shawn O. Pearce @ 2008-12-25 2:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1230171079-17156-16-git-send-email-spearce@spearce.org>
This is a slight performance improvement for the PackReverseIndex
construction. The only code that really cares about the ObjectId
from a PackIndex entry is test cases. By avoiding construction
we can save some CPU time during the several passes we do to make
the reverse index data structure within PackWriter.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../tst/org/spearce/jgit/lib/PackIndexTest.java | 4 +-
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 2 +-
.../src/org/spearce/jgit/lib/PackIndex.java | 48 +++++++++++--------
.../src/org/spearce/jgit/lib/PackIndexV1.java | 20 +++++---
.../src/org/spearce/jgit/lib/PackIndexV2.java | 27 +++++++----
5 files changed, 61 insertions(+), 40 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackIndexTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackIndexTest.java
index 8ab380e..7163718 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackIndexTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackIndexTest.java
@@ -134,10 +134,10 @@ assertEquals("c59759f143fb1fe21c197981df75a7ee00290799", iter.next()
*/
public void testCompareEntriesOffsetsWithFindOffsets() {
for (MutableEntry me : smallIdx) {
- assertEquals(smallIdx.findOffset(me), me.getOffset());
+ assertEquals(smallIdx.findOffset(me.toObjectId()), me.getOffset());
}
for (MutableEntry me : denseIdx) {
- assertEquals(denseIdx.findOffset(me), me.getOffset());
+ assertEquals(denseIdx.findOffset(me.toObjectId()), me.getOffset());
}
}
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index 3c02955..ec138a0 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -487,7 +487,7 @@ public int compare(MutableEntry o1, MutableEntry o2) {
int i = 0;
for (MutableEntry me : entries) {
- assertEquals(objectsOrder[i++], me.copy());
+ assertEquals(objectsOrder[i++].toObjectId(), me.toObjectId());
}
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndex.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndex.java
index 5fb41b1..5b7a62d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndex.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndex.java
@@ -239,15 +239,10 @@ abstract long findCRC32(AnyObjectId objId) throws MissingObjectException,
* in pack (both mutable).
*
*/
- public static class MutableEntry extends MutableObjectId {
- private long offset;
+ public static class MutableEntry {
+ protected final MutableObjectId idBuffer = new MutableObjectId();
- /**
- * Empty constructor. Object fields should be filled in later.
- */
- public MutableEntry() {
- super();
- }
+ long offset;
/**
* Returns offset for this index object entry
@@ -258,30 +253,43 @@ public long getOffset() {
return offset;
}
- void setOffset(long offset) {
- this.offset = offset;
+ /** @return hex string describing the object id of this entry. */
+ public String name() {
+ ensureId();
+ return idBuffer.name();
}
- private MutableEntry(MutableEntry src) {
- super(src);
- this.offset = src.offset;
+ /** @return a copy of the object id. */
+ public ObjectId toObjectId() {
+ ensureId();
+ return idBuffer.toObjectId();
}
- /**
- * Returns mutable copy of this mutable entry.
- *
- * @return copy of this mutable entry
- */
+ /** @return a complete copy of this entry, that won't modify */
public MutableEntry cloneEntry() {
- return new MutableEntry(this);
+ final MutableEntry r = new MutableEntry();
+ ensureId();
+ r.idBuffer.w1 = idBuffer.w1;
+ r.idBuffer.w2 = idBuffer.w2;
+ r.idBuffer.w3 = idBuffer.w3;
+ r.idBuffer.w4 = idBuffer.w4;
+ r.idBuffer.w5 = idBuffer.w5;
+ r.offset = offset;
+ return r;
+ }
+
+ protected void ensureId() {
+ // Override in implementations.
}
}
protected abstract class EntriesIterator implements Iterator<MutableEntry> {
- protected MutableEntry objectId = new MutableEntry();
+ protected final MutableEntry entry = initEntry();
protected long returnedNumber = 0;
+ protected abstract MutableEntry initEntry();
+
public boolean hasNext() {
return returnedNumber < getObjectCount();
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV1.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV1.java
index 02465f6..90b5f6f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV1.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV1.java
@@ -162,21 +162,27 @@ boolean hasCRC32Support() {
private int levelTwo;
+ @Override
+ protected MutableEntry initEntry() {
+ return new MutableEntry() {
+ protected void ensureId() {
+ idBuffer.fromRaw(idxdata[levelOne], levelTwo
+ - Constants.OBJECT_ID_LENGTH);
+ }
+ };
+ }
+
public MutableEntry next() {
for (; levelOne < idxdata.length; levelOne++) {
if (idxdata[levelOne] == null)
continue;
-
if (levelTwo < idxdata[levelOne].length) {
- long offset = NB.decodeUInt32(idxdata[levelOne], levelTwo);
- objectId.setOffset(offset);
- objectId.fromRaw(idxdata[levelOne], levelTwo + 4);
+ entry.offset = NB.decodeUInt32(idxdata[levelOne], levelTwo);
levelTwo += Constants.OBJECT_ID_LENGTH + 4;
returnedNumber++;
- return objectId;
- } else {
- levelTwo = 0;
+ return entry;
}
+ levelTwo = 0;
}
throw new NoSuchElementException();
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV2.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV2.java
index cc3ad65..48a5206 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV2.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackIndexV2.java
@@ -234,25 +234,32 @@ else if (cmp == 0) {
private int levelTwo;
+ @Override
+ protected MutableEntry initEntry() {
+ return new MutableEntry() {
+ protected void ensureId() {
+ idBuffer.fromRaw(names[levelOne], levelTwo
+ - Constants.OBJECT_ID_LENGTH / 4);
+ }
+ };
+ }
+
public MutableEntry next() {
for (; levelOne < names.length; levelOne++) {
if (levelTwo < names[levelOne].length) {
- objectId.fromRaw(names[levelOne], levelTwo);
- int arrayIdx = levelTwo / (Constants.OBJECT_ID_LENGTH / 4)
- * 4;
- long offset = NB.decodeUInt32(offset32[levelOne], arrayIdx);
+ int idx = levelTwo / (Constants.OBJECT_ID_LENGTH / 4) * 4;
+ long offset = NB.decodeUInt32(offset32[levelOne], idx);
if ((offset & IS_O64) != 0) {
- arrayIdx = (8 * (int) (offset & ~IS_O64));
- offset = NB.decodeUInt64(offset64, arrayIdx);
+ idx = (8 * (int) (offset & ~IS_O64));
+ offset = NB.decodeUInt64(offset64, idx);
}
- objectId.setOffset(offset);
+ entry.offset = offset;
levelTwo += Constants.OBJECT_ID_LENGTH / 4;
returnedNumber++;
- return objectId;
- } else {
- levelTwo = 0;
+ return entry;
}
+ levelTwo = 0;
}
throw new NoSuchElementException();
}
--
1.6.1.rc4.301.g5497a
^ permalink raw reply related
* [JGIT PATCH 13/23] Dispose of RevCommit buffers when they aren't used in PackWriter
From: Shawn O. Pearce @ 2008-12-25 2:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1230171079-17156-13-git-send-email-spearce@spearce.org>
We don't need the commit buffer, so we might as well throw it
away immediately to reduce the total memory usage within the
writer process.
The same goes for the buffers within UploadPack when its doing
a check to see if it has a complete base.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/PackWriter.java | 2 ++
.../src/org/spearce/jgit/transport/UploadPack.java | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index 89460f2..88b2b1f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -802,10 +802,12 @@ private void findObjectsToPack(final ObjectWalk walker)
while ((o = walker.next()) != null) {
addObject(o);
+ o.dispose();
initMonitor.update(1);
}
while ((o = walker.nextObject()) != null) {
addObject(o);
+ o.dispose();
initMonitor.update(1);
}
initMonitor.endTask();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
index 4401951..d57df03 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
@@ -434,6 +434,7 @@ private boolean wantSatisfied(final RevCommit want) throws IOException {
}
return true;
}
+ c.dispose();
}
return false;
}
--
1.6.1.rc4.301.g5497a
^ permalink raw reply related
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