* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Johannes Schindelin @ 2007-06-11 10:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Steven Grimm, Shawn O. Pearce, Junio C Hamano,
Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706102144080.12885@xanadu.home>
Hi,
On Sun, 10 Jun 2007, Nicolas Pitre wrote:
> On Sun, 10 Jun 2007, Sam Vilain wrote:
>
> > Anyway it's a free world so be my guest to implement it, I guess if
> > this was selectable it would only be a minor annoyance waiting a bit
> > longer pulling from from some repositories, and it would be
> > interesting to see if it did make a big difference with pack file
> > sizes.
>
> It won't happen for a simple reason: to be backward compatible with
> older GIT clients. If you have your repo compressed with bzip2 and an
> old client pulls it then the server would have to decompress and
> recompress everything with gzip. If instead your repo remains with gzip
> and a new client asks for bzip2 then you have to recompress as well
> (slow). So in practice it is best to remain with a single compression
> method.
With the extension mechanism we have in place, the client can send what
kind of compression it supports, and the server can actually refuse to
send anything if it does not want to recompress.
What I am trying to say: you do not necessarily have to allow every client
to access that particular repository. I agree that mixed-compression repos
are evil, but nothing stands in the way of a flag allowing (or
disallowing) recompression in a different format when fetching.
So if you should decide someday to track data with Git (remember: Generic
Information Tracker, not just source code), that is particularly unfit for
compression with gzip, but that you _need_ to store in a different
compressed manner, you can set up a repository which will _only_ _ever_
use that compression.
Of course, you'd need to prepare Git for that, but I could imagine
something like a music library, which stores everything as ogg encoded
snippets. It might even use some perception-based hash on small chunks of
the music, and store the music as tree objects, which concatenate the
small chunks. I might even try to do this for fun, some day in the distant
future.
It's a wild world,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-11 10:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, gitster, Johan Herland
In-Reply-To: <alpine.LFD.0.99.0706102206590.12885@xanadu.home>
Hi,
On Sun, 10 Jun 2007, Nicolas Pitre wrote:
> On Sat, 9 Jun 2007, Johannes Schindelin wrote:
>
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
>
> Isn't this abusing the refs namespace a bit? Why not
> .git/annotations/... instead?
In the way I planned it, it is not at all abusing the refs namespace.
These annotations _are_ tracked in a proper branch. Only that the "file
names" in the tree objects actually refer to commit names.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-11 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v4plf5qxp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I do not understand... the entries of a tree object are sorted
> > alphabetically, right? Including the convention that if one is a
> > prefix of another, it is "smaller".
> >
> > While I think that the length would not be any problem, the entries'
> > names of refs/annotations/commit^{tree} are _all_ of length two, and
> > point to other tree objects. _Those_ tree objects contain _only_
> > entries whose names contain exactly 38 characters.
>
> That is ONLY true if you are introducing a specialized tree
> object parser that knows it is dealing with the tree used in
> your annotation scheme that has entries of uniform size. In
> such a tree parser, you could bisect or Newton-Raphson a tree
> object data to find an entry more efficiently than for normal
> trees with enries of variable size.
Ouch. That is a real flaw in my proposal. It completely destroys my "I
think this will scale just fine" argument.
> If that happens, "refs/annotations/commit:?{40}" format would let you
> look up an annotation for a given commit much more efficiently than
> "refs/annotations/commit:??/?{38}", because it would have to open only
> one tree object, instead of two.
Let me think that one through. At the moment I cannot think of an easy
fix.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-11 10:47 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <20070611083406.GH955MdfPADPa@greensroom.kotnet.org>
On 6/11/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:
> > And I'll drop the "unless otherwise
> > noted, name=path" behaviour. If we later decide it would be useful we
> > can always "re-add" it.
>
> So every (sub)module subsection will have to have a path element?
Yes
> Why?
It addresses Junio's concern about ambiguity and confusion. And it
felt like the 'safe choice', i.e. starting out with a strict rule and
possibly loosen it later on is a lot easier than starting loose and
then trying to make it stricter.
Btw: adding support for the optional path specification on top of my
latest patch-series is trivial:
diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..297272b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -34,8 +34,7 @@ module_name()
{
name=$(GIT_CONFIG=.gitmodules git-config --get-regexp
'^submodule\..*\.path$' "$1" |
sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
- test -z "$name" &&
- die "No submodule mapping found in .gitmodules for path '$path'"
+ test -z "$name" && name="$path"
echo "$name"
}
--
larsh
^ permalink raw reply related
* Re: [PATCH 2/3] Add gitmodules(5)
From: Sven Verdoolaege @ 2007-06-11 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <8c5c35580706110347u55a944ds86f06dabce9e6435@mail.gmail.com>
On Mon, Jun 11, 2007 at 12:47:43PM +0200, Lars Hjemli wrote:
> On 6/11/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> >On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:
> >> And I'll drop the "unless otherwise
> >> noted, name=path" behaviour. If we later decide it would be useful we
> >> can always "re-add" it.
> >
> >So every (sub)module subsection will have to have a path element?
>
> Yes
>
> >Why?
>
> It addresses Junio's concern about ambiguity and confusion.
Junio, is this really what you meant?
Linus even advocated removing the mapping completely
(http://article.gmane.org/gmane.comp.version-control.git/48871),
but I wouldn't go that far.
skimo
^ permalink raw reply
* Re: [PATCH] git-svn: cache max revision in rev_db databases
From: Sam Vilain @ 2007-06-11 11:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070610214753.GC12222@muzzle>
Eric Wong wrote:
> Sam Vilain <sam@vilain.net> wrote:
>
>> Cache the maximum revision for each rev_db URL rather than looking it
>> up each time. This saves a lot of time when rebuilding indexes on a
>> freshly cloned repository.
>>
>
> It looks correct, but I'm not sure how often we can even hit this
> optimization to make it worth it.
>
> Any live repositories and benchmarks you've run this on?
> (without the rev-list => log patch applied, which would be a big
> performance improvement if all log messages were under 16k).
>
It may not make a huge difference with the current code, but it might
with a different rev_db back-end with higher connection cost, and it
seemed like an obvious and innocuous enough memoization.
Sam
^ permalink raw reply
* Re: Adding empty directory gives bogus error message
From: Jeff King @ 2007-06-11 12:30 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, git
In-Reply-To: <20070610204648.GA32214@diku.dk>
On Sun, Jun 10, 2007 at 10:46:48PM +0200, Jonas Fonseca wrote:
> During a talk with madduck on #git today, we stumbled upon this
> confusing error message:
>
> $ mkdir repo
> $ cd repo/
> $ git init
> Initialized empty Git repository in .git/
> $ mkdir empty
> $ git add empty/
> The following paths are ignored by one of your .gitignore files:
> empty/ (directory)
> Use -f if you really want to add them.
> $ git add -f empty/
> fatal: unable to index file empty/
Urgh, that's ugly. The problem is that git-add sticks
assumed-to-be-ignored stuff back into the list of files found by
read_directory, but with some special ignored flags (which aren't used
anywhere else!). When the assumption is wrong (because the path is
_actually_ just empty), you get the bogus message, and when you try to
force it, you get an error from elsewhere in the code.
Patch series will be out momentarily.
-Peff
^ permalink raw reply
* [PATCH]: git-cherry: Document 'limit' command-line option
From: Luiz Fernando N. Capitulino @ 2007-06-11 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index b62c970..e694382 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -53,6 +53,9 @@ OPTIONS
<head>::
Working branch; defaults to HEAD.
+<limit>::
+ Do not report commits up to (and including) limit.
+
Author
------
Written by Junio C Hamano <junkio@cox.net>
--
Luiz Fernando N. Capitulino
^ permalink raw reply related
* Re: Please pull mergetool.git
From: Theodore Tso @ 2007-06-11 13:31 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <46a038f90706101855g639656f3qe80adeeb3a7d6dc2@mail.gmail.com>
On Mon, Jun 11, 2007 at 01:55:25PM +1200, Martin Langhoff wrote:
> FWIW, it depends on whether you are using xterm (DISPLAY is set) or
> Terminal.app (DISPLAY may not be set). In any case FileMerge.app will
> ignore DISPLAY.
Is there a reliable way on MacOS to determine whether the user is
sitting in front of the terminal, as opposed to logged into the MacOS
box remotely? Ideally we would only try opendiff/FileMerge.app if we
new that the user is indeed sitting in front of the graphical display.
- Ted
^ permalink raw reply
* [PATCH 2/3] dir_struct: add collect_ignored option
From: Jeff King @ 2007-06-11 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <20070611123045.GA28814@coredump.intra.peff.net>
When set, this option will cause read_directory to keep
track of which entries were ignored. While this shouldn't
effect functionality in most cases, it can make warning
messages to the user much more useful.
Signed-off-by: Jeff King <peff@peff.net>
---
dir.c | 12 ++++++++++++
dir.h | 5 ++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/dir.c b/dir.c
index e810258..1ffc1e5 100644
--- a/dir.c
+++ b/dir.c
@@ -291,6 +291,15 @@ struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int
return dir->entries[dir->nr++] = dir_entry_new(pathname, len);
}
+struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char *pathname, int len)
+{
+ if(cache_name_pos(pathname, len) >= 0)
+ return NULL;
+
+ alloc_grow(dir->ignored, dir->ignored_nr, dir->ignored_alloc);
+ return dir->ignored[dir->ignored_nr++] = dir_entry_new(pathname, len);
+}
+
enum exist_status {
index_nonexistent = 0,
index_directory,
@@ -463,6 +472,8 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
continue;
exclude = excluded(dir, fullname);
+ if (exclude && dir->collect_ignored)
+ dir_add_ignored(dir, fullname, baselen + len);
if (exclude != dir->show_ignored) {
if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
continue;
@@ -609,6 +620,7 @@ int read_directory(struct dir_struct *dir, const char *path, const char *base, i
read_directory_recursive(dir, path, base, baselen, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
+ qsort(dir->ignored, dir->ignored_nr, sizeof(*dir->ignored), cmp_name);
return dir->nr;
}
diff --git a/dir.h b/dir.h
index 172147f..c94f3cb 100644
--- a/dir.h
+++ b/dir.h
@@ -31,11 +31,14 @@ struct exclude_list {
struct dir_struct {
int nr, alloc;
+ int ignored_nr, ignored_alloc;
unsigned int show_ignored:1,
show_other_directories:1,
hide_empty_directories:1,
- no_gitlinks:1;
+ no_gitlinks:1,
+ collect_ignored:1;
struct dir_entry **entries;
+ struct dir_entry **ignored;
/* Exclude info */
const char *exclude_per_dir;
--
1.5.2.1.958.gbaa74-dirty
^ permalink raw reply related
* [PATCH 1/3] refactor dir_add_name
From: Jeff King @ 2007-06-11 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <20070611123045.GA28814@coredump.intra.peff.net>
This is in preparation for keeping two entry lists in the
dir object.
This patch adds and uses the alloc_grow macro, which
implements the commonly used idiom of growing a dynamic
array using the alloc_nr function (not just in dir.c, but
everywhere).
We also move creation of a dir_entry to dir_entry_new.
Signed-off-by: Jeff King <peff@peff.net>
---
If we like the alloc_grow approach, there are a lot of places where we
can drop a 3-5 line conditional into a single line. I find it much more
readable, but others may disagree.
cache.h | 6 ++++++
dir.c | 23 +++++++++++------------
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index 5e7381e..f771519 100644
--- a/cache.h
+++ b/cache.h
@@ -224,6 +224,12 @@ extern void verify_filename(const char *prefix, const char *name);
extern void verify_non_filename(const char *prefix, const char *name);
#define alloc_nr(x) (((x)+16)*3/2)
+#define alloc_grow(x, nr, alloc) do { \
+ if(nr >= alloc) { \
+ alloc = alloc_nr(alloc); \
+ x = xrealloc((x), alloc * sizeof(*(x))); \
+ } \
+} while(0)
/* Initialize and use the cache information */
extern int read_index(struct index_state *);
diff --git a/dir.c b/dir.c
index f543f50..e810258 100644
--- a/dir.c
+++ b/dir.c
@@ -271,27 +271,26 @@ int excluded(struct dir_struct *dir, const char *pathname)
return 0;
}
-struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
-{
+static
+struct dir_entry *dir_entry_new(const char *pathname, int len) {
struct dir_entry *ent;
-
- if (cache_name_pos(pathname, len) >= 0)
- return NULL;
-
- if (dir->nr == dir->alloc) {
- int alloc = alloc_nr(dir->alloc);
- dir->alloc = alloc;
- dir->entries = xrealloc(dir->entries, alloc*sizeof(ent));
- }
ent = xmalloc(sizeof(*ent) + len + 1);
ent->ignored = ent->ignored_dir = 0;
ent->len = len;
memcpy(ent->name, pathname, len);
ent->name[len] = 0;
- dir->entries[dir->nr++] = ent;
return ent;
}
+struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
+{
+ if (cache_name_pos(pathname, len) >= 0)
+ return NULL;
+
+ alloc_grow(dir->entries, dir->nr, dir->alloc);
+ return dir->entries[dir->nr++] = dir_entry_new(pathname, len);
+}
+
enum exist_status {
index_nonexistent = 0,
index_directory,
--
1.5.2.1.958.gbaa74-dirty
^ permalink raw reply related
* [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jeff King @ 2007-06-11 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <20070611123045.GA28814@coredump.intra.peff.net>
Previously, the code would always set up the excludes, and then manually
pick through the pathspec we were given, assuming that non-added but
existing paths were just ignored. This was mostly correct, but would
erroneously mark a totally empty directory as 'ignored'.
Instead, we now use the collect_ignored option of dir_struct, which
unambiguously tells us whether a path was ignored. This simplifies the
code, and means empty directories are now just not mentioned at all.
Furthermore, we now conditionally ask dir_struct to respect excludes,
depending on whether the '-f' flag has been set. This means we don't have
to pick through the result, checking for an 'ignored' flag; ignored entries
were either added or not in the first place.
We can safely get rid of the special 'ignored' flags to dir_entry, which
were not used anywhere else.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-add.c | 89 ++++++++++++++++++++++++++++++--------------------------
dir.c | 1 -
dir.h | 4 +--
3 files changed, 49 insertions(+), 45 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 1591171..8988930 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -19,6 +19,23 @@ static const char builtin_add_usage[] =
static int take_worktree_changes;
static const char *excludes_file;
+static int in_pathspec(const char *k, const char **pathspec) {
+ while(*pathspec) {
+ if (!strcmp(k, *pathspec))
+ return 1;
+ pathspec++;
+ }
+ return 0;
+}
+
+static void prune_ignored(struct dir_struct *dir, const char **pathspec) {
+ int i;
+ for (i = 0; i < dir->ignored_nr; i++) {
+ if (!in_pathspec(dir->ignored[i]->name, pathspec))
+ dir->ignored[i] = NULL;
+ }
+}
+
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
@@ -40,42 +57,29 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
dir->nr = dst - dir->entries;
for (i = 0; i < specs; i++) {
- struct stat st;
- const char *match;
- if (seen[i])
- continue;
-
- match = pathspec[i];
- if (!match[0])
- continue;
-
- /* Existing file? We must have ignored it */
- if (!lstat(match, &st)) {
- struct dir_entry *ent;
-
- ent = dir_add_name(dir, match, strlen(match));
- ent->ignored = 1;
- if (S_ISDIR(st.st_mode))
- ent->ignored_dir = 1;
- continue;
- }
- die("pathspec '%s' did not match any files", match);
+ if(!seen[i] && !file_exists(pathspec[i]))
+ die("pathspec '%s' did not match any files",
+ pathspec[i]);
}
}
-static void fill_directory(struct dir_struct *dir, const char **pathspec)
+static void fill_directory(struct dir_struct *dir, const char **pathspec,
+ int ignored_too)
{
const char *path, *base;
int baselen;
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(*dir));
- dir->exclude_per_dir = ".gitignore";
- path = git_path("info/exclude");
- if (!access(path, R_OK))
- add_excludes_from_file(dir, path);
- if (!access(excludes_file, R_OK))
- add_excludes_from_file(dir, excludes_file);
+ if (!ignored_too) {
+ dir->collect_ignored = 1;
+ dir->exclude_per_dir = ".gitignore";
+ path = git_path("info/exclude");
+ if (!access(path, R_OK))
+ add_excludes_from_file(dir, path);
+ if (!access(excludes_file, R_OK))
+ add_excludes_from_file(dir, excludes_file);
+ }
/*
* Calculate common prefix for the pathspec, and
@@ -93,8 +97,10 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
/* Read the directory and prune it */
read_directory(dir, path, base, baselen, pathspec);
- if (pathspec)
+ if (pathspec) {
+ prune_ignored(dir, pathspec);
prune_directory(dir, pathspec, baselen);
+ }
}
static void update_callback(struct diff_queue_struct *q,
@@ -160,6 +166,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
const char **pathspec;
struct dir_struct dir;
int add_interactive = 0;
+ int has_ignored;
for (i = 1; i < argc; i++) {
if (!strcmp("--interactive", argv[i]) ||
@@ -219,13 +226,11 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
pathspec = get_pathspec(prefix, argv + i);
- fill_directory(&dir, pathspec);
+ fill_directory(&dir, pathspec, ignored_too);
if (show_only) {
const char *sep = "", *eof = "";
for (i = 0; i < dir.nr; i++) {
- if (!ignored_too && dir.entries[i]->ignored)
- continue;
printf("%s%s", sep, dir.entries[i]->name);
sep = " ";
eof = "\n";
@@ -237,25 +242,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die("index file corrupt");
- if (!ignored_too) {
- int has_ignored = 0;
- for (i = 0; i < dir.nr; i++)
- if (dir.entries[i]->ignored)
- has_ignored = 1;
- if (has_ignored) {
- fprintf(stderr, ignore_warning);
- for (i = 0; i < dir.nr; i++) {
- if (!dir.entries[i]->ignored)
- continue;
- fprintf(stderr, "%s", dir.entries[i]->name);
- if (dir.entries[i]->ignored_dir)
- fprintf(stderr, " (directory)");
- fputc('\n', stderr);
- }
- fprintf(stderr,
- "Use -f if you really want to add them.\n");
- exit(1);
+ has_ignored = 0;
+ for (i = 0; i < dir.ignored_nr; i++) {
+ if (dir.ignored[i])
+ has_ignored = 1;
+ }
+ if (has_ignored) {
+ fprintf(stderr, ignore_warning);
+ for (i = 0; i < dir.ignored_nr; i++) {
+ if (dir.ignored[i])
+ fprintf(stderr, "%s\n", dir.ignored[i]->name);
}
+ fprintf(stderr, "Use -f if you really want to add them.\n");
+ exit(1);
}
for (i = 0; i < dir.nr; i++)
diff --git a/dir.c b/dir.c
index 1ffc1e5..d903a49 100644
--- a/dir.c
+++ b/dir.c
@@ -275,7 +275,6 @@ static
struct dir_entry *dir_entry_new(const char *pathname, int len) {
struct dir_entry *ent;
ent = xmalloc(sizeof(*ent) + len + 1);
- ent->ignored = ent->ignored_dir = 0;
ent->len = len;
memcpy(ent->name, pathname, len);
ent->name[len] = 0;
diff --git a/dir.h b/dir.h
index c94f3cb..ec0e8ab 100644
--- a/dir.h
+++ b/dir.h
@@ -13,9 +13,7 @@
struct dir_entry {
- unsigned int ignored : 1;
- unsigned int ignored_dir : 1;
- unsigned int len : 30;
+ unsigned int len;
char name[FLEX_ARRAY]; /* more */
};
^ permalink raw reply related
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Nicolas Pitre @ 2007-06-11 14:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Steven Grimm, Shawn O. Pearce, Junio C Hamano,
Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706111109430.4059@racer.site>
On Mon, 11 Jun 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 10 Jun 2007, Nicolas Pitre wrote:
>
> > On Sun, 10 Jun 2007, Sam Vilain wrote:
> >
> > > Anyway it's a free world so be my guest to implement it, I guess if
> > > this was selectable it would only be a minor annoyance waiting a bit
> > > longer pulling from from some repositories, and it would be
> > > interesting to see if it did make a big difference with pack file
> > > sizes.
> >
> > It won't happen for a simple reason: to be backward compatible with
> > older GIT clients. If you have your repo compressed with bzip2 and an
> > old client pulls it then the server would have to decompress and
> > recompress everything with gzip. If instead your repo remains with gzip
> > and a new client asks for bzip2 then you have to recompress as well
> > (slow). So in practice it is best to remain with a single compression
> > method.
>
> With the extension mechanism we have in place, the client can send what
> kind of compression it supports, and the server can actually refuse to
> send anything if it does not want to recompress.
>
> What I am trying to say: you do not necessarily have to allow every client
> to access that particular repository. I agree that mixed-compression repos
> are evil, but nothing stands in the way of a flag allowing (or
> disallowing) recompression in a different format when fetching.
I know.
But is it worthwhile? I think not.
However I won't stand in the way of anyone who wants to try and provide
numbers. I just don't believe this is worthwhile and am not inclined to
do it.
OK... Well, I just performed a really quick test:
$ mkdir test-bzip2
$ mkdir test-gzip
$ cp git/*.[cho] test-bzip2
$ cp git/*.[cho] test-gzip
$ bzip2 test-bzip2/*
$ gzip test-gzip/*
$ du -s test-bzip2 test-gzip
5016 test-bzip2
4956 test-gzip
It is true that bzip2 is better with large files, but we typically have
very few of them in a Git repo, and in the presence of large files bzip2
then becomes _much_ slower than gzip. So, given that the nature of Git
objects are likely to be small in 98% of the cases due to deltas, it
appears that bzip2 won't be a gain at all but rather a waste, making a
poor case for supporting it forever afterwards.
> So if you should decide someday to track data with Git (remember: Generic
> Information Tracker, not just source code),
Bah... if you please.
> that is particularly unfit for
> compression with gzip, but that you _need_ to store in a different
> compressed manner, you can set up a repository which will _only_ _ever_
> use that compression.
Maybe. But you'd better have a concrete data set and result numbers to
convince me. Designing software for hypothetical situations before they
actually exist leads to bloatware.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/3] refactor dir_add_name
From: Johannes Schindelin @ 2007-06-11 14:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jonas Fonseca, git
In-Reply-To: <20070611133944.GA7008@coredump.intra.peff.net>
Hi,
On Mon, 11 Jun 2007, Jeff King wrote:
> If we like the alloc_grow approach, there are a lot of places where we
> can drop a 3-5 line conditional into a single line. I find it much more
> readable, but others may disagree.
I like it!
Ciao,
Dscho
^ permalink raw reply
* Asking again... [Re: how to properly import perforce history?]
From: Kevin Green @ 2007-06-11 14:25 UTC (permalink / raw)
To: git
In-Reply-To: <20070608202236.GJ25093@menevado.ms.com>
Reading this again, the subject was probably misleading... Sorry for that.
In the meantime I've been scouring the archives looking for the proper way to
import p4 history into a project.
I'm attempting to use git-p4import.py as that's what came with my version of
git. I ran into the problems below.
How can I properly migrate a project from perforce to git?
Thanks
--Kevin
On 06/08/07 16:22:36, Kevin Green wrote:
>
> Very new to git. Was hoping this would be much more straightforward and I'm
> assuming I'm just missing something fundamentally easy.
>
> I'm using git-p4import.py which came with my release of git.
>
> I have a small project I'd like to move from perforce to git ( 111 files, 165
> revisions ).
>
> I've used a number of different approaches to do this, all of them resulting
> in my files being deleted.
>
> 1)
> $ git init
> $ git-p4import //depot/path master
>
> bombs out with missing .git/index
>
> 2)
> $ p4 sync ...
> $ git init
> $ git add .
> $ git commit
> $ git-p4import --stitch //depot/path
>
> This imports all the comment history, but deletes all of my files!!
>
> 3)
> $ p4 sync ...
> $ git init
> $ git add .
> $ git commit
> $ git-p4import //depot/path new
> ### new branch with no files, but all my files in master
> $ git checkout master
> $ git merge new
> ### Now I see it deleting all of my files, but it pulls in all of the history.
>
>
> NOTE: All of the commits pulled in have no file information associated with
> them...
>
>
> What am I missing?
>
>
> Thanks
>
> --Kevin
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Simon Hausmann @ 2007-06-11 14:56 UTC (permalink / raw)
To: git
In-Reply-To: <20070611142525.GN25093@menevado.ms.com>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On Monday 11 June 2007 16:25:25 Kevin Green wrote:
> Reading this again, the subject was probably misleading... Sorry for that.
>
> In the meantime I've been scouring the archives looking for the proper way
> to import p4 history into a project.
>
> I'm attempting to use git-p4import.py as that's what came with my version
> of git. I ran into the problems below.
>
> How can I properly migrate a project from perforce to git?
*plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git . It
should be just a matter of calling
git-p4 clone //depot/path
or
git-p4 clone //depot/path@all
(the former if you just want perforce #head, the latter if you want to import
all revisions).
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jonas Fonseca @ 2007-06-11 15:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070611133956.GC7008@coredump.intra.peff.net>
Hej Jeff,
Thanks for looking into this and making these patches. :)
Jeff King <peff@peff.net> wrote Mon, Jun 11, 2007:
> builtin-add.c | 89 ++++++++++++++++++++++++++++++--------------------------
> dir.c | 1 -
> dir.h | 4 +--
> 3 files changed, 49 insertions(+), 45 deletions(-)
>
> diff --git a/builtin-add.c b/builtin-add.c
> index 1591171..8988930 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -160,6 +166,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> const char **pathspec;
> struct dir_struct dir;
> int add_interactive = 0;
> + int has_ignored;
>
> for (i = 1; i < argc; i++) {
> if (!strcmp("--interactive", argv[i]) ||
> @@ -237,25 +242,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> if (read_cache() < 0)
> die("index file corrupt");
>
> - if (!ignored_too) {
> - int has_ignored = 0;
> - for (i = 0; i < dir.nr; i++)
> - if (dir.entries[i]->ignored)
> - has_ignored = 1;
> - if (has_ignored) {
> - fprintf(stderr, ignore_warning);
> - for (i = 0; i < dir.nr; i++) {
> - if (!dir.entries[i]->ignored)
> - continue;
> - fprintf(stderr, "%s", dir.entries[i]->name);
> - if (dir.entries[i]->ignored_dir)
> - fprintf(stderr, " (directory)");
> - fputc('\n', stderr);
> - }
> - fprintf(stderr,
> - "Use -f if you really want to add them.\n");
> - exit(1);
> + has_ignored = 0;
> + for (i = 0; i < dir.ignored_nr; i++) {
> + if (dir.ignored[i])
> + has_ignored = 1;
> + }
> + if (has_ignored) {
> + fprintf(stderr, ignore_warning);
> + for (i = 0; i < dir.ignored_nr; i++) {
> + if (dir.ignored[i])
> + fprintf(stderr, "%s\n", dir.ignored[i]->name);
> }
> + fprintf(stderr, "Use -f if you really want to add them.\n");
> + exit(1);
> }
>
> for (i = 0; i < dir.nr; i++)
I think you could even get rid of has_ignored with something like this.
diff --git a/builtin-add.c b/builtin-add.c
index 8988930..da6ab11 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -166,7 +166,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
const char **pathspec;
struct dir_struct dir;
int add_interactive = 0;
- int has_ignored;
for (i = 1; i < argc; i++) {
if (!strcmp("--interactive", argv[i]) ||
@@ -242,12 +241,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die("index file corrupt");
- has_ignored = 0;
- for (i = 0; i < dir.ignored_nr; i++) {
- if (dir.ignored[i])
- has_ignored = 1;
- }
- if (has_ignored) {
+ if (dir.ignored_nr) {
fprintf(stderr, ignore_warning);
for (i = 0; i < dir.ignored_nr; i++) {
if (dir.ignored[i])
--
Jonas Fonseca
^ permalink raw reply related
* Re: Asking again... [Re: how to properly import perforce history?]
From: Alex Riesen @ 2007-06-11 15:44 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706111656.33696.simon@lst.de>
On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
>
> *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git . It
> should be just a matter of calling
>
> git-p4 clone //depot/path
>
Can I suggest you add a target directory mapping to your tool?
Something like:
git-p4 clone //depot/project/path [libs/project/path] [rev-range]
The way Perforce handles branches and directories leads to
the problem that it actually cannot cleanly support neither of
them, and it is very hard to untangle a big repo which
historically has had many projects living in it.
Especially if some idiot actually tried to "do branching".
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Linus Torvalds @ 2007-06-11 15:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070611064203.GG6073@spearce.org>
On Mon, 11 Jun 2007, Shawn O. Pearce wrote:
>
> Thanks! I'm glad at least one other person on this planet finds
> my work on the blame viewer at least partially useful.
I think a lot of people are going to enjoy the git-gui blame viewer..
I don't generally do "git blame" very much at all, and I've found that any
time I do it (even historically - when I've used bk annotate and even
CVS), I have invariably _always_ wanted to go back in history to see the
blame of the *previous* version (because the commit that gets blamed
initially is simply not interesting, and is just whitespace cleanups or
whatever!).
Now, this was something I knew very well on an intellectual level, and I
tried to explain in one of my early discourses on why "annotate" is such a
horribly interface, and why git could do so much better, but it's
something that I think "git-gui blame" is showing that could really be
done.
Now, admittedly, git-gui seems buggy in this regard (I *think* you meant
that the two commits that show up listed to the left of each line are the
"before and after" commit, but they end both being the "after" commit for
me, but I can almost *taste* git-gui doing the right thing here. And once
it does that, I think a lot of people will start to realize how useful
this kind of interactive "drill down into the history of a line" thing can
be.
So I think git-gui isn't quite there yet, but I think it's getting pretty
close. It would need
- the afore-mentioned bug fixed (I _think_ it is a bug, but maybe you had
some other reason for having two separate columns of commits per line),
so that you can literally click on the *previous* version of a line and
say "I don't care about this commit, I want to see the previous one".
- I'd love to see a "go to most recent change" thing (the way _I_ work, I
tend to peel history, so I often look at recent changes, but if that
one isn't interesting, I'd go to the "previous version" and then again
ask for "go to the most recent change".
- I like the floating tooltip showing what the commit was, but I think it
could be extended a bit more to perhaps literally show what the
previous contents of that chunk were (again, that's useful for the "am
I interested in _this_ commit, or should I just dig down to the
previous one")
But yes, the current git-gui blame is already quite interesting. It's not
"all that it could be", but it has gone from "Whee, that looks so ugly
that I need to find me a couple of spoons to dig out my eyeballs with" to
"Hey, I can see this being _really_ good".
Linus
^ permalink raw reply
* Re: [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jeff King @ 2007-06-11 15:54 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, git
In-Reply-To: <20070611150122.GA11020@diku.dk>
On Mon, Jun 11, 2007 at 05:01:23PM +0200, Jonas Fonseca wrote:
> Thanks for looking into this and making these patches. :)
No problem. I had run it across it before and it was on my "look into
this" list...thank you for providing a test case. :)
> I think you could even get rid of has_ignored with something like this.
Nope, I had originally wanted to do that, but the dir_struct.ignored
list contains _all_ ignored items, not just those that were originally
in the pathspec. The prune_ignored call sets uninteresting ones to
NULL. That function could compact the list and re-set ignored_nr, but
it doesn't currently do so.
An even more elegant solution would be for read_directory to mark
whether an ignored file comes from a pathspec, or was found through
recursion. That would be more efficient, and it would remove the
prune_ignored thing, which is IMHO a little hack-ish.
I don't have time to work on it now, but I might look at it more tonight
or tomorrow (but please, if you are interested, take a crack at it).
-Peff
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Junio C Hamano @ 2007-06-11 16:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706110826590.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I don't generally do "git blame" very much at all, and I've found that any
> time I do it (even historically - when I've used bk annotate and even
> CVS), I have invariably _always_ wanted to go back in history to see the
> blame of the *previous* version (because the commit that gets blamed
> initially is simply not interesting, and is just whitespace cleanups or
> whatever!).
Incidentally I added a small patch to underlying git-blame to
let you ignore whitespace changes so that you can blame through
them. I do not think I merged it to 'master' yet, but it is
trivial and look obviously safe and correct.
> So I think git-gui isn't quite there yet, but I think it's getting pretty
> close. It would need
>
> - the afore-mentioned bug fixed (I _think_ it is a bug, but maybe you had
> some other reason for having two separate columns of commits per line),
> so that you can literally click on the *previous* version of a line and
> say "I don't care about this commit, I want to see the previous one".
I think the two columns are for "who _placed_ these lines in the
final image" vs "where these lines originally came into the
history". The former is with -C, and the latter is without.
An option to re-blame starting from the parent commit of what is
currently blamed (i.e. "peel" one level) would certainly be
interesting but I do not think git-gui has it (yet). Of course
it has a not-so-interesting corner case of deciding which parent
to follow for a merge, but a merge commit is blamed only for
lines that are either evil or conflict fixups, so in practice
there is not much to be gained from peeling a merge.
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Junio C Hamano @ 2007-06-11 16:17 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: Lars Hjemli, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <20070611110445.GJ955MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
>> >Why?
>>
>> It addresses Junio's concern about ambiguity and confusion.
>
> Junio, is this really what you meant?
I think I initially misread Lars's patch and log message that
said:
This teaches git-submodule to check module.*.path when looking for the
config for a submodule path. If no match is found it falls back to the
current behaviour (module.$path).
Somehow I thought that it would make it ambiguous to have
module.$name.path and module.$path when answering the question:
"given a name of a module how would you find which path to bind
it to".
But I do not think it is a problem; at least "ambiguity" worry
is unfounded. This section, without "path = " line:
[module "foo"]
url = ...
is equivalent to have "path = foo" in it. Finding path from
module name is well defined.
The other, finding what module should go to a given path, is not
well defined. IOW, you would not know which module you want at
the path bar/ when you have:
[module "foo"]
url = ...
path = bar
[module "bar"]
url = ...
But that problem exists with or without these "module.*.path
and module.$path", so it cannot be an argument against the
definition of the fallback behaviour.
^ permalink raw reply
* Re: [PATCH 1/3] refactor dir_add_name
From: Junio C Hamano @ 2007-06-11 16:23 UTC (permalink / raw)
To: Jeff King; +Cc: Jonas Fonseca, git
In-Reply-To: <20070611133944.GA7008@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If we like the alloc_grow approach, there are a lot of places where we
> can drop a 3-5 line conditional into a single line. I find it much more
> readable, but others may disagree.
I like the readability, but
> cache.h | 6 ++++++
> dir.c | 23 +++++++++++------------
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 5e7381e..f771519 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -224,6 +224,12 @@ extern void verify_filename(const char *prefix, const char *name);
> extern void verify_non_filename(const char *prefix, const char *name);
>
> #define alloc_nr(x) (((x)+16)*3/2)
> +#define alloc_grow(x, nr, alloc) do { \
> + if(nr >= alloc) { \
> + alloc = alloc_nr(alloc); \
> + x = xrealloc((x), alloc * sizeof(*(x))); \
> + } \
> +} while(0)
worry a bit about macro safety. I think the presence of an
assignment to alloc and x would make sure we would catch an
error to pass non lvalue as 'alloc' and 'x', so it may be Ok as
is. A comment before the macro, and a space between 'if' and
opening parenthesis, would be good things to have.
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Kevin Green @ 2007-06-11 16:41 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706111656.33696.simon@lst.de>
On 06/11/07 10:56:33, Simon Hausmann wrote:
> On Monday 11 June 2007 16:25:25 Kevin Green wrote:
> > Reading this again, the subject was probably misleading... Sorry for that.
> >
> > In the meantime I've been scouring the archives looking for the proper way
> > to import p4 history into a project.
> >
> > I'm attempting to use git-p4import.py as that's what came with my version
> > of git. I ran into the problems below.
> >
> > How can I properly migrate a project from perforce to git?
>
> *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git . It
> should be just a matter of calling
>
> git-p4 clone //depot/path
>
> or
>
> git-p4 clone //depot/path@all
>
> (the former if you just want perforce #head, the latter if you want to import
> all revisions).
>
Thanks... I'll try this today and post back on my experience. From your
usage example here, it seems to behave the way I thought git-p4import.py
would.
Is git-p4import.py still used and maintained? I submitted a patch to fix
something trivial on Friday, but didn't here any response to that either,
which led me to believe that it's not the tool being used most often for
p4->git migration...
--Kevin
^ permalink raw reply
* [PATCH] Unquote From line from patch before comparing with given from address.
From: Kristian Høgsberg @ 2007-06-11 17:04 UTC (permalink / raw)
To: git
This makes --suppress-from actually work when you're unfortunate enough
to have non-ASCII in your name. Also, if there's a match use the optionally
RFC2047 quoted version from the email.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
git-send-email.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index eb876f8..7c0c90b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -561,7 +561,8 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- if ($2 eq $from) {
+ if (unquote_rfc2047($2) eq $from) {
+ $from = $2;
next if ($suppress_from);
}
elsif ($1 eq 'From') {
--
1.5.2.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox