* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-03 21:59 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
0 files changed, 0 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-03 20:01 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
Davide Libenzi <davidel@xmailserver.org> writes:
>> For example, the first hunk says:
>>
>> @@ -0,0 +6 @@
>> +#include "diff.h"
>>
>> Which is inconsistent with what GNU diff says:
>>
>> @@ -5,0 +6 @@
>> +#include "diff.h"
>>
>> I've tried this patch but...
>
> The fix is fine, but you should do the same even in the s2 case. The
> correct hunk should have been:
>
> @@ -6,0 +6 @@
You are right. GNU says -5,0 not -6,0 so presumably "patch"
other people use expect it to say -5,0 not -6,0; even though we
could argue the insertion happens at 6th position and saying
-6,0 is more logical, it does not matter -- what incumbent does
wins X-<. I notice that your fix shows -5,0 to match it ;-).
Thanks for the fix.
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
On Mon, 3 Apr 2006, Davide Libenzi wrote:
> On Mon, 3 Apr 2006, Junio C Hamano wrote:
>>
>> I've tried this patch but it is not right; the diff between the
>> attached two files show a 47-line hunk that inserts at line 400,
>> then the next 6-line hunk inserts at line 401 which is obviously
>> bogus.
That's fine, since that's orig file position *before* the insert. Try the
same with GNU diff and you should see the same. Also try to create a diff
with libxdiff (with the fix) and feed it to GNU patch.
- Davide
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-03 19:37 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think we can conclude from this:
>
> - this is not impossible using the current model, and some extra
> useful information can be seen in the tree that shows more real
> dependency information and relationships between individual commits
>
> - doing automatic n-head creation would probably be madness, as
> far too many useless heads are created (though it is almost
> guaranteed that supporting 'patch commuting' a la darcs would
> make this *even worse* as it would mean that you could potentially
> have even more heads)
I suspect people have hard time grasping _why_ you are jumping
through hoops. At least I do. What problem are you trying to
solve? You perhaps described your mechanism well enough, but it
is not quite clear to me what kind of operations are made easier
with this exercise, against which possible downside of it, if
any, would be judged.
> - the current tools make this style of development difficult.
Git was born from necessity, and we have been aiming to have
tools to do what are commonly needed. It is not surprising to
see existing tools do not support modes of operations that are
"unusual" (meaning, things we have not done with git so far).
Also we do not tend to do things only because we can.
Now admittably I am guilty of having done a few things only
because we can. Octopus is an example. Making an Octopus only
because you can does not buy you much, other than its coolness
value, and it would make exporting the history to other SCMs
somewhat harder I suspect, and it makes bisecting more
expensive [*1*].
For example, the point jdl raised during the discussion is far
easier to understand. When working on multiple topics, he often
needs to test them as a whole, so he pulls them into a test
branch (can be a throwaway branch). When he needs to do fixups,
it is most efficient to do compile/run test while still in the
test branch, but after things test out, in order to keep
logically different things separate, he needs to go back to
relevant topic branches and make a commit. This is painful --
are there ways to make this easier [*2*]?
Would patch commutation calculus help with his problem?
I suspect patch commutation could be used to solve his problem,
but if it does not, it does not mean what you are trying to do
with hydra is not interesting. It just means from your
descriptions it is not clear what real problems hydra is trying
to solve, and I misunderstood that it is related to his problem
(just like jdl did, I suspect).
So can you step back a bit and start from describing what
problem you are trying to solve, before describing the
mechanisms you think would help?
One thing I can think of that could potentially come out of your
approach would be an alternative implementation of what StGIT
does. Inside a local developer repository, being able to
reorder patches and rewrite them flexibly is very useful.
While I agree with Linus's reaction "I want my merges fast", I
am not necessarily so negative about the approach. For example,
if you use it only as a tool to reorder and clean-up local
development history to a presentable form (IOW, using hydra to
manage your development, but the result exposed to the outside
world is exported from that hydra into a more linear form, that
does not give other people a heart attach when they look at the
ancestry graph in gitk), you would not negatively affect other
people who work with you.
[Footnote]
*1* Do not get me wrong. Octopus is sometimes the most natural
way to express what happened, but the case it applies to is
quite narrowly defined -- to merge in independent branches that
happened to mature at the same time together. So the tool
discourages you from making an Octopus that is not trivial,
deliberately.
*2* I see two approaches, the more obvious being "git checkout
-m that-topic". Just edit (but not update-index) on top of
test, have "checkout -m" adjust your changes to the topic branch
you want to commit to, make a commit there, and then come back
to the test branch, and merge the topic branch again.
Another obvious strategy would be to make commits on top of
"test" and then cherry-pick them back on top of the relevant
topics later.
topicA You have three topics
o---o you need to test together...
/
---o---o topicB
\
o---o
topicC
==>
topicA So merge them up and start testing.
o---o
/ \
---o---o---T
\ /
o---o
topicB
==>
topicA But you find problems, and fix them
o---o up as you go along...
/ \
---o---o---T---1---2
\ /
o---o
topicB
==>
topicA Later you cherry-pick them into
o---o---1' relevant topics.
/
---o---o topicB
\
o---o---2'
topicC
==>
topicA Next round of test will continue
o---o---1' by rebuilding the test branch
/ \
---o---o-------T
\ /
o---o---2'
topicC
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q1bglkp.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Apr 2006, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>> No problem. That's only an eye-issue though, since the diff is still a
>> valid diff according to its definition where D=A-B => B+D==A && A-D==B
>> From the day I released 0.18, xregression is continuosly running w/out
>> any issue. I'll check it out though ...
>
> There is another to report, when ctxlen == 0.
>
> Between the attached files "diff -u0 8f352aa dd40a03", the
> header for a hunk with only inserted lines misidentify the
> original location.
>
> For example, the first hunk says:
>
> @@ -0,0 +6 @@
> +#include "diff.h"
>
> Which is inconsistent with what GNU diff says:
>
> @@ -5,0 +6 @@
> +#include "diff.h"
>
> I've tried this patch but it is not right; the diff between the
> attached two files show a 47-line hunk that inserts at line 400,
> then the next 6-line hunk inserts at line 401 which is obviously
> bogus.
>
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index afaada1..3e7f999 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -244,7 +244,7 @@ int xdl_emit_hunk_hdr(long s1, long c1,
> memcpy(buf, "@@ -", 4);
> nb += 4;
>
> - nb += xdl_num_out(buf + nb, c1 ? s1: 0);
> + nb += xdl_num_out(buf + nb, c1 ? s1 : (s1-1));
>
> if (c1 != 1) {
> memcpy(buf + nb, ",", 1);
The fix is fine, but you should do the same even in the s2 case. The
correct hunk should have been:
@@ -6,0 +6 @@
because the lines are actually inserted at the 6th position, but patch
handle its own special 0 count case by adding 1 to the position, so I had
to change even the xpatchi.c code. The 0-context diffs are pretty
dangerous though, since in case of purely added hunks, patch has no way to
verify the orig-file position by matching contexts.
Now I'll take a look at the pre-diff optimization issue ...
- Davide
--- xdiff/xpatchi.c
+++ xdiff/xpatchi.c
@@ -162,9 +162,9 @@
* We start from zero, so decrement by one unless it's the special position
* '0' inside the unified diff (new or deleted file).
*/
- if (hki->s1 > 0)
+ if (hki->s1 > 0 && hki->c1 > 0)
hki->s1--;
- if (hki->s2 > 0)
+ if (hki->s2 > 0 && hki->c2 > 0)
hki->s2--;
return 0;
--- xdiff/xutils.c
+++ xdiff/xutils.c
@@ -537,7 +537,7 @@
memcpy(buf, "@@ -", 4);
nb += 4;
- nb += xdl_num_out(buf + nb, c1 ? s1: 0);
+ nb += xdl_num_out(buf + nb, c1 ? s1: s1 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
@@ -547,7 +547,7 @@
memcpy(buf + nb, " +", 2);
nb += 2;
- nb += xdl_num_out(buf + nb, c2 ? s2: 0);
+ nb += xdl_num_out(buf + nb, c2 ? s2: s2 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
Ah, should have known. I am behind a (lame) transparent proxy on port 80.
I opened that file in my web browser and it showed the old heads. After
a force-refresh (ctrl+F5, which sends some additionally http headers to
refresh the page from the real server), the old heads disappeared, and
git now clones successfully.
git-http-fetch should probably send those extra headers too. I'll try to
find some time to look at this next week.
Thanks!
Daniel
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-03 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Drake, git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 10:23:22AM -0700, Junio C Hamano wrote:
> My standard answer would be
>
> http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
> http-server$ GIT_DIR=. git-update-server-info
Is there any interest in making the HTTP transport slighly less dumb by
using DAV?
I have a working patch to http-fetch that tries to use PROPFIND to get a
remote pack list and falls back to using objects/info/packs. It's
feasible to do something similar to get a remote ref list when cloning,
although that's a bit more work as all refs would have to be fetched
into a local repo and parsed to determine the object type.
Long term, this could give a repo admin the choice of either making sure
git-update-server-info has been run after every ref/pack change or
enabling DAV once. Assuming they need to use HTTP.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Junio C Hamano @ 2006-04-03 17:23 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <443146EC.7060704@gentoo.org>
Daniel Drake <dsd@gentoo.org> writes:
> I maintain a small git repo. I upload it over ssh (with git-push) to a
> machine where it is distributed over http:
>
> http://dsd.object4.net/git/zd1211.git/
>...
> I have tried running git-prune and git-update-server-info, but that
> doesn't help.
>
> Any ideas?
My standard answer would be
http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
http-server$ GIT_DIR=. git-update-server-info
but you said you have run it already... Can you try to see if
there is some caching proxy involved that still serves stale
info/refs file?
client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 16:54 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:
> -YFLAGS=-d
> +YFLAGS=-d -l
> +LFLAGS=-l
Works for me too; thanks for the fix.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] Replace xmalloc+memset(0) with xcalloc.
From: Peter Eriksen @ 2006-04-03 16:35 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Mon Apr 3 19:30:46 2006 +0100
Subject: [PATCH] Replace xmalloc+memset(0) with xcalloc.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
Is something like this considered a cleaup?
Regards,
Peter
apply.c | 9 +++------
blob.c | 3 +--
commit.c | 3 +--
convert-objects.c | 3 +--
http-push.c | 6 ++----
object.c | 6 ++----
read-tree.c | 9 +++------
tag.c | 3 +--
tree.c | 7 ++-----
update-index.c | 6 ++----
10 files changed, 18 insertions(+), 37 deletions(-)
d5c82aa8a2b9d776bb30efac17d15a8a596b47f4
diff --git a/apply.c b/apply.c
index c50b3a6..6623ae7 100644
--- a/apply.c
+++ b/apply.c
@@ -924,8 +924,7 @@ static int parse_single_patch(char *line
struct fragment *fragment;
int len;
- fragment = xmalloc(sizeof(*fragment));
- memset(fragment, 0, sizeof(*fragment));
+ fragment = xcalloc(1, sizeof(*fragment));
len = parse_fragment(line, size, patch, fragment);
if (len <= 0)
die("corrupt patch at line %d", linenr);
@@ -1651,8 +1650,7 @@ static void add_index_file(const char *p
if (!write_index)
return;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
memcpy(ce->name, path, namelen);
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = htons(namelen);
@@ -1808,8 +1806,7 @@ static int apply_patch(int fd, const cha
struct patch *patch;
int nr;
- patch = xmalloc(sizeof(*patch));
- memset(patch, 0, sizeof(*patch));
+ patch = xcalloc(1, sizeof(*patch));
nr = parse_chunk(buffer + offset, size, patch);
if (nr < 0)
break;
diff --git a/blob.c b/blob.c
index 84ec121..c1fdd86 100644
--- a/blob.c
+++ b/blob.c
@@ -8,8 +8,7 @@ struct blob *lookup_blob(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct blob *ret = xmalloc(sizeof(struct blob));
- memset(ret, 0, sizeof(struct blob));
+ struct blob *ret = xcalloc(1, sizeof(struct blob));
created_object(sha1, &ret->object);
ret->object.type = blob_type;
return ret;
diff --git a/commit.c b/commit.c
index eb42d51..d4976fb 100644
--- a/commit.c
+++ b/commit.c
@@ -73,8 +73,7 @@ struct commit *lookup_commit(const unsig
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct commit *ret = xmalloc(sizeof(struct commit));
- memset(ret, 0, sizeof(struct commit));
+ struct commit *ret = xcalloc(1, sizeof(struct commit));
created_object(sha1, &ret->object);
ret->object.type = commit_type;
return ret;
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..b2aafbb 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -18,8 +18,7 @@ static struct entry * convert_entry(unsi
static struct entry *insert_new(unsigned char *sha1, int pos)
{
- struct entry *new = xmalloc(sizeof(struct entry));
- memset(new, 0, sizeof(*new));
+ struct entry *new = xcalloc(1, sizeof(struct entry));
memcpy(new->old_sha1, sha1, 20);
memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * sizeof(struct entry *));
convert[pos] = new;
diff --git a/http-push.c b/http-push.c
index ba7d9de..b60fa8d 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1008,8 +1008,7 @@ static int fetch_indices(void)
struct active_request_slot *slot;
struct slot_results results;
- data = xmalloc(4096);
- memset(data, 0, 4096);
+ data = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
buffer.buffer = data;
@@ -2042,8 +2041,7 @@ static void update_remote_info_refs(stru
char *if_header;
struct curl_slist *dav_headers = NULL;
- buffer.buffer = xmalloc(4096);
- memset(buffer.buffer, 0, 4096);
+ buffer.buffer = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
remote_ls("refs/", (PROCESS_FILES | RECURSIVE),
diff --git a/object.c b/object.c
index c9ca481..71e15e1 100644
--- a/object.c
+++ b/object.c
@@ -85,8 +85,7 @@ struct object_refs *alloc_object_refs(un
struct object_refs *refs;
size_t size = sizeof(*refs) + count*sizeof(struct object *);
- refs = xmalloc(size);
- memset(refs, 0, size);
+ refs = xcalloc(1, size);
refs->count = count;
return refs;
}
@@ -178,8 +177,7 @@ struct object *lookup_unknown_object(con
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- union any_object *ret = xmalloc(sizeof(*ret));
- memset(ret, 0, sizeof(*ret));
+ union any_object *ret = xcalloc(1, sizeof(*ret));
created_object(sha1, &ret->object);
ret->object.type = NULL;
return &ret->object;
diff --git a/read-tree.c b/read-tree.c
index eaff444..58e5636 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -133,11 +133,9 @@ #endif
pathlen = strlen(first);
ce_size = cache_entry_size(baselen + pathlen);
- src = xmalloc(sizeof(struct cache_entry *) * src_size);
- memset(src, 0, sizeof(struct cache_entry *) * src_size);
+ src = xcalloc(src_size, sizeof(struct cache_entry *));
- subposns = xmalloc(sizeof(struct tree_list_entry *) * len);
- memset(subposns, 0, sizeof(struct tree_list_entry *) * len);
+ subposns = xcalloc(len, sizeof(struct tree_list_entry *));
if (cache_name && !strcmp(cache_name, first)) {
any_files = 1;
@@ -177,8 +175,7 @@ #endif
else
ce_stage = 2;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
ce->ce_mode = create_ce_mode(posns[i]->mode);
ce->ce_flags = create_ce_flags(baselen + pathlen,
ce_stage);
diff --git a/tag.c b/tag.c
index ac0e573..f390ee7 100644
--- a/tag.c
+++ b/tag.c
@@ -19,8 +19,7 @@ struct tag *lookup_tag(const unsigned ch
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tag *ret = xmalloc(sizeof(struct tag));
- memset(ret, 0, sizeof(struct tag));
+ struct tag *ret = xcalloc(1, sizeof(struct tag));
created_object(sha1, &ret->object);
ret->object.type = tag_type;
return ret;
diff --git a/tree.c b/tree.c
index 87e0d74..d599fb5 100644
--- a/tree.c
+++ b/tree.c
@@ -18,10 +18,8 @@ static int read_one_entry(unsigned char
len = strlen(pathname);
size = cache_entry_size(baselen + len);
- ce = xmalloc(size);
+ ce = xcalloc(1, size);
- memset(ce, 0, size);
-
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = create_ce_flags(baselen + len, stage);
memcpy(ce->name, base, baselen);
@@ -130,8 +128,7 @@ struct tree *lookup_tree(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tree *ret = xmalloc(sizeof(struct tree));
- memset(ret, 0, sizeof(struct tree));
+ struct tree *ret = xcalloc(1, sizeof(struct tree));
created_object(sha1, &ret->object);
ret->object.type = tree_type;
return ret;
diff --git a/update-index.c b/update-index.c
index 797245a..1efac27 100644
--- a/update-index.c
+++ b/update-index.c
@@ -114,8 +114,7 @@ static int add_file_to_cache(const char
namelen = strlen(path);
size = cache_entry_size(namelen);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->name, path, namelen);
ce->ce_flags = htons(namelen);
fill_stat_cache_info(ce, &st);
@@ -312,8 +311,7 @@ static int add_cacheinfo(unsigned int mo
len = strlen(path);
size = cache_entry_size(len);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->sha1, sha1, 20);
memcpy(ce->name, path, len);
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: git-svn and svn sw --relocate
From: Nicolas Vilz 'niv' @ 2006-04-03 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060402222100.GA17888@localdomain>
Eric Wong wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
>>i have now my repository locally and i want to get it remotely on a
>>server, in order to have a few collaborators...
>>
>>the steps on the svn-side are clear. But what do i have todo on the
>>git-svn-side of this life?
>>
>>does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
>
>
> Yes, you'll need to do that in .git/git-svn/tree and also update
> .git/git-svn/info/url by hand.
Will there be any other sha1-sums for that repository so that i have to
merge them again and again? This issue occured to me the last time i
encountered the git-svn-change with the external sources, where i had to
repair my external git-svn-tree, which resulted in new sha1sums
somehow... that was very unpleasant to my collegue..
Although the uuids there should remain the same... so i think, that
would be no problem to try.
Thanks for the tip.
Nicolas
^ permalink raw reply
* HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 16:01 UTC (permalink / raw)
To: git
Hi,
I maintain a small git repo. I upload it over ssh (with git-push) to a
machine where it is distributed over http:
http://dsd.object4.net/git/zd1211.git/
For some reason it is no longer possible to clone this repo over http:
walk 35afe6b3a859242a18812e7485ea8b211e24abaf
walk 93d9a9f469282e1e392c16ce571da4c08805e8bb
error: Couldn't get
http://dsd.object4.net/git/zd1211.git/refs/heads/softmac-old for
heads/softmac-old
The requested URL returned error: 404
error: Could not interpret heads/softmac-old as something to pull
"softmac-old" is an old branch, which I have recently deleted. I deleted
it by removing the .git/refs/heads/softmac-old file, and relying on
git-prune to clear out old objects.
Even on the server-side, there is no obvious reference to this old head:
$ find -name '*softmac*'
$ grep -R softmac *
(no results for either)
"git-fsck-objects" reports nothing, "git-fsck-objects --full" reports:
dangling commit 7cc423c942975005f96f308186537ad6e7808c2e
dangling commit b36378de6231f1b5100b1517b9c8c243a21090fd
I have tried running git-prune and git-update-server-info, but that
doesn't help.
Any ideas? I'm still new to git.
I am running git-1.2.4
Thanks,
Daniel
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-03 15:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604030727250.3781@g5.osdl.org>
On Mon, 2006-04-03 at 07:29 -0700, Linus Torvalds wrote:
> I really think that darcs is just "nice theory", and has nothing to do
> with real life.
>
> Terms like "patch calculus" may sound cool and useful, but let's face it,
> the proof is in the pudding, and quite frankly, I would bet that trying to
> do something like that on a real project would just be a total disaster.
>
> I want my merges simple. I want them to take a couple of seconds. I
> don't want to see strange patch dependencies that nobody cares about.
Dave really was right with his keynote comment about nomenclature in
Dunedin. I shouldn't even have put the term "patch calculus" in the
e-mail body at all :-P
Seriously, though, the rest of the report basically agrees with your
position. Sorry if it was rambling and that key message wasn't clear.
We did kind of work out along the way that the best bits of patch
calculus were probably obtained with good use of topic branches. Likely
if there are any key advances to be made, they will be found in the form
of clever ways to manage topic branches.
> And I very much don't want to see theory over practice.
Theory? Do I *look* like a theorist?
(looks around sheepishly)
This was valuable cross-culture field research!
(looks around at rather non-plussed eyes)
Hey, I found it quite enlightening, and at least a few other people were
amused by the ordeal. And I learned a little bit more about git along
the way.
(waits for a 'hear', 'hear'! silence.)
I'll get me coat.
Sam.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jeff King @ 2006-04-03 15:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1144075047.2303.97.camel@neko.keithp.com>
On Mon, Apr 03, 2006 at 07:37:27AM -0700, Keith Packard wrote:
> You can't. You need to create a local copy of the repository. There is a
> tool which can do that using the cvs protocol, but I don't recall the
> name.
I believe you're thinking of CVSSuck:
http://cvs.m17n.org/~akr/cvssuck/
-Peff
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Johannes Schindelin @ 2006-04-03 15:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
Hi,
On Mon, 3 Apr 2006, Linus Torvalds wrote:
> On Mon, 3 Apr 2006, Johannes Schindelin wrote:
> >
> > The problem is not mmap() on cygwin, but that a fork() has to jump through
> > loops to reinstall the open file descriptors on cygwin. If the
> > corresponding file was deleted, that fails. Therefore, we work around that
> > on cygwin by actually reading the file into memory, *not* mmap()ing it.
>
> Well, we could actually do a _real_ mmap on pack-files. The pack-files are
> much better mmap'ed - there we don't _want_ them to be removed while we're
> using them. It was the index file etc that was problematic.
>
> Maybe the cygwin fake mmap should be triggered only for the index (and
> possibly the individual objects - if only because there doing a
> malloc+read may actually be faster).
I hit the problem *only* with "git-whatchanged -p". Which means that the
upcoming we-no-longer-write-temp-files-for-diff version should make that
gitfakemmap() hack obsolete. (I have not checked whether there are other
places where a file is mmap()ed and then used by a fork()ed process.)
Ciao,
Dscho
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 14:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: keithp, git
In-Reply-To: <e0rb0j$ml9$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Mon, 2006-04-03 at 16:21 +0200, Jakub Narebski wrote:
> From the comments on #git, parsecvs reads raw ,v files for creating history
> tree, then uses 'cvs co ...' for getting the contents.
It's not using cvs co, it's using the rcs 'co' command. I will probably
fix it to just generate the files directly as that will be a lot faster.
If there was a git command to create blobs directly from file contents,
it would be faster still as I could create all of the blobs for a
particular file in one pass and then just build trees in the index out
of those.
--
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: Alex Riesen @ 2006-04-03 14:38 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604030246q21fccb9ar93004ac67d8b28b3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On 4/3/06, Kees-Jan Dijkzeul <k.j.dijkzeul@gmail.com> wrote:
> I'm trying to get Git to manage a 5Gb source tree. Under linux, this
> works like a charm. Under cygwin, however, I run in to difficulties.
> For example:
>
> $ git-clone sgp-wa/ sgp-wa.clone
> fatal: packfile
> ./objects/pack/pack-56aa013a0234e198467ed37ae5db925764a6ee98.pack
> cannot be mapped.
> fatal: unexpected EOF
> fetch-pack from '/cygdrive/e/Projects/sgp-wa/.git' failed.
>
> To figure out what is happening, I printed the value of errno, which
> turns out to be 12 (Cannot allocate memory). I'm not sure how mmap is
mmap in git on cygwin does not mmaps anything,
but just reads the whole file in memory.
> I'm not sure how to approach this problem. Any tips would be greatly
> appreciated.
I ended up hacking gitfakemmap like in the attached patches (sorry for mime).
It's very ugly and unsafe hack, and it's actually exactly the reason why it was
never submitted. Still, it helps me (it speedups revlist, for
instance), and maybe
it'll help you.
It is a really good example what stupid windows restrictions can do to
a program.
The patch is against git as of 3-Apr-2005, ~10 CET
[-- Attachment #2: cygmmap.patch --]
[-- Type: text/x-patch, Size: 5710 bytes --]
diff --git a/Makefile b/Makefile
index c79d646..8a46436
--- a/Makefile
+++ b/Makefile
@@ -389,7 +389,7 @@ ifdef NO_SETENV
endif
ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
- COMPAT_OBJS += compat/mmap.o
+ COMPAT_OBJS += compat/mmap.o compat/realmmap.o
endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6
diff --git a/compat/realmmap.c b/compat/realmmap.c
new file mode 100644
index 0000000..8f26641
--- /dev/null
+++ b/compat/realmmap.c
@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <sys/mman.h>
+#include "../git-compat-util.h"
+
+#undef mmap
+#undef munmap
+
+void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
+{
+ if (start != NULL || !(flags & MAP_PRIVATE)) {
+ errno = ENOTSUP;
+ return MAP_FAILED;
+ }
+ start = mmap(start, length, prot, flags, fd, offset);
+ return start;
+}
+
+int realmunmap(void *start, size_t length)
+{
+ return munmap(start, length);
+}
+
+
diff --git a/diff.c b/diff.c
index e496905..f1a2cf0 100644
--- a/diff.c
+++ b/diff.c
@@ -450,7 +450,7 @@ int diff_populate_filespec(struct diff_f
fd = open(s->path, O_RDONLY);
if (fd < 0)
goto err_empty;
- s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
+ s->data = realmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (s->data == MAP_FAILED)
goto err_empty;
@@ -482,7 +482,7 @@ void diff_free_filespec_data(struct diff
if (s->should_free)
free(s->data);
else if (s->should_munmap)
- munmap(s->data, s->size);
+ realmunmap(s->data, s->size);
s->should_free = s->should_munmap = 0;
s->data = NULL;
free(s->cnt_data);
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..85150f8 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -42,22 +42,28 @@ extern int error(const char *err, ...) _
#ifdef NO_MMAP
-#ifndef PROT_READ
+#include <sys/mman.h>
+/*#ifndef PROT_READ
#define PROT_READ 1
#define PROT_WRITE 2
#define MAP_PRIVATE 1
#define MAP_FAILED ((void*)-1)
-#endif
+#endif*/
#define mmap gitfakemmap
#define munmap gitfakemunmap
extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
extern int gitfakemunmap(void *start, size_t length);
+extern void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int realmunmap(void *start, size_t length);
+
#else /* NO_MMAP */
#include <sys/mman.h>
+#define realmmap mmap
+#define realmunmap munmap
#endif /* NO_MMAP */
#ifdef NO_SETENV
diff --git a/sha1_file.c b/sha1_file.c
index 58edec0..712a068 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -330,14 +330,14 @@ void prepare_alt_odb(void)
close(fd);
return;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return;
link_alt_odb_entries(map, map + st.st_size, '\n',
get_object_directory());
- munmap(map, st.st_size);
+ realmunmap(map, st.st_size);
}
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
@@ -378,7 +378,7 @@ static int check_packed_git_idx(const ch
return -1;
}
idx_size = st.st_size;
- idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ idx_map = realmmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (idx_map == MAP_FAILED)
return -1;
@@ -423,7 +423,7 @@ static int unuse_one_packed_git(void)
}
if (!lru)
return 0;
- munmap(lru->pack_base, lru->pack_size);
+ realmunmap(lru->pack_base, lru->pack_size);
lru->pack_base = NULL;
return 1;
}
@@ -460,7 +460,7 @@ int use_packed_git(struct packed_git *p)
}
if (st.st_size != p->pack_size)
die("packfile %s size mismatch.", p->pack_name);
- map = mmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
die("packfile %s cannot be mapped.", p->pack_name);
@@ -494,7 +494,7 @@ struct packed_git *add_packed_git(char *
/* do we have a corresponding .pack file? */
strcpy(path + path_len - 4, ".pack");
if (stat(path, &st) || !S_ISREG(st.st_mode)) {
- munmap(idx_map, idx_size);
+ realmunmap(idx_map, idx_size);
return NULL;
}
/* ok, it looks sane as far as we can check without
@@ -647,7 +647,7 @@ static void *map_sha1_file_internal(cons
*/
sha1_file_open_flag = 0;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return NULL;
@@ -1184,7 +1184,7 @@ int sha1_object_info(const unsigned char
*sizep = size;
}
inflateEnd(&stream);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return status;
}
@@ -1210,7 +1210,7 @@ void * read_sha1_file(const unsigned cha
map = map_sha1_file_internal(sha1, &mapsize);
if (map) {
buf = unpack_sha1_file(map, mapsize, type, size);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return buf;
}
return NULL;
@@ -1493,7 +1493,7 @@ int write_sha1_to_fd(int fd, const unsig
} while (posn < objsize);
if (map)
- munmap(map, objsize);
+ realmunmap(map, objsize);
if (temp_obj)
free(temp_obj);
@@ -1646,7 +1646,7 @@ int index_fd(unsigned char *sha1, int fd
buf = "";
if (size)
- buf = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ buf = realmmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (buf == MAP_FAILED)
return -1;
@@ -1660,7 +1660,7 @@ int index_fd(unsigned char *sha1, int fd
ret = 0;
}
if (size)
- munmap(buf, size);
+ realmunmap(buf, size);
return ret;
}
^ permalink raw reply related
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 14:37 UTC (permalink / raw)
To: Erik Mouw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Mon, 2006-04-03 at 16:03 +0200, Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
> > The UI is a total disaster, sufficient for testing. You must create an
> > Authors file in the current directory which looks like the git-cvsimport
> > authors file. You must also have a edit-change-log program in your path
> > which edits the commit message in place. /bin/true will work if you
> > don't need to edit the messages.
> >
> > I should clearly steal the existing git-cvsimport command line arguments
> > and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
You can't. You need to create a local copy of the repository. There is a
tool which can do that using the cvs protocol, but I don't recall the
name.
It turns out that parsing the ,v files directly is both faster and more
accurate than attempting to interpret the output of cvs log.
--
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: Linus Torvalds @ 2006-04-03 14:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
On Mon, 3 Apr 2006, Linus Torvalds wrote:
>
> That said, I think git _does_ have problems with large pack-files. We have
> some 32-bit issues etc
I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
the packfile data structure does. The index has 32-bit offsets into
individual pack-files.
That's not hugely fundamental, but I didn't expect people to hit it this
quickly. What kind of project has a 1.5GB pack-file _already_? I hope it's
fifteen years of history (so that we'll have another fifteen years before
we'll have to worry about 4GB pack-files ;)
Linus
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Linus Torvalds @ 2006-04-03 14:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 3 Apr 2006, Johannes Schindelin wrote:
>
> The problem is not mmap() on cygwin, but that a fork() has to jump through
> loops to reinstall the open file descriptors on cygwin. If the
> corresponding file was deleted, that fails. Therefore, we work around that
> on cygwin by actually reading the file into memory, *not* mmap()ing it.
Well, we could actually do a _real_ mmap on pack-files. The pack-files are
much better mmap'ed - there we don't _want_ them to be removed while we're
using them. It was the index file etc that was problematic.
Maybe the cygwin fake mmap should be triggered only for the index (and
possibly the individual objects - if only because there doing a
malloc+read may actually be faster).
Using malloc+read on pack-files is pretty wasteful, since we usually only
use a very small part of them (ie if we have a 1.5GB pack-file, it's sad
to read all of it, when we'd usually actually access just a small small
fraction of it).
That said, I think git _does_ have problems with large pack-files. We have
some 32-bit issues etc, and just virtual address space things. So for now,
it's probably best to limit pack-files to the few-hundred-meg size, and
create serveral smaller ones rather than one huge one.
Linus
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Linus Torvalds @ 2006-04-03 14:29 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
On Mon, 3 Apr 2006, Sam Vilain wrote:
>
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
I really think that darcs is just "nice theory", and has nothing to do
with real life.
Terms like "patch calculus" may sound cool and useful, but let's face it,
the proof is in the pudding, and quite frankly, I would bet that trying to
do something like that on a real project would just be a total disaster.
I want my merges simple. I want them to take a couple of seconds. I don't
want to see strange patch dependencies that nobody cares about. And I very
much don't want to see theory over practice.
Linus
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Morten Welinder @ 2006-04-03 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
> The problem is not mmap() on cygwin, but that a fork() has to jump through
> loops to reinstall the open file descriptors on cygwin. If the
> corresponding file was deleted, that fails. Therefore, we work around that
> on cygwin by actually reading the file into memory, *not* mmap()ing it.
Maybe, but you aren't going to be able to handler much bigger packs
even on *nix. Unless you go 64-bit, that is.
M.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jakub Narebski @ 2006-04-03 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
>> The UI is a total disaster, sufficient for testing. You must create an
>> Authors file in the current directory which looks like the git-cvsimport
>> authors file. You must also have a edit-change-log program in your path
>> which edits the commit message in place. /bin/true will work if you
>> don't need to edit the messages.
>>
>> I should clearly steal the existing git-cvsimport command line arguments
>> and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
>From the comments on #git, parsecvs reads raw ,v files for creating history
tree, then uses 'cvs co ...' for getting the contents.
If you have access to remote CVS repository, it was suggested to use either
cvsclone or cvsup.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 14:03 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
> The UI is a total disaster, sufficient for testing. You must create an
> Authors file in the current directory which looks like the git-cvsimport
> authors file. You must also have a edit-change-log program in your path
> which edits the commit message in place. /bin/true will work if you
> don't need to edit the messages.
>
> I should clearly steal the existing git-cvsimport command line arguments
> and use those.
What is the current way to use it? I get the impression it reads raw ,v
files, but how do I get along with a remote CVS repository?
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 13:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
On Mon, Apr 03, 2006 at 09:25:54AM +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-04-02 21:10:56 -0700, Keith Packard <keithp@keithp.com> wrote:
> > I think this is a bug in your version of flex; I'm using standard lex
> > conventions here. I don't know how to make it work for you.
>
> It compiles for me with this patch (thanks to Linus for the hint):
>
> diff --git a/Makefile b/Makefile
[...]
> Would you please verify that it doesn't break things for you?
Almost there. I applied your patch and ran "make clean", but the
Makefile forgets to remove lex.c. Here's an updated patch:
diff --git a/Makefile b/Makefile
index 639353a..5651e70 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,8 @@ GCC_WARNINGS2=-Wmissing-prototypes -Wmis
GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)
CFLAGS=-O0 -g $(GCC_WARNINGS)
-YFLAGS=-d
+YFLAGS=-d -l
+LFLAGS=-l
SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c
@@ -20,4 +21,4 @@ lex.o: lex.c
y.tab.h: gram.c
clean:
- rm -f $(OBJS) y.tab.h gram.c parsecvs
+ rm -f $(OBJS) y.tab.h gram.c lex.c parsecvs
It compiles! Ship it! ;-)
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ 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