* Re: Gitk feature - show nearby tags
From: Jonas Fonseca @ 2006-06-05 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7v3bek7589.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sun, Jun 04, 2006:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> >> - I want to see the neighbouring commits, but UP or DOWN
> >> does not do what I naïvely expect. It scrolls the lower
> >> pane. I say TAB to go up.
> >
> > I wonder what tig version you are using. If you are using the tig
> > version from my git repo this should also be working to your
> > expectation, making ...
>
> Whichever was the latest when I wrote the message. I see you
> have added a handful commits on it since then.
Yes, I added your Makefile patch. Thanks for that one.
> >> - Press UP or DOWN and I can move the highlight to
> >> neighbouring commits. This is wonderful, but the lower
> >> pane does not follow this -- it keeps showing the original
> >> commit, and I have to say ENTER again.
> >
> > .. this unnecessary.
>
> Maybe I am misusing it then.
I admit the basic user controls might still have some rough spots.
Here is my take on what you are trying to do:
- When you open tig, UP/DOWN will move the cursor line.
- When you press ENTER on the commit you would like to see, it will
open the split view and move focus to the diff view. So if you press
Enter again it will start scrolling the diff view. This is much like
the way Mutt works.
- If you press UP/DOWN (while the diff view is focused) you will move
to previous or next commit in the main view (the one-line log view)
and load it in the diff view. That is, there is no reason to switch
to the main view unless you want to navigate to a commit without
repeatedly reloading the diff view which is clearly not what you are
requesting.
Is this not what you requested? That you can "see neighbouring commit"
by pressing UP and DOWN? But without having to press ENTER again.
Now, I've experienced some problems with ncurses and key detection but
only for Insert/Delete and Home/End. If UP/DOWN scrolls the diff view
something is terrible wrong.
> I like viewing the list in the upper and diff/log in the lower
> at the same time, and that is the primary reason I liked tig, so
> moving around in the commit list view and not seeing the
> diff/log updated in sync was major dissapointment at least for
> me.
Ok, well I can just make it optional, if you want the split view always
to be in sync, even while moving when the main view is in focus.
--
Jonas Fonseca
^ permalink raw reply
* Re: Using pickaxe to track changed symbol CR4_FEATURES_ADDR
From: Thomas Glanzmann @ 2006-06-05 20:16 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Junio C Hamano, git
In-Reply-To: <20060605131151.b8878c7c.rdunlap@xenotime.net>
Hello Randy,
I confused it. CR4_FEATURES_ADDR was in the glue code of parallels
binary only modules, but it sounded like a a MMU definition. Thanks a
lot. That was why my pickaxe did not work out in the first place.
However I have a workaround for the damn build problem.
See http://wwwcip.informatik.uni-erlangen.de/~sithglan/parallels/
Thanks,
Thomas
^ permalink raw reply
* Re: Using pickaxe to track changed symbol CR4_FEATURES_ADDR
From: Randy.Dunlap @ 2006-06-05 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sithglan, git
In-Reply-To: <7v8xob4bft.fsf@assigned-by-dhcp.cox.net>
On Mon, 05 Jun 2006 13:03:34 -0700 Junio C Hamano wrote:
> Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
>
> > I am looking for the symbol CR4_FEATURES_ADDR which must be gone in one
> > of the last kernel revision. Now how I do use pickaxe to track any
> > changes that involve my missing symbol? Or is there a better way to
> > track that change down?
>
> None of the major recent versions seem to have the symbol.
>
> : gitster; git grep -e CR4_FEATURES_ADDR \
> v2.6.12-rc2 v2.6.12 v2.6.13 v2.6.14 v2.6.15 \
> v2.6.16
>
> and I did not get any google hits for "CR4_FEATURES_ADDR". Are
> you spelling it right?
include/asm-i386/processor.h has names like:
/*
* Intel CPU features in CR4
*/
#define X86_CR4_VME 0x0001 /* enable vm86 extensions */
#define X86_CR4_PVI 0x0002 /* virtual interrupts flag enable */
#define X86_CR4_TSD 0x0004 /* disable time stamp at ipl 3 */
#define X86_CR4_DE 0x0008 /* enable debugging extensions */
#define X86_CR4_PSE 0x0010 /* enable page size extensions */
#define X86_CR4_PAE 0x0020 /* enable physical address extensions */
#define X86_CR4_MCE 0x0040 /* Machine check enable */
#define X86_CR4_PGE 0x0080 /* enable global pages */
#define X86_CR4_PCE 0x0100 /* enable performance counters at ipl 3 */
#define X86_CR4_OSFXSR 0x0200 /* enable fast FPU save and restore */
#define X86_CR4_OSXMMEXCPT 0x0400 /* enable unmasked SSE exceptions */
extern unsigned long mmu_cr4_features;
static inline void set_in_cr4 (unsigned long mask)
{
unsigned cr4;
mmu_cr4_features |= mask;
cr4 = read_cr4();
cr4 |= mask;
write_cr4(cr4);
}
static inline void clear_in_cr4 (unsigned long mask)
{
unsigned cr4;
mmu_cr4_features &= ~mask;
cr4 = read_cr4();
cr4 &= ~mask;
write_cr4(cr4);
}
but nothing exactly like you asked about.
---
~Randy
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-05 20:08 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Paul Mackerras, git
In-Reply-To: <7v3bek7589.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> Whichever was the latest when I wrote the message. I see you
> have added a handful commits on it since then.
>
>>> - Press UP or DOWN and I can move the highlight to
>>> neighbouring commits. This is wonderful, but the lower
>>> pane does not follow this -- it keeps showing the original
>>> commit, and I have to say ENTER again.
>>
>> .. this unnecessary.
>
> Maybe I am misusing it then.
Sorry, I *was* misusing it. I was doing PageUp/PageDown. Duh.
I typed uparrow and downarrow while in the split view and it was
doing what I wanted to do.
^ permalink raw reply
* Re: Using pickaxe to track changed symbol CR4_FEATURES_ADDR
From: Junio C Hamano @ 2006-06-05 20:03 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20060605102627.GB24346@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
> I am looking for the symbol CR4_FEATURES_ADDR which must be gone in one
> of the last kernel revision. Now how I do use pickaxe to track any
> changes that involve my missing symbol? Or is there a better way to
> track that change down?
None of the major recent versions seem to have the symbol.
: gitster; git grep -e CR4_FEATURES_ADDR \
v2.6.12-rc2 v2.6.12 v2.6.13 v2.6.14 v2.6.15 \
v2.6.16
and I did not get any google hits for "CR4_FEATURES_ADDR". Are
you spelling it right?
^ permalink raw reply
* [PATCH] builtin-push: don't pass --thin to HTTP transport
From: Nick Hengeveld @ 2006-06-05 20:02 UTC (permalink / raw)
To: git
git-http-push does not currently use packs to transfer objects.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
builtin-push.c | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index e530022..66b9407 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -214,7 +214,7 @@ static int do_push(const char *repo)
{
const char *uri[MAX_URI];
int i, n;
- int remote;
+ int common_argc;
const char **argv;
int argc;
@@ -231,23 +231,25 @@ static int do_push(const char *repo)
argv[argc++] = "--force";
if (execute)
argv[argc++] = execute;
- if (thin)
- argv[argc++] = "--thin";
- remote = argc;
- argv[argc++] = "dummy-remote";
- while (refspec_nr--)
- argv[argc++] = *refspec++;
- argv[argc] = NULL;
+ common_argc = argc;
for (i = 0; i < n; i++) {
int error;
+ int dest_argc = common_argc;
+ int dest_refspec_nr = refspec_nr;
+ const char **dest_refspec = refspec;
const char *dest = uri[i];
const char *sender = "git-send-pack";
if (!strncmp(dest, "http://", 7) ||
!strncmp(dest, "https://", 8))
sender = "git-http-push";
+ else if (thin)
+ argv[dest_argc++] = "--thin";
argv[0] = sender;
- argv[remote] = dest;
+ argv[dest_argc++] = dest;
+ while (dest_refspec_nr--)
+ argv[dest_argc++] = *dest_refspec++;
+ argv[dest_argc] = NULL;
error = run_command_v(argc, argv);
if (!error)
continue;
--
1.3.3.g423a-dirty
^ permalink raw reply related
* Re: Horrible re-packing?
From: Linus Torvalds @ 2006-06-05 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <7vy7wb4cmy.fsf@assigned-by-dhcp.cox.net>
On Mon, 5 Jun 2006, Junio C Hamano wrote:
>
> IIRC, sometimes this function is called with path and name split
> and sometimes with full path in name
Yeah, I was pretty confused by the whole hashing thing. Are you sure that
complexity is needed, it seems a bit overkill.
Linus
^ permalink raw reply
* Fix typo in tutorial-2.txt
From: Linus Torvalds @ 2006-06-05 19:47 UTC (permalink / raw)
To: J. Bruce Fields, Junio C Hamano, Git Mailing List
This should be obvious enough.
I didn't actually _test_ the tutorial, but if the old command worked,
something is really wrong!
Signed-off-by: Linus "Duh!" Torvalds <torvalds@osdl.org>
---
Documentation/tutorial-2.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 82c6922..894ca5e 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -136,7 +136,7 @@ The "tree" object here refers to the new
------------------------------------------------
$ git ls-tree d0492b36
100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt
-$ git cat-file commit a0423896
+$ git cat-file blob a0423896
hello world!
------------------------------------------------
^ permalink raw reply related
* Re: [PATCH] Fix git_setup_directory_gently when GIT_DIR is set
From: Junio C Hamano @ 2006-06-05 19:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0606051943540.29608@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When calling git_setup_directory_gently, and GIT_DIR was set, it just
> ignored the variable nongit_ok.
Hmph. Is this really a breakage? That is, gently() is meant
for a case where you do not know if you even find a git
repository and tell it not to complain because you are prepared
for the case where you are not in a git repository.
If the environment has an incorrect GIT_DIR, I think that falls
into a different category. It is more like "the user or calling
script says we have GIT_DIR there but it is corrupt and
unusable".
I do not have a strong opinion on this, though. If you have
two commands in your script, the first of which does gently()
with such an environment, your change may allow that first
command to succeed, but if the second command does not say
nongit_ok, it would die() there anyway.
^ permalink raw reply
* Re: Horrible re-packing?
From: Junio C Hamano @ 2006-06-05 19:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606051155000.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think the hash function with its comment is self-explanatory:
>
> /*
> * This effectively just creates a sortable number from the
> * last sixteen non-whitespace characters. Last characters
> * count "most", so things that end in ".c" sort together.
> */
> while ((c = *name++) != 0) {
> if (isspace(c))
> continue;
> hash = (hash >> 2) + (c << 24);
> }
> return hash;
>
> ie we just create a 32-bit hash, where we "age" previous characters by two
> bits, so the last characters in a filename count most. So when we then
> compare the hashes in the sort routine, filenames that end the same way
> sort the same way.
IIRC, sometimes this function is called with path and name split
and sometimes with full path in name, depending on who calls you
(the latter happens for rev-list --object generated names, and
the former is for objects we extract ourselves from the --thin
base tree, or something like that). I suspect your patch may
break paths whose filename after the last slash is shorter than
16 bytes.
^ permalink raw reply
* Re: Horrible re-packing?
From: Linus Torvalds @ 2006-06-05 19:03 UTC (permalink / raw)
To: Junio C Hamano, Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606051140530.5498@g5.osdl.org>
On this same thread..
This trivial patch not only simplifies the name hashing, it actually
improves packing for both git and the kernel.
The git archive pack shrinks from 6824090->6622627 bytes (a 3%
improvement), and the kernel pack shrinks from 108756213 to 108219021 (a
mere 0.5% improvement, but still, it's an improvement from making the
hashing much simpler!)
I think the hash function with its comment is self-explanatory:
/*
* This effectively just creates a sortable number from the
* last sixteen non-whitespace characters. Last characters
* count "most", so things that end in ".c" sort together.
*/
while ((c = *name++) != 0) {
if (isspace(c))
continue;
hash = (hash >> 2) + (c << 24);
}
return hash;
ie we just create a 32-bit hash, where we "age" previous characters by two
bits, so the last characters in a filename count most. So when we then
compare the hashes in the sort routine, filenames that end the same way
sort the same way.
It takes the subdirectory into account (unless the filename is > 16
characters), but files with the same name within the same subdirectory
will obviously sort closer than files in different subdirectories.
And, incidentally (which is why I tried the hash change in the first
place, of course) builtin-rev-list.c will sort fairly close to rev-list.c.
And no, it's not a "good hash" in the sense of being secure or unique, but
that's not what we're looking for. The whole "hash" thing is misnamed
here. It's not so much a hash as a "sorting number".
Comments?
Linus
----
pack-objects.c | 41 +++++++++++------------------------------
1 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/pack-objects.c b/pack-objects.c
index 3590cd5..ae49fba 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -473,38 +473,19 @@ #define DIRBITS 12
static unsigned name_hash(struct name_path *path, const char *name)
{
- struct name_path *p = path;
- const char *n = name + strlen(name);
- unsigned hash = 0, name_hash = 0, name_done = 0;
-
- if (n != name && n[-1] == '\n')
- n--;
- while (name <= --n) {
- unsigned char c = *n;
- if (c == '/' && !name_done) {
- name_hash = hash;
- name_done = 1;
- hash = 0;
- }
- hash = hash * 11 + c;
- }
- if (!name_done) {
- name_hash = hash;
- hash = 0;
- }
- for (p = path; p; p = p->up) {
- hash = hash * 11 + '/';
- n = p->elem + p->len;
- while (p->elem <= --n) {
- unsigned char c = *n;
- hash = hash * 11 + c;
- }
- }
+ unsigned char c;
+ unsigned hash = 0;
+
/*
- * Make sure "Makefile" and "t/Makefile" are hashed separately
- * but close enough.
+ * This effectively just creates a sortable number from the
+ * last sixteen non-whitespace characters. Last characters
+ * count "most", so things that end in ".c" sort together.
*/
- hash = (name_hash<<DIRBITS) | (hash & ((1U<<DIRBITS )-1));
+ while ((c = *name++) != 0) {
+ if (isspace(c))
+ continue;
+ hash = (hash >> 2) + (c << 24);
+ }
return hash;
}
^ permalink raw reply related
* Re: Horrible re-packing?
From: Linus Torvalds @ 2006-06-05 18:44 UTC (permalink / raw)
To: Junio C Hamano, Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606050951120.5498@g5.osdl.org>
On Mon, 5 Jun 2006, Linus Torvalds wrote:
>
> Whaah! That nice 6.33MB pack-file exploded to 14.5MB!
>
> And it's possibly broken by the fact that we've been renaming things
> lately (ie the "rev-list.c" -> "builtin-rev-list.c" thing ends up not
> finding things)
No, it's even simpler.
The breakage is entirely mine, and due to the tree-walking conversion of
the "process_tree()" function.
In that function, we used to have a local "const char *name" that
_shadowed_ the incoming _argument_ with the same type, and the
tree-walking conversion did not notice that the inner "name" should have
been converted to "entry.path" - so it used the outer-level "name".
Gaah. We should probably use -Wshadow or something, which would hopefully
have warned about the re-use of the same variable name in two different
scopes.
Regardless, this fixes it.
Linus
---
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 17c04b9..e885624 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -135,9 +135,9 @@ static struct object_list **process_tree
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
- p = process_tree(lookup_tree(entry.sha1), p, &me, name);
+ p = process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
else
- p = process_blob(lookup_blob(entry.sha1), p, &me, name);
+ p = process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
}
free(tree->buffer);
tree->buffer = NULL;
^ permalink raw reply related
* Re: [RFC] git commit --branch
From: Jon Loeliger @ 2006-06-05 18:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Git List
In-Reply-To: <7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-05-30 at 17:52, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> >> And your approach is to backport the fix to its original topic
> >> and then re-pull the topic onto the test branch.
> >
> > yes. I was doing this after working on gitweb a bit.
> > In order to test gitweb, I need some local adaptations.
>
> Funny you mention this. I had exactly the same arrangement for
> hacking on gitweb. One "localconf" branch to tell it where the
> repositories are, "origin" to track upstream, "master" to use
> for deployment, and other topic branches.
We all do. :-)
BTW, did you (anyone?) see my patch to help the local
configuration issue some? It basically separates out the
config bits into a separate hash table in a separate file that
can be updated quite independently without even modifying
the original gitweb.cgi. That allows the gitweb.cgi
proper to be slammed down and updated much more readily.
http://marc.theaimsgroup.com/?l=git&m=114308224922372&w=2
jdl
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Pavel Roskin @ 2006-06-05 17:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5u8fk$ju6$1@sea.gmane.org>
On Sun, 2006-06-04 at 11:17 +0200, Jakub Narebski wrote:
> > The big feature is the use of tabs instead of independent windows.
> >
> > This change alone could be enough for a release. It's a big rewrite of UI
> > code to let browsing revisions and patches quicker and easier.
>
> Of course that is advantage _only_ if the tabs are independend, and one
> (usually) doesn't need to view them simultaneously, e.g. side by side.
What would you want to see side-by-side?
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Fix git_setup_directory_gently when GIT_DIR is set
From: Johannes Schindelin @ 2006-06-05 17:46 UTC (permalink / raw)
To: git, junkio
When calling git_setup_directory_gently, and GIT_DIR was set, it just
ignored the variable nongit_ok.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
setup.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index fe7f884..74301c2 100644
--- a/setup.c
+++ b/setup.c
@@ -184,6 +184,10 @@ const char *setup_git_directory_gently(i
}
return NULL;
bad_dir_environ:
+ if (nongit_ok) {
+ *nongit_ok = 1;
+ return NULL;
+ }
path[len] = 0;
die("Not a git repository: '%s'", path);
}
--
1.3.3.gdb440-dirty
^ permalink raw reply related
* Re: [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-05 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606051902210.20820@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Mon, 5 Jun 2006, Johannes Schindelin wrote:
> Hi,
>
> sorry, I did not test with the subdir=... stuff I copied from Pasky's
> patch. It breaks things for me. Looking into it...
There were actually two bugs: I did not change the subdir back in all
cases, and git_setup_directory_gently had a bug (will send patch
separately). The updated patch:
---
git.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index bc463c9..8854472 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h"
#include "builtin.h"
@@ -32,6 +33,113 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static const char *alias_command;
+static char *alias_string = NULL;
+
+static int git_alias_config(const char *var, const char *value)
+{
+ if (!strncmp(var, "alias.", 6) && !strcmp(var + 6, alias_command)) {
+ alias_string = strdup(value);
+ }
+ return 0;
+}
+
+static int split_cmdline(char *cmdline, const char ***argv)
+{
+ int src, dst, count = 0, size = 16;
+ char quoted = 0;
+
+ *argv = malloc(sizeof(char*) * size);
+
+ /* split alias_string */
+ (*argv)[count++] = cmdline;
+ for (src = dst = 0; cmdline[src];) {
+ char c = cmdline[src];
+ if (!quoted && isspace(c)) {
+ cmdline[dst++] = 0;
+ while (cmdline[++src]
+ && isspace(cmdline[src]))
+ ; /* skip */
+ if (count >= size) {
+ size += 16;
+ *argv = realloc(*argv, sizeof(char*) * size);
+ }
+ (*argv)[count++] = cmdline + dst;
+ } else if(!quoted && (c == '\'' || c == '"')) {
+ quoted = c;
+ src++;
+ } else if (c == quoted) {
+ quoted = 0;
+ src++;
+ } else {
+ if (c == '\\' && quoted != '\'') {
+ src++;
+ c = cmdline[src];
+ if (!c) {
+ free(*argv);
+ *argv = NULL;
+ return error("cmdline ends with \\");
+ }
+ }
+ cmdline[dst++] = c;
+ src++;
+ }
+ }
+
+ cmdline[dst] = 0;
+
+ if (quoted) {
+ free(*argv);
+ *argv = NULL;
+ return error("unclosed quote");
+ }
+
+ return count;
+}
+
+static int handle_alias(int *argcp, const char ***argv)
+{
+ int nongit = 0, ret = 0;
+ const char *subdir;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ int count;
+ const char** new_argv;
+
+ alias_command = (*argv)[0];
+ git_config(git_alias_config);
+ if (alias_string) {
+
+ count = split_cmdline(alias_string, &new_argv);
+
+ if (count < 1)
+ die("empty alias for %s", alias_command);
+
+ if (!strcmp(alias_command, new_argv[0]))
+ die("recursive alias: %s", alias_command);
+
+ /* insert after command name */
+ if (*argcp > 1) {
+ new_argv = realloc(new_argv, sizeof(char*) *
+ (count + *argcp - 1));
+ memcpy(new_argv + count, *argv, sizeof(char*) *
+ (*argcp - 1));
+ }
+
+ *argv = new_argv;
+ *argcp += count - 1;
+
+ ret = 1;
+ }
+ }
+
+ if (subdir)
+ chdir(subdir);
+
+ return ret;
+}
+
const char git_version_string[] = GIT_VERSION;
static void handle_internal_command(int argc, const char **argv, char **envp)
@@ -121,6 +229,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,6 +287,8 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
+ handle_alias(&argc, &argv);
+
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
^ permalink raw reply related
* Horrible re-packing?
From: Linus Torvalds @ 2006-06-05 17:08 UTC (permalink / raw)
To: Junio C Hamano, Nicolas Pitre; +Cc: Git Mailing List
Junio, Nico,
I just tried doing a "git repack -a -d -f" to because I expected a full
re-pack to do _better_ than doing occasional incrementals, and verify the
pack generation, but imagine my shock when IT SUCKS.
I didn't look at where the suckage started, but look at this:
[torvalds@g5 git]$ git repack -a -d
Generating pack...
Done counting 21322 objects.
Deltifying 21322 objects.
100% (21322/21322) done
Writing 21322 objects.
100% (21322/21322) done
Total 21322, written 21322 (delta 14489), reused 21319 (delta 14486)
Pack pack-fe4ff117c9959ead3443b826a777423b3062b666 created.
[torvalds@g5 git]$ ll .git/objects/pack/
total 7008
-rw-r--r-- 1 torvalds torvalds 512792 Jun 5 09:41 pack-fe4ff117c9959ead3443b826a777423b3062b666.idx
-rw-r--r-- 1 torvalds torvalds 6643695 Jun 5 09:41 pack-fe4ff117c9959ead3443b826a777423b3062b666.pack
Ie, we have anice 6.33MB pack-file.
Now:
[torvalds@g5 git]$ git repack -a -d -f
Generating pack...
Done counting 21322 objects.
Deltifying 21322 objects.
100% (21322/21322) done
Writing 21322 objects.
100% (21322/21322) done
Total 21322, written 21322 (delta 10187), reused 6777 (delta 0)
Pack pack-fe4ff117c9959ead3443b826a777423b3062b666 created.
[torvalds@g5 git]$ ll .git/objects/pack/
total 15352
-rw-r--r-- 1 torvalds torvalds 512792 Jun 5 09:41 pack-fe4ff117c9959ead3443b826a777423b3062b666.idx
-rw-r--r-- 1 torvalds torvalds 15176139 Jun 5 09:41 pack-fe4ff117c9959ead3443b826a777423b3062b666.pack
Whaah! That nice 6.33MB pack-file exploded to 14.5MB!
Doing repeated "git repack -a -d" to try to do incrementals, it stopped
improving after the sixth one, at which point it was down to 11.7MB, still
almost twice as big as before.
Re-doing it with
git repack -a -d -f --depth=100 --window=100
got me back to 6.94MB, but that's still 10% larger than the pack-file I
had before.
Interestingly, it's the "window" that matters more. The depth part didn't
make that huge of a difference, so it looks like it's the sorting
heuristic that may be broken again.
And it's possibly broken by the fact that we've been renaming things
lately (ie the "rev-list.c" -> "builtin-rev-list.c" thing ends up not
finding things)
Nico? Any ideas?
Linus
^ permalink raw reply
* Re: [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-05 17:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606051847480.18604@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
sorry, I did not test with the subdir=... stuff I copied from Pasky's
patch. It breaks things for me. Looking into it...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-05 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bekacts.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 4 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > For me, short cuts have to be easy to type, so they never
> > include digits, and they are never case sensitive, so I do not
> > need any fancy config stuff...
>
> Fair enough, and the spirit is the same as what Pasky suggested
> earlier, I think.
>
> However, I am not sure about some parts of the code. I started
> mucking with it myself, but realized it is far easier for me to
> just let the original submitter, especially the capable one like
> you, do a bit more work ;-).
Are you trying to butter me up? If so, it's working ;-)
Here is a revised patch which addresses all of your comments (and Pasky's
implicit ones) except the move of split_cmdline to somewhere central (I
am not sure if that function is really needed elsewhere...):
---
git.c | 113 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 113 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index bc463c9..db6ac61 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h"
#include "builtin.h"
@@ -32,6 +33,115 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static const char *alias_command;
+static char *alias_string = NULL;
+
+static int git_alias_config(const char *var, const char *value)
+{
+ if (!strncmp(var, "alias.", 6) && !strcmp(var + 6, alias_command)) {
+ alias_string = strdup(value);
+ }
+ return 0;
+}
+
+static int split_cmdline(char *cmdline, const char ***argv)
+{
+ int src, dst, count = 0, size = 16;
+ char quoted = 0;
+
+ *argv = malloc(sizeof(char*) * size);
+
+ /* split alias_string */
+ (*argv)[count++] = cmdline;
+ for (src = dst = 0; cmdline[src];) {
+ char c = cmdline[src];
+ if (!quoted && isspace(c)) {
+ cmdline[dst++] = 0;
+ while (cmdline[++src]
+ && isspace(cmdline[src]))
+ ; /* skip */
+ if (count >= size) {
+ size += 16;
+ *argv = realloc(*argv, sizeof(char*) * size);
+ }
+ (*argv)[count++] = cmdline + dst;
+ } else if(!quoted && (c == '\'' || c == '"')) {
+ quoted = c;
+ src++;
+ } else if (c == quoted) {
+ quoted = 0;
+ src++;
+ } else {
+ if (c == '\\' && quoted != '\'') {
+ src++;
+ c = cmdline[src];
+ if (!c) {
+ free(*argv);
+ *argv = NULL;
+ return error("cmdline ends with \\");
+ }
+ }
+ cmdline[dst++] = c;
+ src++;
+ }
+ }
+
+ cmdline[dst] = 0;
+
+ if (quoted) {
+ free(*argv);
+ *argv = NULL;
+ return error("unclosed quote");
+ }
+
+ return count;
+}
+
+static int handle_alias(int *argcp, const char ***argv)
+{
+ int nongit = 0;
+ const char *subdir;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ int count;
+ const char** new_argv;
+
+ alias_command = (*argv)[0];
+ git_config(git_alias_config);
+ if (!alias_string)
+ return 0;
+
+ count = split_cmdline(alias_string, &new_argv);
+
+ if (count < 1)
+ die("empty alias for %s", alias_command);
+
+ if (!strcmp(alias_command, new_argv[0]))
+ die("recursive alias: %s", alias_command);
+
+ /* insert after command name */
+ if (*argcp > 1) {
+ new_argv = realloc(new_argv,
+ sizeof(char*) * (count + *argcp - 1));
+ memcpy(new_argv + count, *argv, sizeof(char*) * (*argcp - 1));
+ }
+
+ *argv = new_argv;
+ *argcp += count - 1;
+
+ if (subdir)
+ chdir(subdir);
+
+ return 1;
+ }
+
+ if (subdir)
+ chdir(subdir);
+
+ return 0;
+}
+
const char git_version_string[] = GIT_VERSION;
static void handle_internal_command(int argc, const char **argv, char **envp)
@@ -121,6 +231,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,6 +289,8 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
+ handle_alias(&argc, &argv);
+
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
^ permalink raw reply related
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Nikolai Weibull @ 2006-06-05 16:48 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Horst.H.von.Brand, git
In-Reply-To: <4484239C.7020608@op5.se>
On 6/5/06, Andreas Ericsson <ae@op5.se> wrote:
> Nikolai Weibull wrote:
> > On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> >
> >> Most do not seem to be typoes, depending on where you learned
> >> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.).
> >
> > Where do you write "ie" instead of "i.e."?
> >
>
> Mailing lists, online conversations, tech docs written in code
> editors...
Do you mean that code editors usually don't let you enter a dot into
the buffer, or what?
> Compare with online'ish abbrevs (afaict, iirc, imo, fyi).
That's hardly the same thing. Most people would upcase AFAICT, IIRC,
IMO, and FYI.
I wouldn't group "i.e." with such abbreviations in any case. (Hehe.)
> > In Swedish, there has been a trend to remove dots from abbreviated
> > expressions, but it seems people are returning to use dots.
> > Personally, I find that dots make things a lot clearer.
>
> Swedish has lots of abbreviations where one "part" of the abbreviation
> consists of multiple characters, like t.ex.
And "bl.a.".
> When each character of the abbrev defines one complete word dots are
> just prettiness-noise, their presence or absence decided by the gravity
> of the meaning ("R.I.P." vs "ie"). Obviously, correctness never hurts
> but this is, on two accounts, punktknulleri.
Considering that people don't want to get stuck on trying to
understand what the word "ie" is supposed to mean in a manual page
they're trying to understand what some command does (this happened to
me), I really think that fucking with the dots is called for.
Anyway, the general guidelines recommended by "The Chicago Manual of Style" are:
Use periods with abbreviations that appear in lowercase letters; use
no periods with abbreviations that appear in full capitals or small
capitals, whether two letters or more.
One possible solution is to expand "i.e." to "that is" (or something
equally befitting) and "e.g." to "for example", "such as", or similar.
nikolai
^ permalink raw reply
* Re: irc usage..
From: Sean @ 2006-06-05 16:07 UTC (permalink / raw)
To: antarus
Cc: martin.langhoff, spyderous, torvalds, ydirson, git, smurf,
Johannes.Schindelin
In-Reply-To: <448398BC.5090402@gentoo.org>
On Sun, 04 Jun 2006 22:36:44 -0400
Alec Warner <antarus@gentoo.org> wrote:
> I'll keep chugging on this one; it won't be the final import as I
> haven't used the complete Authors file, so I will try the repacking
> optimization next time I do an import.
Hi Alec,
You may want to go back and do another import for other reasons, but if
the only reason is to fix up the author information it would be _much_
faster to simply rewrite the git commit history. Cogito has something
called "cg-admin-rewritehist" which should do what you need and there
are other scripts floating around specificially for rewriting just the
author information.
HTH,
Sean
^ permalink raw reply
* Re: [PATCH, take 2] Add example xinetd(8) configuration to Documentation/everyday.txt
From: Dmitry V. Levin @ 2006-06-05 13:12 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200606050054.k550sFCC018490@laptop11.inf.utfsm.cl>
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
On Sun, Jun 04, 2006 at 08:54:15PM -0400, Horst von Brand wrote:
> Dmitry V. Levin <ldv@altlinux.org> wrote:
> > It is a bad advice to run git-daemon as root.
>
> Right, my bad. Fixed patch below.
[...]
> + user = root
Really?
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Using pickaxe to track changed symbol CR4_FEATURES_ADDR
From: Andreas Ericsson @ 2006-06-05 12:43 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20060605102627.GB24346@cip.informatik.uni-erlangen.de>
Thomas Glanzmann wrote:
> Hello,
> I am looking for the symbol CR4_FEATURES_ADDR which must be gone in one
> of the last kernel revision. Now how I do use pickaxe to track any
> changes that involve my missing symbol? Or is there a better way to
> track that change down?
>
$ git whatchanged -S'CR4_FEATURES_ADDR'
last time I checked, but that was 10 days and an immense amount of cheap
turkish alcohol ago so it's quite possible that I'm wrong.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Andreas Ericsson @ 2006-06-05 12:29 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Junio C Hamano, Horst.H.von.Brand, git
In-Reply-To: <dbfc82860606041059l31605bc5j18ad2b35ea6f6dc0@mail.gmail.com>
Nikolai Weibull wrote:
> On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
>
>> Most do not seem to be typoes, depending on where you learned
>> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.).
>
>
> Where do you write "ie" instead of "i.e."?
>
Mailing lists, online conversations, tech docs written in code
editors... Compare with online'ish abbrevs (afaict, iirc, imo, fyi).
> In Swedish, there has been a trend to remove dots from abbreviated
> expressions, but it seems people are returning to use dots.
> Personally, I find that dots make things a lot clearer.
>
Swedish has lots of abbreviations where one "part" of the abbreviation
consists of multiple characters, like t.ex.
When each character of the abbrev defines one complete word dots are
just prettiness-noise, their presence or absence decided by the gravity
of the meaning ("R.I.P." vs "ie"). Obviously, correctness never hurts
but this is, on two accounts, punktknulleri.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-05 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd305dk9.fsf@assigned-by-dhcp.cox.net>
On 6/5/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> I think your "start from positive ones, traverse one by one and
> stop traversal that hits the negative one" logic requires the
> negative one to be directly on the traversal paths starting from
> positive ones to have _any_ effect. We often ask "what's the
> ones that are still not merged to the master from the side
> branch" while dealing with topic branches:
>
> c-------d---e master time flows from
> / / left to right
> --a---b---x---y---z side
>
> and the way to ask that question is "rev-list master..side"
> (which is "rev-list side ^master"). It should list z and not
> show y nor x nor b nor a.
>
> In order for it to be able to notice that y should not be
> listed, it needs to perform traversals from negative ones as
> well in order to learn that y is reachable from master.
>
Thanks for your clear explanation. Now I see much better what's the deal.
>
> I think one useful thing we can do is to generalize what
> "describe", "nave-rev", and "merge-base" do to have a command
> that takes a committish X and a set of other committish T1..Tn,
> and examines if Ti (1<=i<=n) is reachable from X and if X is
> reachable from Ti (1<=i<=n), and give a short-hand to specify
> the set of T for common patterns like --heads --tags and --all.
>
I don't know if this is enough for our original problem to find previous tag.
Our problem is indeed not only to find previous tags, but _nearest_
previous, so I think we have to think to a generalization that takes
in account also a kind of 'metric' among tags because the only
reachability seems to fall short in finding the nearset one.
But definitely I need to think more about this ;-)
Marco
^ 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