* [PATCH 2/6] merge-recur: Get rid of debug code
From: Johannes Schindelin @ 2006-07-27 17:12 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 65 +----------------------------------------------------
1 files changed, 1 insertions(+), 64 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index b0035cc..8d9451f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -22,56 +22,6 @@ #include "tag.h"
#include "path-list.h"
-/*#define DEBUG*/
-
-#ifdef DEBUG
-#define debug(...) fprintf(stderr, __VA_ARGS__)
-#else
-#define debug(...) do { ; /* nothing */ } while (0)
-#endif
-
-#ifdef DEBUG
-#include "quote.h"
-static void show_ce_entry(const char *tag, struct cache_entry *ce)
-{
- if (tag && *tag &&
- (ce->ce_flags & htons(CE_VALID))) {
- static char alttag[4];
- memcpy(alttag, tag, 3);
- if (isalpha(tag[0]))
- alttag[0] = tolower(tag[0]);
- else if (tag[0] == '?')
- alttag[0] = '!';
- else {
- alttag[0] = 'v';
- alttag[1] = tag[0];
- alttag[2] = ' ';
- alttag[3] = 0;
- }
- tag = alttag;
- }
-
- fprintf(stderr,"%s%06o %s %d\t",
- tag,
- ntohl(ce->ce_mode),
- sha1_to_hex(ce->sha1),
- ce_stage(ce));
- write_name_quoted("", 0, ce->name,
- '\n', stderr);
- fputc('\n', stderr);
-}
-
-static void ls_files(void) {
- int i;
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
- show_ce_entry("", ce);
- }
- fprintf(stderr, "---\n");
- if (0) ls_files(); /* avoid "unused" warning */
-}
-#endif
-
/*
* A virtual commit has
* - (const char *)commit->util set to the name, and
@@ -346,13 +296,9 @@ static int save_files_dirs(const unsigne
static int get_files_dirs(struct tree *tree)
{
int n;
- debug("get_files_dirs ...\n");
- if (read_tree_recursive(tree, "", 0, 0, NULL, save_files_dirs) != 0) {
- debug(" get_files_dirs done (0)\n");
+ if (read_tree_recursive(tree, "", 0, 0, NULL, save_files_dirs) != 0)
return 0;
- }
n = current_file_set.nr + current_directory_set.nr;
- debug(" get_files_dirs done (%d)\n", n);
return n;
}
@@ -434,11 +380,6 @@ static struct path_list *get_renames(str
int i;
struct path_list *renames;
struct diff_options opts;
-#ifdef DEBUG
- time_t t = time(0);
-
- debug("get_renames ...\n");
-#endif
renames = xcalloc(1, sizeof(struct path_list));
diff_setup(&opts);
@@ -479,9 +420,6 @@ #endif
opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_queued_diff.nr = 0;
diff_flush(&opts);
-#ifdef DEBUG
- debug(" get_renames done in %ld\n", time(0)-t);
-#endif
return renames;
}
@@ -829,7 +767,6 @@ static void conflict_rename_rename_2(str
free(new_path1);
}
-/* General TODO: get rid of all the debug messages */
static int process_renames(struct path_list *a_renames,
struct path_list *b_renames,
const char *a_branch,
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 3/6] merge-recur: Remove dead code
From: Johannes Schindelin @ 2006-07-27 17:13 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 22 ----------------------
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 8d9451f..9a86cdb 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -197,11 +197,6 @@ static int index_only = 0;
*/
static int git_read_tree(const struct tree *tree)
{
-#if 0
- fprintf(stderr, "GIT_INDEX_FILE='%s' git-read-tree %s\n",
- getenv("GIT_INDEX_FILE"),
- sha1_to_hex(tree->object.sha1));
-#endif
int rc;
const char *argv[] = { "git-read-tree", NULL, NULL, };
if (cache_dirty)
@@ -219,14 +214,6 @@ static int git_merge_trees(const char *u
struct tree *head,
struct tree *merge)
{
-#if 0
- fprintf(stderr, "GIT_INDEX_FILE='%s' git-read-tree %s -m %s %s %s\n",
- getenv("GIT_INDEX_FILE"),
- update_arg,
- sha1_to_hex(common->object.sha1),
- sha1_to_hex(head->object.sha1),
- sha1_to_hex(merge->object.sha1));
-#endif
int rc;
const char *argv[] = {
"git-read-tree", NULL, "-m", NULL, NULL, NULL,
@@ -247,10 +234,6 @@ #endif
*/
static struct tree *git_write_tree(void)
{
-#if 0
- fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
- getenv("GIT_INDEX_FILE"));
-#endif
FILE *fp;
int rc;
char buf[41];
@@ -672,11 +655,6 @@ static struct merge_file_info merge_file
argv[6] = lb = strdup(mkpath("%s/%s", branch2Name, b->path));
argv[4] = lo = strdup(mkpath("orig/%s", o->path));
-#if 0
- printf("%s %s %s %s %s %s %s %s %s %s\n",
- argv[0], argv[1], argv[2], argv[3], argv[4],
- argv[5], argv[6], argv[7], argv[8], argv[9]);
-#endif
code = run_command_v(10, argv);
free(la);
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 4/6] merge-recur: Fix compiler warning with -pedantic
From: Johannes Schindelin @ 2006-07-27 17:13 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 9a86cdb..645ef8c 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -642,7 +642,7 @@ static struct merge_file_info merge_file
char src2[PATH_MAX];
const char *argv[] = {
"merge", "-L", NULL, "-L", NULL, "-L", NULL,
- src1, orig, src2,
+ NULL, NULL, NULL,
NULL
};
char *la, *lb, *lo;
@@ -654,6 +654,9 @@ static struct merge_file_info merge_file
argv[2] = la = strdup(mkpath("%s/%s", branch1Name, a->path));
argv[6] = lb = strdup(mkpath("%s/%s", branch2Name, b->path));
argv[4] = lo = strdup(mkpath("orig/%s", o->path));
+ argv[7] = src1;
+ argv[8] = orig;
+ argv[9] = src2,
code = run_command_v(10, argv);
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 5/6] merge-recur: Cleanup last mixedCase variables...
From: Johannes Schindelin @ 2006-07-27 17:13 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 46 +++++++++++++++++++++++-----------------------
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 645ef8c..b0f2ecc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -609,7 +609,7 @@ static char *git_unpack_file(const unsig
static struct merge_file_info merge_file(struct diff_filespec *o,
struct diff_filespec *a, struct diff_filespec *b,
- const char *branch1Name, const char *branch2Name)
+ const char *branch1, const char *branch2)
{
struct merge_file_info result;
result.merge = 0;
@@ -651,8 +651,8 @@ static struct merge_file_info merge_file
git_unpack_file(a->sha1, src1);
git_unpack_file(b->sha1, src2);
- argv[2] = la = strdup(mkpath("%s/%s", branch1Name, a->path));
- argv[6] = lb = strdup(mkpath("%s/%s", branch2Name, b->path));
+ argv[2] = la = strdup(mkpath("%s/%s", branch1, a->path));
+ argv[6] = lb = strdup(mkpath("%s/%s", branch2, b->path));
argv[4] = lo = strdup(mkpath("orig/%s", o->path));
argv[7] = src1;
argv[8] = orig;
@@ -966,8 +966,8 @@ static unsigned char *has_sha(const unsi
/* Per entry merge function */
static int process_entry(const char *path, struct stage_data *entry,
- const char *branch1Name,
- const char *branch2Name)
+ const char *branch1,
+ const char *branch2)
{
/*
printf("processing entry, clean cache: %s\n", index_only ? "yes": "no");
@@ -997,14 +997,14 @@ static int process_entry(const char *pat
if (!a_sha) {
output("CONFLICT (delete/modify): %s deleted in %s "
"and modified in %s. Version %s of %s left in tree.",
- path, branch1Name,
- branch2Name, branch2Name, path);
+ path, branch1,
+ branch2, branch2, path);
update_file(0, b_sha, b_mode, path);
} else {
output("CONFLICT (delete/modify): %s deleted in %s "
"and modified in %s. Version %s of %s left in tree.",
- path, branch2Name,
- branch1Name, branch1Name, path);
+ path, branch2,
+ branch1, branch1, path);
update_file(0, a_sha, a_mode, path);
}
}
@@ -1019,14 +1019,14 @@ static int process_entry(const char *pat
const char *conf;
if (a_sha) {
- add_branch = branch1Name;
- other_branch = branch2Name;
+ add_branch = branch1;
+ other_branch = branch2;
mode = a_mode;
sha = a_sha;
conf = "file/directory";
} else {
- add_branch = branch2Name;
- other_branch = branch1Name;
+ add_branch = branch2;
+ other_branch = branch1;
mode = b_mode;
sha = b_sha;
conf = "directory/file";
@@ -1060,8 +1060,8 @@ static int process_entry(const char *pat
} else {
const char *new_path1, *new_path2;
clean_merge = 0;
- new_path1 = unique_path(path, branch1Name);
- new_path2 = unique_path(path, branch2Name);
+ new_path1 = unique_path(path, branch1);
+ new_path2 = unique_path(path, branch2);
output("CONFLICT (add/add): File %s added non-identically "
"in both branches. Adding as %s and %s instead.",
path, new_path1, new_path2);
@@ -1085,7 +1085,7 @@ static int process_entry(const char *pat
b.mode = b_mode;
mfi = merge_file(&o, &a, &b,
- branch1Name, branch2Name);
+ branch1, branch2);
if (mfi.clean)
update_file(1, mfi.sha, mfi.mode, path);
@@ -1111,8 +1111,8 @@ static int process_entry(const char *pat
static int merge_trees(struct tree *head,
struct tree *merge,
struct tree *common,
- const char *branch1Name,
- const char *branch2Name,
+ const char *branch1,
+ const char *branch2,
struct tree **result)
{
int code, clean;
@@ -1143,13 +1143,13 @@ static int merge_trees(struct tree *head
re_head = get_renames(head, common, head, merge, entries);
re_merge = get_renames(merge, common, head, merge, entries);
clean = process_renames(re_head, re_merge,
- branch1Name, branch2Name);
+ branch1, branch2);
for (i = 0; i < entries->nr; i++) {
const char *path = entries->items[i].path;
struct stage_data *e = entries->items[i].util;
if (e->processed)
continue;
- if (!process_entry(path, e, branch1Name, branch2Name))
+ if (!process_entry(path, e, branch1, branch2))
clean = 0;
}
@@ -1179,8 +1179,8 @@ static int merge_trees(struct tree *head
static
int merge(struct commit *h1,
struct commit *h2,
- const char *branch1Name,
- const char *branch2Name,
+ const char *branch1,
+ const char *branch2,
int call_depth /* =0 */,
struct commit *ancestor /* =None */,
struct commit **result)
@@ -1236,7 +1236,7 @@ int merge(struct commit *h1,
}
clean = merge_trees(h1->tree, h2->tree, merged_common_ancestors->tree,
- branch1Name, branch2Name, &mrtree);
+ branch1, branch2, &mrtree);
if (!ancestor && (clean || index_only)) {
*result = make_virtual_commit(mrtree, "merged tree");
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 6/6] merge-recur: Explain why sha_eq() and struct stage_data cannot go
From: Johannes Schindelin @ 2006-07-27 17:14 UTC (permalink / raw)
To: git, junkio
There were two TODOs to remove sha_eq() and to convert users of
struct stage_data to active_cache users, but this is not possible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index b0f2ecc..cb21bc5 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -47,8 +47,8 @@ static struct commit *make_virtual_commi
}
/*
- * TODO: we should not have to copy the SHA1s around, but rather reference
- * them. That way, sha_eq() is just sha1 == sha2.
+ * Since we use get_tree_entry(), which does not put the read object into
+ * the object pool, we cannot rely on a == b.
*/
static int sha_eq(const unsigned char *a, const unsigned char *b)
{
@@ -58,9 +58,8 @@ static int sha_eq(const unsigned char *a
}
/*
- * TODO: check if we can just reuse the active_cache structure: it is already
- * sorted (by name, stage).
- * Only problem: do not write it when flushing the cache.
+ * Since we want to write the index eventually, we cannot reuse the index
+ * for these (temporary) data.
*/
struct stage_data
{
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 17:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607270947540.4168@g5.osdl.org>
On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Thu, 27 Jul 2006, André Goddard Rosa wrote:
> > >
> > > Please try git 1.4.1.1, it fixes git-clone.
> >
> > Thank you so much, Pavel!
> >
> > Downloading it right now!
>
> The problem is that at least the timeout-fix is a server-side thing, it
> won't fix the client. So if a server is running the broken 1.4.1 release,
> it will time out the clients after 10 minutes. It wasn't obvious breakage,
> because most people do smaller fetches, and never even got close to that
> timeout (most of my connections tend to be in the seconds ;).
>
> I asked Kees to upgrade kernel.org, but he's apparently busy at OSCON this
> week, so I'm bcc'ing the other admins here to ask them to upgrade to
> 1.4.1.1. That won't fix the montavista site, though.
>
> That said, I don't think the timeout problem should have caused a _stall_
> of the connection, it should have caused an early EOF and thus a unpack
> error.
Great! Thank you so much, I will try to contact Montavista.
Best regards,
--
[]s,
André Goddard
^ permalink raw reply
* Windows port, was Re: Projects using git now
From: Johannes Schindelin @ 2006-07-27 17:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eaas2o$bj8$1@sea.gmane.org>
Hi,
On Thu, 27 Jul 2006, Jakub Narebski wrote:
> I guess that the worst obstacles in wider adoption of git is lack of
> intrinsic subproject support (for modular projects, and perhas for
> distributions), and lack of native MS Windows port.
I started playing around with a MinGW32 port, and it already was able to
show a git-log. All the network things, and all the exec things are
non-working.
If anybody wants to play with it, I'll send a patch against
tags/v1.4.1-rc1~37.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Petr Baudis @ 2006-07-27 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.63.0607271602060.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Thu, Jul 27, 2006 at 04:04:11PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Thu, 27 Jul 2006, Jon Smirl wrote:
>
> > On 7/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > ... or whether it is neccessary for an Eclipse-plugin to something else
> > > than GPL.
> >
> > Eclipse is not licensed GPL.
>
> We are talking about Eclipse _plugins_ here. Often (especially when the
> deciding people have $$ in their eyes), plugins have less restrictions
> (for example, WSAD would not be possible if _all_ extensions to Eclipse
> would have to be CPL).
I concur. IANAL but from my understanding is that GPL requires just
the work and its derivatives to be free. So it's a matter of the
derivatives chain; if you write the plugin, does Eclipse become its
derivative work? Well, the derivation went the other way around, so
the plugin is derivative work of Git and possibly Eclipse. So AFAICS the
only possible clash that _might_ happen is if Git requires CVS and
Eclipse requires some other licence.
Too bad for Eclipse's GPL-incompatible viral licence...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Licensing and the library version of git
From: Petr Baudis @ 2006-07-27 17:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, git
In-Reply-To: <20060727172047.GB13776@pasky.or.cz>
Dear diary, on Thu, Jul 27, 2006 at 07:20:47PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> only possible clash that _might_ happen is if Git requires CVS and
^^^
Er, GPL! *blush*
That said, Git still requires RCS for the merge operation. Any plans
to finally switch to diff3 and toss out another useless dependency?
*blush for shameless plug*
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 17:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <b8bf37780607271017p22fa908bt82a564a4a1a15a79@mail.gmail.com>
On 7/27/06, André Goddard Rosa <andre.goddard@gmail.com> wrote:
> On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > On Thu, 27 Jul 2006, André Goddard Rosa wrote:
> > > >
> > > > Please try git 1.4.1.1, it fixes git-clone.
> > >
> > > Thank you so much, Pavel!
> > >
> > > Downloading it right now!
> >
> > The problem is that at least the timeout-fix is a server-side thing, it
> > won't fix the client. So if a server is running the broken 1.4.1 release,
> > it will time out the clients after 10 minutes. It wasn't obvious breakage,
> > because most people do smaller fetches, and never even got close to that
> > timeout (most of my connections tend to be in the seconds ;).
> >
> > I asked Kees to upgrade kernel.org, but he's apparently busy at OSCON this
> > week, so I'm bcc'ing the other admins here to ask them to upgrade to
> > 1.4.1.1. That won't fix the montavista site, though.
> >
> > That said, I don't think the timeout problem should have caused a _stall_
> > of the connection, it should have caused an early EOF and thus a unpack
> > error.
>
> Great! Thank you so much, I will try to contact Montavista.
Hi, Linus!
The problem happened again, and it stalls AFAICS.
Can you reproduce there?
# git clone git://source.mvista.com/git/linux-davinci-2.6.git
Here I have a constant 55 kbps and it stalls with about 117Mb downloaded.
I will try to contact Montavista.
Thanks you so much for the support,
--
[]s,
André Goddard
^ permalink raw reply
* Brand new Enhanced male power and unlimited prowess with your girl The best products for the winning guys
From: Richie @ 2006-07-27 16:27 UTC (permalink / raw)
To: glenda
Dear client.
Boost your manhood to astonishing levels Everything a real man would ever need.Make your girlfriend or wife speechless with increased hardness, richer orgsms and more power in bed
Masculine performance has never been so easy to increase with these products
See our shop: http://www.isohyetab.com
Richie Rossi
Elementary sartorial techniques initially applied obviate the need for repetitive similar actions to the square of three.Youth is wasted on the young A faithful friend is a medicine for life.
Every path has its puddle. Love is the strangest thing
^ permalink raw reply
* Re: Projects using git now
From: Pavel Roskin @ 2006-07-27 17:28 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: git
In-Reply-To: <b8bf37780607271004x45092f60rfd35e29fc1fc922c@mail.gmail.com>
On Thu, 2006-07-27 at 13:04 -0400, André Goddard Rosa wrote:
> Sorry to bother, I already found these two pages:
>
> http://git.or.cz/gitwiki/GitProjects
> http://en.wikipedia.org/wiki/Git_(software)
>
> Do you think they are updated?
See history or "recent changes" on both pages.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Projects using git now
From: André Goddard Rosa @ 2006-07-27 17:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1154021317.13273.3.camel@dv>
On 7/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2006-07-27 at 13:04 -0400, André Goddard Rosa wrote:
> > Sorry to bother, I already found these two pages:
> >
> > http://git.or.cz/gitwiki/GitProjects
> > http://en.wikipedia.org/wiki/Git_(software)
> >
> > Do you think they are updated?
>
> See history or "recent changes" on both pages.
I'm so sorry, thank you! I made that but asked first. :|
--
[]s,
André Goddard
^ permalink raw reply
* Re: Licensing and the library version of git
From: Linus Torvalds @ 2006-07-27 17:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Jon Smirl, git
In-Reply-To: <20060727172329.GC13776@pasky.or.cz>
On Thu, 27 Jul 2006, Petr Baudis wrote:
>
> That said, Git still requires RCS for the merge operation. Any plans
> to finally switch to diff3 and toss out another useless dependency?
If libxdiff ever gets a real 3-way merge, I think we'd do it in a
heartbeat.
Right now it has a function called "xdl_merge3()", but it doesn't actually
have anythign to do with a real merge:
"The function works by creating a differential between mmfo and mmf2 and
by applying the resulting patch to mmf1"
so it's really just a "diff + patch".
I asked Davide about it some time ago, and I think he said that he'd like
to do it properly, but it's always been on his back-burner and that he
didn't foresee that changing in the immediate future..
So we can hope. Or somebody who knows the algorithms could just implement
it and send it to both us and Davide (libxdiff _is_ LGPL, btw).
Linus
^ permalink raw reply
* Re: Licensing and the library version of git
From: Jon Smirl @ 2006-07-27 17:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607270941400.4168@g5.osdl.org>
On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I seriously doubt that Eclipse or Visual Stupido could ever actually
> _understand_ what git does, so the only parts you actually would want to
> use for those is literally the trivial stuff - the "look up objects" and
> "generate commits" part.
Typically an integrated IDE can move, delete, rename directories and
files. Get a log. Push, pull and commit. Revert a change. Generate
diffs to previous versions.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: Linus Torvalds @ 2006-07-27 17:50 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <b8bf37780607271025m1a611006x65a900e9e487ce1b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 391 bytes --]
On Thu, 27 Jul 2006, André Goddard Rosa wrote:
>
> The problem happened again, and it stalls AFAICS.
> Can you reproduce there?
>
> # git clone git://source.mvista.com/git/linux-davinci-2.6.git
Nope. I have a fairly constant 120kbps, and:
[torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
Checking files out...)
100% (19754/19754) done
here
Linus
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 17:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607271049460.4168@g5.osdl.org>
On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 27 Jul 2006, André Goddard Rosa wrote:
> >
> > The problem happened again, and it stalls AFAICS.
> > Can you reproduce there?
> >
> > # git clone git://source.mvista.com/git/linux-davinci-2.6.git
>
> Nope. I have a fairly constant 120kbps, and:
>
> [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> Checking files out...)
> 100% (19754/19754) done
> here
Do you think you can reproduce the server timeout by CTRL + Z and
stopping the process for a while?
I sent an email to the last one who commited in that tree asking for
updating the git version there. I also sent and email to the maillist
owner asking this.
Thanks again,
--
[]s,
André Goddard
^ permalink raw reply
* Re: local clone performance
From: Petr Baudis @ 2006-07-27 18:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910607261637w75c99a2ehcb25b6c81449d298@mail.gmail.com>
Dear diary, on Thu, Jul 27, 2006 at 01:38:00AM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> Comparing git-clone to cg-clone
>
> [jonsmirl@jonsmirl apps]$ time git-clone git foo
> ......
> real 0m5.755s
> user 0m4.548s
> sys 0m0.512s
>
> [jonsmirl@jonsmirl apps]$ time cg-clone git foo
> ....
> real 0m18.970s
> user 0m10.737s
> sys 0m1.392s
>
> Why does it take cg clone so long to set up the missing tags?
> git-clone is over 3x faster.
How many tags do you have?
It's true that cg-clone does not scale very well with big amounts of
tags, because it won't fetch tagged objects you wouldn't get otherwise
(so if you tagged some random huge blob or a history line which is not
part of any branch you have, cg-clone won't grab it all). This
unfortunately costs us one special fetch invocation per tag; I will look
into hacking git-local-fetch to accept multiple commit ids at once, that
should speed it up considerably.
That said, with cg-clone -a I will be able to cut that difference
entirely and blindly take everything from the other repository.
Could you please try the patch below and check if it has at least
any measurable impact on the performance at all? Thanks.
diff --git a/cg-fetch b/cg-fetch
index a6e6959..23e0e77 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -54,7 +54,6 @@ _git_wc_unneeded=1
fetch_progress()
{
- [ $verbose -ge 2 ] && exec cat
if [ -t 1 ]; then
exec "${COGITO_LIB}"cg-Xfetchprogress "$_git_objects"
else
@@ -166,7 +165,11 @@ fetch_http()
{
whead=
[ "$3" ] && whead="-w $3"
- (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
+ if [ $verbose -ge 2 ]; then
+ git-http-fetch -a -v $whead $recovery "$1" "$2/"
+ else
+ (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
+ fi
return ${PIPESTATUS[0]}
}
@@ -197,7 +200,11 @@ fetch_local()
{
whead=
[ "$3" ] && whead="-w $3"
- (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
+ if [ $verbose -ge 2 ]; then
+ git-local-fetch -a -l -v $whead $recovery "$1" "$2"
+ else
+ (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
+ fi
return ${PIPESTATUS[0]}
}
@@ -230,6 +237,7 @@ fetch_tags()
# if so, fetch the tag -- which should be
# a cheap operation -- to complete the chain.
echo -n "Missing tag ${tagname#tags/}... "
+ local verbose=2
if $fetch "$tagname" "$uri" "$tagname" 2>/dev/null >&2; then
echo "retrieved"
else
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: local clone performance
From: Jon Smirl @ 2006-07-27 18:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060727181554.GD13776@pasky.or.cz>
On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Jul 27, 2006 at 01:38:00AM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > Comparing git-clone to cg-clone
> >
> > [jonsmirl@jonsmirl apps]$ time git-clone git foo
> > ......
> > real 0m5.755s
> > user 0m4.548s
> > sys 0m0.512s
> >
> > [jonsmirl@jonsmirl apps]$ time cg-clone git foo
> > ....
> > real 0m18.970s
> > user 0m10.737s
> > sys 0m1.392s
> >
> > Why does it take cg clone so long to set up the missing tags?
> > git-clone is over 3x faster.
>
> How many tags do you have?
I am cloning the git source tree. It looks to have about 40 tags.
> It's true that cg-clone does not scale very well with big amounts of
> tags, because it won't fetch tagged objects you wouldn't get otherwise
> (so if you tagged some random huge blob or a history line which is not
> part of any branch you have, cg-clone won't grab it all). This
> unfortunately costs us one special fetch invocation per tag; I will look
> into hacking git-local-fetch to accept multiple commit ids at once, that
> should speed it up considerably.
>
> That said, with cg-clone -a I will be able to cut that difference
> entirely and blindly take everything from the other repository.
>
> Could you please try the patch below and check if it has at least
> any measurable impact on the performance at all? Thanks.
New timings
real 0m11.259s
user 0m9.977s
sys 0m1.280s
That's a 40% improvement.
> diff --git a/cg-fetch b/cg-fetch
> index a6e6959..23e0e77 100755
> --- a/cg-fetch
> +++ b/cg-fetch
> @@ -54,7 +54,6 @@ _git_wc_unneeded=1
>
> fetch_progress()
> {
> - [ $verbose -ge 2 ] && exec cat
> if [ -t 1 ]; then
> exec "${COGITO_LIB}"cg-Xfetchprogress "$_git_objects"
> else
> @@ -166,7 +165,11 @@ fetch_http()
> {
> whead=
> [ "$3" ] && whead="-w $3"
> - (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
> + if [ $verbose -ge 2 ]; then
> + git-http-fetch -a -v $whead $recovery "$1" "$2/"
> + else
> + (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
> + fi
> return ${PIPESTATUS[0]}
> }
>
> @@ -197,7 +200,11 @@ fetch_local()
> {
> whead=
> [ "$3" ] && whead="-w $3"
> - (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
> + if [ $verbose -ge 2 ]; then
> + git-local-fetch -a -l -v $whead $recovery "$1" "$2"
> + else
> + (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
> + fi
> return ${PIPESTATUS[0]}
> }
>
> @@ -230,6 +237,7 @@ fetch_tags()
> # if so, fetch the tag -- which should be
> # a cheap operation -- to complete the chain.
> echo -n "Missing tag ${tagname#tags/}... "
> + local verbose=2
> if $fetch "$tagname" "$uri" "$tagname" 2>/dev/null >&2; then
> echo "retrieved"
> else
>
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Snow falling on Perl. White noise covering line noise.
> Hides all the bugs too. -- J. Putnam
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: Pavel Roskin @ 2006-07-27 18:41 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0607271049460.4168@g5.osdl.org>
On Thu, 2006-07-27 at 10:50 -0700, Linus Torvalds wrote:
> Nope. I have a fairly constant 120kbps, and:
>
> [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> Checking files out...)
> 100% (19754/19754) done
Same thing here. Current git from the master branch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Licensing and the library version of git
From: David Lang @ 2006-07-27 18:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607270936200.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> (*) I will, in fact, claim that the difference between a bad programmer
> and a good one is whether he considers his code or his data structures
> more important. Bad programmers worry about the code. Good programmers
> worry about data structures and their relationships.
personally I'd add to this that after the data structures are defined and you
turn to the code the API is significantly more important then the code itself.
David Lang
^ permalink raw reply
* [PATCH] Remove -d from *-fetch usage strings
From: Petr Baudis @ 2006-07-27 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is a really ancient remnant of the short era of delta objects stored
directly in the object database.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
http-fetch.c | 2 +-
local-fetch.c | 2 +-
ssh-fetch.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 12493fb..dc286b7 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1245,7 +1245,7 @@ int main(int argc, char **argv)
arg++;
}
if (argc < arg + 2) {
- usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
+ usage("git-http-fetch [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url");
return 1;
}
commit_id = argv[arg];
diff --git a/local-fetch.c b/local-fetch.c
index ffa4887..65a803a 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -194,7 +194,7 @@ int fetch_ref(char *ref, unsigned char *
}
static const char local_pull_usage[] =
-"git-local-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
+"git-local-fetch [-c] [-t] [-a] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
/*
* By default we only use file copy.
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 28f7fd9..a8a6cfb 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -120,7 +120,7 @@ int fetch_ref(char *ref, unsigned char *
static const char ssh_fetch_usage[] =
MY_PROGRAM_NAME
- " [-c] [-t] [-a] [-v] [-d] [--recover] [-w ref] commit-id url";
+ " [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url";
int main(int argc, char **argv)
{
char *commit_id;
^ permalink raw reply related
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 19:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Git Mailing List, Linus Torvalds, Ribeiro, Humberto Plinio
In-Reply-To: <1154025679.13273.5.camel@dv>
On 7/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2006-07-27 at 10:50 -0700, Linus Torvalds wrote:
> > Nope. I have a fairly constant 120kbps, and:
> >
> > [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> > Checking files out...)
> > 100% (19754/19754) done
>
> Same thing here. Current git from the master branch.
Forgot to say that we are using this script in GIT_PROXY_COMMAND
environment variable:
(echo "CONNECT $1:$2 HTTP/1.0"; echo; cat ) | nc <proxy_add> <portnum>
| (read a; read a; cat )
The first 'read a' removes the 'CONNECT SUCCESS HTTP RESPONSE 200' and
the second removes an empty line as described here:
http://www.gelato.unsw.edu.au/archives/git/0605/20664.html
I will try from home later again.
Thanks,
--
[]s,
André Goddard
^ permalink raw reply
* Re: Licensing and the library version of git
From: Daniel Barkalow @ 2006-07-27 19:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Grzegorz Kulewski, Jon Smirl, Petr Baudis, Johannes Schindelin,
git
In-Reply-To: <Pine.LNX.4.64.0607271003270.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> >
> > I think that part of the anwser for question "Why do people use GIT?" is that
> > they trust you and other maintainers that you do a good and stable job. Won't
> > creating several ports/forks/whatever destroy at least part of this?
>
> Sure. But the point is, the GPLv2 isn't exactly up for discussion. People
> can complain all they want, but if they want to trust me, they'll take the
> GPLv2. It's that easy.
I think there'd be a justification for licensing part of git like sparse
is licensed, for the same reasons. It wouldn't include any of the
interesting operations, probably, but it would be worth having a canonical
implementation of reading and writing the data structures, so other
implementations don't screw that up. I wouldn't like to have someone write
a version that generated subtly corrupt git objects that it accepts along
with proper objects, such that we have to work around the breakage. It's a
bit less likely to happen if there's no licensing reason not to use the
same code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git bisect: merge problem with deleted file
From: Meelis Roos @ 2006-07-27 19:37 UTC (permalink / raw)
To: git
mroos@nartsiss:~/compile/linux-2.6$ git bisect start
mroos@nartsiss:~/compile/linux-2.6$ git bisect good 9be2f7c38e0bd64e8a0f74ea68df1e73e2ddfcc3
mroos@nartsiss:~/compile/linux-2.6$ git bisect bad 9676489866a75fdd56b0d3e40ec7884298bb1338
Bisecting: 43 revisions left to test after this
fatal: Untracked working tree file 'Documentation/filesystems/devfs/ChangeLog' would be overwritten by merge.
Got this while trying to bisec Linus' linux-2.6 tree. I have 1
uncommited change in the tree so this might influence the need for
merging.
--
Meelis Roos (mroos@linux.ee)
^ 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