* Re: [PATCH] Small script to patch .spec for Suse
From: H. Peter Anvin @ 2005-11-15 22:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <20051115215943.GW30496@pasky.or.cz>
Petr Baudis wrote:
>
> Actually, can you have some kind of %if in specfiles? Then you could
> keep everything in the specfile and just pass it whatever system you
> want to build for.
>
Sure. It's called %if. There is also %ifdef and %define.
-hpa
^ permalink raw reply
* Deprecate --cache.* ?
From: Lukas Sandström @ 2005-11-15 22:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Currently, most of the remaining references to "cache" in Documantation/
are related to the --cache.* flag of four git commands.
git-dif-*index* uses --cached to mean "do not consider on-disk files at all"
git-fsck-objects uses --cache to consider index entries as head nodes for
unreachability traces.
git-ls-files --cached shows all files recorded in the index.
git-update-*index* --cacheinfo is used to place a "fake" entry in the index
git-update-index also has the option --index-info which does something different.
My suggestion is that these cache-references be deprecated in favor of
--index, --in-index, --index-only, --insert-index, or something along those lines.
Backward compability could be ensured by having both versions of the flags
around for a while and issuing a warning when the old form is used.
Good idea? Bad? Stupid? Do we want to keep "cache" around?
^ permalink raw reply
* Re: [RFC] Add support for short help to Cogito commands
From: Petr Baudis @ 2005-11-15 22:17 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20051115125516.GD13925@diku.dk>
Hi,
Dear diary, on Tue, Nov 15, 2005 at 01:55:16PM CET, I got a letter
where Jonas Fonseca <fonseca@diku.dk> said that...
> I hope I am not the only one feeling that -h can sometimes be a little
> too verbose when you want to have a quick overview of a Cogito command.
> I'd like to make -h show only a short summary of the available options
> and keep the longer help text for --help. I have attached a patch that
> does something like this. Example:
Good idea. Perhaps even make this default for --help as well and offer
--long-help. cg-help would still default to the long help, unless -s or
something would be passed to it.
> - Add a special line with the caption. Since we already 'filters' the
> help text in the script headers this could go after the '::'.
> Example:
>
> # ...
> #
> # -r FROM_ID[..TO_ID]:: Specify revisions to diff
> # Specify the revisions to diff using either '-r rev1
> # ...
>
> So that it will be easy to remove from the --help output and from the
> generated manpages.
>
> The last option is less intrusive, but does make the syntax of the
> script headers less clean. Comments?
I prefer the second option and don't think it's much less clean. I think
it would be actually uglier the other way - strange without separating
empty line, too long with the separating line.
--
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] Small script to patch .spec for Suse
From: Petr Baudis @ 2005-11-15 21:59 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <437A46E4.5010909@zytor.com>
Dear diary, on Tue, Nov 15, 2005 at 09:36:52PM CET, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> Junio C Hamano wrote:
> >
> >I've applied the patch from HPA to update it to git.spec already
> >in my tree, so your script would not work any more ;-)
> >
> >But seriously, I suspect we should take a hint from the fact
> >that "git.spec.in" has ".in" in its name already.
> >
>
> I'd prefer to have just @@OPENSSH_PACKAGE@@ and @@EXPAT_PACKAGE@@
> instead of completely virtualizing the dependencies. Less flexible to
> be sure, but it makes it less confusing to read and fix.
Actually, can you have some kind of %if in specfiles? Then you could
keep everything in the specfile and just pass it whatever system you
want to build for.
--
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] Small script to patch .spec for Suse
From: Andreas Ericsson @ 2005-11-15 21:56 UTC (permalink / raw)
To: git
In-Reply-To: <437A46E4.5010909@zytor.com>
H. Peter Anvin wrote:
>
> I'd prefer to have just @@OPENSSH_PACKAGE@@ and @@EXPAT_PACKAGE@@
> instead of completely virtualizing the dependencies. Less flexible to
> be sure, but it makes it less confusing to read and fix.
>
git doesn't, strictly speaking, require openssh, for two reasons;
a. It's been known to work equally well over rsh.
b. ssh is run as an executed command. ssh can be installed later and the
previously installed git will start working just like magic.
If you really *want* an openssh requirement, you should just go with
Requires: /usr/bin/ssh
It's the most accurate one after all, since git doesn't really care
which package it came from so long as it's there.
As for BuildRequires, I think package maintainers can be trusted to
figure those out for themselves. It's not as if they'll be producing
flawed RPM's after all.
If you want one for expat anyways, then go with
BuildRequires: expat
since that's true for both dists (and FC maintainers will then happily
figure out that they need expat-devel to build it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Small script to patch .spec for Suse
From: Junio C Hamano @ 2005-11-15 21:47 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Josef Weidendorfer, git
In-Reply-To: <437A46E4.5010909@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>> I've applied the patch from HPA to update it to git.spec already
>> in my tree, so your script would not work any more ;-)
>> But seriously, I suspect we should take a hint from the fact
>> that "git.spec.in" has ".in" in its name already.
>>
>
> I'd prefer to have just @@OPENSSH_PACKAGE@@ and @@EXPAT_PACKAGE@@
> instead of completely virtualizing the dependencies. Less flexible to
> be sure, but it makes it less confusing to read and fix.
Sounds good.
^ permalink raw reply
* Re: A case for tailor
From: Johannes Schindelin @ 2005-11-15 21:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511151259l51d13181j670274e123d7610f@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 488 bytes --]
Hi,
On Wed, 16 Nov 2005, Martin Langhoff wrote:
> The short of it is that tailor won't do branches. So for trivial
> single-line-of-development projects, you're fine with it, probably
> even happier than with our import scripts. Sadly, none of the
> projects I've worked in the last 6 years fall into that category ;-)
I wasn´t aware of that. However, I am luckier than you are: only a few
release+bugfix branches, none of which are of interest right now.
Ciao,
Dscho
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Lukas Sandström @ 2005-11-15 21:41 UTC (permalink / raw)
To: Alex Riesen, git; +Cc: junkio
In-Reply-To: <20051115213442.GA4256@steel.home>
Alex Riesen wrote:
> Alex Riesen, Tue, Nov 15, 2005 16:49:30 +0100:
>
>>llist_sorted_difference_inplace didn't handle the match in the first
>>sha1 correctly and the lists went wild everywhere.
>
>
> This wasn't enough. It never (>5 min on 2.4GHz PIV) finishes on
> my local mirror of git, which has 22 packs by now.
>
If the patch I just sent out doesn't fix the problem, and you don't
want to debug it yourself, could you please publish the .idx files
so I could have a look at them?
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Lukas Sandström @ 2005-11-15 21:38 UTC (permalink / raw)
To: git; +Cc: Timo Hirvonen, junkio
In-Reply-To: <20051115180848.561a6da5.tihirvon@gmail.com>
Timo Hirvonen wrote:
> 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.
>
Well, well. Live and learn I suppose. I have never heard of it before.
How portable is it to #include <linux/list.h>? (non-rethorical)
Would there be a performance benefit from doubly-linked list or would
it just simplify parts of the code? My first implementation used d-lists,
but I dropped the ->prev when I realised it was never used.
^ permalink raw reply
* [PATCH 3/3] Add option --only-use-symrefs to git-init-db
From: Johannes Schindelin @ 2005-11-15 21:37 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
init-db.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
applies-to: 5ba4aa2c83265b321ccebc0e4f24707cdd577794
7089086c9c77ac61f1e59d3382eda7b65a5dc687
diff --git a/init-db.c b/init-db.c
index b62ee72..7019109 100644
--- a/init-db.c
+++ b/init-db.c
@@ -215,7 +215,7 @@ static void create_default_files(const c
}
static const char init_db_usage[] =
-"git-init-db [--template=<template-directory>]";
+"git-init-db [--template=<template-directory>] [--only-use-symrefs]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -236,6 +236,8 @@ int main(int argc, char **argv)
break;
else if (!strncmp(arg, "--template=", 11))
template_dir = arg+11;
+ else if (!strcmp(arg, "--only-use-symrefs"))
+ only_use_symrefs = 1;
else
die(init_db_usage);
}
@@ -264,5 +266,9 @@ int main(int argc, char **argv)
safe_create_dir(path);
strcpy(path+len, "/info");
safe_create_dir(path);
+
+ if (only_use_symrefs)
+ git_config_set("core.SymrefsOnly", "true");
+
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/3] Add git-config-set, a simple helper for scripts to set config variables
From: Johannes Schindelin @ 2005-11-15 21:36 UTC (permalink / raw)
To: git, junkio
This is meant for the end user, who cannot be expected to edit
.git/config by hand.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Makefile | 3 ++-
config-set.c | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
create mode 100644 config-set.c
applies-to: 182b0cedc3aa9a6d4afb3331a9c9472306cf77c6
ef6b137c5b90c3d0cba100d39b0fd7ed9de0dad8
diff --git a/Makefile b/Makefile
index d20cf66..55f4d44 100644
--- a/Makefile
+++ b/Makefile
@@ -125,7 +125,8 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- git-name-rev$X git-pack-redundant$X $(SIMPLE_PROGRAMS)
+ git-name-rev$X git-pack-redundant$X git-config-set$X \
+ $(SIMPLE_PROGRAMS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
diff --git a/config-set.c b/config-set.c
new file mode 100644
index 0000000..fe024da
--- /dev/null
+++ b/config-set.c
@@ -0,0 +1,16 @@
+#include "cache.h"
+
+static const char git_config_set_usage[] =
+"git-config-set name value";
+
+int main(int argc, const char **argv)
+{
+ setup_git_directory();
+ switch (argc) {
+ case 3:
+ return git_config_set(argv[1], argv[2]);
+ default:
+ usage(git_config_set_usage);
+ }
+ return 0;
+}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/3] Add function git_config_set()
From: Johannes Schindelin @ 2005-11-15 21:36 UTC (permalink / raw)
To: git, junkio
This function does exactly what you think it does. Given a key and a value,
it sets the key (in the form "core.filemode") to the value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
cache.h | 1
config.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 146 insertions(+), 0 deletions(-)
applies-to: a54ecd1a81180a8d860a6554e6fc71dcab3327ef
c38f654a4387ed503a8ea445824e49b44a796c61
diff --git a/cache.h b/cache.h
index 9a6bfb9..91070ae 100644
--- a/cache.h
+++ b/cache.h
@@ -384,6 +384,7 @@ extern int git_default_config(const char
extern int git_config(config_fn_t fn);
extern int git_config_int(const char *, const char *);
extern int git_config_bool(const char *, const char *);
+extern int git_config_set(const char *, const char *);
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
diff --git a/config.c b/config.c
index bd35138..1b39290 100644
--- a/config.c
+++ b/config.c
@@ -247,3 +247,148 @@ int git_config(config_fn_t fn)
}
return ret;
}
+
+static struct {
+ int baselen;
+ const char* key;
+ const char* value;
+ off_t offset;
+ enum { START, SECTION_SEEN, SECTION_END_SEEN, KEY_SEEN } state;
+} store;
+
+static int store_aux(const char* key, const char* value)
+{
+ switch (store.state) {
+ case KEY_SEEN:
+ if (!strcmp(key, store.key))
+ store.offset = ftell(config_file);
+ break;
+ case SECTION_SEEN:
+ if (strncmp(key, store.key, store.baselen+1)) {
+ store.offset = ftell(config_file);
+ store.state = SECTION_END_SEEN;
+ break;
+ }
+ case SECTION_END_SEEN:
+ case START:
+ if (!strcmp(key, store.key)) {
+ store.offset = ftell(config_file);
+ store.state = KEY_SEEN;
+ } else if(!strncmp(key, store.key, store.baselen))
+ store.state = SECTION_SEEN;
+ }
+ return 0;
+}
+
+static void store_write_section(int fd)
+{
+ write(fd, "[", 1);
+ write(fd, store.key, store.baselen);
+ write(fd, "]\n", 2);
+}
+
+static void store_write_pair(int fd)
+{
+ int i;
+
+ write(fd, "\t", 1);
+ write(fd, store.key+store.baselen+1,
+ strlen(store.key+store.baselen+1));
+ write(fd, " = ", 3);
+ for (i = 0; store.value[i]; i++)
+ switch (store.value[i]) {
+ case '\n': write(fd, "\\n", 2); break;
+ case '\t': write(fd, "\\t", 2); break;
+ case '"': case '\\': write(fd, "\\", 1);
+ default: write(fd, store.value+i, 1);
+ }
+ write(fd, "\n", 1);
+}
+
+int git_config_set(const char* key, const char* value)
+{
+ int i;
+ struct stat st;
+ int fd;
+ char* config_file = strdup(git_path("config"));
+ char* lock_file = strdup(git_path("config.lock"));
+
+ for (store.baselen = 0;
+ key[store.baselen] != '.' && key[store.baselen];
+ store.baselen++);
+ if (!key[store.baselen]) {
+ fprintf(stderr, "key does not contain a section: %s\n", key);
+ return 2;
+ }
+
+ for (i = 0; key[i]; i++)
+ if (i != store.baselen && !isalpha(key[i])) {
+ fprintf(stderr, "invalid key: %s\n", key);
+ return 1;
+ }
+
+ store.key = key;
+ store.value = value;
+
+ fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ if (fd < 0) {
+ fprintf(stderr, "could not lock config file\n");
+ return -1;
+ }
+
+ if (stat(config_file, &st)) {
+ /* write new file */
+ static const char contents[] =
+ "#\n"
+ "# This is the config file\n"
+ "#\n"
+ "\n";
+
+ write(fd, contents, sizeof(contents)-1);
+ store_write_section(fd);
+ store_write_pair(fd);
+ } else{
+ int in_fd;
+ char* contents;
+ int offset;
+
+ store.offset = 0;
+ store.state = START;
+
+ if (git_config(store_aux)) {
+ fprintf(stderr, "invalid config file\n");
+ return 3;
+ }
+
+ in_fd = open(config_file, O_RDONLY, 0666);
+ contents = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, in_fd, 0);
+ close(in_fd);
+
+ if (store.offset == 0)
+ offset = st.st_size;
+ else {
+ for (offset = store.offset-2; offset > 0
+ && contents[offset] != '\n'; offset--);
+ offset++;
+ }
+ write(fd, contents, offset);
+ if (store.state == START)
+ store_write_section(fd);
+ store_write_pair(fd);
+ if (store.offset > offset)
+ write(fd, contents + store.offset,
+ st.st_size - store.offset);
+
+ unlink(config_file);
+ }
+
+ close(fd);
+
+ if (rename(lock_file, config_file) < 0) {
+ fprintf(stderr, "Could not rename the lock file?\n");
+ return 4;
+ }
+
+ return 0;
+}
+
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/3] Support setting SymrefsOnly=true from scripts
From: Johannes Schindelin @ 2005-11-15 21:36 UTC (permalink / raw)
To: git, junkio
Hi,
this series of patches does three things:
- support for setting config variables
- ditto, but from scripts
- set SymrefsOnly=true right from the start with
git-init-db --dont-use-symrefs
Ciao,
Dscho
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Alex Riesen @ 2005-11-15 21:34 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, junkio
In-Reply-To: <81b0412b0511150749g5672158v7b39c02ffdf13e08@mail.gmail.com>
Alex Riesen, Tue, Nov 15, 2005 16:49:30 +0100:
> llist_sorted_difference_inplace didn't handle the match in the first
> sha1 correctly and the lists went wild everywhere.
This wasn't enough. It never (>5 min on 2.4GHz PIV) finishes on
my local mirror of git, which has 22 packs by now.
^ permalink raw reply
* [PATCH] Fix llist_sorted_difference_inplace in git-pack-redundant
From: Lukas Sandström @ 2005-11-15 21:24 UTC (permalink / raw)
To: junkio; +Cc: Alex Riesen, git, Lukas Sandström
In-Reply-To: <81b0412b0511150749g5672158v7b39c02ffdf13e08@mail.gmail.com>
Simplify and actually make llist_sorted_difference_inplace work
by using llist_sorted_remove instead of duplicating parts of the
code.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
Looking at the code; I must have been tired when I wrote llist_sorted_difference_inplace.
This should hopefully fix things up nicely. Note that I think the old version got the
case "remove last element from list" wrong too.
I think the Signed-off line is in utf8 this time. Tell me if it works better, of if I
just should change my name ;)
pack-redundant.c | 47 +++++++++++++++--------------------------------
1 files changed, 15 insertions(+), 32 deletions(-)
applies-to: 4b6dbe856a3e63699b299c76f4f1fc5cb34cbe26
560aa97889ef028fed0678389d4bb05ebf3ead62
diff --git a/pack-redundant.c b/pack-redundant.c
index 28b82ee..fcb36ff 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -127,38 +127,6 @@ inline struct llist_item * llist_insert_
return llist_insert_back(list, sha1);
}
-/* computes A\B */
-void llist_sorted_difference_inplace(struct llist *A,
- struct llist *B)
-{
- struct llist_item *prev, *a, *b, *x;
-
- prev = a = A->front;
- b = B->front;
-
- while (a != NULL && b != NULL) {
- int cmp = memcmp(a->sha1, b->sha1, 20);
- if (!cmp) {
- x = a;
- if (a == A->front)
- A->front = a->next;
- a = prev->next = a->next;
-
- if (a == NULL) /* end of list */
- A->back = prev;
- A->size--;
- free(x);
- b = b->next;
- } else
- if (cmp > 0)
- b = b->next;
- else {
- prev = a;
- a = a->next;
- }
- }
-}
-
/* returns a pointer to an item in front of sha1 */
inline struct llist_item * llist_sorted_remove(struct llist *list, char *sha1,
struct llist_item *hint)
@@ -194,6 +162,21 @@ redo_from_start:
return prev;
}
+/* computes A\B */
+void llist_sorted_difference_inplace(struct llist *A,
+ struct llist *B)
+{
+ struct llist_item *hint, *b;
+
+ hint = NULL;
+ b = B->front;
+
+ while (b) {
+ hint = llist_sorted_remove(A, b->sha1, hint);
+ b = b->next;
+ }
+}
+
inline struct pack_list * pack_list_insert(struct pack_list **pl,
struct pack_list *entry)
{
---
0.99.9.GIT
^ permalink raw reply related
* Re: A case for tailor
From: Martin Langhoff @ 2005-11-15 20:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511151931001.1157@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/16/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Just wanted to let people know...
I've checked out tailor a while ago, and it seems a quite capable
tool. Even bounced a few emails with the author, because I thought
that we could perhaps deprecate our imports scripts. It _is_ good, and
seems to have a cool community around it.
The short of it is that tailor won't do branches. So for trivial
single-line-of-development projects, you're fine with it, probably
even happier than with our import scripts. Sadly, none of the
projects I've worked in the last 6 years fall into that category ;-)
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Small script to patch .spec for Suse
From: H. Peter Anvin @ 2005-11-15 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vfypxlp8k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I've applied the patch from HPA to update it to git.spec already
> in my tree, so your script would not work any more ;-)
>
> But seriously, I suspect we should take a hint from the fact
> that "git.spec.in" has ".in" in its name already.
>
I'd prefer to have just @@OPENSSH_PACKAGE@@ and @@EXPAT_PACKAGE@@
instead of completely virtualizing the dependencies. Less flexible to
be sure, but it makes it less confusing to read and fix.
-hpa
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-15 18:21 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <1132074375.25640.47.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:
>>
>> 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...
The voice of reason comes from Pasky; I agree with this.
> 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.
I think it is a bit too late for that, but please keep that
patch; I'll hold on to it too.
>> > 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 am in favor of that. Something like this, perhaps:
core.filemode = 1 # trustworthy
core.usesymlink = 0 # new style
> Agreed. By the way, the symref doesn't need to be called HEAD - it
> could be "trunk" or "main" or "default-branch".
Actually, I was thinking about changing get_sha1_basic() in
sha1_name.c so that refs immediately under ${GIT_DIR-.git} are
restricted to uppercase only. The other day I did
$ git-update-ref linus blah
which created .git/linus in addition to .git/refs/heads/linus;
this gives you considerable confusion.
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Junio C Hamano @ 2005-11-15 19:03 UTC (permalink / raw)
To: Mike McCormack; +Cc: git, Martin Langhoff
In-Reply-To: <4379B9F6.5020402@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> We have a (semi-experimental) wine.git tree, which is updated at the
> same time as the Wine CVS, by the project maintainer:
>
> http://source.winehq.org/git/wine.git
Wow. How is the acceptance by wine community? Favorable, I
hope.
It would be nice before 1.0 happens to have a list of publicly
visible projects and people who use git as part of the workflow;
the degree would vary per project, from using it as the primary
repository (the kernel, I guess) to merely accessible with git.
> It will probably be maintained in parallel with the Wine CVS for a
> while, unless somebody writes a GIT->CVS gateway.
git-cvsexportcommit? I haven't had a chance to use it myself,
although I have to interoperate with CVS in some projects.
Martin, do you want to do a plug (or brag) here?
> I find git-rebase to be particularly useful.
It is handy, especially for simple things like rebasing topic
branches, when the things are of managable size without using
quilt or StGIT. Do you manage binary files?
> Pushing patches from git into a drafts folder means I don't have to
> manually generate a diff, open a mail, type the mailing list address,
> attach the patch and write/copy-paste a ChangeLog entry.
Yes, I saw that value there. Maybe adding hooks to format-patch
so that it can do form-letter-ish things you had to add there
without patching might help? I dunno.
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-15 18:13 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <1132075295.25640.59.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> 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.
Ah, thanks.
git-clone-pack has the same problem. It basically "guesses" by:
- If the master branch exists, and the object name of
the branch tip matches the object name of HEAD, assume
HEAD points at master. Even when there are other
branches that happen to share the same branch head.
- Otherwise, if there is a branch whose tip matches the
object name of HEAD, assume HEAD points at it. It
just picks "one-of-them" if more than one branches
match.
- If there is no branch that matches HEAD, issue a
warning and create HEAD that records the object name,
not pointing anywhere.
To solve this generally we would need to extend what ls-remote
returns, I suppose.
^ permalink raw reply
* Re: [PATCH] Add config variable core.symrefsonly
From: Johannes Schindelin @ 2005-11-15 18:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0511151028540.3945@g5.osdl.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 460 bytes --]
Hi,
On Tue, 15 Nov 2005, Linus Torvalds wrote:
> On Tue, 15 Nov 2005, Johannes Schindelin wrote:
> >
> > Linus, is there any reason you don´t allow spaces, underscores
> > and dashes in the config variables?
>
> [...]
>
> PrettyCase is for toys [...] And ini files are PC: it's more important
> that a config file is human-readable than it is that it's very precise
> and strict.
Thanks for the explanation. Makes sense.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Small script to patch .spec for Suse
From: Junio C Hamano @ 2005-11-15 18:50 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511151230.30030.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Everytime I update and want to generate RPM packages for
> my Suse distribution, I have to patch the git-core.spec.in
> Here is the current script for patching. It is only about
> package names, so a seperate .spec file would
> be overkill and a maintenance problem for me.
I've applied the patch from HPA to update it to git.spec already
in my tree, so your script would not work any more ;-)
But seriously, I suspect we should take a hint from the fact
that "git.spec.in" has ".in" in its name already.
Right now, git.spec is generated with this:
git.spec: git.spec.in Makefile
sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
So presumably you could do something like this:
--- git.spec.in
+++ git.spec.in
@@ -9,3 +9,3 @@
Source: http://kernel.org/pub/software/scm/git/%{name}-%{...
-BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, exp...
+BuildRequires: @@BUILD_REQUIRES@@
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(...
@@ -26,3 +26,3 @@
Group: Development/Tools
-Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clie...
+Requires: @@CORE_REQUIRES@@
%description core
@@ -40,3 +40,3 @@
Group: Development/Tools
-Requires: git-core = %{version}-%{release}, subversion
+Requires: git-core = %{version}-%{release}, @@SVN_REQUIRES@@
%description svn
@@ -47,3 +47,3 @@
Group: Development/Tools
-Requires: git-core = %{version}-%{release}, cvs, cvsps
+Requires: git-core = %{version}-%{release}, @@CVS_REQUIRES@@
...
and have something like this in the Makefile when you munge
git.spec.in to produce git.spec for use with rpmbuild?
RPM_BUILD_REQUIRES = zlib-devel >= 1.2 openssl-devel ...
RPM_CORE_REQUIRES = zlib >= 1.2 rsync rcs curl less ...
ifdef SUSE
include suse.rpm.defs
endif
git.spec: git.spec.in Makefile
sed \
-e 's/@@VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@BUILD_REQUIRES@@/$(RPM_BUILD_REQUIRES)/g' \
-e 's/@@CORE_REQUIRES@@/$(RPM_CORE_REQUIRES)/g' \
-e 's/@@SVN_REQUIRES@@/$(RPM_SVN_REQUIRES)/g' \
-e 's/@@CVS_REQUIRES@@/$(RPM_CVS_REQUIRES)/g' \
-e 's/@@TLA_REQUIRES@@/$(RPM_TLA_REQUIRES)/g' \
-e 's/@@EMAIL_REQUIRES@@/$(RPM_EMAIL_REQUIRES)/g' \
-e 's/@@GITK_REQUIRES@@/$(RPM_GITK_REQUIRES)/g' \
<$< >$@
^ permalink raw reply
* A case for tailor
From: Johannes Schindelin @ 2005-11-15 18:48 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1831 bytes --]
Hi,
I was trying to import a project into git, the upstream of which is
managed by Subversion. There has been a flurry of enhancements to
git-svnimport, so I thought I´d give it a try.
Short version: it did not work.
Longer version: depending on the argument to "-T", it stopped right away,
or it stopped after about 60 commits. Right at the beginning, a lot of
warnings told me about some files not being where they were expected.
Possible explanation: at some early stage, the trunk was named "trunk",
but somehow (don´t ask me how, I am a fan of git, not svn) renamed to
"head".
Well, could also be cygwin, which I am stuck with in my office.
BTW, I noticed that the manpage tells me that "-t" should be used to
specify the trunk, but the program (and it´s usage message) disagree.
Enter tailor. It is a program written in python, which is meant to convert
repositories between different SCM formats. It was mentioned some time ago
on this list, supports svn import and git export, so I thought I´d give
that a try.
Short version: it worked.
Longer version: I had to fix a little bug which made git ignore the
author_date (only to find that this had been fixed in the current devel
version of tailor), had to make sure .git/info existed, and I added a
dirty workaround to git so that empty commits would not lead to a
screeching halt of the conversion.
Comparing the speeds, I´d also say that they are comparable, maybe
git-svnimport is just a tad faster (until it fscks up).
I am right now trying to convert tailor´s repository (since I don´t like
to keep it in the darcs (pun intended) format). However there is still a
little problem with darcs, which is probably a problem with the operating
system.
Just wanted to let people know...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add config variable core.symrefsonly
From: Linus Torvalds @ 2005-11-15 18:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0511151923120.1103@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1321 bytes --]
On Tue, 15 Nov 2005, Johannes Schindelin wrote:
>
> Linus, is there any reason you don´t allow spaces, underscores
> and dashes in the config variables?
I much preferred being anal and maybe relaxing the rules later than being
permissive and accepting horrible crap.
Spaces are definitely out, since we are trying to igore whitespace
everywhere, but underscores and dashes might be ok.
However, the traditional way to do these kinds of things in ini files is
with PrettyCaps(tm), ie you'd do
[core]
SymRefsOnly = true
rather than the C way.
Let's face it, the C way is the only true way for a programming language,
but having case matter in something unimportant and human-readable like a
"ini" file is just bothersome, so PrettyCase(tm) actually makes sense
there.
PrettyCase is for toys - unimportant things where it's more important to
say "we don't care" over saying "we need to be precise". So Pascal is PC.
It's a toy language. FAT is PC - it's a toy filesystem. And ini files are
PC: it's more important that a config file is human-readable than it is
that it's very precise and strict.
Put another way: real programmers want strict rules, because they know
they'll be hurt without them. But _users_ need to be coddled. And ini
files aren't for programmers, they are for users.
Linus
^ permalink raw reply
* 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