* Re: [PATCH 2/2] shortlog: code restruturing and clean-up
From: Alex Riesen @ 2007-12-08 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1197077573-14945-2-git-send-email-gitster@pobox.com>
Junio C Hamano, Sat, Dec 08, 2007 02:32:53 +0100:
> Subject: Re: [PATCH 2/2] shortlog: code restruturing and clean-up
restruturing -> restructuring
^ permalink raw reply
* [PATCH] send-email: Allow sleeping between sending mails
From: Dan Nicholson @ 2007-12-08 17:12 UTC (permalink / raw)
To: git
Sometimes when sending many mails, the thread appears out of order for
the recipient. This adds a simple workaround by sleeping between sending
mails. This is controlled by the option --sleep, which defaults to 0.
Since the perl builtin function sleep is used, only integer granularity
is offered. GetOptions seems to perform the necessary checking for this.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
---
Documentation/git-send-email.txt | 5 +++++
git-send-email.perl | 14 +++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 659215a..45341db 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -71,6 +71,11 @@ The --cc option must be repeated for each user you want on the cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
+--sleep::
+ Specify an integer number of seconds to sleep between sending
+ mails. This can help when sending many mails at once and they
+ appear out of order for the recipient. Defaults to 0.
+
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
diff --git a/git-send-email.perl b/git-send-email.perl
index 76baa8e..a105306 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -100,6 +100,9 @@ Options:
--envelope-sender Specify the envelope sender used to send the emails.
+ --sleep Specify an integer number of seconds to sleep between
+ sending mails. Defaults to 0.
+
EOT
exit(1);
}
@@ -158,6 +161,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
my $envelope_sender;
+my $mail_index;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -171,7 +175,7 @@ if ($@) {
}
# Behavior modification variables
-my ($quiet, $dry_run) = (0, 0);
+my ($quiet, $dry_run, $sleep_time) = (0, 0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
@@ -222,6 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
+ "sleep=i" => \$sleep_time,
);
unless ($rc) {
@@ -669,6 +674,7 @@ X-Mailer: git-send-email $gitversion
$reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
$subject = $initial_subject;
+$mail_index = 0;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
@@ -803,6 +809,12 @@ foreach my $t (@files) {
$references = "$message_id";
}
}
+
+ # sleep if requested and there are any mails left
+ if ($sleep_time > 0 && $mail_index < $#files) {
+ sleep $sleep_time;
+ }
+ $mail_index++;
}
if ($compose) {
--
1.5.3.2
^ permalink raw reply related
* Re: RAM consumption when working with the gcc repo
From: Martin Koegler @ 2007-12-08 17:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Jon Smirl, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712071529580.555@xanadu.home>
On Fri, Dec 07, 2007 at 03:46:30PM -0500, Nicolas Pitre wrote:
> On Fri, 7 Dec 2007, david@lang.hm wrote:
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> > > I noticed two things when doing a repack of the gcc repo. First is
> > > that the git process is getting to be way too big. Turning off the
> > > delta caches had minimal impact. Why does the process still grow to
> > > 4.8GB?
> > >
> > > Putting this in perspective, this is a 4.8GB process constructing a
> > > 330MB file. Something isn't right. Memory leak or inefficient data
> > > structure?
> >
> > keep in mind that that 330MB file is _very_ heavily compressed. the simple
> > zlib compression is probably getting you 10:1 or 20:1 compression and the
> > delta compression is a significant multiplier on top of that.
>
> Doesn't matter. Something is indeed fishy.
>
> The bulk of pack-objects memory consumption can be estimated as follows:
>
> 1M objects * sizeof(struct object_entry) ~= 100MB
> 256 window entries with data (assuming a big 1MB per entry) = 256MB
For each (uncompressed) object in the delta window, a delta index is
created. It can have the same size as the uncompressed object.
Each thread has its own window, so using 4 threads means having 1024 objects
in memory => 1 GB
> Delta result caching was disabled therefore 0MB
> read-side delta cache limited to 16MB
>
> So the purely ram allocation might get to roughly 400MB.
>
> Then add the pack and index map, which, depending on the original pack
> size,
> might be 2GB.
>
> So we're pessimistically talking of about 2.5GB of virtual space.
>
> The other 2.3GB is hard to explain.
mfg Martin Kögler
^ permalink raw reply
* Submodules and merging
From: Finn Arne Gangstad @ 2007-12-08 18:40 UTC (permalink / raw)
To: git
>From an earlier discussion here on the mailing list I had the
impression that there was some support for merging submodules from the
supermodule. This does not seem to be the case, but I think it would
be very good if this WAS possible?
Here is the shortest example that still mimics "real" work that shows
the problem. Assume change1 and change2 are done by two different
people in two different repositories and push this into separate
branches in a central repo somewhere. A maintainer at the central
repo wants to merge in one or both changes:
# Create directory and some repos with a simple README
rm -rf submodule-test
mkdir submodule-test
cd submodule-test
( mkdir super-module; cd super-module; git init )
( mkdir sub-module; cd sub-module; git init )
cd super-module
echo 'this is the super module' > README
git add README
git commit -m 'added a readme'
cd ../sub-module
echo 'this is the sub module' > README
git add README
git commit -m 'added a readme'
cd ..
# Make a testdir, clone the master repo, and add
# the sub-module
mkdir testdir
cd testdir
git clone `pwd`/../super-module
cd super-module
git submodule add `pwd`/../../sub-module
git commit -m 'added the submodule'
# make change1 on a branch in both super and sub module
git checkout -b change1
cd sub-module/
git checkout -b sub-change1
echo 'This is change1' > change1
git add change1
git commit -m 'added change1 file'
cd ..
git add sub-module
git commit -m 'did change1 in change1 branch'
# Make change2 on a branch in both super and sub module
git checkout -b change2 master
git submodule update
cd sub-module/
git checkout -b sub-change2
echo 'this is change2' > change2
git add change2
git commit -m 'added change2 file'
cd ..
git add sub-module
git commit -m 'did the change2 change'
# Try to merge change1 and change2
git checkout -b mergetest master
git submodule update
git merge change1
git merge change2
This fails with the somewhat obscure error message:
fatal: cannot merge modes?
Merge with strategy recursive failed.
- Finn Arne
^ permalink raw reply
* Re: RAM consumption when working with the gcc repo
From: Marco Costalba @ 2007-12-08 19:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, david, Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712081153500.27959@racer.site>
On Dec 8, 2007 12:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > BTW does exist a tool to profile memory consumption by each source level
> > struct / vector/ or any other data container?
> >
> > Valgrind checks mainly memory leaks, callgrind gives profiling
> > information in terms of call graphs and times/cycles consumed by each
> > function.
>
> Have you looked at Massif (also part of Valgrind)?
>
Only very quickly, so probably I've missed something, but anyway
that's my comment on Massiv:
- Interesting output is in html format, graph is nice but gives very
general info.
- The tool mainly tracks who called malloc and friends also going back
in the stack frame (in my box if I try to set stack deep at 4 instead
of default 3 program crashes)
- Does not seem to give information regarding the structures where
memory is allocated, only the function names that allocate directly or
indirectly the memory. Nothing like
struct my_data has 34.256 instantiations
struct stuff has 2.456 instantiations
- Relation between memory and time of allocation is IMHO a little bit
confusing, it's like a parameter obtained from multipling allocated
bytes x time, not very useful.
- Regarding the previous point, it seems missing a way to
trigger/snapshotting the memory map in terms of source level
structures used by the application in a given time, triggable through
code.
Just to be clear, the much better callgrind tool allows to insert in
the code the macros
CALLGRIND_START_INSTRUMENTATION and
CALLGRIND_STOP_INSTRUMENTATION
that start/stop recording of events in the code ranges specified by
the developer. What it seems to be missing in massif it's a macro like
MASSIV_SNAPSHOT_MEM_MAP
to be used _where_ developer needs and that gives information on heap
allocation in terms of source level entities that *use* that memory,
not low level addresses or allocator functions.
Thanks
Marco
^ permalink raw reply
* Re: importing bk into git (succeeded)
From: Christoph @ 2007-12-08 19:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <474FC2C5.8060400@op5.se>
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
On Friday 30 November 2007 08:59:01 you wrote:
> Christoph wrote:
> > I am trying to import a BitKeeper repo into a (new) git repo.
> >
> > I am trying with the script bk2git.py that I found on the web.
> > This does not quite work - I fear script is no longer working with the
> > current git release. (I am using the current git release.)
[snip]
> > The following lines fail
> > os.system("cd %s; git-ls-files --deleted | xargs
> > git-update-cache --remove" % tmp_dir)
[snip]
> It should still do this, afaik, although it's probably better
> to just use GIT_DIR nowadays.
Using GIT_DIR works, one has to set it to point to the .git directory (I had
assumed the git_dir to be the one *containing* .git).
Another point with the original script was that you had to have all commiters
in the mapping (email -> name), otherwise it would not work.
(Supplying '*Unknown*' fixed this.)
I have added
- better arguments parsing (see --help)
- ability to do incremental conversions (--incr-db, -r)
- different levels of verbosity
I have attached a working version of the script. I have added comments that
(try to) explain the script if someone else has trouble with it.
Moreover, it is very helpful to put the directories inside a ramdisk.
Otherwise, you have to be extremely patient.
(You have to be patient anyway. For a bk repo of some 14k files (>110MB
when 'clean', 8000 changesets) the script took some 11hrs).
Another issue (when using ramdisks) is memory. On my machine memory is scarce
(only 1 GB). So the ever growing bare repo (can't be gc'ed before getting its
head) exhausted the ramdisk space. I worked around this by doing an
incremental conversion. After each increment a gc is possible and the git
repo shrinks to a managable size (and still fits inside the ramdisk).
So, to sum up: converting a big repo is no fun, but it works, given enough
time (and ram).
Thanks, best regards
Christoph
--
A billion here, a couple of billion there -- first thing you know it
adds up to be real money.
-- Senator Everett McKinley Dirksen
[-- Attachment #2: bk2git.py --]
[-- Type: application/x-python, Size: 10396 bytes --]
^ permalink raw reply
* Re: Git and GCC
From: Joe Buck @ 2007-12-08 19:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J.C. Pizarro, Linus Torvalds, David Miller, gcc, git
In-Reply-To: <Pine.LNX.4.64.0712081223070.27959@racer.site>
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
> > 1. "Don't compress this repo but compact this uncompressed repo
> > using minimal spanning forest and deltas"
> > 2. "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
> > burning it to DVD for backup reasons or before replicating it to
> > internet".
On Sat, Dec 08, 2007 at 12:24:00PM +0000, Johannes Schindelin wrote:
> Patches? ;-)
git list, meet J.C. Pizarro. Care to take him off of our hands for
a while? He's been hanging on the gcc list for some time, and perhaps
seeks new horizons.
Mr. Pizarro has endless ideas, and he'll give you some new ones every day.
He thinks that no one else knows any computer science, and he will attempt
to teach you what he knows, and tell you to rewrite all of your code based
on something he read and half-understood. But he's not interested in
actually DOING the work, mind you; that's up to you. When you object
that he's wasting your time, he'll start talking about freedom of speech.
^ permalink raw reply
* Re: Git and GCC
From: Marco Costalba @ 2007-12-08 20:28 UTC (permalink / raw)
To: Joe Buck
Cc: Johannes Schindelin, J.C. Pizarro, Linus Torvalds, David Miller,
gcc, git
In-Reply-To: <20071208195352.GB4731@synopsys.com>
On Dec 8, 2007 8:53 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
> Mr. Pizarro has endless ideas, and he'll give you some new ones every day.
That's true.
> He thinks that no one else knows any computer science, and he will attempt
> to teach you what he knows,
It's not the only one ;-) is in good and numerous company.
> But he's not interested in
> actually DOING the work, mind you; that's up to you.
Where did have you read this ? I missed that part.
> When you object
> that he's wasting your time, he'll start talking about freedom of speech.
>
Actually he never spoke like that (probably I missed that part too).
Thanks
Marco
^ permalink raw reply
* dmalloc and leaks in git
From: Jon Smirl @ 2007-12-08 20:53 UTC (permalink / raw)
To: Git Mailing List
It is very easy to use dmalloc with git. Follow the instructions here,
http://dmalloc.com/docs/latest/online/dmalloc_4.html
But using dmalloc shows a pervasive problem, none of the git commands
are cleaning up after themselves. For example I ran a simple command,
git-status, and thousands of objects were not freed.
Normally this doesn't hurt since exiting the process obviously frees
all of the memory. But when programming this way it becomes impossible
to tell which leaks were on purpose and which were accidental.
To sort this out an #ifdef DMALLOC needs to be created and then code
for freeing all of the 'on purpose' leaks needs to be added in an
IFDEF right before the process exits. The test scripts can then be
modified to ensure that everything is freed when the command exits.
I've used this process on several projects I've managed and it is a
very good thing to do. Once the new infrastructure is in place leaks
can be detected automatically and nipped in the bud before they get
out of control. The key to making this work is getting code in place
in the #ifdef to free those "on-purpose" leaks.
I tried a couple of year ago to add leak detection to Mozilla but
Mozilla is way too far gone. There are 10,000 places where things are
allocated and not being freed. It is a huge manually intensive task
sorting out which of these were on-purpose vs accidental. If Mozilla
had followed a discipline of ensuring that nothing was every leaked
(by using the scheme above) a lot of recent leak clean up work could
have been avoided.
I don't know enough about the structure of git to add the cleanups in
#ifdefs before exit. People who wrote the commands are going to have
to help out with this.
diff --git a/Makefile b/Makefile
index 0a5df7a..426830c 100644
--- a/Makefile
+++ b/Makefile
@@ -752,7 +752,7 @@ SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
-LIBS = $(GITLIBS) $(EXTLIBS)
+LIBS = $(GITLIBS) $(EXTLIBS) -ldmalloc
BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
$(COMPAT_CFLAGS)
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..8894c30 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -428,3 +428,5 @@ static inline int strtol_i(char const *s, int
base, int *result)
}
#endif
+
+#include "dmalloc.h"
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: dmalloc and leaks in git
From: Johannes Schindelin @ 2007-12-08 20:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712081253t7cd43f87o6001f32fddc01565@mail.gmail.com>
Hi,
On Sat, 8 Dec 2007, Jon Smirl wrote:
> It is very easy to use dmalloc with git. Follow the instructions here,
> http://dmalloc.com/docs/latest/online/dmalloc_4.html
>
> But using dmalloc shows a pervasive problem, none of the git commands
> are cleaning up after themselves. For example I ran a simple command,
> git-status, and thousands of objects were not freed.
Known problem. Goes by the name of "libification" on this list.
Ciao,
Dscho
^ permalink raw reply
* Re: dmalloc and leaks in git
From: Jon Smirl @ 2007-12-08 21:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712082058280.27959@racer.site>
On 12/8/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 8 Dec 2007, Jon Smirl wrote:
>
> > It is very easy to use dmalloc with git. Follow the instructions here,
> > http://dmalloc.com/docs/latest/online/dmalloc_4.html
> >
> > But using dmalloc shows a pervasive problem, none of the git commands
> > are cleaning up after themselves. For example I ran a simple command,
> > git-status, and thousands of objects were not freed.
>
> Known problem. Goes by the name of "libification" on this list.
I tried using dmalloc to find the leak in repack but it is impossible
to sort out the accidental leaks from the on-purpose ones. On exit
there were millions of unfreed objects coming from all over the place.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: dmalloc and leaks in git
From: Johannes Schindelin @ 2007-12-08 21:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712081302h64d9b062kad02c4f13818d59f@mail.gmail.com>
Hi,
On Sat, 8 Dec 2007, Jon Smirl wrote:
> On 12/8/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Sat, 8 Dec 2007, Jon Smirl wrote:
> >
> > > It is very easy to use dmalloc with git. Follow the instructions here,
> > > http://dmalloc.com/docs/latest/online/dmalloc_4.html
> > >
> > > But using dmalloc shows a pervasive problem, none of the git commands
> > > are cleaning up after themselves. For example I ran a simple command,
> > > git-status, and thousands of objects were not freed.
> >
> > Known problem. Goes by the name of "libification" on this list.
>
> I tried using dmalloc to find the leak in repack but it is impossible
> to sort out the accidental leaks from the on-purpose ones. On exit
> there were millions of unfreed objects coming from all over the place.
This might be a starting point:
http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=2083418c5010f04fbcd6e1f67de522ad6acd863d
Hth,
Dscho
^ permalink raw reply
* Re: Removing redundant packs
From: Junio C Hamano @ 2007-12-08 21:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071208125050.GA17478@machine.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> At the same time, I have to be careful not to prune all unreferenced
> objects since they can be referenced in forks.
How about...
(1) In each repository, run "repack -a -d". That would ensure that
everybody has the necessary objects that they themselves need. By
doing this for a repository that borrows from another makes sure
pruning the latter would not break the former, so you start from
leaves and move on to the repositories they borrow from.
(2) In each repository, run "repack -a -l -d". By doing this for a
repository that borrows from another repacks the former without
objects it borrows from the latter, so the former repository will
retain what it needs but will borrow what are common from the
latter, so you start from the repository that does not borrow from
anybody else, and move on to the repositories that borrow from the
one you already run this step.
^ permalink raw reply
* Re: Something is broken in repack
From: Junio C Hamano @ 2007-12-08 22:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712072032410.555@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 7 Dec 2007, Jon Smirl wrote:
>
>> Starting with a 2GB pack of the same data my process size only grew to
>> 3GB with 2GB of mmaps.
>
> Which is quite reasonable, even if the same issue might still be there.
>
> So the problem seems to be related to the pack access code and not the
> repack code. And it must have something to do with the number of deltas
> being replayed. And because the repack is attempting delta compression
> roughly from newest to oldest, and because old objects are typically in
> a deeper delta chain, then this might explain the logarithmic slowdown.
>
> So something must be wrong with the delta cache in sha1_file.c somehow.
I was reaching the same conclusion but haven't managed to spot anything
blatantly wrong in that area. Will need to dig more.
^ permalink raw reply
* [Misfeature] cloning without configuration fails and returns 0
From: Benoit Sigoure @ 2007-12-08 22:21 UTC (permalink / raw)
To: Git Mailing List
Hi,
on a new machine I have access to, I fetched tonight's git master
(git version 1.5.3.7.g9758e) and installed it on my account in order
to clone one of my projects. I did not setup anything in my git
config and stumbled on the following misfeature:
----------------------------------------------------------------------
$ git clone ssh://login@host/~/path/git/project/.git project
Initialized empty Git repository in /home/me/git/project/.git/
Password:
remote: Counting objects: 609, done.
remote: Compressing objects: 100% (465/465), done.
remote: Total 609 (delta 267), reused 462 (delta 134)
Receiving objects: 100% (609/609), 1.56 MiB | 63 KiB/s, done.
Resolving deltas: 100% (267/267), done.
*** Your name cannot be determined from your system services (gecos).
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: empty ident <me@fqdn> not allowed
[last 11 lines repeated 3 times!]
fatal: Not a valid object name HEAD
----------------------------------------------------------------------
Not only the same 11 lines of error message were printed 3 times, but
also the command returned 0!
This is not user friendly at all. So I thought I'd point this out on
this ML.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Where has "git ls-remote" reference pattern matching gone?
From: Eyvind Bernhardsen @ 2007-12-08 22:05 UTC (permalink / raw)
To: git
git-ls-remote(1) says that ls-remote supports filtering by reference
name:
> SYNOPSIS
> git-ls-remote [--heads] [--tags] [-u <exec> | --upload-pack
> <exec>]
> <repository> <refs>...
>
> [...]
>
> <refs>...
> When unspecified, all references, after filtering done
> with
> --heads and --tags, are shown. When <refs>... are
> specified,
> only references matching the given patterns are
> displayed.
>
> [...]
>
> $ git ls-remote --tags public v\*
> d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
> f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/
> v0.99.1
> c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/
> v0.99.2
> 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/
> v0.99.3
But when I try to use the <refs> argument on a current build of git
(git version v1.5.3.7-1112-g9758ecd), I just get its usage message,
which doesn't mention that argument:
> vredefort:[backup]% git ls-remote origin foob
> usage: git-ls-remote [--upload-pack=<git-upload-pack>]
> [<host>:]<directory>
ls-remote was recently made a builtin; was reference filtering
deliberately removed, or was it just lost in translation from the
shell script?
Eyvind Bernhardsen
^ permalink raw reply
* Re: Some git performance measurements..
From: Brian Downing @ 2007-12-08 23:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mike Ralphson, Steffen Prohaska, Junio C Hamano, Nicolas Pitre,
Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712081103430.27959@racer.site>
On Sat, Dec 08, 2007 at 11:05:35AM +0000, Johannes Schindelin wrote:
> On Fri, 7 Dec 2007, Mike Ralphson wrote:
> > I've just tried the mergesort implementation as used in msysgit and that
> > performs faster for me. It's simpler, and compatibly licensed. It looks
> > good.
>
> Now I'm confused. You said you tested qsortG, NetBSD qsort and qlibc,
> with glibc performing the slowest. Now, 4msysgit's implementation is
> based on glibc (Thanks Brian!), so I wonder if you could redo the
> performance tests and say if qsortG still is substantially faster than
> 4msysgit's qsort?
This is just me guessing, but when he said:
> I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> system but has funky licensing, the NetBSD qsort was middle-range and
> the glibc one the slowest of the three (but that could be due to it
> being tuned for a "Sun 4/260"). All of them show over 100x speed
> improvements on a git-status of my main repo (104s -> ~0.7s)
It's possible he tried glibc's actual quicksort implementation, rather
than their "qsort." Their qsort basically has the following behavior:
if size < 1024
mergesort with temporary array on stack
if allocating size bytes would likely cause swapping
quicksort in place
else
mergesort with temporary array in heap
I removed the "quicksort in place" possibility, as it would have added
another sort algorithm and I had no way to easily determine whether
"allocating size bytes would likely cause swapping."
-bcd
^ permalink raw reply
* Re: Removing redundant packs
From: Jeff King @ 2007-12-08 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vsl2cvpef.fsf@gitster.siamese.dyndns.org>
On Sat, Dec 08, 2007 at 01:37:44PM -0800, Junio C Hamano wrote:
> (1) In each repository, run "repack -a -d". That would ensure that
> everybody has the necessary objects that they themselves need. By
> doing this for a repository that borrows from another makes sure
> pruning the latter would not break the former, so you start from
> leaves and move on to the repositories they borrow from.
I'm not sure this works. Try this:
# make parent repo with two commits, fully packed
mkdir parent && cd parent && git init &&
echo content >file && git add file && git commit -m added &&
echo more >>file && git commit -m more -a &&
git repack -a -d
# clone child repo with alternates
git clone -s . ../child
# and now forget about the second commit in the parent
git reset --hard HEAD^
rm -rf .git/logs
# at this point the "parent" repo doesn't know anything about the second
# commit, but contains the objects; the child repo does know about it,
# but relies on the pack in the parent for the objects
# so your advice is to "repack -a -d" first in the child, then in the
# parent.
# child first; output will be: "Nothing new to pack."
cd ../child && git repack -a -d
# and then parent, which will lose the objects for the second commit
cd ../parent && git repack -a -d
# and confirm that child is broken
# output is: "fatal: bad object HEAD"
cd ../child && PAGER=cat git show
You seem to think that repacking without "-l" will pull objects from
alternates, but it doesn't (I have also seen "repack -a -d" recommended
for "how do I break alternates dependencies", but it obviously also
doesn't work for that).
-Peff
^ permalink raw reply
* Re: Removing redundant packs
From: Jeff King @ 2007-12-08 23:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20071208234414.GA31121@sigill.intra.peff.net>
On Sat, Dec 08, 2007 at 06:44:15PM -0500, Jeff King wrote:
> You seem to think that repacking without "-l" will pull objects from
> alternates, but it doesn't (I have also seen "repack -a -d" recommended
> for "how do I break alternates dependencies", but it obviously also
> doesn't work for that).
And by "you seem to think" I obviously don't mean "stupid n00b, you
don't understand git" but "I'm unclear on what the behavior should be.
You seem to be saying this, which means this is a serious bug."
-Peff
^ permalink raw reply
* Re: git-svn branch naming question
From: Miklos Vajna @ 2007-12-08 23:52 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071208165657.GC2844@xp.machine.xx>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Sat, Dec 08, 2007 at 05:56:57PM +0100, Peter Baumann <waste.manager@gmx.de> wrote:
> On the other hand you could forget completly the remote part by specifying
>
> [svn-remote "svn"]
> url = https://url/to/your/svn/repo
> fetch = trunk:refs/heads/trunk
> branches = branches/*:refs/heads/*
> tags = tags/*:refs/heads/tags/*
>
> but I advice you to not do this. refs/remotes has a special meaning in git,
> e.g. you can't commit directly to it (which makes sense, because it only
> tracks the state of the remote repo. On the other hand remote branches won't
> get cloned per default.)
yes, that's exactly what i want to do - in case the target is to convert
an svn repo to a git one (and i need git-svn since git-svnimport is to
be removed in 1.5.4)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Misfeature] cloning without configuration fails and returns 0
From: Junio C Hamano @ 2007-12-09 1:32 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List
In-Reply-To: <9438BB94-AE9C-4F4E-A4DA-8E2121642736@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> on a new machine I have access to, I fetched tonight's git master (git
> version 1.5.3.7.g9758e) and installed it on my account in order to
> clone one of my projects. I did not setup anything in my git config
> and stumbled on the following misfeature:
This is not a misfeature but an outright bug in an earlier fix to
13208572fbe8838fd8835548d7502202d1f7b21d (builtin-commit: fix --signoff)
Can you try this and see if it works for you?
-- >8 --
Re-fix "builtin-commit: fix --signoff"
An earlier fix to the said commit was incomplete; it mixed up the
meaning of the flag parameter passed to the internal fmt_ident()
function, so this corrects it.
git_author_info() and git_committer_info() can be told to issue a
warning when no usable user information is found, and optionally can be
told to error out. Operations that actually use the information to
record a new commit or a tag will still error out, but the caller to
leave reflog record will just silently use bogus user information.
Not warning on misconfigured user information while writing a reflog
entry is somewhat debatable, but it is probably nicer to the users to
silently let it pass, because the only information you are losing is who
checked out the branch.
* git_author_info() and git_committer_info() used to take 1 (positive
int) to error out with a warning on misconfiguration; this is now
signalled with a symbolic constant IDENT_ERROR_ON_NO_NAME.
* These functions used to take -1 (negative int) to warn but continue;
this is now signalled with a symbolic constant IDENT_WARN_ON_NO_NAME.
* fmt_ident() function implements the above error reporting behaviour
common to git_author_info() and git_committer_info(). A symbolic
constant IDENT_NO_DATE can be or'ed in to the flag parameter to make
it return only the "Name <email@address.xz>".
* fmt_name() is a thin wrapper around fmt_ident() that always passes
IDENT_ERROR_ON_NO_NAME and IDENT_NO_DATE.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit-tree.c | 4 ++--
builtin-commit.c | 4 ++--
builtin-log.c | 4 ++--
builtin-tag.c | 4 ++--
cache.h | 3 +++
ident.c | 30 ++++++++++++------------------
refs.c | 2 +-
var.c | 4 ++--
8 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 88b0ab3..6610d18 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -98,8 +98,8 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
strbuf_addf(&buffer, "parent %s\n", sha1_to_hex(parent_sha1[i]));
/* Person/date information */
- strbuf_addf(&buffer, "author %s\n", git_author_info(1));
- strbuf_addf(&buffer, "committer %s\n", git_committer_info(1));
+ strbuf_addf(&buffer, "author %s\n", git_author_info(IDENT_ERROR_ON_NO_NAME));
+ strbuf_addf(&buffer, "committer %s\n", git_committer_info(IDENT_ERROR_ON_NO_NAME));
if (!encoding_is_utf8)
strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
strbuf_addch(&buffer, '\n');
diff --git a/builtin-commit.c b/builtin-commit.c
index 19297ac..a7e8d4a 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -497,7 +497,7 @@ static void determine_author_info(struct strbuf *sb)
email = xstrndup(lb + 2, rb - (lb + 2));
}
- strbuf_addf(sb, "author %s\n", fmt_ident(name, email, date, 1));
+ strbuf_addf(sb, "author %s\n", fmt_ident(name, email, date, IDENT_ERROR_ON_NO_NAME));
}
static int parse_and_validate_options(int argc, const char *argv[],
@@ -776,7 +776,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
determine_author_info(&sb);
- strbuf_addf(&sb, "committer %s\n", git_committer_info(1));
+ strbuf_addf(&sb, "committer %s\n", git_committer_info(IDENT_ERROR_ON_NO_NAME));
if (!is_encoding_utf8(git_commit_encoding))
strbuf_addf(&sb, "encoding %s\n", git_commit_encoding);
strbuf_addch(&sb, '\n');
diff --git a/builtin-log.c b/builtin-log.c
index e1f1cf6..b6a1122 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -557,7 +557,7 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
static void gen_message_id(char *dest, unsigned int length, char *base)
{
- const char *committer = git_committer_info(-1);
+ const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
const char *email_start = strrchr(committer, '<');
const char *email_end = strrchr(committer, '>');
if(!email_start || !email_end || email_start > email_end - 1)
@@ -665,7 +665,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
!strcmp(argv[i], "-s")) {
const char *committer;
const char *endpos;
- committer = git_committer_info(1);
+ committer = git_committer_info(IDENT_ERROR_ON_NO_NAME);
endpos = strchr(committer, '>');
if (!endpos)
die("bogos committer info %s\n", committer);
diff --git a/builtin-tag.c b/builtin-tag.c
index 729389b..36a5e9d 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -186,7 +186,7 @@ static int do_sign(struct strbuf *buffer)
int len;
if (!*signingkey) {
- if (strlcpy(signingkey, git_committer_info(1),
+ if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
sizeof(signingkey)) > sizeof(signingkey) - 1)
return error("committer info too long.");
bracket = strchr(signingkey, '>');
@@ -296,7 +296,7 @@ static void create_tag(const unsigned char *object, const char *tag,
sha1_to_hex(object),
typename(type),
tag,
- git_committer_info(1));
+ git_committer_info(IDENT_ERROR_ON_NO_NAME));
if (header_len > sizeof(header_buf) - 1)
die("tag header too big.");
diff --git a/cache.h b/cache.h
index 406befb..c6142e9 100644
--- a/cache.h
+++ b/cache.h
@@ -453,6 +453,9 @@ void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
enum date_mode parse_date_format(const char *format);
+#define IDENT_WARN_ON_NO_NAME 1
+#define IDENT_ERROR_ON_NO_NAME 2
+#define IDENT_NO_DATE 4
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
diff --git a/ident.c b/ident.c
index 7631698..892d77a 100644
--- a/ident.c
+++ b/ident.c
@@ -182,14 +182,15 @@ static const char *env_hint =
"Omit --global to set the identity only in this repository.\n"
"\n";
-static const char *fmt_ident_1(const char *name, const char *email,
- const char *date_str, int flag)
+const char *fmt_ident(const char *name, const char *email,
+ const char *date_str, int flag)
{
static char buffer[1000];
char date[50];
int i;
- int error_on_no_name = !!(flag & 01);
- int name_addr_only = !!(flag & 02);
+ int error_on_no_name = (flag & IDENT_ERROR_ON_NO_NAME);
+ int warn_on_no_name = (flag & IDENT_WARN_ON_NO_NAME);
+ int name_addr_only = (flag & IDENT_NO_DATE);
setup_ident();
if (!name)
@@ -200,12 +201,12 @@ static const char *fmt_ident_1(const char *name, const char *email,
if (!*name) {
struct passwd *pw;
- if (0 <= error_on_no_name &&
+ if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
env_hint = NULL; /* warn only once, for "git-var -l" */
}
- if (0 < error_on_no_name)
+ if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
pw = getpwuid(getuid());
if (!pw)
@@ -234,30 +235,23 @@ static const char *fmt_ident_1(const char *name, const char *email,
return buffer;
}
-const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int error_on_no_name)
-{
- int flag = (error_on_no_name ? 01 : 0);
- return fmt_ident_1(name, email, date_str, flag);
-}
-
const char *fmt_name(const char *name, const char *email)
{
- return fmt_ident_1(name, email, NULL, 03);
+ return fmt_ident(name, email, NULL, IDENT_ERROR_ON_NO_NAME | IDENT_NO_DATE);
}
-const char *git_author_info(int error_on_no_name)
+const char *git_author_info(int flag)
{
return fmt_ident(getenv("GIT_AUTHOR_NAME"),
getenv("GIT_AUTHOR_EMAIL"),
getenv("GIT_AUTHOR_DATE"),
- error_on_no_name);
+ flag);
}
-const char *git_committer_info(int error_on_no_name)
+const char *git_committer_info(int flag)
{
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
- error_on_no_name);
+ flag);
}
diff --git a/refs.c b/refs.c
index 3e6e98c..759924d 100644
--- a/refs.c
+++ b/refs.c
@@ -1094,7 +1094,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
adjust_shared_perm(log_file);
msglen = msg ? strlen(msg) : 0;
- committer = git_committer_info(-1);
+ committer = git_committer_info(0);
maxlen = strlen(committer) + msglen + 100;
logrec = xmalloc(maxlen);
len = sprintf(logrec, "%s %s %s\n",
diff --git a/var.c b/var.c
index 4127031..0de0efa 100644
--- a/var.c
+++ b/var.c
@@ -21,7 +21,7 @@ static void list_vars(void)
{
struct git_var *ptr;
for(ptr = git_vars; ptr->read; ptr++) {
- printf("%s=%s\n", ptr->name, ptr->read(0));
+ printf("%s=%s\n", ptr->name, ptr->read(IDENT_WARN_ON_NO_NAME));
}
}
@@ -32,7 +32,7 @@ static const char *read_var(const char *var)
val = NULL;
for(ptr = git_vars; ptr->read; ptr++) {
if (strcmp(var, ptr->name) == 0) {
- val = ptr->read(1);
+ val = ptr->read(IDENT_ERROR_ON_NO_NAME);
break;
}
}
^ permalink raw reply related
* Re: Where has "git ls-remote" reference pattern matching gone?
From: Junio C Hamano @ 2007-12-09 1:34 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: git, Daniel Barkalow
In-Reply-To: <4E5E5B1E-A303-45C9-9944-57D54FD50F80@orakel.ntnu.no>
Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:
> ls-remote was recently made a builtin; was reference filtering
> deliberately removed, or was it just lost in translation from the
> shell script?
I suspect that to be the case. Daniel, I think this is yours.
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-09 1:51 UTC (permalink / raw)
To: Marco Costalba
Cc: Joe Buck, Johannes Schindelin, J.C. Pizarro, Linus Torvalds,
David Miller, gcc, git
In-Reply-To: <e5bfff550712081228s6bcb064ep23f2bb06ef2c6b9b@mail.gmail.com>
>
> Where did have you read this ? I missed that part.
>
> > When you object
> > that he's wasting your time, he'll start talking about freedom of speech.
> >
>
> Actually he never spoke like that (probably I missed that part too).
>
>
Read gcc mailing list archives, if you have a lot of time on your hands.
^ permalink raw reply
* Re: git-svn branch naming question
From: Miklos Vajna @ 2007-12-09 2:05 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071208235248.GK3199@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
On Sun, Dec 09, 2007 at 12:52:48AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > [svn-remote "svn"]
> > url = https://url/to/your/svn/repo
> > fetch = trunk:refs/heads/trunk
> > branches = branches/*:refs/heads/*
> > tags = tags/*:refs/heads/tags/*
> >
> > but I advice you to not do this. refs/remotes has a special meaning in git,
> > e.g. you can't commit directly to it (which makes sense, because it only
> > tracks the state of the remote repo. On the other hand remote branches won't
> > get cloned per default.)
>
> yes, that's exactly what i want to do - in case the target is to convert
> an svn repo to a git one (and i need git-svn since git-svnimport is to
> be removed in 1.5.4)
hm, this seem to be not-working for me.
after "git svn init -s url" i edited the config:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = svn+ssh://vmiklos@svn.gnome.org/svn/ooo-build
fetch = trunk:refs/master
branches = branches/*:refs/*
tags = tags/*:refs/tags/*
and wanted to fetch the revisions, but actually
$ git svn fetch
does not fetch any revisions. (yes, it does once i put back the
"remotes" prefix). is this a bug? :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn branch naming question
From: Björn Steinbrink @ 2007-12-09 2:13 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Peter Baumann, git
In-Reply-To: <20071209020510.GM3199@genesis.frugalware.org>
On 2007.12.09 03:05:10 +0100, Miklos Vajna wrote:
> On Sun, Dec 09, 2007 at 12:52:48AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > > [svn-remote "svn"]
> > > url = https://url/to/your/svn/repo
> > > fetch = trunk:refs/heads/trunk
^^^^^
> > > branches = branches/*:refs/heads/*
^^^^^
> > > tags = tags/*:refs/heads/tags/*
^^^^^
> url = svn+ssh://vmiklos@svn.gnome.org/svn/ooo-build
> fetch = trunk:refs/master
> branches = branches/*:refs/*
> tags = tags/*:refs/tags/*
Just a guess, but this seems pretty headless ;-)
Björn
> and wanted to fetch the revisions, but actually
>
> $ git svn fetch
>
> does not fetch any revisions. (yes, it does once i put back the
> "remotes" prefix). is this a bug? :)
>
> thanks,
> - VMiklos
^ 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