* stgit truncates binary files to zero length when applying patches
From: Karl Hasselström @ 2005-11-15 14:42 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
When applying patches and not fast-forwarding, stgit truncates the
binary files to zero length:
$ cg-init .
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as 73161b6ee428ac8b1c1b16b560c40e13330693d2.
$ stg init
$ stg new foo
Invoking the editor: "emacs .stgit.msg"... done (exit code: 0)
$ cp /bin/bash .
$ stg add bash
$ stg refresh
Refreshing patch "foo"... done
$ ls -l
total 584
-rwxr-xr-x 1 kha vtech 593304 Nov 15 15:34 bash*
$ stg pop
Popping patch "foo"... done
No patches applied
$ stg new bar
Invoking the editor: "emacs .stgit.msg"... done (exit code: 0)
$ echo bar > bar.txt
$ stg add bar.txt
$ stg refresh
Refreshing patch "bar"... done
$ stg push foo
Pushing patch "foo"... done
Now at patch "foo"
$ ls -l
total 4
-rw-r--r-- 1 kha vtech 4 Nov 15 15:34 bar.txt
-rwxr-xr-x 1 kha vtech 0 Nov 15 15:35 bash*
Without the "bar" patch, popping and then pushing "foo" works as
expected.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Chuck Lever @ 2005-11-15 15:29 UTC (permalink / raw)
To: Petr Baudis
Cc: Catalin Marinas, Martin Langhoff, Junio C Hamano, Ryan Anderson,
Linus Torvalds, git
In-Reply-To: <b0943d9e0511150204h25417993l@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
Catalin Marinas wrote:
> On 12/11/05, Petr Baudis <pasky@suse.cz> wrote:
>
>>On the same note, I would like StGIT to drop functionality not really
>>belonging to patch stack manager (stg add, stg rm, stg status, ...) so
>>that its commandset gets smaller and more focused
>
>
> This was the case with the first StGIT implementations but I slowly
> began to want to only use StGIT and not switch to something else for
> trivial SCM operations. I eventually added 'stg commit' which stores
> the patches permanently into the base of the stack to enable some kind
> of maintainer mode for StGIT. My main use for this was to import
> patches directly into the main branch and not keep a separate one and
> pull between them.
...
> Anyway, while I'll try not to add more SCM functionality to StGIT, I
> don't think I should remove the existing add/rm/status functionality.
> It's just handy not to use a different command when you want a new
> file added to a patch.
petr,
currently it isn't recommended to use StGIT with other porcelains.
so either: make it completely safe to use StGIT with other porcelains,
or add a minimal amount of SCM-like functionality so users don't miss it
and try to use other porcelains and trash their repositories.
overall i agree with catalin-- it's just easier to use a single tool.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9i aka 1.0rc2
From: walt @ 2005-11-15 15:26 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vr79isfy9.fsf@assigned-by-dhcp.cox.net>
On Mon, 14 Nov 2005, Junio C Hamano wrote:
> GIT 0.99.9i aka 1.0rc2 is found at usual places.
>
> I think the source-tree-wise almost everything is done except:
>
> - http-fetch file descriptor leak fix; I tried Nick's
> clean-ups, but haven't tried Pasky's patch yet. Walt reports
> neither patch fixed the problem. I wasted the weekend not
> being able to reproduce this myself, until Pasky reminded me
> that I have an old special code in git-clone, which was
> unrelated to this problem, but nevertheless was masking it.
So, you're saying that you have *not* fixed it? Hm. Using the
up-to-the-minute repository versions of cogito and git I can now
do a successful clone of the git repository with ulimit -n 64,
which I couldn't do two days ago. When I get home I'll try it
again on NetBSD also.
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Adrien Beau @ 2005-11-15 15:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de>
> Well, I can see no good reason for symrefs, except for backwards
> compatibility! Modern systems do support symlinks, you know?
What about less modern systems? I like to have tools that work on those, too.
> Let´s face it. The main target for git is not Windows users.
Yes, but they are a worthy secondary target.
> If we really want to support all idiocies of all possible ones,
I don't think we want that, but I don't think the symref vs. symlink
issue is an idiocy either.
> how about this one:
>
> If I clone a repository to a USB stick on cygwin, and try to access it
> from my iBook, it does not work, because for *backward compatibility*
> reasons, files fitting the 8.3 format are stored in UPPER CASE.
>
> So, I would like to have support for UPPER CASE files in .git, please? And
> since I cannot do my own testing, please could you force everybody´s git
> to write OBJECTS and MASTER in UPPER CASE?
Long and mixed-case filenames are supported almost universally. Why
aren't you using FAT32 on your USB key? Even that decade-old
filesystem supports them.
^ permalink raw reply
* fix git-pack-redundant crashing sometimes
From: Alex Riesen @ 2005-11-15 15:49 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, junkio
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
llist_sorted_difference_inplace didn't handle the match in the first
sha1 correctly and the lists went wild everywhere.
---
I noticed it on a very big repository (more than 100k files), trying
to prune it.
The code could profit from double-linked lists greatly, IMHO.
[-- Attachment #2: fix-pack-redundant.patch --]
[-- Type: application/xxxxx, Size: 421 bytes --]
^ permalink raw reply
* [PATCH] git-fsck-objects: Free tree entries after use
From: Sergey Vlasov @ 2005-11-15 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The Massif tool of Valgrind revealed that parsed tree entries occupy
more than 60% of memory allocated by git-fsck-objects. These entries
can be freed immediately after use, which significantly decreases
memory consumption.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
fsck-objects.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
applies-to: 4b6dbe856a3e63699b299c76f4f1fc5cb34cbe26
0742a20134cc7f58f2c4cbc982a3eb115c6eaf47
diff --git a/fsck-objects.c b/fsck-objects.c
index 17d0536..c1b279e 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -184,10 +184,17 @@ static int fsck_tree(struct tree *item)
default:
break;
}
+ free(last->name);
+ free(last);
}
last = entry;
}
+ if (last) {
+ free(last->name);
+ free(last);
+ }
+ item->entries = NULL;
retval = 0;
if (has_full_path) {
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Rework object refs tracking to reduce memory usage
From: Sergey Vlasov @ 2005-11-15 16:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Store pointers to referenced objects in a variable sized array instead
of linked list. This cuts down memory usage of utilities which use
object references; e.g., git-fsck-objects --full on the git.git
repository consumes about 2 MB of memory tracked by Massif instead of
7 MB before the change. Object refs are still the biggest consumer of
memory (57%), but the malloc overhead for a single block instead of a
linked list is substantially smaller.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
commit.c | 19 ++++++++++++++---
fsck-objects.c | 22 +++++++++++--------
object.c | 64 +++++++++++++++++++++++++++++++++++++++-----------------
object.h | 10 +++++++--
server-info.c | 25 ++++++++++++++++------
tag.c | 7 ++++--
tree.c | 13 +++++++++++
7 files changed, 117 insertions(+), 43 deletions(-)
applies-to: 4d3146cd52c79f88fcc08b542630cfe7394f5047
1ab535abd04f9150a9a7904d1459109211369f6c
diff --git a/commit.c b/commit.c
index ebf4db6..e867b86 100644
--- a/commit.c
+++ b/commit.c
@@ -204,6 +204,7 @@ int parse_commit_buffer(struct commit *i
unsigned char parent[20];
struct commit_list **pptr;
struct commit_graft *graft;
+ unsigned n_refs = 0;
if (item->object.parsed)
return 0;
@@ -214,7 +215,7 @@ int parse_commit_buffer(struct commit *i
return error("bad tree pointer in commit %s\n", sha1_to_hex(item->object.sha1));
item->tree = lookup_tree(parent);
if (item->tree)
- add_ref(&item->object, &item->tree->object);
+ n_refs++;
bufptr += 46; /* "tree " + "hex sha1" + "\n" */
pptr = &item->parents;
@@ -230,7 +231,7 @@ int parse_commit_buffer(struct commit *i
new_parent = lookup_commit(parent);
if (new_parent) {
pptr = &commit_list_insert(new_parent, pptr)->next;
- add_ref(&item->object, &new_parent->object);
+ n_refs++;
}
}
if (graft) {
@@ -241,10 +242,22 @@ int parse_commit_buffer(struct commit *i
if (!new_parent)
continue;
pptr = &commit_list_insert(new_parent, pptr)->next;
- add_ref(&item->object, &new_parent->object);
+ n_refs++;
}
}
item->date = parse_commit_date(bufptr);
+
+ if (track_object_refs) {
+ unsigned i = 0;
+ struct commit_list *p;
+ struct object_refs *refs = alloc_object_refs(n_refs);
+ if (item->tree)
+ refs->ref[i++] = &item->tree->object;
+ for (p = item->parents; p; p = p->next)
+ refs->ref[i++] = &p->item->object;
+ set_object_refs(&item->object, refs);
+ }
+
return 0;
}
diff --git a/fsck-objects.c b/fsck-objects.c
index c1b279e..0433a1d 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -56,7 +56,6 @@ static void check_connectivity(void)
/* Look up all the requirements, warn about missing objects.. */
for (i = 0; i < nr_objs; i++) {
struct object *obj = objs[i];
- struct object_list *refs;
if (!obj->parsed) {
if (!standalone && has_sha1_file(obj->sha1))
@@ -67,14 +66,19 @@ static void check_connectivity(void)
continue;
}
- for (refs = obj->refs; refs; refs = refs->next) {
- if (refs->item->parsed ||
- (!standalone && has_sha1_file(refs->item->sha1)))
- continue;
- printf("broken link from %7s %s\n",
- obj->type, sha1_to_hex(obj->sha1));
- printf(" to %7s %s\n",
- refs->item->type, sha1_to_hex(refs->item->sha1));
+ if (obj->refs) {
+ const struct object_refs *refs = obj->refs;
+ unsigned j;
+ for (j = 0; j < refs->count; j++) {
+ struct object *ref = refs->ref[j];
+ if (ref->parsed ||
+ (!standalone && has_sha1_file(ref->sha1)))
+ continue;
+ printf("broken link from %7s %s\n",
+ obj->type, sha1_to_hex(obj->sha1));
+ printf(" to %7s %s\n",
+ ref->type, sha1_to_hex(ref->sha1));
+ }
}
if (show_unreachable && !(obj->flags & REACHABLE)) {
diff --git a/object.c b/object.c
index 1fdebe0..427e14c 100644
--- a/object.c
+++ b/object.c
@@ -67,40 +67,66 @@ void created_object(const unsigned char
nr_objs++;
}
-void add_ref(struct object *refer, struct object *target)
+struct object_refs *alloc_object_refs(unsigned count)
{
- struct object_list **pp, *p;
+ struct object_refs *refs;
+ size_t size = sizeof(*refs) + count*sizeof(struct object *);
- if (!track_object_refs)
- return;
+ refs = xmalloc(size);
+ memset(refs, 0, size);
+ refs->count = count;
+ return refs;
+}
+
+static int compare_object_pointers(const void *a, const void *b)
+{
+ const struct object * const *pa = a;
+ const struct object * const *pb = b;
+ return *pa - *pb;
+}
+
+void set_object_refs(struct object *obj, struct object_refs *refs)
+{
+ unsigned int i, j;
- pp = &refer->refs;
- while ((p = *pp) != NULL) {
- if (p->item == target)
- return;
- pp = &p->next;
+ /* Do not install empty list of references */
+ if (refs->count < 1) {
+ free(refs);
+ return;
}
- target->used = 1;
- p = xmalloc(sizeof(*p));
- p->item = target;
- p->next = NULL;
- *pp = p;
+ /* Sort the list and filter out duplicates */
+ qsort(refs->ref, refs->count, sizeof(refs->ref[0]),
+ compare_object_pointers);
+ for (i = j = 1; i < refs->count; i++) {
+ if (refs->ref[i] != refs->ref[i - 1])
+ refs->ref[j++] = refs->ref[i];
+ }
+ if (j < refs->count) {
+ /* Duplicates were found - reallocate list */
+ size_t size = sizeof(*refs) + j*sizeof(struct object *);
+ refs->count = j;
+ refs = xrealloc(refs, size);
+ }
+
+ for (i = 0; i < refs->count; i++)
+ refs->ref[i]->used = 1;
+ obj->refs = refs;
}
void mark_reachable(struct object *obj, unsigned int mask)
{
- struct object_list *p = obj->refs;
-
if (!track_object_refs)
die("cannot do reachability with object refs turned off");
/* If we've been here already, don't bother */
if (obj->flags & mask)
return;
obj->flags |= mask;
- while (p) {
- mark_reachable(p->item, mask);
- p = p->next;
+ if (obj->refs) {
+ const struct object_refs *refs = obj->refs;
+ unsigned i;
+ for (i = 0; i < refs->count; i++)
+ mark_reachable(refs->ref[i], mask);
}
}
diff --git a/object.h b/object.h
index 6accda3..336d986 100644
--- a/object.h
+++ b/object.h
@@ -7,13 +7,18 @@ struct object_list {
const char *name;
};
+struct object_refs {
+ unsigned count;
+ struct object *ref[0];
+};
+
struct object {
unsigned parsed : 1;
unsigned used : 1;
unsigned int flags;
unsigned char sha1[20];
const char *type;
- struct object_list *refs;
+ struct object_refs *refs;
void *util;
};
@@ -35,7 +40,8 @@ struct object *parse_object(const unsign
/** Returns the object, with potentially excess memory allocated. **/
struct object *lookup_unknown_object(const unsigned char *sha1);
-void add_ref(struct object *refer, struct object *target);
+struct object_refs *alloc_object_refs(unsigned count);
+void set_object_refs(struct object *obj, struct object_refs *refs);
void mark_reachable(struct object *obj, unsigned int mask);
diff --git a/server-info.c b/server-info.c
index 0cba8e1..e4006f0 100644
--- a/server-info.c
+++ b/server-info.c
@@ -424,7 +424,6 @@ static void find_pack_info_one(int pack_
{
unsigned char sha1[20];
struct object *o;
- struct object_list *ref;
int i;
struct packed_git *p = info[pack_ix]->p;
int num = num_packed_objects(p);
@@ -437,8 +436,12 @@ static void find_pack_info_one(int pack_
die("corrupt pack file %s?", p->pack_name);
if ((o = lookup_object(sha1)) == NULL)
die("cannot parse %s", sha1_to_hex(sha1));
- for (ref = o->refs; ref; ref = ref->next)
- ref->item->flags = 0;
+ if (o->refs) {
+ struct object_refs *refs = o->refs;
+ int j;
+ for (j = 0; j < refs->count; j++)
+ refs->ref[j]->flags = 0;
+ }
o->flags = 0;
}
@@ -448,8 +451,12 @@ static void find_pack_info_one(int pack_
die("corrupt pack file %s?", p->pack_name);
if ((o = lookup_object(sha1)) == NULL)
die("cannot find %s", sha1_to_hex(sha1));
- for (ref = o->refs; ref; ref = ref->next)
- ref->item->flags |= REFERENCED;
+ if (o->refs) {
+ struct object_refs *refs = o->refs;
+ int j;
+ for (j = 0; j < refs->count; j++)
+ refs->ref[j]->flags |= REFERENCED;
+ }
o->flags |= INTERNAL;
}
@@ -460,8 +467,12 @@ static void find_pack_info_one(int pack_
die("cannot find %s", sha1_to_hex(sha1));
show(o, pack_ix);
- for (ref = o->refs; ref; ref = ref->next)
- show(ref->item, pack_ix);
+ if (o->refs) {
+ struct object_refs *refs = o->refs;
+ int j;
+ for (j = 0; j < refs->count; j++)
+ show(refs->ref[j], pack_ix);
+ }
}
}
diff --git a/tag.c b/tag.c
index e574c4b..61ac434 100644
--- a/tag.c
+++ b/tag.c
@@ -75,8 +75,11 @@ int parse_tag_buffer(struct tag *item, v
item->tag[taglen] = '\0';
item->tagged = lookup_object_type(object, type);
- if (item->tagged)
- add_ref(&item->object, item->tagged);
+ if (item->tagged && track_object_refs) {
+ struct object_refs *refs = alloc_object_refs(1);
+ refs->ref[0] = item->tagged;
+ set_object_refs(&item->object, refs);
+ }
return 0;
}
diff --git a/tree.c b/tree.c
index 315b6a5..8b42a07 100644
--- a/tree.c
+++ b/tree.c
@@ -148,6 +148,7 @@ int parse_tree_buffer(struct tree *item,
{
void *bufptr = buffer;
struct tree_entry_list **list_p;
+ int n_refs = 0;
if (item->object.parsed)
return 0;
@@ -184,11 +185,21 @@ int parse_tree_buffer(struct tree *item,
obj = &entry->item.blob->object;
}
if (obj)
- add_ref(&item->object, obj);
+ n_refs++;
entry->parent = NULL; /* needs to be filled by the user */
*list_p = entry;
list_p = &entry->next;
}
+
+ if (track_object_refs) {
+ struct tree_entry_list *entry;
+ unsigned i = 0;
+ struct object_refs *refs = alloc_object_refs(n_refs);
+ for (entry = item->entries; entry; entry = entry->next)
+ refs->ref[i++] = entry->item.any;
+ set_object_refs(&item->object, refs);
+ }
+
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: fix git-pack-redundant crashing sometimes
From: Timo Hirvonen @ 2005-11-15 16:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, lukass, junkio
In-Reply-To: <81b0412b0511150749g5672158v7b39c02ffdf13e08@mail.gmail.com>
On Tue, 15 Nov 2005 16:49:30 +0100
Alex Riesen <raa.lkml@gmail.com> wrote:
> llist_sorted_difference_inplace didn't handle the match in the first
> sha1 correctly and the lists went wild everywhere.
>
> ---
>
> I noticed it on a very big repository (more than 100k files), trying
> to prune it.
> The code could profit from double-linked lists greatly, IMHO.
I use list.h from Linux when I need double-linked lists. It is very
easy to use, efficient and fast.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Alex Riesen @ 2005-11-15 16:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, lukass, junkio
In-Reply-To: <20051115180848.561a6da5.tihirvon@gmail.com>
On 11/15/05, Timo Hirvonen <tihirvon@gmail.com> wrote:
> > The code could profit from double-linked lists greatly, IMHO.
>
> I use list.h from Linux when I need double-linked lists. It is very
> easy to use, efficient and fast.
>
Yes, I had it in mind, too.
^ permalink raw reply
* Re: [PATCH] git-core-foo -> git-foo, except the core package
From: H. Peter Anvin @ 2005-11-15 16:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: Git Mailing List
In-Reply-To: <625fc13d0511150641k353d7128pf72f3542da601104@mail.gmail.com>
Josh Boyer wrote:
> On 11/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
>
>>This patch renames the tarball "git" rather than "git-core", and changes
>>the names of various packages from git-core-foo to git-foo. git-core is
>>still the true core package; an empty RPM package named "git" pulls in
>>ALL the git packages -- this makes updates work correctly, and allows
>>"yum install git" to do the obvious thing.
>
> What about "yum remove git" ? I don't think that will work quite so
> well. The "git" package will be removed just fine since nothing
> depends on it, but git-<foo> will still remain. Maybe not that big of
> a deal, but it might not be obvious to some.
True. If you have a solution to that, I'd love to hear it. Note that
having the core package depend on everything else is not acceptable.
> Also, what about http://www.gnu.org/software/git/git.html ? I seem to
> recall that was the reason the name git-core was used in the first
> place.
It's changing its name to "gitfm".
-hpa
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-15 16:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, git
In-Reply-To: <tnxek5i42y5.fsf@arm.com>
On Tue, 2005-11-15 at 10:31 +0000, Catalin Marinas wrote:
> Pavel Roskin <proski@gnu.org> wrote:
> > In particular, StGIT still needs fixing.
>
> StGIT has been fixed for this in the latest snapshot (but not in the
> latest release). It now uses "git-symbolic-ref HEAD" to get the name
> of the current branch.
Indeed. I misinterpreted an error message.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-15 16:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:
> <yousortofaskedforit>
> Well, I can see no good reason for symrefs, except for backwards
> compatibility! Modern systems do support symlinks, you know?
You misunderstood me here. I meant backward compatibility with git
wrappers, not with old operating systems.
I meant, the only reason we don't want symrefs to be used by default is
because there are wrappers around git that only work with symlinks. So,
if we change the default behavior in git now, those wrappers will break
on new repositories.
> Let´s face it. The main target for git is not Windows users. If we really
> want to support all idiocies of all possible ones, how about this one:
>
> If I clone a repository to a USB stick on cygwin, and try to access it
> from my iBook, it does not work, because for *backward compatibility*
> reasons, files fitting the 8.3 format are stored in UPPER CASE.
>
> So, I would like to have support for UPPER CASE files in .git, please? And
> since I cannot do my own testing, please could you force everybody´s git
> to write OBJECTS and MASTER in UPPER CASE?
That was pretty funny :-)
Actually, what's different about symlinks is that they go beyond the
paradigm of one data stream per file. There are two data streams
accessible through the symlink, one being the data in the file it points
to, and the other being the path to that file.
This doesn't map well to many data transfer protocols. We don't want
git to work only over protocols that have explicit support for symlinks.
One example is http, sometimes the only protocol allowed to transcend
corporate firewalls.
Another, more controversial example is CVS. Sourceforge doesn't support
git, but I could store my git database in Sourceforge CVS, and thus
share it with other contributors. Not being able to put .git/HEAD there
would be an annoyance.
I believe Cygwin developers were actually more concerned about symlinks
damaged by SMB than about any issues with storing them locally. After
all, Cygwin is quite good at emulating POSIX, including symlinks.
Returning to your example, 8.3 format is a problem with storage. Those
are behind us. It's problems with transfer that are going to limit us.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-15 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Pavel Roskin, git
In-Reply-To: <20051115121854.GV30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Yes, I would very much like to have this. I still want to go
> symrefs-only for public repositories created for cg-admin-setuprepo, so
> that fetching over HTTP works properly.
Sorry, I must have missed that part. How does fetch-over-HTTP
break with symlinked HEAD?
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-15 17:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20051115121854.GV30496@pasky.or.cz>
On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:
> Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > I think Junio is right: we should not force everybody not to use symlinks,
> > only because there happens to be VFAT-, SMB- or HTTP-shared repositories.
> > As Junio says, if there are people experiencing problems because they lack
> > symbolic links, they should fix it.
>
> I'm ambivalent here. I would like to have just a single behaviour here,
> since the symbolic ref otherwise really does not get much testing. But I
> can also understand that we are breaking tools here.
>
> Still, for the reason above, I think we should aim at the symbolic refs
> being the canonical format in the next major release after 1.0, giving
> users time to fix their tools. I can see no advantage in symlinks except
> the backwards compatibility - speed argument was presented, but I don't
> buy that until I see hard data supporting that.
I planned to write about symrefs long ago, and probably I waited for too
long. I still hope it will be the default for 1.0 release, but if not,
I hope the next release won't be too far away.
> > On the other hand, I think it would be useful to be able to configure the
> > behaviour via .git/config.
>
> Yes, I would very much like to have this. I still want to go
> symrefs-only for public repositories created for cg-admin-setuprepo, so
> that fetching over HTTP works properly.
Agreed. By the way, the symref doesn't need to be called HEAD - it
could be "trunk" or "main" or "default-branch".
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [Question] info/grafts file.
From: Linus Torvalds @ 2005-11-15 17:16 UTC (permalink / raw)
To: Alan Chandler; +Cc: Junio C Hamano, git
In-Reply-To: <200511150831.40463.alan@chandlerfamily.org.uk>
On Tue, 15 Nov 2005, Alan Chandler wrote:
> On Tuesday 15 Nov 2005 00:03, Carl Baldwin wrote:
> > This is fine, I just needed to know.
> >
> > How hard is it to, in a generic way, take a grafts file and reconstruct
> > commits to include the parents in the graft file in the actual tree? I
> > am wondering because I couldn't, after much work, get git-svnimport to
> > find my merges correctly. So, I am needing to hand-graft some merges in
> > to make things right. Any suggestions? I could try to figure something
> > out if I can find some time. I'm good with graph traversals and such.
> >
>
> I am interested in that question as well. If you recall I was asking on this
> list about a week ago how to lose history (because it was irrelevent).
I think you should be able to use "git-convert-objects" to do both history
pruning and history adding.
It would need a bit of work: right now "convert_commit()" parses the
commit 100% by hand, and doesn't care about the grafts file. But that is
where such a conversion would be done.
Right now "convert_commit()" actually does the first conversion in-place
(because the size of the head of the commit never changes), and then calls
"convert_date()" which will allocate a new buffer and do the conversion
there - that's for totally stupid hysterical raisins, and it should really
have allocated the new buffer in convert_commit() - something you'd need
to do if you end up editing the "parent" information at that point.
So it would take some work, but the infrastructure for doing these kinds
of conversions is all there.
Linus
^ permalink raw reply
* Re: [PATCH] git-core-foo -> git-foo, except the core package
From: Josh Boyer @ 2005-11-15 17:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <437A09F2.8080109@zytor.com>
On 11/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
> Josh Boyer wrote:
> > On 11/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> >>This patch renames the tarball "git" rather than "git-core", and changes
> >>the names of various packages from git-core-foo to git-foo. git-core is
> >>still the true core package; an empty RPM package named "git" pulls in
> >>ALL the git packages -- this makes updates work correctly, and allows
> >>"yum install git" to do the obvious thing.
> >
> > What about "yum remove git" ? I don't think that will work quite so
> > well. The "git" package will be removed just fine since nothing
> > depends on it, but git-<foo> will still remain. Maybe not that big of
> > a deal, but it might not be obvious to some.
>
> True. If you have a solution to that, I'd love to hear it. Note that
> having the core package depend on everything else is not acceptable.
%preun section that does rpm -e of the packages it brings in. But
that is a hack that would cause some to become violently ill. Perhaps
it's an issue not worth worrying about.
>
> > Also, what about http://www.gnu.org/software/git/git.html ? I seem to
> > recall that was the reason the name git-core was used in the first
> > place.
>
> It's changing its name to "gitfm".
Sweet.
josh
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-15 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <7v8xvpn8ne.fsf@assigned-by-dhcp.cox.net>
On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Yes, I would very much like to have this. I still want to go
> > symrefs-only for public repositories created for cg-admin-setuprepo, so
> > that fetching over HTTP works properly.
>
> Sorry, I must have missed that part. How does fetch-over-HTTP
> break with symlinked HEAD?
With symlinks, cogito doesn't know which branch it is fetching if the
branch is not explicitly specified.
The old behavior was to fetch the "master" branch by default.
Currently, cogito uses HEAD, but it cannot read the symlink, it can only
read the SHA1. So, if somebody decides to use "cg-switch" on the public
repository (admittedly not a very good idea), all the clients that are
not using an explicit branch will unknowingly switch to another branch
upon update.
It also could be useful for users to know the branch name. I, for one,
would like to know if HEAD links to "stable" or "sandbox4crazyhacks",
even if both have the same SHA1 at the moment.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Linus Torvalds @ 2005-11-15 17:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: Timo Hirvonen, git, lukass, junkio
In-Reply-To: <81b0412b0511150811w2a7a2c4ft9a2920ac4f030ee4@mail.gmail.com>
On Tue, 15 Nov 2005, Alex Riesen wrote:
> On 11/15/05, Timo Hirvonen <tihirvon@gmail.com> wrote:
> > > The code could profit from double-linked lists greatly, IMHO.
> >
> > I use list.h from Linux when I need double-linked lists. It is very
> > easy to use, efficient and fast.
>
> Yes, I had it in mind, too.
There's a "ptrlist" implementation in sparse, which does a very
space-efficient implementation of arbitrary lists of pointers. It's also
very CPU-efficient (in fact, thanks to being very cache-friendly, more so
than the kernel list.h implementation) for most well-behaved operations
(ie it's not hugely friendly to removal, but it's great for "add to end"
and "traverse the list").
The ptrlist implementation is optimized for cases where the lists are
usually shortish, but not trivial. So they are worthwhile if you expect
the list length to be on the order of 5-10 entries rather than just 1-2
(if you have just a couple of entries, the kernel lists are better). But
perhaps more importantly, they are very space-efficient when the lists
grow bigger (ie they average to just about 5% over the memory cost of a
single pointer per list element for long lists).
Sparse in general is under the OSL license, but I'll happily dual-license
the ptrlist thing, it's trivial and all my code (and I already checked
with the person who did the list sorting code that we can dual-license
that too).
Linus
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Nick Hengeveld @ 2005-11-15 17:32 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <1132075295.25640.59.camel@dv>
On Tue, Nov 15, 2005 at 12:21:35PM -0500, Pavel Roskin wrote:
> > Sorry, I must have missed that part. How does fetch-over-HTTP
> > break with symlinked HEAD?
Symlinks can also be problematic for push-over-HTTP, since there are no
guarantees about the backend on the server (eg. pushing into a
subversion repo with mod_dav_svn.)
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Linus Torvalds @ 2005-11-15 17:33 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <1132075295.25640.59.camel@dv>
On Tue, 15 Nov 2005, Pavel Roskin wrote:
>
> With symlinks, cogito doesn't know which branch it is fetching if the
> branch is not explicitly specified.
>
> The old behavior was to fetch the "master" branch by default.
> Currently, cogito uses HEAD, but it cannot read the symlink, it can only
> read the SHA1.
Hmm? Why not just use "git-symbolic-ref HEAD" to figure it out? That works
with both symlinks and symrefs (and indeed, was added for that reason).
Linus
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Petr Baudis @ 2005-11-15 17:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0511150931010.3945@g5.osdl.org>
Dear diary, on Tue, Nov 15, 2005 at 06:33:44PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 15 Nov 2005, Pavel Roskin wrote:
> >
> > With symlinks, cogito doesn't know which branch it is fetching if the
> > branch is not explicitly specified.
> >
> > The old behavior was to fetch the "master" branch by default.
> > Currently, cogito uses HEAD, but it cannot read the symlink, it can only
> > read the SHA1.
>
> Hmm? Why not just use "git-symbolic-ref HEAD" to figure it out? That works
> with both symlinks and symrefs (and indeed, was added for that reason).
If you show me a way how to do git-symbolic-ref over HTTP, I will be
most grateful. :-)
Seriously though, if people have huge problem with having symbolic refs
by default, that's unfortunate since we have two possibilities which are
not equally tested, but I can live with it - just give me a way to
configure that behaviour per-repository, so that I can make GIT use
symbolic refs in public repositories (or I can whip up a patch myself at
the evening, after all...).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Linus Torvalds @ 2005-11-15 18:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20051115174213.GO16061@pasky.or.cz>
On Tue, 15 Nov 2005, Petr Baudis wrote:
>
> If you show me a way how to do git-symbolic-ref over HTTP, I will be
> most grateful. :-)
Hmm, why do you care?
If you do a fetch over http, you'd just fetch HEAD directly. If that's
just a SHA1 (like it will be with a symlink) you'll just use that as the
branch (and don't care about what branch it was). And if it's a symref,
you can see what the branch should be and fetch that. No?
Linus
^ permalink raw reply
* Re: [PATCH] git-core-foo -> git-foo, except the core package
From: Andreas Ericsson @ 2005-11-15 18:05 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <625fc13d0511150919l48786dcam6fda56bc9d3a9fa0@mail.gmail.com>
Josh Boyer wrote:
> On 11/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
>
>>Josh Boyer wrote:
>>
>>>What about "yum remove git" ? I don't think that will work quite so
>>>well. The "git" package will be removed just fine since nothing
>>>depends on it, but git-<foo> will still remain. Maybe not that big of
>>>a deal, but it might not be obvious to some.
>>
>>True. If you have a solution to that, I'd love to hear it. Note that
>>having the core package depend on everything else is not acceptable.
>
>
> %preun section that does rpm -e of the packages it brings in. But
> that is a hack that would cause some to become violently ill. Perhaps
> it's an issue not worth worrying about.
>
Less puky while bringing some obviousity:
%preun
echo "To get rid of git completely, yada yada (real instructions)."
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Add config variable core.symrefsonly
From: Johannes Schindelin @ 2005-11-15 18:24 UTC (permalink / raw)
To: git, junkio
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2808 bytes --]
This allows you to force git to avoid symlinks for refs. Just add
something like
[core]
symrefsonly = true
to .git/config.
Don´t forget to "git checkout your_branch", or it does not do anything...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Linus, is there any reason you don´t allow spaces, underscores
and dashes in the config variables?
Petr, happy?
cache.h | 1 +
config.c | 5 +++++
environment.c | 1 +
refs.c | 10 ++++++----
symbolic-ref.c | 1 +
5 files changed, 14 insertions(+), 4 deletions(-)
applies-to: 4b6dbe856a3e63699b299c76f4f1fc5cb34cbe26
b12e60607e70f01de9dc65b88f15c9b17f7be4c5
diff --git a/cache.h b/cache.h
index 677c6ac..9a6bfb9 100644
--- a/cache.h
+++ b/cache.h
@@ -179,6 +179,7 @@ extern int commit_index_file(struct cach
extern void rollback_index_file(struct cache_file *);
extern int trust_executable_bit;
+extern int only_use_symrefs;
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
diff --git a/config.c b/config.c
index e89bab2..bd35138 100644
--- a/config.c
+++ b/config.c
@@ -214,6 +214,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.symrefsonly")) {
+ only_use_symrefs = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
strncpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 1dc7af5..b5026f1 100644
--- a/environment.c
+++ b/environment.c
@@ -12,6 +12,7 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
+int only_use_symrefs = 0;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
diff --git a/refs.c b/refs.c
index a52b038..f324be5 100644
--- a/refs.c
+++ b/refs.c
@@ -121,10 +121,12 @@ int create_symref(const char *git_HEAD,
int fd, len, written;
#if USE_SYMLINK_HEAD
- unlink(git_HEAD);
- if (!symlink(refs_heads_master, git_HEAD))
- return 0;
- fprintf(stderr, "no symlink - falling back to symbolic ref\n");
+ if (!only_use_symrefs) {
+ unlink(git_HEAD);
+ if (!symlink(refs_heads_master, git_HEAD))
+ return 0;
+ fprintf(stderr, "no symlink - falling back to symbolic ref\n");
+ }
#endif
len = snprintf(ref, sizeof(ref), "ref: %s\n", refs_heads_master);
diff --git a/symbolic-ref.c b/symbolic-ref.c
index a72d7ac..193c87c 100644
--- a/symbolic-ref.c
+++ b/symbolic-ref.c
@@ -20,6 +20,7 @@ static void check_symref(const char *HEA
int main(int argc, const char **argv)
{
setup_git_directory();
+ git_config(git_default_config);
switch (argc) {
case 2:
check_symref(argv[1]);
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] git-core-foo -> git-foo, except the core package
From: H. Peter Anvin @ 2005-11-15 18:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: Git Mailing List
In-Reply-To: <625fc13d0511150919l48786dcam6fda56bc9d3a9fa0@mail.gmail.com>
Josh Boyer wrote:
>>
>>True. If you have a solution to that, I'd love to hear it. Note that
>>having the core package depend on everything else is not acceptable.
>
> %preun section that does rpm -e of the packages it brings in. But
> that is a hack that would cause some to become violently ill. Perhaps
> it's an issue not worth worrying about.
>
%postun, but yes, that sounds pretty sick to me. The Fedora people
might disagree, in which case let them lead and we can follow suit.
-hpa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox