* RE: Problem with clone hanging
From: Bryan O'Sullivan @ 2006-08-07 22:34 UTC (permalink / raw)
To: Tziporet Koren; +Cc: Erik Mouw, git, Michael S. Tsirkin
In-Reply-To: <6AB138A2AB8C8E4A98B9C0C3D52670E301FA761E@mtlexch01.mtl.com>
On Mon, 2006-08-07 at 21:57 +0300, Tziporet Koren wrote:
> OK we will upgrade our git installation (but it will be only tomorrow)
> You are correct - we have not set HTTP interface.
It's OK - Sergey's workaround did the trick for me.
<b
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-07 22:58 UTC (permalink / raw)
To: git
In-Reply-To: <eb8e12$2aa$1@sea.gmane.org>
Jakub Narebski wrote:
> True. So _read_ based on actually reading the files is out.
> git_get_hash_by_ref, git_get_HEAD_hash (or just git_get_ref, git_get_head)
Or git_get_hash, git_get_head_hash
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Multiple refs from the same remote in one git fetch
From: Junio C Hamano @ 2006-08-07 23:05 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20060807221914.GA24393@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> The following seems to fix this issue: simply scan the full
> refspec list for each remote instead of breaking on the first match.
> I had to touch the git-fetch.sh script as well as it is scanning
> the remote list, too. Works for me.
Looks Ok, although I have to admit I just gave a cursory look.
Thanks.
^ permalink raw reply
* [PATCH] gitweb: Remove unused variables in git_shortlog_body and git_heads
From: Jakub Narebski @ 2006-08-07 23:15 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Cleanup.
gitweb/gitweb.perl | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b3bfc6b..eabece7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1065,7 +1065,6 @@ sub git_shortlog_body {
#my $ref = defined $refs ? git_get_referencing($refs, $commit) : '';
my $ref = git_get_referencing($refs, $commit);
my %co = git_read_commit($commit);
- my %ad = date_str($co{'author_epoch'});
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
@@ -1638,7 +1637,6 @@ sub git_heads {
git_header_div('summary', $project);
my $taglist = git_read_refs("refs/heads");
- my $alternate = 0;
if (defined @$taglist) {
git_heads_body($taglist, $head);
}
--
1.4.1.1
^ permalink raw reply related
* Re: fast-import and unique objects.
From: Shawn Pearce @ 2006-08-07 23:02 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Jon Smirl, git
In-Reply-To: <20060807075744.GB15477@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> wrote:
> On Sun, Aug 06, 2006 at 02:03:24PM -0400, Shawn Pearce wrote:
> >
> > - It expects an estimated object count as its second parameter.
> > In your case this would be something around 760000. This tells
> > it how large of an object table to allocate, with each entry
> > being 24 bytes + 1 pointer (28 or 32 bytes). Overshooting
> > this number will cause it to degrade by allocating one
> > overflow entry at a time from malloc.
>
> Hrm, you're allocating a big table and then assigning consecutive
> entries out of it, as pointers.
>
> Why not just malloc a big block, and assign offsets into it, as if it
> were a really big array. Every time it runs out, realloc it to double
> the current size, and update the base pointer.
Because I didn't want to move a 24 MB block of memory. :-)
I'm probably going to clean that section of code up tonight and
allocate a large block at the beginning then allocate overflow blocks
at about 5000 entries at a time. There's no need for the blocks to
be contiguous in memory, I just didn't want to have a high overhead
from malloc when there would be a large number of them...
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Junio C Hamano @ 2006-08-07 23:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb8e12$2aa$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Matthias Lederhofer has noticed that parsing all the tags in "summary" and
> "tags" views, while we use only epoch/timestamp information to sort them
> and discard most of parsed input, is bottleneck due to the fact that
> usually number of tags is linear with history (version tags) and the fact
> that for each tag is one invocation of git (one fork, two execs).
Maybe we would want to expose for_each_ref somehow to the
command level then. Looking at how "git branch" without any
argument lists the branches, and how "git tag -l" lists the
tags, it appears that we could benefit from such a command [*1*].
Of course doing it in Git.xs to make a single C level call is
easy, but that would benefit only Perl scripts, so it is not a
very good general solution.
> So the new guidelines would be:
> * git_get_ prefix for subroutines related to git repository
> and returning single scalar (single value).
> * git_read_ prefix for subroutines related to git repository, reading some
> files or multiline output, and returning hash reference, or list
> reference, or list.
I would suggest to use git_get for both, unless there is a good
reason to differenciate them, since I do not understand why you
would want to differenciate one value vs multivalue.
-- >8 -- [*1*] -- >8 --
[PATCH] git-show-refs
Implementation is left as an exercise ;-)
---
diff --git a/Documentation/git-show-refs.txt b/Documentation/git-show-refs.txt
new file mode 100644
index 0000000..e2869e0
--- /dev/null
+++ b/Documentation/git-show-refs.txt
@@ -0,0 +1,96 @@
+git-show-refs(1)
+================
+
+NAME
+----
+git-show-refs - Lists refs in various formats
+
+SYNOPSIS
+--------
+'git-show-refs' [--count=<max>] [--sort=<sortkeys>] [--format=<format>] [<pattern>]
+
+DESCRIPTION
+-----------
+
+Iterate over refs under `$GIT_DIR/refs` that match `<pattern>`
+and show them according to the given `<format>`, after sorting
+them according to the given `<sortkeys>`. If `<max>` is given,
+stop after showing that many refs.
+
+OPTIONS
+-------
+<max>::
+ By default the command shows all refs that match
+ `<pattern>`. This option makes it stop after showing
+ that many refs.
+
+<sortkeys>::
+ Comma separated field names to sort on. Prefix `-` to
+ sort in descending order of the value. When
+ unspecified, `name` is used.
+
+<format>::
+ A string that interpolates `%(field name)` from the
+ object pointed at by a ref being shown. When
+ unspecified, `%(name)` is used.
+
+<pattern>::
+ If given, the name of the ref is matched against this
+ using fnmatch(3). Refs that do not match the pattern
+ are not shown.
+
+
+FIELD NAMES
+-----------
+
+Various values from structured fields in referenced objects can
+be used to interpolate into the resulting output, or as sort
+keys.
+
+For all objects, the following names can be used:
+
+name::
+ The name of the ref (the part after $GIT_DIR/refs/),
+ except that when `<pattern>` is used, the leading fixed
+ string part of `<pattern>` is stripped out.
+
+objecttype::
+ The type of the object (`blob`, `tree`, `commit`, `tag`)
+
+objectsize::
+ The size of the object (the same as `git-cat-file -s` reports).
+
+objectname::
+ The object name (aka SHA-1).
+
+In addition, for commit and tag objects, the header field names
+(`tree`, `parent`, `object`, `type`, and `tag`) can be used to
+specify the value in the header field. Fields that have
+name-email-date tuple as its value (`author`, `committer`, and
+`tagger`) can be suffixed with `name`, `email`, and `date` to
+extract the named component. The first line of a commit and tag
+object can be referred to with `subject`, the remaining lines
+with `body`, and both (including the typical blank line after
+`subject`) with `contents`.
+
+Also a pseudo field name `ishead` can be used to check if the
+ref is pointed by `$GIT_DIR/HEAD` pointer. The field
+interpolates as "* " if true, otherwise an empty string.
+
+For sorting purposes, fields with numeric values sort in numeric
+order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
+All other fields are used to sort in their byte-value order.
+
+
+EXAMPLES
+--------
+
+Show most recent 16 tags for consumption by gitweb::
+ git-show-refs --count=16 --sort=-taggerdate,name \
+ --format='%(taggerdate) %(name)\t%(tag)\t%(subject)' 'tags/*'
+
+`git-branch` without argument::
+ git-show-refs --format='%(ishead)%(name)' 'heads/*'
+
+`git-tag -l`::
+ git-show-refs tags/*
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 0:10 UTC (permalink / raw)
To: git
In-Reply-To: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> So the new guidelines would be:
>> * git_get_ prefix for subroutines related to git repository
>> and returning single scalar (single value).
>> * git_read_ prefix for subroutines related to git repository, reading some
>> files or multiline output, and returning hash reference, or list
>> reference, or list.
>
> I would suggest to use git_get for both, unless there is a good
> reason to differenciate them, since I do not understand why you
> would want to differenciate one value vs multivalue.
I'd rather have git_read_info_refs, because it _reads_ info/refs file,
and git_read_refs as opposed to git_get_hash/git_get_ref/git_ref_to_hash
(or hash_from_ref). I'm not sure about git_read_projects vs. perhaps
git_get_project_list or git_list_projects. Neither about
git_read_description vs. git_get_project_description
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Since when is a tag a commit?
From: Shawn Pearce @ 2006-08-08 2:12 UTC (permalink / raw)
To: git
Current `next`:
[spearce@pb15 git]$ git cat-file commit v1.4.1
tree 34c8f9c263c1c20592d3f56c3d86bea322577155
parent 6631c73685bea3c6300938f4900db0d0c6bee457
author Linus Torvalds <torvalds@osdl.org> 1151691633 -0700
committer Junio C Hamano <junkio@cox.net> 1151803695 -0700
...
Uhhh, that's a tag. I know it is:
[spearce@pb15 git]$ git cat-file tag v1.4.1
object 0556a11a0df6b4119e01aa77dfb795561e62eb34
type commit
tag v1.4.1
tagger Junio C Hamano <junkio@cox.net> 1151818415 -0700
...
And I know its not a tree:
[spearce@pb15 git]$ git cat-file tree v1.4.1
100644 .gitignore{?MX~ă????y?v?X?u100644 COPYINGo?...
So it better not be a blob:
[spearce@pb15 git]$ git cat-file blob v1.4.1
fatal: git-cat-file v1.4.1: bad file
What the heck is going on? Since when did git cat-file happily
consider a tag to be a tag, a commit and a tree? Its that
intentional that we're peeling back the object to the requested type?
--
Shawn.
^ permalink raw reply
* Re: fast-import and unique objects.
From: Shawn Pearce @ 2006-08-08 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608070737k52aaea7clf871d716d16547c2@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> the change sets. That takes about four days to finish. Doing a
> fast-import backend should fix that.
Shouldn't be a problem. :-)
> >Any thoughts yet on how you might want to feed trees and commits
> >to a fast pack writer? I was thinking about doing a stream into
> >fast-import such as:
>
> The data I have generates an output that indicates add/change/delete
> for each file name. Add/change should have an associated sha-1 for the
> new revision. cvs/svn have no concept of trees.
>
> How about sending out a stream of add/change/delete operations
> interspersed with commits? That would let fast-import track the tree
> and only generate tree nodes when they change.
>
> The protocol may need some thought. I need to be able to handle
> branches and labels too.
Knowing a little bit about SVN I would assume the current cvs2svn
code would issue commands like:
svn copy A B; # Make branch B starting from where A is now.
svn switch B; # Make branch B the current branch.
svn add F; # Add file F.
svn rm Y; # Delete file Y.
svn commit; # Commit current tree on current branch.
svn copy A T; # Create tag T from where A is now.
But I don't know how it would issue a merge commit. Or even if it
could find such a thing in the RCS files.
The above command set would be rather trivial to implement in a
fast-import backend. I'm thinking we extend the protocol so it
looks something like the following:
stream ::= cmd*;
cmd ::= new_blob
| new_branch
| set_branch
| update
| commit
| tag
;
new_blob ::= 'blob' blob_data;
new_branch ::= 'newb' branch_name source_branch;
set_branch ::= 'setb' branch_name;
add_file ::= update_file;
update_file ::= 'updf' file_update;
delete_file ::= 'delf' file_delete;
commit ::= 'comt' author_committer_msg;
tag ::= 'tagg' branch_name tagger_msg;
source_branch ::= branch_name
| zero32
;
branch_name ::= len32 branch_name_str;
branch_name_str ::= # valid GIT branch name, should be relative
# to .git/ (so include a refs/heads prefix)
;
file_update ::= len32 mode sp hexsha1 sp path;
file_delete ::= len32 path;
blob_data ::= len32 binary_data;
author_committer_msg ::= len32
'author' sp name '<' email '>' ts tz lf
'committer' sp name '<' email '>' ts tz lf
lf
binary_data;
tagger_msg ::= len32
'tagger' sp name '<' email '>' ts tz lf
lf
binary_data;
len32 ::= # unsigned 32 bit value, native format;
zero32 ::= # 32 bits, unset, aka '0';
mode ::= 'P' # plain file
| 'X' # executable file
;
binary_data ::= # file content, not interpreted;
sp ::= # ASCII space character;
lf ::= # ASCII newline (LF) character;
path ::= # GIT style file path, e.g. "a/b/c";
hexsha1 ::= # SHA1 in hexadecimal format;
nullsha1 ::= # 40 '0's in sequence;
name ::= # valid GIT author/committer name;
email ::= # valid GIT author/committer email;
ts ::= # time since the epoch in seconds, ascii decimal;
tz ::= # GIT style timezone;
This is a change from the current protocol as new blobs need to
get prefixed by the command 'blob'. Note that all commands are 4
bytes wide and that any variable data portion of a command uses a
"Pascal style" leading 32 bit length. Although ugly it just makes
it a tiny bit easier to code the stream parser. :-)
The commits and tags are half generated in the frontend and half
in the backend. The backend is producing and tracking the tree and
the current SHA1 of each branch. Consequently it will generate the
'tree' and 'parent' lines of a commit or the 'object', 'type' and
'tag' lines of a tag. This is limited to only a linear development
path, no merges...
The backend would need to run inside of an existing GIT repository
as it would output all tags and branch heads when it terminates.
(Right now it runs from anywhere.)
I don't know how many branches you would be asking the backend to
hold at once, but I was thinking that the backend would just create
a tree structure in memory when it receives a new_branch command,
and consider one of those to be the current branch when a set_branch
command is issued. With all branches in memory at once switching
would be very cheap, but if the number of branches is high it could
eat memory like a pig...
Right now I'm thinking that a file entry in a tree would cost:
29 bytes + length_of_name + malloc_overhead
while a single tree would cost that plus:
36 bytes + 4*number_of_entries + 2*malloc_overhead + last_treesz
where last_treesz is last content of that tree (uncompressed),
so we can deltify against it quickly.
So what's your worst case number of files and directories in a
single commit? And how many branches are we talking about carrying
around in the backend?
--
Shawn.
^ permalink raw reply
* Re: Since when is a tag a commit?
From: Daniel Barkalow @ 2006-08-08 3:28 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060808021251.GA19548@spearce.org>
On Mon, 7 Aug 2006, Shawn Pearce wrote:
> What the heck is going on? Since when did git cat-file happily
> consider a tag to be a tag, a commit and a tree? Its that
> intentional that we're peeling back the object to the requested type?
I think it's done that for a long time now. All of the other commands that
take a tree or a commit will accept a tag, so why shouldn't "git cat-file
tree"?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-annotate bug report
From: Junio C Hamano @ 2006-08-08 8:49 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060807115000.GC15477@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> writes:
> Second, one I don't know how to fix, at the moment:
>
> git annotate uses the automatic tree simplification that git rev-list
> does. So, when it sees a commit with 1 parent, it assumes that it
> really only has one parent. git diff-tree -c doesn't know about this
> same tree simplification, and, in the case of a merge commit, will still
> output the -c format patch.
When a merge M between A and B is simplified to have only A as a
parent, that means the file in question are identical in M and
A. So you can just pass all the remaining blame on to A without
letting M taking any blame for itself. So you do not need to do
any diff at all for a simplified merge.
> There is, unfortunately, another situation, that of an octopus merge.
> In the case of read-tree.c (after the rename is followed), the commit
> 7bd1527d2d8c80a6e9a0f8583082a5aee5428c68 is problematic. In it we have
> a 4-way merge, yet only 3 paths affected read-tree.c. The diff-parsing
> in annotate constructs a regular expression to find the diff header and
> read out the line number to work on, and also to construct some regular
> expressions from which to tell which lines affect which parents.
If a merge is not simplified, and if you end up reading from
--cc or -c -p, then:
> For example, it looks for a line like:
> + ++Line added in 3 parents
> with dynamically generated regular expressions.
the merge needs to claim responsibility only for lines that have
all pluses (i.e. evil merge), which you are already doing, I
think. Any line without a minus that has at least one space can
be blamed on the parent that corresponds to the space (and if
there are more than one space, pick the first one).
Your particular "octopus" case, I think, is the same story.
$ git diff-tree --pretty=short -p -c 7bd1527 -- read-tree.c builtin-read-tree.c
would give you a combined diff, none of which has $allparentplus
(so nothing should be attributed to this merge), and the header
would tell you which parent to pass the blame on from that
point.
^ permalink raw reply
* Re: Since when is a tag a commit?
From: Jakub Narebski @ 2006-08-08 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060808021251.GA19548@spearce.org>
Shawn Pearce wrote:
> Current `next`:
>
> [spearce@pb15 git]$ git cat-file commit v1.4.1
> tree 34c8f9c263c1c20592d3f56c3d86bea322577155
> parent 6631c73685bea3c6300938f4900db0d0c6bee457
> author Linus Torvalds <torvalds@osdl.org> 1151691633 -0700
> committer Junio C Hamano <junkio@cox.net> 1151803695 -0700
> ...
This is commit referenced by tag, i.e. v1.4.1^{commit}
> Uhhh, that's a tag. I know it is:
>
> [spearce@pb15 git]$ git cat-file tag v1.4.1
> object 0556a11a0df6b4119e01aa77dfb795561e62eb34
> type commit
> tag v1.4.1
> tagger Junio C Hamano <junkio@cox.net> 1151818415 -0700
> ...
This is tag itself.
> And I know its not a tree:
>
> [spearce@pb15 git]$ git cat-file tree v1.4.1
> 100644 .gitignore{?MX~ă????y?v?X?u100644 COPYINGo?...
This is tree referenced by commit, referenced by tag, i.e. v1.4.1^{tree}
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> +git-show-refs(1)
> +================
> +
> +NAME
> +----
> +git-show-refs - Lists refs in various formats
[...]
> +EXAMPLES
> +--------
> +
> +Show most recent 16 tags for consumption by gitweb::
> + git-show-refs --count=16 --sort=-taggerdate,name \
> + --format='%(taggerdate) %(name)\t%(tag)\t%(subject)' 'tags/*'
> +
> +`git-branch` without argument::
> + git-show-refs --format='%(ishead)%(name)' 'heads/*'
> +
> +`git-tag -l`::
> + git-show-refs tags/*
`git-ls-remotes .` is suspiciously missing from the examples.
Format needs to somewhat incorporate line for referencing object for that,
if it exists.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <eb8cdh$s6n$1@sea.gmane.org>
Jakub Narebski wrote:
> With two scripts attached to the first post in this thread it would be
> simple to apply pre-rename patch, by converting gitweb to pre-rename using
> gitweb-unrename.sh script, then applying patch, then restoring new names
> using gitweb-rename.sh script, and finally comitting changes (or amending
> commit).
Or just apply corrected gitweb-rename.sh script (see below) to patch (mbox),
and then apply and commit the "after rename" patch.
#!/bin/sh
if test -z "$1"; then
FILE=`git rev-parse --show-cdup`gitweb/gitweb.perl
else
FILE=$1
fi
echo "Great subroutine renaming: $FILE"
perl -s -p -i.re~ \
-e 's/\bgit_get_referencing\b/format_mark_referencing/;' \
-e 's/\bgit_read_head\b/git_get_head/;' \
-e 's/\bread_info_ref\b/git_read_info_refs/;' \
-e 's/\bdate_str\b/parse_date/;' \
-e 's/\bgit_read_tag\b/parse_tag/;' \
-e 's/\bgit_read_commit\b/parse_commit/;' \
-e 's/\bgit_blob_plain_mimetype\b/blob_plain_mimetype/;' \
-e 's/\bgit_page_nav\b/git_print_page_nav/;' \
-e 's/\bgit_header_div\b/git_print_header_div/;' \
"$FILE"
# end of gitweb-rename.sh
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 9:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> +`git-branch` without argument::
> + git-show-refs --format='%(ishead)%(name)' 'heads/*'
git-show-refs --format='%(ishead?"* ":" ")%(name)' 'refs/heads/*'
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* gitweb age bug
From: Jeff Garzik @ 2006-08-08 11:26 UTC (permalink / raw)
To: Git Mailing List
At URL
http://www.kernel.org/git/?o=age
one can see the various repositories, sorted by last-modified time.
However, AFAICS, only the 'master' branch is checked. This causes an
incorrect age to be returned, for kernel hackers who always do work in
topic branches ('master' is Linus vanilla kernel).
Thus, the age on my repositories is only updated when I update the
'master' branch with new linux-2.6.git goodies. Development work I do
in topic branches is never noted in the 'age' column.
Jeff
^ permalink raw reply
* qgit feature idea: multiple Patch tabs
From: Jakub Narebski @ 2006-08-08 11:59 UTC (permalink / raw)
To: git
It would be nice to be able to have multiple "Patch" tabs,
e.g. by using "Open in new tab"/Ctrl-Click, instead of default
being only one Patch tab, and new patch replacing the old.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] add NO_PERL_XS for environments which are not able to support perl extensions
From: Alex Riesen @ 2006-08-08 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfygcl6zm.fsf@assigned-by-dhcp.cox.net>
On 8/4/06, Junio C Hamano <junkio@cox.net> wrote:
> >> At the moment, the only known example of such environment is Cygwin with
> >> ActiveState Perl: Makefile, generated by the MakeMaker from ActiveState perl
> >> distribution is not usable by cygwin's gmake.
>
> I'd rather see Git.pm to have an option to emulate what it does
> using Git.xs layer without it, to keep the upper layer of
> programs still usable.
>
Wont work until MakeMaker is used.
^ permalink raw reply
* Re: fast-import and unique objects.
From: Jon Smirl @ 2006-08-08 12:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060808031240.GB19067@spearce.org>
On 8/7/06, Shawn Pearce <spearce@spearce.org> wrote:
> Knowing a little bit about SVN I would assume the current cvs2svn
> code would issue commands like:
We're designing a dumpfile format for git like the one SVN has.
> svn copy A B; # Make branch B starting from where A is now.
> svn switch B; # Make branch B the current branch.
> svn add F; # Add file F.
> svn rm Y; # Delete file Y.
> svn commit; # Commit current tree on current branch.
> svn copy A T; # Create tag T from where A is now.
>
> But I don't know how it would issue a merge commit. Or even if it
> could find such a thing in the RCS files.
AFAIK the svn code doesn't do merge commits. We probably need a post
processing pass in the git repo that finds the merges and closes off
the branches. gitk won't be pretty with 1,500 open branches. This may
need some manual clues.
Another thing missing in cvs2svn is a sane way to handle unnamed
branches. Right now it is generating names. It's not real good at
detecting everything that belongs together in an unnamed branch so one
unnamed branches can turn into dozens of branches.
Once we get everything in a tool where it is possible to visualize the
repo errors like this will be more obvious. That should make it easier
to come up with a strategy to fix the import process.
> The above command set would be rather trivial to implement in a
> fast-import backend. I'm thinking we extend the protocol so it
> looks something like the following:
>
> stream ::= cmd*;
>
> cmd ::= new_blob
> | new_branch
> | set_branch
> | update
> | commit
> | tag
> ;
>
> new_blob ::= 'blob' blob_data;
> new_branch ::= 'newb' branch_name source_branch;
> set_branch ::= 'setb' branch_name;
> add_file ::= update_file;
> update_file ::= 'updf' file_update;
> delete_file ::= 'delf' file_delete;
> commit ::= 'comt' author_committer_msg;
> tag ::= 'tagg' branch_name tagger_msg;
>
> source_branch ::= branch_name
> | zero32
> ;
> branch_name ::= len32 branch_name_str;
> branch_name_str ::= # valid GIT branch name, should be relative
> # to .git/ (so include a refs/heads prefix)
> ;
> file_update ::= len32 mode sp hexsha1 sp path;
> file_delete ::= len32 path;
>
> blob_data ::= len32 binary_data;
>
> author_committer_msg ::= len32
> 'author' sp name '<' email '>' ts tz lf
> 'committer' sp name '<' email '>' ts tz lf
> lf
> binary_data;
>
> tagger_msg ::= len32
> 'tagger' sp name '<' email '>' ts tz lf
> lf
> binary_data;
>
> len32 ::= # unsigned 32 bit value, native format;
> zero32 ::= # 32 bits, unset, aka '0';
>
> mode ::= 'P' # plain file
> | 'X' # executable file
> ;
>
> binary_data ::= # file content, not interpreted;
> sp ::= # ASCII space character;
> lf ::= # ASCII newline (LF) character;
> path ::= # GIT style file path, e.g. "a/b/c";
> hexsha1 ::= # SHA1 in hexadecimal format;
> nullsha1 ::= # 40 '0's in sequence;
> name ::= # valid GIT author/committer name;
> email ::= # valid GIT author/committer email;
> ts ::= # time since the epoch in seconds, ascii decimal;
> tz ::= # GIT style timezone;
>
> This is a change from the current protocol as new blobs need to
> get prefixed by the command 'blob'. Note that all commands are 4
> bytes wide and that any variable data portion of a command uses a
> "Pascal style" leading 32 bit length. Although ugly it just makes
> it a tiny bit easier to code the stream parser. :-)
>
> The commits and tags are half generated in the frontend and half
> in the backend. The backend is producing and tracking the tree and
> the current SHA1 of each branch. Consequently it will generate the
> 'tree' and 'parent' lines of a commit or the 'object', 'type' and
> 'tag' lines of a tag. This is limited to only a linear development
> path, no merges...
>
> The backend would need to run inside of an existing GIT repository
> as it would output all tags and branch heads when it terminates.
> (Right now it runs from anywhere.)
>
> I don't know how many branches you would be asking the backend to
> hold at once, but I was thinking that the backend would just create
> a tree structure in memory when it receives a new_branch command,
> and consider one of those to be the current branch when a set_branch
> command is issued. With all branches in memory at once switching
> would be very cheap, but if the number of branches is high it could
> eat memory like a pig...
>
> Right now I'm thinking that a file entry in a tree would cost:
>
> 29 bytes + length_of_name + malloc_overhead
>
> while a single tree would cost that plus:
>
> 36 bytes + 4*number_of_entries + 2*malloc_overhead + last_treesz
>
> where last_treesz is last content of that tree (uncompressed),
> so we can deltify against it quickly.
The file names are used over and over. Alloc a giant chunk of memory
and keep appending the file name strings to it. Then build a little
tree so that you can look up existing names. i.e. turn the files names
into atoms. Never delete anything.
You can do something similar with the 29 and 36 byte arrays. Alloc two
giant chunks of memory. Append new entries to the end. Maintain a list
of deleted entries for reuse (store the pointer to the next free entry
inside the unused blocks, don't use a separate structure). You have
three things to track, end of used memory, head of free list, end of
allocated memory.
Now there is no malloc overhead on millions of items.
> So what's your worst case number of files and directories in a
> single commit? And how many branches are we talking about carrying
> around in the backend?
About 100,000 files in the initial change set that builds the repo.
FInal repo has 120,000 files.
There are 1,500 branches. I haven't looked at the svn dump file format
for branches, but I suspect that it sends everything on a branch out
at once and doesn't intersperse it with the trunk commits.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* And very useful for your peniis!
From: Caron @ 2006-08-08 13:58 UTC (permalink / raw)
To: glenn
Hello to you! Stop disappointing your partner and join the lucky ones who have overcome this. You might have tried other products and failed - the last thing you need is Extra-Time, the no-failure solution. Just how many times you were embarrassed when your bed marathon ended a couple of minutes after its start? Come in here: http://lorned.com/gall/get/ You will never see her face frustrated again. No arguments and no complaints!
^ permalink raw reply
* Re: [PATCH] Racy git: avoid having to be always too careful
From: Johannes Schindelin @ 2006-08-08 15:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7virl7e8ed.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 5 Aug 2006, Junio C Hamano wrote:
> Immediately after a bulk checkout, most of the paths in the
> working tree would have the same timestamp as the index file,
> and this would force ce_match_stat() to take slow path for all
> of them. When writing an index file out, if many of the paths
> have very new (read: the same timestamp as the index file being
> written out) timestamp, we are better off delaying the return
> from the command, to make sure that later command to touch the
> working tree files will leave newer timestamps than recorded in
> the index, thereby avoiding to take the slow path.
This makes "make test" dog slow. How about making this overrideable?
(It is just a guess, but I _think_ that the sleeping is worse than having
to check the files with the same time stamp again and again -- a "git
status" will help that).
"make test" without this patch:
real 9m59.314s
user 0m36.580s
sys 0m39.290s
"make test" with this patch:
real 1m36.429s
user 0m37.410s
sys 0m40.460s
-- 8< --
[PATCH] read-cache: optionally disable being cautious with racy caches
By setting the environment variable GIT_RISK_RACY_CACHE or the config
variable core.riskRacyCache, the sleeping (to avoid a racy cache) is
disabled. This is also used for "make test", drastically reducing the
needed time.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/config.txt | 4 ++++
Documentation/git.txt | 5 +++++
cache.h | 1 +
config.c | 4 ++++
environment.c | 1 +
read-cache.c | 3 ++-
t/test-lib.sh | 2 ++
7 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d89916b..b61fd91 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -103,6 +103,10 @@ core.legacyheaders::
database directly (where the "http://" and "rsync://" protocols
count as direct access).
+core.riskRacyCache::
+ A boolean which allows to disable the 1-second sleeping to avoid
+ a racy cache.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ba525d3..ff464e8 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -649,6 +649,11 @@ other
stderr telling about alias expansion, built-in command
execution and external command execution.
+'GIT_RISK_RACY_CACHE'::
+ If this variable is set, gitlink:git-read-cache[1] will never
+ sleep to avoid a racy cache by making the timestamps of the index
+ file newer than the files referenced in the index.
+
Discussion[[Discussion]]
------------------------
include::README[]
diff --git a/cache.h b/cache.h
index 19fdef6..e8bbe6d 100644
--- a/cache.h
+++ b/cache.h
@@ -174,6 +174,7 @@ #define REFRESH_UNMERGED 0x0002 /* allow
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
extern int refresh_cache(unsigned int flags);
+extern int risk_racy_cache;
struct lock_file {
struct lock_file *next;
diff --git a/config.c b/config.c
index c6e6f6a..4ab9329 100644
--- a/config.c
+++ b/config.c
@@ -291,6 +291,10 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.riskracycache")) {
+ risk_racy_cache = git_config_bool(var, value);
+ }
+
if (!strcmp(var, "user.name")) {
strlcpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 1ce3411..a481fc4 100644
--- a/environment.c
+++ b/environment.c
@@ -24,6 +24,7 @@ const char *apply_default_whitespace = N
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
int pager_in_use;
int pager_use_color = 1;
+int risk_racy_cache = 0;
static int dyn_git_object_dir, dyn_git_index_file, dyn_git_graft_file;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
diff --git a/read-cache.c b/read-cache.c
index d64b503..f20dac5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1021,7 +1021,8 @@ int write_cache(int newfd, struct cache_
* This assumes that nobody is touching the working tree while
* we are updating the index.
*/
- if (20 < recent || entries <= recent * 4) {
+ if (!risk_racy_cache && !getenv("GIT_RISK_RACY_CACHE") &&
+ (20 < recent || entries <= recent * 4)) {
now = fstat(newfd, &st) ? 0 : st.st_mtime;
while (now && !fstat(newfd, &st) && st.st_mtime <= now) {
struct timespec rq, rm;
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b6d119a..3b6882d 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -197,6 +197,8 @@ # t/ subdirectory and are run in trash s
PATH=$(pwd)/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
export PATH GIT_EXEC_PATH
+GIT_RISK_RACY_CACHE=1
+export GIT_RISK_RACY_CACHE
# Similarly use ../compat/subprocess.py if our python does not
# have subprocess.py on its own.
--
1.4.2.rc3.g6b27
^ permalink raw reply related
* [PATCH 0/4] autoconf: Some improvements
From: Jakub Narebski @ 2006-08-08 16:34 UTC (permalink / raw)
To: git
This series of patches, based on next branch
(commit id: 45c5baf2f082dd5f537f043f7637bff87db515e8)
introduces few minor improvements, and one (last) larger,
following
"autoconf: Unset NO_STH and NEED_STH when it is detected not needed"
* [PATCH 1/4] autoconf: Add configure target to main Makefile
* [PATCH 2/4] autoconf: Error out on --without-shell and --without-perl
* [PATCH 3/4] autoconf: Improvements in NO_PYTHON/PYTHON_PATH handling
* [PATCH 4/4] autoconf: Move variables which we always set
to config.mak.in
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/4] autoconf: Add configure target to main Makefile
From: Jakub Narebski @ 2006-08-08 16:35 UTC (permalink / raw)
To: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
While at it fill git version information in configure.ac
configure target needs autoconf, of course.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This will make testing autoconf improvements easier
Makefile | 7 +++++++
configure.ac | 2 +-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8c225e6..321267b 100644
--- a/Makefile
+++ b/Makefile
@@ -676,6 +676,13 @@ git-instaweb: git-instaweb.sh gitweb/git
chmod +x $@+
mv $@+ $@
+configure: configure.ac
+ rm -f $@ $<+
+ sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $< > $<+
+ autoconf -o $@ $<+
+ rm -f $<+
+
# These can record GIT_VERSION
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/configure.ac b/configure.ac
index 3c56cc5..e2da891 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ #
# Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
-AC_INIT([git], [1.4.1], [git@vger.kernel.org])
+AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
--
1.4.1.1
^ permalink raw reply related
* [PATCH 2/4] autoconf: Error out on --without-shell and --without-perl
From: Jakub Narebski @ 2006-08-08 16:36 UTC (permalink / raw)
To: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
Error out on --without-shell/--with-shell=no and
--without-perl/--with-perl=no instead of just warning
and continuing.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
It's a matter of taste (and not doing unexpected)
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index e2da891..c2ddd9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,7 +37,7 @@ # Used by GIT_ARG_SET_PATH(PROGRAM)
AC_DEFUN([GIT_CONF_APPEND_PATH],
[PROGRAM=m4_toupper($1); \
if test "$withval" = "no"; then \
- AC_MSG_WARN([You cannot use git without $1]); \
+ AC_MSG_ERROR([You cannot use git without $1]); \
else \
if test "$withval" = "yes"; then \
AC_MSG_WARN([You should provide path for --with-$1=PATH]); \
--
1.4.1.1
^ permalink raw reply related
* [PATCH 3/4] autoconf: Improvements in NO_PYTHON/PYTHON_PATH handling
From: Jakub Narebski @ 2006-08-08 16:38 UTC (permalink / raw)
To: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
Unset NO_PYTHON for --with-python without arguments, and when
PYTHON_PATH is set. Do not check for PYTHON_PATH if it is set
via --with-python=PYTHON_PATH. Prefer python to python2.4 etc.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
What might be unexpected is the fact that even for --with-python
(but only without setting PYTHON_PATH) autodetection might set NO_PYTHON
configure.ac | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index c2ddd9b..c27a994 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,7 +105,10 @@ AC_ARG_WITH(python,[AS_HELP_STRING([--wi
AS_HELP_STRING([--no-python], [don't use python scripts])],
[if test "$withval" = "no"; then \
NO_PYTHON=YesPlease; \
- elif test "$withval" != "yes"; then \
+ elif test "$withval" = "yes"; then \
+ NO_PYTHON=; \
+ else \
+ NO_PYTHON=; \
PYTHON_PATH=$withval; \
fi; \
])
@@ -138,15 +141,15 @@ #
# Define NO_PYTHON if you want to lose all benefits of the recursive merge.
# Define PYTHON_PATH to provide path to Python.
if test -z "$NO_PYTHON"; then
- AC_PATH_PROGS(PYTHON_PATH, [python2.4 python2.3 python2 python])
+ if test -z "$PYTHON_PATH"; then
+ AC_PATH_PROGS(PYTHON_PATH, [python python2.4 python2.3 python2])
+ fi
if test -n "$PYTHON_PATH"; then
GIT_CONF_APPEND_LINE([PYTHON_PATH=@PYTHON_PATH@])
- else
- GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
+ NO_PYTHON=""
fi
-else
- GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
fi
+GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
## Checks for libraries.
--
1.4.1.1
^ 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