* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-06 20:12 UTC (permalink / raw)
To: Jim Radford; +Cc: keithp, Git Mailing List
In-Reply-To: <20060406181502.GA15741@blackbean.org>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Thu, 2006-04-06 at 11:15 -0700, Jim Radford wrote:
> Hi Keith,
>
> Here's one more build patch. For some reason the Fedora lex doesn't
> want a space after the -o.
I probably shouldn't even use the -o flag; all it does is change the
#line directives in the output file to point at lex.c instead of
<stdout>. I'm sure it'll break something.
> Almost all of the errors I was seeing in the last version were fixed
> with your "branches that don't get merged back to the trunk" fix.
That's good news at least.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* gitweb: A git:// link for the project?
From: Jan-Benedict Glaw @ 2006-04-06 19:14 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
Hi Kay!
I've got another small idea for gitweb, probably only a line or two,
but Perl isn't exactly my preferred language :)
The idea is to have a 'Copy Link-Lokation'able link presented by
gitweb, maybe placed right to summary, shortlog and log.
That should just link to a URL prefix
(git://git.yourbox.tld/some/path) plus the project path. I guess it's
something like this, but I haven't tested it. Should be good enough to
get an idea of what I ment:
Signed-off-by: Jan-Benedict Glaw <jbglaw@lug-owl.de>
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..b2942fd 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -26,6 +26,9 @@ my $rss_link = "";
#my $projectroot = "/pub/scm";
my $projectroot = "/home/kay/public_html/pub/scm";
+# URL prefix for the git:// link
+my $urlprefix = "git://git.kernel.org/pub/scm";
+
# location of the git-core binaries
my $gitbin = "/usr/bin";
@@ -920,6 +923,7 @@ sub git_project_list {
$cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=summary")}, "summary") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=shortlog")}, "shortlog") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=log")}, "log") .
+ " | " . $cgi->a({-href => "$urlprefix" . esc_param("/$pr->{'path'}")}, "GIT") .
"</td>\n" .
"</tr>\n";
}
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: parsecvs tool now creates git repositories
From: Jim Radford @ 2006-04-06 18:15 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144305392.2303.240.camel@neko.keithp.com>
Hi Keith,
Here's one more build patch. For some reason the Fedora lex doesn't
want a space after the -o.
Almost all of the errors I was seeing in the last version were fixed
with your "branches that don't get merged back to the trunk" fix.
Thanks,
-Jim
diff --git a/Makefile b/Makefile
index 4ca6ffd..137ed34 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ GCC_WARNINGS3=-Wnested-externs -fno-stri
GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)
CFLAGS=-O0 -g $(GCC_WARNINGS)
YFLAGS=-d -l
-LFLAGS=-l -o lex.c
+LFLAGS=-l -olex.c
SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c \
revlist.c atom.c revcvs.c git.c gitutil.c
^ permalink raw reply related
* git-clone and cg-clone
From: Belmar-Letelier @ 2006-04-06 18:10 UTC (permalink / raw)
To: git
Hello
I'm a cogito users,
Since 0.17 to take benefit of cg-switch
I use:
$ git-clone xxx
$ cg-branch-add origin xxx
instead of
$ cg-clone xxx
becauce cg-clone did not fetch all the heads.
Is there a better way to do this ?
--
Luis Belmar-Letelier
^ permalink raw reply
* Re: Fixes to parsecvs
From: Keith Packard @ 2006-04-06 17:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: keithp, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0604061723410.23681@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Thu, 2006-04-06 at 17:26 +0200, Johannes Schindelin wrote:
> Keep in mind that there are many more valid uses for tracking a CVS
> repository than to import it once.
Sure, but we should fix parsecvs to handle incremental CVS tracking if
that's one of the goals for this utility. git-cvsimport does this by
skipping commits earlier than a fixed time; if we did that, we'd
eliminate the huge memory usage except for initial imports. I haven't
considered how this might be done in detail yet; I have no personal need
for this functionality.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] cg-rm: Add option to remove all files which are gone from the working copy
From: Dennis Stosberg @ 2006-04-06 16:17 UTC (permalink / raw)
To: git
Add an -a option to cg-rm, which removes all files that have been
physically deleted.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
cg-rm | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
ac5fc0c8d9c9ccecba7cbf83a74a163bff79f8f4
diff --git a/cg-rm b/cg-rm
index 5ab5dc8..0276632 100755
--- a/cg-rm
+++ b/cg-rm
@@ -19,13 +19,18 @@ #
# -r:: Remove files recursively
# If you pass cg-rm this flag and any directory names, it will try
# to remove files in those directories recursively.
+#
+# -a:: Remove all files which are gone from the working copy
+# Remove all files which have been deleted in the working copy
+# from the index.
-USAGE="cg-rm [-f] [-n] [-r] FILE..."
+USAGE="cg-rm [-f] [-n] [-r] [-a] FILE..."
. "${COGITO_LIB}"cg-Xlib || exit 1
delete=
recursive=
+rmgone=
while optparse; do
if optparse -f; then
delete=1
@@ -33,12 +38,14 @@ while optparse; do
delete=
elif optparse -r; then
recursive=1
+ elif optparse -a; then
+ rmgone=1
else
optfail
fi
done
-[ -n "${ARGS[*]}" ] || usage
+[ -n "${ARGS[*]}" -o "$rmgone" ] || usage
TMPFILE="$(mktemp -t gitrm.XXXXXX)" || exit 1
TMPDIRFILE="$(mktemp -t gitrm.XXXXXX)" || exit 1
@@ -57,6 +64,14 @@ for file in "${ARGS[@]}"; do
echo "$file" >>"$TMPFILE"
fi
done
+
+if [ "$rmgone" ]; then
+ cg-status -s \! -n -w >>"$TMPFILE"
+ if [ ! $(cat "$TMPFILE" | sed -n "$=") ]; then
+ rm "$TMPFILE" "$TMPDIRFILE"
+ die "no files to remove"
+ fi
+fi
cat "$TMPFILE" | sed 's/^/Removing file /'
if [ "$delete" ]; then (
--
1.3-rc2.GIT
^ permalink raw reply related
* Re: Fixes to parsecvs
From: Jan-Benedict Glaw @ 2006-04-06 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0604061723410.23681@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Thu, 2006-04-06 17:26:14 +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 6 Apr 2006, Keith Packard wrote:
> > On Thu, 2006-04-06 at 14:08 +0200, Jan-Benedict Glaw wrote:
> > > But it seems it now starts to really consume memory:
> > The question is whether it needs to be more efficient so that people can
> > constantly convert repositories or whether moving the repository to a
> > sufficiently large machine for the one-time conversion is 'good enough'.
>
> Keep in mind that there are many more valid uses for tracking a CVS
> repository than to import it once.
Even the most simplest usage case reveals this. (It's also what I'm
about to do the the converted GCC repository.)
Get the repo, locally track the changes (so the importet branches are
all like "vendor branches") and do own work in local branches.
I'll do this eg. to be able to easily re-diff patches, which I want to
put into GIT, just because it's so much more convenient than SVN.
However, this is only possible because I'm able to keep track of
upstream SVN changes. They probably won't change their SCM again, just
after they've introduced SVN.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fixes to parsecvs
From: Johannes Schindelin @ 2006-04-06 15:26 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144334896.2303.259.camel@neko.keithp.com>
Hi,
On Thu, 6 Apr 2006, Keith Packard wrote:
> On Thu, 2006-04-06 at 14:08 +0200, Jan-Benedict Glaw wrote:
>
> > But it seems it now starts to really consume memory:
>
> The question is whether it needs to be more efficient so that people can
> constantly convert repositories or whether moving the repository to a
> sufficiently large machine for the one-time conversion is 'good enough'.
Keep in mind that there are many more valid uses for tracking a CVS
repository than to import it once.
Ciao,
Dscho
^ permalink raw reply
* Re: Fixes to parsecvs
From: Keith Packard @ 2006-04-06 14:48 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060406120812.GO13324@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
On Thu, 2006-04-06 at 14:08 +0200, Jan-Benedict Glaw wrote:
> On Wed, 2006-04-05 23:36:32 -0700, Keith Packard <keithp@keithp.com> wrote:
> > note, parsecvs remains available from:
> >
> > git://git.freedesktop.org/~keithp/parsecvs
>
> It now compiles out-of-the-box for me, nice work.
cool
>
> However, it would be nice if you'd add a short description about how
> to use it. Something like this:
I'd rather just fix the usage to be more sane; that shouldn't take but a
few minutes...
> I just ran it against a locally rsync'ed copy of the Binutils ,v
> files. Looging at the progress bar, it is bascally ready:
>
>
> Load: winsup/configure.in,v ....................* 27704 of 27704
Now all of the ,v files have been parsed and each revision placed in
the .git repository as a blob.
> But it seems it now starts to really consume memory:
Yeah, it's doing the change set computation, which is not very space
efficient; it computes the entire set of files at each commit which can
take 'a bit' of space with a large number of files over a long period of
time. Obviously computing revision deltas and saving those would make it
use a lot less memory.
> jbglaw@bixie:~/bin$ ps axflwww|egrep '(VSZ|parsecvs)'|grep -v grep
> F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 0 1000 15564 22879 18 0 2805084 549996 finish T pts/10 30:51 | \_ parsecvs
I'd run a large repository on a large machine; I managed to get
postgresql to run on my laptop (615M CVS with 6000 files), but anything
larger I'd probably want to get it onto a big enough machine. The
question is whether it needs to be more efficient so that people can
constantly convert repositories or whether moving the repository to a
sufficiently large machine for the one-time conversion is 'good enough'.
> How well does this work with even larger repositories?
postgresql is the largest I've run; starting with a 615M CVS repository,
it built a 1.7G .git tree, which packed down to 125M.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: unchecked uses of strdup
From: Alex Riesen @ 2006-04-06 14:11 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87d5fwau3z.fsf_-_@rho.meyering.net>
On 4/5/06, Jim Meyering <jim@meyering.net> wrote:
> There are pretty many uses of strdup in git's sources.
> Here's one that can cause trouble if it ever returns NULL:
>
> [from fsck-objects.c]
> static int fsck_head_link(void)
> {
> unsigned char sha1[20];
> const char *git_HEAD = strdup(git_path("HEAD"));
> const char *git_refs_heads_master = resolve_ref(git_HEAD, sha1, 1);
>
> The problem is that resolve_ref does an unconditional `stat'
> on the parameter corresponding to the maybe-NULL git_HEAD.
That's actually alright (aside a nice core file). Worse are the cases
where a NULL would cause some "normal" behaviour, e.g. arguments,
which have a meaning for NULL value.
^ permalink raw reply
* [PATCH] gitk: Fix Tcl error when merge has interesting diffs.
From: Mark Wooding @ 2006-04-06 12:16 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
If a merge commit with nontrivial diffs is selected, gitk reports a Tcl
error:
wrong # args: should be "getmergediffline mdf id np"
while executing
"getmergediffline file7 9fdb62af92c741addbea15545f214a6e89460865"
Change 79b2c75e... introduced the `np' argument to getmergediffline, but
failed to pass it when the function detaches and reattaches to the file
to make way for an update.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 26fa79a..3b92820 100755
--- a/gitk
+++ b/gitk
@@ -2700,7 +2700,7 @@ proc getmergediffline {mdf id np} {
incr nextupdate 100
fileevent $mdf readable {}
update
- fileevent $mdf readable [list getmergediffline $mdf $id]
+ fileevent $mdf readable [list getmergediffline $mdf $id $np]
}
}
^ permalink raw reply related
* Re: Fixes to parsecvs
From: Jan-Benedict Glaw @ 2006-04-06 12:08 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144305392.2303.240.camel@neko.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]
On Wed, 2006-04-05 23:36:32 -0700, Keith Packard <keithp@keithp.com> wrote:
> note, parsecvs remains available from:
>
> git://git.freedesktop.org/~keithp/parsecvs
It now compiles out-of-the-box for me, nice work.
However, it would be nice if you'd add a short description about how
to use it. Something like this:
---------------------------------------------------------------------
There's still a lot of work to do on parsecvs, but if you want to give
it a run, first create a copy of the whole CVS tree and go to the base
directory of this copy. (You find a lot of *,v files in this directory
and all its subdirectories.)
Now feed all ,v filenames into parsecvs. Keep in mind that a
`edit-change-log' executable needs to be in your $PATH (a one-line
script only exit'ing with 0 will do the job.):
find . -type f -name '*,v' -print | parsecvs
This will create the .git/ directory and put all the objects, commits
and tree information into this new git repository.
---------------------------------------------------------------------
I just ran it against a locally rsync'ed copy of the Binutils ,v
files. Looging at the progress bar, it is bascally ready:
Load: winsup/configure.in,v ....................* 27704 of 27704
But it seems it now starts to really consume memory:
jbglaw@bixie:~/bin$ ps axflwww|egrep '(VSZ|parsecvs)'|grep -v grep
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 15564 22879 18 0 2805084 549996 finish T pts/10 30:51 | \_ parsecvs
How well does this work with even larger repositories?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Thin pack generation: optimization.
From: Junio C Hamano @ 2006-04-06 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5fzlnyt.fsf@assigned-by-dhcp.cox.net>
Jens Axboe noticed that recent "git push" has become very slow
since we made --thin transfer the default.
Thin pack generation to push a handful revisions that touch
relatively small number of paths out of huge tree was stupid; it
registered _everything_ from the excluded revisions. As a
result, "Counting objects" phase was unnecessarily expensive.
This changes the logic to register the blobs and trees from
excluded revisions only for paths we are actually going to send
to the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
pack-objects.c | 119 +++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 79 insertions(+), 40 deletions(-)
b5026f319fc873d03a02f15992b7e431b4b5ad03
diff --git a/pack-objects.c b/pack-objects.c
index 9346392..f1bd8a6 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -505,24 +505,17 @@ static unsigned name_hash(struct name_pa
* but close enough.
*/
hash = (name_hash<<DIRBITS) | (hash & ((1U<<DIRBITS )-1));
-
- if (0) { /* debug */
- n = name + strlen(name);
- if (n != name && n[-1] == '\n')
- n--;
- while (name <= --n)
- fputc(*n, stderr);
- for (p = path; p; p = p->up) {
- fputc('/', stderr);
- n = p->elem + p->len;
- while (p->elem <= --n)
- fputc(*n, stderr);
- }
- fprintf(stderr, "\t%08x\n", hash);
- }
return hash;
}
+
+static struct pbase_tree {
+ struct pbase_tree *next;
+ unsigned char sha1[20];
+ void *tree_data;
+ unsigned long tree_size;
+} *pbase_tree;
+
static int add_object_entry(const unsigned char *sha1, unsigned hash, int exclude)
{
unsigned int idx = nr_objects;
@@ -585,58 +578,99 @@ static int add_object_entry(const unsign
}
}
return status;
+}
+
+static int name_cmp_len(const char *name)
+{
+ int i;
+ for (i = 0; name[i] && name[i] != '\n' && name[i] != '/'; i++)
+ ;
+ return i;
}
-static void add_pbase_tree(struct tree_desc *tree, struct name_path *up)
+static void add_pbase_object(struct tree_desc *tree,
+ struct name_path *up,
+ const char *name,
+ int cmplen)
{
while (tree->size) {
const unsigned char *sha1;
- const char *name;
- unsigned mode, hash;
+ const char *entry_name;
+ int entry_len;
+ unsigned mode;
unsigned long size;
char type[20];
- sha1 = tree_entry_extract(tree, &name, &mode);
+ sha1 = tree_entry_extract(tree, &entry_name, &mode);
update_tree_entry(tree);
- if (!has_sha1_file(sha1))
- continue;
- if (sha1_object_info(sha1, type, &size))
- continue;
-
- hash = name_hash(up, name);
- if (!add_object_entry(sha1, hash, 1))
+ entry_len = strlen(entry_name);
+ if (entry_len != cmplen ||
+ memcmp(entry_name, name, cmplen) ||
+ !has_sha1_file(sha1) ||
+ sha1_object_info(sha1, type, &size))
continue;
-
+ if (name[cmplen] != '/') {
+ unsigned hash = name_hash(up, name);
+ add_object_entry(sha1, hash, 1);
+ return;
+ }
if (!strcmp(type, tree_type)) {
struct tree_desc sub;
void *elem;
struct name_path me;
+ /* We probably should cache these
+ * intermediate tree buffers...
+ */
elem = read_sha1_file(sha1, type, &sub.size);
sub.buf = elem;
if (sub.buf) {
+ const char *down = name+cmplen+1;
+ int downlen = name_cmp_len(down);
+
me.up = up;
- me.elem = name;
- me.len = strlen(name);
- add_pbase_tree(&sub, &me);
+ me.elem = entry_name;
+ me.len = entry_len;
+ add_pbase_object(&sub, &me, down, downlen);
free(elem);
}
}
}
}
+
+static void add_preferred_base_object(char *name)
+{
+ struct pbase_tree *it;
+ int cmplen = name_cmp_len(name);
+ for (it = pbase_tree; it; it = it->next) {
+ if (cmplen == 0) {
+ unsigned hash = name_hash(NULL, "");
+ add_object_entry(it->sha1, hash, 1);
+ }
+ else {
+ struct tree_desc tree;
+ tree.buf = it->tree_data;
+ tree.size = it->tree_size;
+ add_pbase_object(&tree, NULL, name, cmplen);
+ }
+ }
+}
+
static void add_preferred_base(unsigned char *sha1)
{
- struct tree_desc tree;
- void *elem;
+ struct pbase_tree *it;
- elem = read_object_with_reference(sha1, tree_type, &tree.size, NULL);
- tree.buf = elem;
- if (!tree.buf)
+ for (it = pbase_tree; it && memcmp(it->sha1, sha1, 20); it = it->next)
+ ;
+ if (it)
return;
- if (add_object_entry(sha1, name_hash(NULL, ""), 1))
- add_pbase_tree(&tree, NULL);
- free(elem);
+ it = xcalloc(1, sizeof(*it));
+ it->next = pbase_tree;
+ pbase_tree = it;
+ memcpy(it->sha1, sha1, 20);
+ it->tree_data = read_object_with_reference(sha1, tree_type,
+ &it->tree_size, NULL);
}
static void check_object(struct object_entry *entry)
@@ -1051,6 +1085,7 @@ int main(int argc, char **argv)
char line[PATH_MAX + 20];
int window = 10, depth = 10, pack_to_stdout = 0;
struct object_entry **list;
+ int num_preferred_base = 0;
int i;
setup_git_directory();
@@ -1116,6 +1151,7 @@ int main(int argc, char **argv)
for (;;) {
unsigned char sha1[20];
+ unsigned hash;
if (!fgets(line, sizeof(line), stdin)) {
if (feof(stdin))
@@ -1132,12 +1168,15 @@ int main(int argc, char **argv)
if (get_sha1_hex(line+1, sha1))
die("expected edge sha1, got garbage:\n %s",
line+1);
- add_preferred_base(sha1);
+ if (num_preferred_base++ < window)
+ add_preferred_base(sha1);
continue;
}
if (get_sha1_hex(line, sha1))
die("expected sha1, got garbage:\n %s", line);
- add_object_entry(sha1, name_hash(NULL, line+41), 0);
+ add_preferred_base_object(line+41);
+ hash = name_hash(NULL, line+41);
+ add_object_entry(sha1, hash, 0);
}
if (progress)
fprintf(stderr, "Done counting %d objects.\n", nr_objects);
--
1.3.0.rc2.g9cda
^ permalink raw reply related
* Fixes to parsecvs
From: Keith Packard @ 2006-04-06 6:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: keithp
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
note, parsecvs remains available from:
git://git.freedesktop.org/~keithp/parsecvs
I've "fixed" the lexer to permit getc/ungetc in the data parsing
functions. This should resolve the flex -l / -X problems.
Jim Radford send a patch to add '/' as a legal tag character
I added my custom edit-change-log script for people dealing with
X.org-style commit messages.
And, it deals with import branch revisions that aren't supposed to
get merged back to the trunk, creating a custom branch name based on the
branch revision (which must be global across all files).
5e5f4c012aec2db012a08b1c7ed5219ed5100111
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Junio C Hamano @ 2006-04-06 4:13 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604050624h13ebd8deg241ae98cef1f5a74@mail.gmail.com>
"Kees-Jan Dijkzeul" <k.j.dijkzeul@gmail.com> writes:
> I'm trying to get Git to manage my companies source tree. We're
> writing software for digital TV sets. Anyway, the archive is about 5Gb
> in size and contains binaries, zip files, excel sheets meeting minutes
> and whatnot. So it doesn't compress very well. The 1.5Gb pack file
> hardly contains any history at all (five commits or so). On the flip
> side, for now I'll be the only one adding to the archive, so at least
> it will not grow that fast ;-)
>
> Anyway, to reconstitute the tree, I need very nearly the entire pack,
> so limiting the pack size won't do much good, as git will still try to
> allocate a total of 1.5Gb memory (which, unfortunately, isn't there
> :-)
Right now we LRU the pack files and evict older ones when we
mmap too many, but the unit of eviction is the whole file, so it
would not help the case like yours at all. It might be possible
to mmap only part of a packfile, but it would involve fairly
major surgery to sha1_file.c.
^ permalink raw reply
* [PATCH] Add documentation for git-imap-send.
From: Mike McCormack @ 2006-04-06 3:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Signed-off-by: Mike McCormack <mike@codeweavers.com>
---
Documentation/git-imap-send.txt | 60
+++++++++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-imap-send.txt
[-- Attachment #2: 39f36da01434f743e36a7b0d6e8f625ad7785b2b.diff --]
[-- Type: text/x-patch, Size: 1350 bytes --]
39f36da01434f743e36a7b0d6e8f625ad7785b2b
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
new file mode 100644
index 0000000..cfc0d88
--- /dev/null
+++ b/Documentation/git-imap-send.txt
@@ -0,0 +1,60 @@
+git-imap-send(1)
+================
+
+NAME
+----
+git-imap-send - Dump a mailbox from stdin into an imap folder
+
+
+SYNOPSIS
+--------
+'git-imap-send'
+
+
+DESCRIPTION
+-----------
+This command uploads a mailbox generated with git-format-patch
+into an imap drafts folder. This allows patches to be sent as
+other email is sent with mail clients that cannot read mailbox
+files directly.
+
+Typical usage is something like:
+
+git-format-patch --signoff --stdout --attach origin | git-imap-send
+
+
+CONFIGURATION
+-------------
+
+git-imap-send requires the following values in the repository
+configuration file (shown with examples):
+
+[imap]
+ Folder = "INBOX.Drafts"
+
+[imap]
+ Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
+
+[imap]
+ Host = imap.server.com
+ User = bob
+ Password = pwd
+ Port = 143
+
+
+BUGS
+----
+Doesn't handle lines starting with "From " in the message body.
+
+
+Author
+------
+Derived from isync 1.0.1 by Mike McCormack.
+
+Documentation
+--------------
+Documentation by Mike McCormack
+
+GIT
+---
+Part of the gitlink:git[7] suite
^ permalink raw reply related
* Re: blame not working well?
From: Junio C Hamano @ 2006-04-06 1:26 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <7vacazy33w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I was having fun updating blame.c to use the built-in xdiff
> instead of spawning and reading from external GNU diff (it is
> currently in "next" branch). It seems to pass the trivial
> testsuite case but I noticed for example annotating Makefile,
> sha1_name.c, or blame.c in git.git repository seems to show
> quite bogus annotation. One extreme case is the Makefile; for
> all but one line is blamed for the very initial commit made by
> Linus X-<. One good news for me is that the version before this
> change has the same breakage. One bad news is this seems to
> have been broken for some time.
>
> Bisecting indicates 2a0925be3512451834ec9a3e023f4cff23c1cfb7 is
> the first bad commit, but I do not see how the change can break
> it. I'll continue digging it, but if you have a chance, could
> you take a look, too?
It turns out that the only change needed to revert the breakage
was this one-liner. get_revision() used to always rewrite
parents when prune and dense are specified, but the updated code
simply skips during the output filtering phase the parents that
would have been culled by calling rewrite_parents() unless the
caller tells it that it is interested in the parent field by
setting rev.parents.
-- >8 --
[PATCH] blame.c: fix completely broken ancestry traversal.
Recent revision.c updates completely broken the assignment of
blames by not rewriting commit->parents field unless explicitly
asked to by the caller. The caller needs to set revs.parents.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
ba3c93743a8151e3663e1fda6b3cb165d8373ddf
diff --git a/blame.c b/blame.c
index 98f9992..9bb34e6 100644
--- a/blame.c
+++ b/blame.c
@@ -813,6 +813,7 @@ int main(int argc, const char **argv)
rev.prune_fn = simplify_commit;
rev.topo_setter = topo_setter;
rev.topo_getter = topo_getter;
+ rev.parents = 1;
rev.limited = 1;
commit_list_insert(start_commit, &rev.commits);
--
1.3.0.rc2.g9cda
^ permalink raw reply related
* Re: Cygwin can't handle huge packfiles?
From: Christopher Faylor @ 2006-04-06 0:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060405232739.GA18121@nospam.com>
On Thu, Apr 06, 2006 at 01:27:39AM +0200, Rutger Nijlunsing wrote:
>On Wed, Apr 05, 2006 at 05:08:44PM -0400, Christopher Faylor wrote:
>> On Wed, Apr 05, 2006 at 04:14:20PM +0200, Johannes Schindelin wrote:
>> >> Inspired by a patch of Alex Riesen (thanks, Alex), I tried to use the
>> >> regular mmap for mapping pack files, only to discover that I compile
>> >> without defining "NO_MMAP", so I've been using the stock mmap all
>> >> along. So now I'm thinking that the cygwin mmap also does a
>> >> malloc-and-read, just like git does with NO_MMAP. So I'll continue to
>> >> investigate in that direction.
>> >
>> >I think cygwin's mmap() is based on the Win32 API equivalent, which could
>> >mean that it *is* memory mapped, but in a special area (which is smaller
>> >than 1.5 gigabyte). In this case, it would make sense to limit the pack
>> >size, thereby having several packs, and mmap() them as they are needed.
>>
>> Yes, cygwin's mmap uses CreateFileMapping and MapViewOfFile. IIRC,
>> Windows might have a 2G limitation lurking under the hood somewhere but
>> I think that might be tweakable with some registry setting.
>
>Windows places its DLLs criss-cross through the memory space because
>every DLL on the system has its own preferred place to be loaded (the
>base address). This severely limits the amount of largest contiguous
>memory block available, which is needed for one mmap() I think.
>
>Several solutions exist:
> - enlarge the address space with the /3GB boot flag in boot.ini
Thanks. The 3GB boot flag is what I was trying to remember.
> - rebase all DLLs with REBASE.EXE (part of platform sdk) .
> Just make them the same and fix them to a low address.
> Problem is rebasing system dlls since those are locked by the system.
Cygwin has its own version of rebase and a method for rebasing all of the
dlls in the distribution. Using that may help squeeze out a little bit
of memory.
> - at start of program before other DLLs are loaded,
> reserve an as large part of the memory as possible with
> VirtualAlloc()
Cygwin actually uses this trick to try to push DLLs into their right
locations after a fork. It sort of works but sometimes, in a child
proccess, Windows puts "stuff" in locations previously occupied by a
DLL. I could swear that it does that just to be annoying...
There is a chicken/egg problem here in that Cygwin uses Doug Lea's malloc
and that version of malloc will use mmap when sbrk() fails -- as it is
apt to do when allocating gigabytes of memory. So, using malloc is
not a way to avoid mmap.
cgf
^ permalink raw reply
* blame not working well?
From: Junio C Hamano @ 2006-04-06 0:11 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
I was having fun updating blame.c to use the built-in xdiff
instead of spawning and reading from external GNU diff (it is
currently in "next" branch). It seems to pass the trivial
testsuite case but I noticed for example annotating Makefile,
sha1_name.c, or blame.c in git.git repository seems to show
quite bogus annotation. One extreme case is the Makefile; for
all but one line is blamed for the very initial commit made by
Linus X-<. One good news for me is that the version before this
change has the same breakage. One bad news is this seems to
have been broken for some time.
Bisecting indicates 2a0925be3512451834ec9a3e023f4cff23c1cfb7 is
the first bad commit, but I do not see how the change can break
it. I'll continue digging it, but if you have a chance, could
you take a look, too?
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Rutger Nijlunsing @ 2006-04-05 23:27 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Johannes Schindelin, Kees-Jan Dijkzeul, git
In-Reply-To: <20060405210844.GN26780@trixie.casa.cgf.cx>
On Wed, Apr 05, 2006 at 05:08:44PM -0400, Christopher Faylor wrote:
> On Wed, Apr 05, 2006 at 04:14:20PM +0200, Johannes Schindelin wrote:
> >> Inspired by a patch of Alex Riesen (thanks, Alex), I tried to use the
> >> regular mmap for mapping pack files, only to discover that I compile
> >> without defining "NO_MMAP", so I've been using the stock mmap all
> >> along. So now I'm thinking that the cygwin mmap also does a
> >> malloc-and-read, just like git does with NO_MMAP. So I'll continue to
> >> investigate in that direction.
> >
> >I think cygwin's mmap() is based on the Win32 API equivalent, which could
> >mean that it *is* memory mapped, but in a special area (which is smaller
> >than 1.5 gigabyte). In this case, it would make sense to limit the pack
> >size, thereby having several packs, and mmap() them as they are needed.
>
> Yes, cygwin's mmap uses CreateFileMapping and MapViewOfFile. IIRC,
> Windows might have a 2G limitation lurking under the hood somewhere but
> I think that might be tweakable with some registry setting.
Windows places its DLLs criss-cross through the memory space because
every DLL on the system has its own preferred place to be loaded (the
base address). This severely limits the amount of largest contiguous
memory block available, which is needed for one mmap() I think.
Several solutions exist:
- enlarge the address space with the /3GB boot flag in boot.ini
- rebase all DLLs with REBASE.EXE (part of platform sdk) .
Just make them the same and fix them to a low address.
Problem is rebasing system dlls since those are locked by the system.
- at start of program before other DLLs are loaded,
reserve an as large part of the memory as possible with
VirtualAlloc()
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* [PATCH] Fix searching for filenames in gitk
From: Pavel Roskin @ 2006-04-05 23:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
findcont should not accept any arguments.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 26fa79a..e1848cd 100755
--- a/gitk
+++ b/gitk
@@ -2230,7 +2230,7 @@ proc donefilediff {} {
}
}
-proc findcont {id} {
+proc findcont {} {
global findid treediffs parentlist
global ffileline findstartline finddidsel
global displayorder numcommits matchinglines findinprogress
^ permalink raw reply related
* Re: [RFC/PATCH] date parsing: be friendlier to our European friends.
From: Junio C Hamano @ 2006-04-05 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> This does three things, only applies to cases where the user
> manually tries to override the author/commit time by environment
> variables, with non-ISO, non-2822 format date-string:
>
> - Refuses to use the interpretation to put the date in the
> future; recent kernel history has a commit made with
> 10/03/2006 which is recorded as October 3rd.
>
> - Adds '.' as the possible year-month-date separator. We
> learned from our European friends on the #git channel that
> dd.mm.yyyy is the norm there.
>
> - When the separator is '.', we prefer dd.mm.yyyy over
> mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
> dd/mm/yy[yy].
Before the list gets useless comments, the code prefer to accept
more sensible and/or unambiguous forms, such as ISO or RFC2822.
The issue this addresses is what to do when we get other forms.
^ permalink raw reply
* Re: [RFC/PATCH] date parsing: be friendlier to our European friends.
From: Sam Ravnborg @ 2006-04-05 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net>
On Wed, Apr 05, 2006 at 03:39:35PM -0700, Junio C Hamano wrote:
> This does three things, only applies to cases where the user
> manually tries to override the author/commit time by environment
> variables, with non-ISO, non-2822 format date-string:
>
> - Refuses to use the interpretation to put the date in the
> future; recent kernel history has a commit made with
> 10/03/2006 which is recorded as October 3rd.
>
> - Adds '.' as the possible year-month-date separator. We
> learned from our European friends on the #git channel that
> dd.mm.yyyy is the norm there.
I my company we have always used yyyy-mm-dd - this is an ISO standard
IIRC. The company is European based.
mm/dd/yy has always made my head spin ;-)
Sam
^ permalink raw reply
* [RFC/PATCH] date parsing: be friendlier to our European friends.
From: Junio C Hamano @ 2006-04-05 22:39 UTC (permalink / raw)
To: git
In-Reply-To: <7virpo4jxf.fsf@assigned-by-dhcp.cox.net>
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is more of a RFC than ready-to-be-merged patch.
Alternative patches and improvements are welcome.
date.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 56 insertions(+), 21 deletions(-)
b9065540826426ac0e4959e869ba7e08d1ae65d8
diff --git a/date.c b/date.c
index 376d25d..034d722 100644
--- a/date.c
+++ b/date.c
@@ -197,26 +197,43 @@ static int match_alpha(const char *date,
return skip_alpha(date);
}
-static int is_date(int year, int month, int day, struct tm *tm)
+static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, struct tm *tm)
{
if (month > 0 && month < 13 && day > 0 && day < 32) {
+ struct tm check = *tm;
+ struct tm *r = (now_tm ? &check : tm);
+ time_t specified;
+
+ r->tm_mon = month - 1;
+ r->tm_mday = day;
if (year == -1) {
- tm->tm_mon = month-1;
- tm->tm_mday = day;
- return 1;
+ if (!now_tm)
+ return 1;
+ r->tm_year = now_tm->tm_year;
}
- if (year >= 1970 && year < 2100) {
- year -= 1900;
- } else if (year > 70 && year < 100) {
- /* ok */
- } else if (year < 38) {
- year += 100;
- } else
+ else if (year >= 1970 && year < 2100)
+ r->tm_year = year - 1900;
+ else if (year > 70 && year < 100)
+ r->tm_year = year;
+ else if (year < 38)
+ r->tm_year = year + 100;
+ else
return 0;
+ if (!now_tm)
+ return 1;
+
+ specified = my_mktime(r);
- tm->tm_mon = month-1;
- tm->tm_mday = day;
- tm->tm_year = year;
+ /* Be it commit time or author time, it does not make
+ * sense to specify timestamp way into the future. Make
+ * sure it is not later than ten days from now...
+ */
+ if (now + 10*24*3600 < specified)
+ return 0;
+ tm->tm_mon = r->tm_mon;
+ tm->tm_mday = r->tm_mday;
+ if (year != -1)
+ tm->tm_year = r->tm_year;
return 1;
}
return 0;
@@ -224,6 +241,9 @@ static int is_date(int year, int month,
static int match_multi_number(unsigned long num, char c, const char *date, char *end, struct tm *tm)
{
+ time_t now;
+ struct tm now_tm;
+ struct tm *refuse_future;
long num2, num3;
num2 = strtol(end+1, &end, 10);
@@ -246,19 +266,33 @@ static int match_multi_number(unsigned l
case '-':
case '/':
+ case '.':
+ now = time(NULL);
+ refuse_future = NULL;
+ if (gmtime_r(&now, &now_tm))
+ refuse_future = &now_tm;
+
if (num > 70) {
/* yyyy-mm-dd? */
- if (is_date(num, num2, num3, tm))
+ if (is_date(num, num2, num3, refuse_future, now, tm))
break;
/* yyyy-dd-mm? */
- if (is_date(num, num3, num2, tm))
+ if (is_date(num, num3, num2, refuse_future, now, tm))
break;
}
- /* mm/dd/yy ? */
- if (is_date(num3, num, num2, tm))
+ /* Our eastern European friends say dd.mm.yy[yy]
+ * is the norm there, so giving precedence to
+ * mm/dd/yy[yy] form only when separator is not '.'
+ */
+ if (c != '.' &&
+ is_date(num3, num, num2, refuse_future, now, tm))
+ break;
+ /* European dd.mm.yy[yy] or funny US dd/mm/yy[yy] */
+ if (is_date(num3, num2, num, refuse_future, now, tm))
break;
- /* dd/mm/yy ? */
- if (is_date(num3, num2, num, tm))
+ /* Funny European mm.dd.yy */
+ if (c == '.' &&
+ is_date(num3, num, num2, refuse_future, now, tm))
break;
return 0;
}
@@ -288,10 +322,11 @@ static int match_digit(const char *date,
}
/*
- * Check for special formats: num[:-/]num[same]num
+ * Check for special formats: num[-.:/]num[same]num
*/
switch (*end) {
case ':':
+ case '.':
case '/':
case '-':
if (isdigit(end[1])) {
--
1.3.0.rc2.g1b83
^ permalink raw reply related
* [PATCH] Tweaks to make asciidoc play nice.
From: Francis Daly @ 2006-04-05 22:25 UTC (permalink / raw)
To: git; +Cc: Marco Roeland
Once the content has been generated, the formatting elves can reorder
it to be pretty...
Signed-off-by: Francis Daly <francis@daoine.org>
---
The manpage formatting needed to stop things being ugly is
nontrivial. In this case, an option has multi-paragraph content,
some of which should be displayed preformatted.
"+" means "this next paragraph is a continuation of the same section"
"--" means "the next paragraphs are all continuations -- don't worry
about all the other "+"s
"------" means "the next content is preformatted"
"------", the blank line, and the extra indentation within ------ are
there because docbook-xsl stylesheets are odd in different ways.
This combination makes the preformatted text be visually distinct
with both versions 1.68 and 1.69. Without that oddness, we could
use either just ------ or just indentation. Ho hum.
Documentation/git-commit.txt | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
e46caf57bc2d09c032b992f9024226acd2d68fbc
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index ec8b562..0a7365b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -83,15 +83,16 @@ OPTIONS
the current tip as parents -- so the current top commit is
discarded.
+
+--
It is a rough equivalent for:
-+
-$ git reset --soft HEAD^
-+
-$ ... do something else to come up with the right tree ...
-+
-$ git commit -c ORIG_HEAD
-+
+------
+ $ git reset --soft HEAD^
+ $ ... do something else to come up with the right tree ...
+ $ git commit -c ORIG_HEAD
+
+------
but can be used to amend a merge commit.
+--
-i|--include::
Instead of committing only the files specified on the
--
1.2.4.g3488
--
Francis Daly francis@daoine.org
^ 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