* Re: [PATCH] git-rev-list --help anywhere
From: linux @ 2006-02-19 19:39 UTC (permalink / raw)
To: Johannes.Schindelin, raa.lkml; +Cc: git, junkio, linux
In-Reply-To: <Pine.LNX.4.63.0602192023270.11855@wbgn013.biozentrum.uni-wuerzburg.de>
> can someone please enlighten me why you need to see the usage, when you
> cannot execute the command anyway?
Because you're writing a script, or explaining it to someone over
the phone, or writing shell autocompletion macros, otherwise using
it in some kind of delayed or deferred way.
These ain't no steenkin GUI tools; they can be used in more ways
that typed interactively for immediate execution.
(Have you ever noticed how all the GUI people have rediscovered the
concept of a pathname and a single-character directory separator when
explaining how to navigate a menu/dialog maze? The character '>' seems
to be popular.
Go to menu A
Then go to submenu B
Then select item C to open a dialog
Then go to tab D of that dialog.
Then hit the "Advanced options" button
Then select tab E of that dialog
Then select option F
How exactly is this is an improvement over A/B/C/D/Advanced options/E/F?)
^ permalink raw reply
* Re: [PATCH] git-rev-list --help anywhere
From: A Large Angry SCM @ 2006-02-19 19:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, linux, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0602192023270.11855@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> can someone please enlighten me why you need to see the usage, when you
> cannot execute the command anyway?
>
> Puzzled,
> Dscho
How about so that you can find the options needed to run the command in
another window where it will work.
^ permalink raw reply
* Re: New shiny gitk
From: Sergey Vlasov @ 2006-02-19 20:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17400.23434.724188.649656@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
On Sun, 19 Feb 2006 22:50:34 +1100 Paul Mackerras wrote:
> I just created a branch called "new" in my gitk repository at
>
> git://git.kernel.org/pub/scm/gitk/gitk.git
>
> which has a new improved version of gitk which is much faster than the
> old one and has a better graph layout algorithm. I'd like people to
> try it out and tell me how they like it and if I broke anything (I'm
> pretty sure I broke the "Update" function, for instance).
I have found a case where the new algorithm produces much worse layout
than before.
I cloned the Linus' kernel tree:
git clone git://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
then fetched the Ubuntu tree:
git fetch git://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git master:ubuntu
then tried to look at Ubuntu changes:
gitk origin..ubuntu
The old algorithm was producing a graph with less than 20 lines on the
left, so the patch description was visible. The new version, however,
produces something which does not fit even on a 1920x1200 screen (look
at the bottom of the graph).
> If you use -d to get commits ordered by date, you will need the latest
> version of git-rev-list, which has the --date-order option.
I tried this option - it changes some things, but does not fix that
layout problem.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* [PATCH] Really honour NO_PYTHON
From: Johannes Schindelin @ 2006-02-19 20:13 UTC (permalink / raw)
To: git, junkio
Do not even test for subprocess (trying to execute python).
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
In my setup, gmake output would not say "/usr/bin/python: not found",
but instead "08;"... :-)
Makefile | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
9fe05fa9b21ed71ccfde30aa0d87ed031b923d40
diff --git a/Makefile b/Makefile
index 58291f3..a2cb70c 100644
--- a/Makefile
+++ b/Makefile
@@ -300,8 +300,10 @@ endif
ifdef WITH_OWN_SUBPROCESS_PY
PYMODULES += compat/subprocess.py
else
- ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
- PYMODULES += compat/subprocess.py
+ ifeq ($(NO_PYTHON),)
+ ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
+ PYMODULES += compat/subprocess.py
+ endif
endif
endif
--
1.2.1.gb7c4-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Sam Vilain @ 2006-02-19 21:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20060219144752.GA5541@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
>>>I added your name on the copyright since this is a new file.
>>I did that too at first, but then I changed it back since I reckoned
>>more than 50% of the file was copy-pasted from elsewhere. But
>>thanks. :-)
> By the way, it seems like my name got munged when you edited the
> commit.
I have noticed this munging happening, when I am using a UTF-8 locale.
While we are talking about non-linear messing around with the commit
history, can I request a feature?
Currently, I have a patch stack where I want the top of one of the
patches to always be a particular revision. Consider the last revision
to be like a "difference" revision (ie "what's left" when re-organising
a patch set).
How about a "stg push --fudge-to c033171d..." command for this?
Sam.
^ permalink raw reply
* Re: contrib/ area
From: Sam Vilain @ 2006-02-19 21:18 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <873biikx6k.fsf@wine.dyndns.org>
Alexandre Julliard wrote:
> Is there interest in an emacs interface for git? I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.
Out of interest, why did you choose not to make this a vc- plug-in?
Sam.
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Sam Vilain @ 2006-02-19 21:24 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <43F8BCB1.2010701@gmail.com>
Jacob Kroon wrote:
> When I started my git repository for my project, I never setup
> GIT_AUTHOR_NAME etc. correctly,
> so my commit messages used the default information,
> "<jacob@skeletor.(none)>", "skeletor" being the
> hostname of the computer I'm working on. I'd like to change it so that
> the messages will contain correct
> information about my e-mail and username. I noticed that this question
> has been brought up here before
> and that the solution might be to use git-convert-objects, but that it
> might need some modifications.
>
> Has anyone come up with a working tool for this task ?
Perhaps "stg uncommit"
Sam.
^ permalink raw reply
* Re: contrib/ area
From: Alexandre Julliard @ 2006-02-19 21:56 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <43F8E0B8.20508@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> Alexandre Julliard wrote:
>> Is there interest in an emacs interface for git? I posted a first
>> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
>> some time ago, I'd be happy to send you a patch with my latest version
>> if you want to include it.
>
> Out of interest, why did you choose not to make this a vc- plug-in?
For the same reason that there are both vc-cvs and pcl-cvs modes, they
are completely different approaches to the user interface. The VC mode
is purely file-oriented, and is very limited in its ability to handle
project-wide changes. It has its uses, but IMO there's no way to
exploit the full capabilities of a tool like git (or even CVS) with
the VC interface.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Jon Nelson @ 2006-02-19 22:35 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <43F8BCB1.2010701@gmail.com>
On Sun, 19 Feb 2006, Jacob Kroon wrote:
> When I started my git repository for my project, I never setup GIT_AUTHOR_NAME
> etc. correctly,
> so my commit messages used the default information, "<jacob@skeletor.(none)>",
> "skeletor" being the
> hostname of the computer I'm working on. I'd like to change it so that the
> messages will contain correct
> information about my e-mail and username. I noticed that this question has
> been brought up here before
> and that the solution might be to use git-convert-objects, but that it might
> need some modifications.
>
> Has anyone come up with a working tool for this task ?
I modified git-convert-objects to perform just that task.
I'll see if I can dig it up (I'm not able to do so right now).
--
Jon Nelson <jnelson-git@jamponi.net>
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Jon Nelson @ 2006-02-19 23:01 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.63.0602191634480.6352@gheavc.wnzcbav.cig>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1116 bytes --]
On Sun, 19 Feb 2006, Jon Nelson wrote:
> On Sun, 19 Feb 2006, Jacob Kroon wrote:
>
> > When I started my git repository for my project, I never setup GIT_AUTHOR_NAME
> > etc. correctly,
> > so my commit messages used the default information, "<jacob@skeletor.(none)>",
> > "skeletor" being the
> > hostname of the computer I'm working on. I'd like to change it so that the
> > messages will contain correct
> > information about my e-mail and username. I noticed that this question has
> > been brought up here before
> > and that the solution might be to use git-convert-objects, but that it might
> > need some modifications.
> >
> > Has anyone come up with a working tool for this task ?
>
> I modified git-convert-objects to perform just that task.
> I'll see if I can dig it up (I'm not able to do so right now).
Attached. Notes:
1. it's ugly
2. it's indented funny
3. it didn't seem to break anything for me, but no guarantees
4. it probably smells of elderberries
5. set your GIT_* environment up properly first or you'll wonder why it
doesn't work like I did.
--
Jon Nelson <jnelson-git@jamponi.net>
[-- Attachment #2: Type: TEXT/PLAIN, Size: 9682 bytes --]
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..109bfb0 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -263,7 +263,156 @@ static void convert_date(void *buffer, u
newlen += size;
write_sha1_file(new, newlen, "commit", result_sha1);
- free(new);
+ free(new);
+}
+
+static int convert_email_line(char *dst, void **buf, unsigned long *sp, const char *name, const char *new_email)
+{
+ unsigned long size = *sp;
+ char *line = *buf;
+ char *space = strchr(line, ' ');
+ char *next = strchr(line, '\n');
+ char *email_start = strchr(line, '<');
+ char *email_end = strchr(line, '>');
+ int len, total = 0;
+
+ // "author|committer xyz <xyz> date"
+ // "committer xyz <xyz> date"
+ if (!space || !next || !email_start || !email_end)
+ die("missing or bad author/committer line %s", line);
+
+ ++space;
+ ++email_start;
+ ++next;
+
+ //fprintf(stderr, "yikes: size; %lu \"%s\"\n", size, line);
+
+ *buf = next;
+ *sp = size - (next - line);
+
+ /* copy the stuff from before the name */
+ len = space - line;
+ memcpy(dst, line, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* copy the new name */
+ len = strlen(name);
+ memcpy(dst, name, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* put a space in there */
+ *dst = ' ';
+ ++dst;
+ ++total;
+ --size;
+
+ /* put a '<' in there */
+ *dst = '<';
+ ++dst;
+ ++total;
+ --size;
+
+ /* copy the new email */
+ len = strlen(new_email);
+ memcpy(dst, new_email, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* copy the rest of the line */
+ len = next - email_end;
+ memcpy(dst, email_end, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ return total;
+}
+
+static void convert_authorcommitter(void *buffer, unsigned long size, unsigned char *result_sha1)
+{
+ char *new = xmalloc(size + 100);
+ unsigned long newlen = 0;
+ char *author_info = strdup(git_author_info());
+ char *committer_info = strdup(git_committer_info());
+ char *author_name, *author_email;
+ char *committer_name, *committer_email;
+ char *temp;
+
+//#define TESTING
+#ifdef TESTING
+ fprintf(stderr, "author_info: \"%s\"\n",
+ author_info);
+ fprintf(stderr, "committer_info: \"%s\"\n",
+ committer_info);
+#endif
+ author_name = author_info;
+ temp = strchr(author_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ author_email = temp;
+ temp = strrchr(author_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ committer_name = committer_info;
+ temp = strchr(committer_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ committer_email = temp;
+ temp = strrchr(committer_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+#ifdef TESTING
+ fprintf(stderr, "author_name: \"%s\"\n", author_name);
+ fprintf(stderr, "author_email: \"%s\"\n", author_email);
+ fprintf(stderr, "committer_name: \"%s\"\n", committer_name);
+ fprintf(stderr, "committer_email: \"%s\"\n", committer_email);
+ exit(0);
+#endif
+
+ // "tree <sha1>\n"
+ memcpy(new + newlen, buffer, 46);
+ newlen += 46;
+ buffer += 46;
+ size -= 46;
+
+ // "parent <sha1>\n"
+ while (!memcmp(buffer, "parent ", 7)) {
+ memcpy(new + newlen, buffer, 48);
+ newlen += 48;
+ buffer += 48;
+ size -= 48;
+ }
+
+ // "author xyz <xyz> date"
+ // "committer xyz <xyz> date"
+ newlen += convert_email_line(new + newlen, &buffer, &size, author_name, author_email);
+ newlen += convert_email_line(new + newlen, &buffer, &size, committer_name, committer_email);
+
+ // Rest
+ memcpy(new + newlen, buffer, size);
+ newlen += size;
+
+ write_sha1_file(new, newlen, "commit", result_sha1);
+ free(new);
+ free(author_info);
+ free(committer_info);
}
static void convert_commit(void *buffer, unsigned long size, unsigned char *result_sha1)
@@ -279,7 +428,117 @@ static void convert_commit(void *buffer,
convert_ascii_sha1(buffer+7);
buffer += 48;
}
- convert_date(orig_buffer, orig_size, result_sha1);
+ convert_authorcommitter(orig_buffer, orig_size, result_sha1);
+}
+
+static void convert_tag(void *buffer, unsigned long size, unsigned char *result_sha1)
+{
+ void *orig_buffer = buffer;
+
+ char *new = xmalloc(size + 100);
+ unsigned long newlen = 0;
+
+ char *author_info = strdup(git_author_info());
+ char *committer_info = strdup(git_committer_info());
+ char *author_name, *author_email;
+ char *committer_name, *committer_email;
+ char *temp;
+ unsigned long len = 0;
+ char *email_start;
+ char *email_end;
+ char *author_start;
+ int has_author = 1;
+
+ author_name = author_info;
+ temp = strchr(author_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ author_email = temp;
+ temp = strrchr(author_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ committer_name = committer_info;
+ temp = strchr(committer_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ committer_email = temp;
+ temp = strrchr(committer_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ //* START *//
+
+ if (memcmp(buffer, "object ", 7))
+ die("Bad tag '%s'", (char*) buffer);
+ convert_ascii_sha1(buffer+7);
+// fprintf(stderr, "converting %s", (char *) (buffer + 7));
+ buffer += 7 + 40 + 1; /* "object " + "hex sha1" + "\n" */
+ /* type commit
+ tag boa-0.94.14rc6
+ tagger...
+ */
+ /* with tagger, we check for tagger author_name <author_email>
+ * and if so, we convert that, too
+ */
+ temp = strchr(buffer, '\n'); /* end of commit line */
+ if (!temp) {
+ die("Bad tag '%s'", (char *) buffer);
+ }
+ ++temp;
+ temp = strchr(temp, '\n'); /* end of tag line */
+ if (!temp) {
+ die("Bad tag '%s'", (char *) buffer);
+ }
+ ++temp;
+ if (memcmp(temp, "tagger ", 7))
+ die("Bad tag '%s'", (char *) buffer);
+ temp += 7; /* just after 'tagger ' */
+
+ len = (temp - (char *) orig_buffer);
+ memcpy(new, orig_buffer, len);
+ newlen += len;
+ ++temp;
+
+ /* check to see if the next item looks like an name + email */
+ email_start = strchr(temp, '<');
+ if (email_start) {
+ email_end = strchr(email_start, '>');
+ if (email_end) {
+ author_start = strchr(temp, ' ');
+ if (author_start && author_start < email_start) {
+ has_author = 1;
+ newlen += sprintf(new + newlen,
+ "%s <%s>\n",
+ author_name,
+ author_email);
+ len = (email_end - (char *) buffer) + 2;
+ }
+
+ }
+ }
+
+ if (len > size) {
+ memcpy(new + newlen, orig_buffer + len, size - len);
+ newlen += (size - len);
+ }
+// fprintf(stderr, "About to write: %s", new);
+// exit(0);
+
+ write_sha1_file(new, newlen, "tag", result_sha1);
+ free(new);
+ free(author_info);
+ free(committer_info);
}
static struct entry * convert_entry(unsigned char *sha1)
@@ -297,13 +556,15 @@ static struct entry * convert_entry(unsi
buffer = xmalloc(size);
memcpy(buffer, data, size);
-
+
if (!strcmp(type, "blob")) {
write_sha1_file(buffer, size, "blob", entry->new_sha1);
- } else if (!strcmp(type, "tree"))
- convert_tree(buffer, size, entry->new_sha1);
- else if (!strcmp(type, "commit"))
- convert_commit(buffer, size, entry->new_sha1);
+ } else if (!strcmp(type, "tree"))
+ convert_tree(buffer, size, entry->new_sha1);
+ else if (!strcmp(type, "commit"))
+ convert_commit(buffer, size, entry->new_sha1);
+ else if (!strcmp(type, "tag"))
+ convert_tag(buffer, size, entry->new_sha1);
else
die("unknown object type '%s' in %s", type, sha1_to_hex(sha1));
entry->converted = 1;
@@ -318,6 +579,7 @@ int main(int argc, char **argv)
struct entry *entry;
setup_git_directory();
+ setup_ident();
if (argc != 2 || get_sha1(argv[1], sha1))
usage("git-convert-objects <sha1>");
^ permalink raw reply related
* Re: Fixing author/email fields in commit messages
From: Jacob Kroon @ 2006-02-19 23:33 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602191651340.6352@gheavc.wnzcbav.cig>
Jon Nelson wrote:
>>I modified git-convert-objects to perform just that task.
>>I'll see if I can dig it up (I'm not able to do so right now).
>>
>>
>
>Attached. Notes:
>
>1. it's ugly
>2. it's indented funny
>3. it didn't seem to break anything for me, but no guarantees
>4. it probably smells of elderberries
>5. set your GIT_* environment up properly first or you'll wonder why it
>doesn't work like I did.
>
>
>
Hi Jon,
I've applied your patch to the latest git sources, and it compiles, but
I'm not quite sure how to
invoke the command. I've setup GIT_* env. variables, and
git-convert-objects needs a sha1 identifier.
I've tried passing "HEAD", and some other commit id's, but they don't
seem to make any difference.
Am I doing things right ? How exactly do I invoke the command to clean
up the commit messages ?
At least I don't get any error messages.
//Jacob
^ permalink raw reply
* Delta-transfer using thin-pack
From: Junio C Hamano @ 2006-02-19 23:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
I'll be sending out three experimental patches that would come
on top of "next". With them, you should be able to:
$ git send-pack --thin other/repo/sitory
and it would send deltified representation based on things not
in the transferred data.
This is somewhat experimental, although I tried it myself and it
seems to work with my limited test. Do not push into your
production repository with it yet, but please do try it out.
How does it work?
"git send-pack" works by:
(1) negotiating with the other end to find out what common
commits our repository and the other one has;
(2) computing the list of objects to send to the other end by
running
"git-rev-list --objects $heads `git-rev-parse --not $commons`"
($heads are what we are going to send, $commons are what
they already have).
(3) feeding (2) to git-pack-object --stdout, sending the result
to the other end.
(4) invoke git-receive-pack on the other end and have it read
the output from (3), which will feed git-unpack-objects on
the other end.
In general, the packfile is designed to be "self contained".
This is necessary in case we need to deal with more than one
huge packfiles that we can mmap only one at a time -- we
guarantee that the base object of a deltified object is found
while unpacking that deltified object because the base object
can always be found in the same pack.
However, during send-pack/receive-pack transfer, we will unpack
the resulting packfile on the other end into loose objects, so
it is not strictly necessary to require self-containedness to
the packfile used for the transfer.
^ permalink raw reply
* [PATCH] rev-list --objects-edge
From: Junio C Hamano @ 2006-02-19 23:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
This new flag is similar to --objects, but causes rev-list to
show list of "uninteresting" commits that appear on the edge
commit prefixed with '-'.
Downstream pack-objects will be changed to take these as hints
to use the trees and blobs contained with them as base objects
of resulting pack, producing an incomplete (not self-contained)
pack.
Such a pack cannot be used in .git/objects/pack (it is prevented
by git-index-pack erroring out if it is fed to git-fetch-pack -k
or git-clone-pack), but would be useful when transferring only
small changes to huge blobs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Together with "thin-pack" patch I'll send next, this will
allow you to do the "delta transfer" we discussed on the #git
channel last night (eh, *my* last night anyway).
rev-list.c | 34 ++++++++++++++++++++++++++++------
rev-parse.c | 1 +
2 files changed, 29 insertions(+), 6 deletions(-)
52de788e6094b31be218f0f69576cbbfb310205f
diff --git a/rev-list.c b/rev-list.c
index f2d1105..373549e 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -30,7 +30,7 @@ static const char rev_list_usage[] =
" --date-order\n"
" formatting output:\n"
" --parents\n"
-" --objects\n"
+" --objects | --objects-edge\n"
" --unpacked\n"
" --header | --pretty\n"
" --abbrev=nr | --no-abbrev\n"
@@ -44,6 +44,7 @@ static int bisect_list = 0;
static int tag_objects = 0;
static int tree_objects = 0;
static int blob_objects = 0;
+static int edge_hint = 0;
static int verbose_header = 0;
static int abbrev = DEFAULT_ABBREV;
static int show_parents = 0;
@@ -430,16 +431,30 @@ static struct commit_list *find_bisectio
return best;
}
+static void mark_edge_parents_uninteresting(struct commit *commit)
+{
+ struct commit_list *parents;
+
+ for (parents = commit->parents; parents; parents = parents->next) {
+ struct commit *parent = parents->item;
+ if (!(parent->object.flags & UNINTERESTING))
+ continue;
+ mark_tree_uninteresting(parent->tree);
+ if (edge_hint)
+ printf("-%s\n", sha1_to_hex(parent->object.sha1));
+ }
+}
+
static void mark_edges_uninteresting(struct commit_list *list)
{
for ( ; list; list = list->next) {
- struct commit_list *parents = list->item->parents;
+ struct commit *commit = list->item;
- for ( ; parents; parents = parents->next) {
- struct commit *commit = parents->item;
- if (commit->object.flags & UNINTERESTING)
- mark_tree_uninteresting(commit->tree);
+ if (commit->object.flags & UNINTERESTING) {
+ mark_tree_uninteresting(commit->tree);
+ continue;
}
+ mark_edge_parents_uninteresting(commit);
}
}
@@ -843,6 +858,13 @@ int main(int argc, const char **argv)
blob_objects = 1;
continue;
}
+ if (!strcmp(arg, "--objects-edge")) {
+ tag_objects = 1;
+ tree_objects = 1;
+ blob_objects = 1;
+ edge_hint = 1;
+ continue;
+ }
if (!strcmp(arg, "--unpacked")) {
unpacked = 1;
limited = 1;
diff --git a/rev-parse.c b/rev-parse.c
index a5fb93c..610eacb 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -43,6 +43,7 @@ static int is_rev_argument(const char *a
"--min-age=",
"--no-merges",
"--objects",
+ "--objects-edge",
"--parents",
"--pretty",
"--show-breaks",
--
1.2.2.g0d27
^ permalink raw reply related
* [PATCH] send-pack --thin: use "thin pack" delta transfer.
From: Junio C Hamano @ 2006-02-19 23:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
The new flag loosens the usual "self containedness" requirment
of packfiles, and sends deltified representation of objects when
we know the other side has the base objects needed to unpack
them. This would help reducing the transfer size.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Together with the other two patches, this allows you to say
"git-send-pack --thin" to implement the "delta transfer" we
discussed earlier.
send-pack.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
7830d82ec3103e3e4c099750620626b3d53530be
diff --git a/send-pack.c b/send-pack.c
index 990be3f..ad22da5 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -12,6 +12,7 @@ static const char *exec = "git-receive-p
static int verbose = 0;
static int send_all = 0;
static int force_update = 0;
+static int use_thin_pack = 0;
static int is_zero_sha1(const unsigned char *sha1)
{
@@ -41,7 +42,10 @@ static void exec_rev_list(struct ref *re
int i = 0;
args[i++] = "rev-list"; /* 0 */
- args[i++] = "--objects"; /* 1 */
+ if (use_thin_pack) /* 1 */
+ args[i++] = "--objects-edge";
+ else
+ args[i++] = "--objects";
while (refs) {
char *buf = malloc(100);
if (i > 900)
@@ -361,6 +365,10 @@ int main(int argc, char **argv)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--thin")) {
+ use_thin_pack = 1;
+ continue;
+ }
usage(send_pack_usage);
}
if (!dest) {
--
1.2.2.g0d27
^ permalink raw reply related
* [PATCH] Thin pack - create packfile with missing delta base.
From: Junio C Hamano @ 2006-02-19 23:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
This goes together with "rev-list --object-edge" change, to feed
pack-objects list of edge commits in addition to the usual
object list. Upon seeing such list, pack-objects loosens the
usual "self contained delta" constraints, and can produce delta
against blobs and trees contained in the edge commits without
storing the delta base objects themselves.
The resulting packfile is not usable in .git/object/packs, but
is a good way to implement "delta-only" transfer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For "delta transfer"; this comes on top of "next".
pack-objects.c | 298 +++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 218 insertions(+), 80 deletions(-)
630dcb88482d99b77f83e1ed67b24d4026183c81
diff --git a/pack-objects.c b/pack-objects.c
index 0c9f4c9..fc923c9 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -3,6 +3,7 @@
#include "delta.h"
#include "pack.h"
#include "csum-file.h"
+#include "diff.h"
#include <sys/time.h>
static const char pack_usage[] = "git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
@@ -26,6 +27,13 @@ struct object_entry {
struct object_entry *delta_sibling; /* other deltified objects who
* uses the same base as me
*/
+ int preferred_base; /* we do not pack this, but is encouraged to
+ * be used as the base objectto delta huge
+ * objects against.
+ */
+ int based_on_preferred; /* current delta candidate is a preferred
+ * one, or delta against a preferred one.
+ */
};
/*
@@ -48,7 +56,7 @@ static int local = 0;
static int incremental = 0;
static struct object_entry **sorted_by_sha, **sorted_by_type;
static struct object_entry *objects = NULL;
-static int nr_objects = 0, nr_alloc = 0;
+static int nr_objects = 0, nr_alloc = 0, nr_result = 0;
static const char *base_name;
static unsigned char pack_file_sha1[20];
static int progress = 1;
@@ -229,7 +237,8 @@ static int encode_header(enum object_typ
return n;
}
-static unsigned long write_object(struct sha1file *f, struct object_entry *entry)
+static unsigned long write_object(struct sha1file *f,
+ struct object_entry *entry)
{
unsigned long size;
char type[10];
@@ -239,6 +248,9 @@ static unsigned long write_object(struct
enum object_type obj_type;
int to_reuse = 0;
+ if (entry->preferred_base)
+ return 0;
+
obj_type = entry->type;
if (! entry->in_pack)
to_reuse = 0; /* can't reuse what we don't have */
@@ -326,10 +338,11 @@ static void write_pack_file(void)
if (!base_name)
f = sha1fd(1, "<stdout>");
else
- f = sha1create("%s-%s.%s", base_name, sha1_to_hex(object_list_sha1), "pack");
+ f = sha1create("%s-%s.%s", base_name,
+ sha1_to_hex(object_list_sha1), "pack");
hdr.hdr_signature = htonl(PACK_SIGNATURE);
hdr.hdr_version = htonl(PACK_VERSION);
- hdr.hdr_entries = htonl(nr_objects);
+ hdr.hdr_entries = htonl(nr_result);
sha1write(f, &hdr, sizeof(hdr));
offset = sizeof(hdr);
for (i = 0; i < nr_objects; i++)
@@ -341,9 +354,10 @@ static void write_pack_file(void)
static void write_index_file(void)
{
int i;
- struct sha1file *f = sha1create("%s-%s.%s", base_name, sha1_to_hex(object_list_sha1), "idx");
+ struct sha1file *f = sha1create("%s-%s.%s", base_name,
+ sha1_to_hex(object_list_sha1), "idx");
struct object_entry **list = sorted_by_sha;
- struct object_entry **last = list + nr_objects;
+ struct object_entry **last = list + nr_result;
unsigned int array[256];
/*
@@ -368,7 +382,7 @@ static void write_index_file(void)
* Write the actual SHA1 entries..
*/
list = sorted_by_sha;
- for (i = 0; i < nr_objects; i++) {
+ for (i = 0; i < nr_result; i++) {
struct object_entry *entry = *list++;
unsigned int offset = htonl(entry->offset);
sha1write(f, &offset, 4);
@@ -378,27 +392,87 @@ static void write_index_file(void)
sha1close(f, NULL, 1);
}
-static int add_object_entry(unsigned char *sha1, unsigned int hash)
+static int locate_object_entry_hash(const unsigned char *sha1)
+{
+ int i;
+ unsigned int ui;
+ memcpy(&ui, sha1, sizeof(unsigned int));
+ i = ui % object_ix_hashsz;
+ while (0 < object_ix[i]) {
+ if (!memcmp(sha1, objects[object_ix[i]-1].sha1, 20))
+ return i;
+ if (++i == object_ix_hashsz)
+ i = 0;
+ }
+ return -1 - i;
+}
+
+static struct object_entry *locate_object_entry(const unsigned char *sha1)
+{
+ int i;
+
+ if (!object_ix_hashsz)
+ return NULL;
+
+ i = locate_object_entry_hash(sha1);
+ if (0 <= i)
+ return &objects[object_ix[i]-1];
+ return NULL;
+}
+
+static void rehash_objects(void)
{
+ int i;
+ struct object_entry *oe;
+
+ object_ix_hashsz = nr_objects * 2;
+ if (object_ix_hashsz < 256)
+ object_ix_hashsz = 256;
+ object_ix = xrealloc(object_ix, sizeof(int) * object_ix_hashsz);
+ object_ix = memset(object_ix, 0, sizeof(int) * object_ix_hashsz);
+ for (i = 0, oe = objects; i < nr_objects; i++, oe++) {
+ int ix = locate_object_entry_hash(oe->sha1);
+ if (0 <= ix)
+ continue;
+ ix = -1 - ix;
+ object_ix[ix] = i + 1;
+ }
+}
+
+static int add_object_entry(const unsigned char *sha1, const char *name, int exclude)
+{
+ unsigned int hash = 0;
unsigned int idx = nr_objects;
struct object_entry *entry;
struct packed_git *p;
unsigned int found_offset = 0;
struct packed_git *found_pack = NULL;
+ int ix;
- for (p = packed_git; p; p = p->next) {
- struct pack_entry e;
- if (find_pack_entry_one(sha1, &e, p)) {
- if (incremental)
- return 0;
- if (local && !p->pack_local)
- return 0;
- if (!found_pack) {
- found_offset = e.offset;
- found_pack = e.p;
+ if (!exclude) {
+ for (p = packed_git; p; p = p->next) {
+ struct pack_entry e;
+ if (find_pack_entry_one(sha1, &e, p)) {
+ if (incremental)
+ return 0;
+ if (local && !p->pack_local)
+ return 0;
+ if (!found_pack) {
+ found_offset = e.offset;
+ found_pack = e.p;
+ }
}
}
}
+ if ((entry = locate_object_entry(sha1)) != NULL)
+ goto already_added;
+
+ while (*name) {
+ unsigned char c = *name++;
+ if (isspace(c))
+ continue;
+ hash = hash * 11 + c;
+ }
if (idx >= nr_alloc) {
unsigned int needed = (idx + 1024) * 3 / 2;
@@ -406,45 +480,79 @@ static int add_object_entry(unsigned cha
nr_alloc = needed;
}
entry = objects + idx;
+ nr_objects = idx + 1;
memset(entry, 0, sizeof(*entry));
memcpy(entry->sha1, sha1, 20);
entry->hash = hash;
- if (found_pack) {
- entry->in_pack = found_pack;
- entry->in_pack_offset = found_offset;
+
+ if (object_ix_hashsz <= nr_objects * 2)
+ rehash_objects();
+ else {
+ ix = locate_object_entry_hash(entry->sha1);
+ if (0 <= ix)
+ die("internal error in object hashing.");
+ object_ix[-1 - ix] = idx + 1;
+ }
+
+ already_added:
+ if (exclude)
+ entry->preferred_base = 1;
+ else {
+ if (found_pack) {
+ entry->in_pack = found_pack;
+ entry->in_pack_offset = found_offset;
+ }
}
- nr_objects = idx+1;
return 1;
}
-static int locate_object_entry_hash(unsigned char *sha1)
+static void add_pbase_tree(struct tree_desc *tree)
{
- int i;
- unsigned int ui;
- memcpy(&ui, sha1, sizeof(unsigned int));
- i = ui % object_ix_hashsz;
- while (0 < object_ix[i]) {
- if (!memcmp(sha1, objects[object_ix[i]-1].sha1, 20))
- return i;
- if (++i == object_ix_hashsz)
- i = 0;
+ while (tree->size) {
+ const unsigned char *sha1;
+ const char *name;
+ unsigned mode;
+ unsigned long size;
+ char type[20];
+
+ sha1 = tree_entry_extract(tree, &name, &mode);
+ update_tree_entry(tree);
+ if (!has_sha1_file(sha1))
+ continue;
+ if (sha1_object_info(sha1, type, &size))
+ continue;
+ add_object_entry(sha1, name, 1);
+ if (!strcmp(type, "tree")) {
+ struct tree_desc sub;
+ void *elem;
+ elem = read_sha1_file(sha1, type, &sub.size);
+ sub.buf = elem;
+ if (sub.buf) {
+ add_pbase_tree(&sub);
+ free(elem);
+ }
+ }
}
- return -1 - i;
}
-static struct object_entry *locate_object_entry(unsigned char *sha1)
+static void add_preferred_base(unsigned char *sha1)
{
- int i = locate_object_entry_hash(sha1);
- if (0 <= i)
- return &objects[object_ix[i]-1];
- return NULL;
+ struct tree_desc tree;
+ void *elem;
+ elem = read_object_with_reference(sha1, "tree", &tree.size, NULL);
+ tree.buf = elem;
+ if (!tree.buf)
+ return;
+ add_object_entry(sha1, "", 1);
+ add_pbase_tree(&tree);
+ free(elem);
}
static void check_object(struct object_entry *entry)
{
char type[20];
- if (entry->in_pack) {
+ if (entry->in_pack && !entry->preferred_base) {
unsigned char base[20];
unsigned long size;
struct object_entry *base_entry;
@@ -463,7 +571,8 @@ static void check_object(struct object_e
*/
if (!no_reuse_delta &&
entry->in_pack_type == OBJ_DELTA &&
- (base_entry = locate_object_entry(base))) {
+ (base_entry = locate_object_entry(base)) &&
+ (!base_entry->preferred_base)) {
/* Depth value does not matter - find_deltas()
* will never consider reused delta as the
@@ -501,25 +610,6 @@ static void check_object(struct object_e
sha1_to_hex(entry->sha1), type);
}
-static void hash_objects(void)
-{
- int i;
- struct object_entry *oe;
-
- object_ix_hashsz = nr_objects * 2;
- object_ix = xcalloc(sizeof(int), object_ix_hashsz);
- for (i = 0, oe = objects; i < nr_objects; i++, oe++) {
- int ix = locate_object_entry_hash(oe->sha1);
- if (0 <= ix) {
- error("the same object '%s' added twice",
- sha1_to_hex(oe->sha1));
- continue;
- }
- ix = -1 - ix;
- object_ix[ix] = i + 1;
- }
-}
-
static unsigned int check_delta_limit(struct object_entry *me, unsigned int n)
{
struct object_entry *child = me->delta_child;
@@ -538,7 +628,6 @@ static void get_object_details(void)
int i;
struct object_entry *entry;
- hash_objects();
prepare_pack_ix();
for (i = 0, entry = objects; i < nr_objects; i++, entry++)
check_object(entry);
@@ -576,6 +665,24 @@ static int sha1_sort(const struct object
return memcmp(a->sha1, b->sha1, 20);
}
+static struct object_entry **create_final_object_list()
+{
+ struct object_entry **list;
+ int i, j;
+
+ for (i = nr_result = 0; i < nr_objects; i++)
+ if (!objects[i].preferred_base)
+ nr_result++;
+ list = xmalloc(nr_result * sizeof(struct object_entry *));
+ for (i = j = 0; i < nr_objects; i++) {
+ if (!objects[i].preferred_base)
+ list[j++] = objects + i;
+ }
+ current_sort = sha1_sort;
+ qsort(list, nr_result, sizeof(struct object_entry *), sort_comparator);
+ return list;
+}
+
static int type_size_sort(const struct object_entry *a, const struct object_entry *b)
{
if (a->type < b->type)
@@ -586,6 +693,10 @@ static int type_size_sort(const struct o
return -1;
if (a->hash > b->hash)
return 1;
+ if (a->preferred_base < b->preferred_base)
+ return -1;
+ if (a->preferred_base > b->preferred_base)
+ return 1;
if (a->size < b->size)
return -1;
if (a->size > b->size)
@@ -610,6 +721,8 @@ static int try_delta(struct unpacked *cu
{
struct object_entry *cur_entry = cur->entry;
struct object_entry *old_entry = old->entry;
+ int old_preferred = (old_entry->preferred_base ||
+ old_entry->based_on_preferred);
unsigned long size, oldsize, delta_size, sizediff;
long max_size;
void *delta_buf;
@@ -618,9 +731,15 @@ static int try_delta(struct unpacked *cu
if (cur_entry->type != old_entry->type)
return -1;
- /* If the current object is at edge, take the depth the objects
- * that depend on the current object into account -- otherwise
- * they would become too deep.
+ /* We do not compute delta to *create* objects we are not
+ * going to pack.
+ */
+ if (cur_entry->preferred_base)
+ return -1;
+
+ /* If the current object is at pack edge, take the depth the
+ * objects that depend on the current object into account --
+ * otherwise they would become too deep.
*/
if (cur_entry->delta_child) {
if (max_depth <= cur_entry->delta_limit)
@@ -646,8 +765,27 @@ static int try_delta(struct unpacked *cu
* delete).
*/
max_size = size / 2 - 20;
- if (cur_entry->delta)
- max_size = cur_entry->delta_size-1;
+ if (cur_entry->delta) {
+ if (cur_entry->based_on_preferred) {
+ if (old_preferred)
+ max_size = cur_entry->delta_size-1;
+ else
+ /* trying with non-preferred one when we
+ * already have a delta based on preferred
+ * one is pointless.
+ */
+ return 0;
+ }
+ else if (!old_preferred)
+ max_size = cur_entry->delta_size-1;
+ else
+ /* otherwise... even if delta with a
+ * preferred one produces a bigger result than
+ * what we currently have, which is based on a
+ * non-preferred one, it is OK.
+ */
+ ;
+ }
if (sizediff >= max_size)
return -1;
delta_buf = diff_delta(old->data, oldsize,
@@ -657,6 +795,7 @@ static int try_delta(struct unpacked *cu
cur_entry->delta = old_entry;
cur_entry->delta_size = delta_size;
cur_entry->depth = old_entry->depth + 1;
+ cur_entry->based_on_preferred = old_preferred;
free(delta_buf);
return 0;
}
@@ -722,7 +861,7 @@ static void find_deltas(struct object_en
static void prepare_pack(int window, int depth)
{
if (progress)
- fprintf(stderr, "Packing %d objects", nr_objects);
+ fprintf(stderr, "Packing %d objects", nr_result);
get_object_details();
if (progress)
fputc('.', stderr);
@@ -861,8 +1000,6 @@ int main(int argc, char **argv)
gettimeofday(&prev_tv, NULL);
}
while (fgets(line, sizeof(line), stdin) != NULL) {
- unsigned int hash;
- char *p;
unsigned char sha1[20];
if (progress && (eye_candy <= nr_objects)) {
@@ -881,31 +1018,32 @@ int main(int argc, char **argv)
}
eye_candy += eye_candy_incr;
}
+ if (line[0] == '-') {
+ if (get_sha1_hex(line+1, sha1))
+ die("expected edge sha1, got garbage:\n %s",
+ line+1);
+ add_preferred_base(sha1);
+ continue;
+ }
if (get_sha1_hex(line, sha1))
die("expected sha1, got garbage:\n %s", line);
- hash = 0;
- p = line+40;
- while (*p) {
- unsigned char c = *p++;
- if (isspace(c))
- continue;
- hash = hash * 11 + c;
- }
- add_object_entry(sha1, hash);
+ add_object_entry(sha1, line+40, 0);
}
if (progress)
fprintf(stderr, "Done counting %d objects.\n", nr_objects);
if (non_empty && !nr_objects)
return 0;
- sorted_by_sha = create_sorted_list(sha1_sort);
+ sorted_by_sha = create_final_object_list();
SHA1_Init(&ctx);
list = sorted_by_sha;
- for (i = 0; i < nr_objects; i++) {
+ for (i = 0; i < nr_result; i++) {
struct object_entry *entry = *list++;
SHA1_Update(&ctx, entry->sha1, 20);
}
SHA1_Final(object_list_sha1, &ctx);
+ if (progress && (nr_objects != nr_result))
+ fprintf(stderr, "Result has %d objects.\n", nr_result);
if (reuse_cached_pack(object_list_sha1, pack_to_stdout))
;
@@ -918,6 +1056,6 @@ int main(int argc, char **argv)
}
if (progress)
fprintf(stderr, "Total %d, written %d (delta %d), reused %d (delta %d)\n",
- nr_objects, written, written_delta, reused, reused_delta);
+ nr_result, written, written_delta, reused, reused_delta);
return 0;
}
--
1.2.2.g0d27
^ permalink raw reply related
* Re: Fixing author/email fields in commit messages
From: Jon Nelson @ 2006-02-19 23:34 UTC (permalink / raw)
Cc: git
In-Reply-To: <43F9005E.30901@gmail.com>
On Mon, 20 Feb 2006, Jacob Kroon wrote:
> Jon Nelson wrote:
>
> > >I modified git-convert-objects to perform just that task.
> > >I'll see if I can dig it up (I'm not able to do so right now).
> > >
> > >
> >
> >Attached. Notes:
> >
> >1. it's ugly
> >2. it's indented funny
> >3. it didn't seem to break anything for me, but no guarantees
> >4. it probably smells of elderberries
> >5. set your GIT_* environment up properly first or you'll wonder why it
> >doesn't work like I did.
> >
> >
> >
> Hi Jon,
>
> I've applied your patch to the latest git sources, and it compiles, but I'm
> not quite sure how to
> invoke the command. I've setup GIT_* env. variables, and git-convert-objects
> needs a sha1 identifier.
> I've tried passing "HEAD", and some other commit id's, but they don't seem to
> make any difference.
> Am I doing things right ? How exactly do I invoke the command to clean up the
> commit messages ?
>
> At least I don't get any error messages.
If I recall properly, it should be sufficient to invoke it with the sha1
of the HEAD branch.
Thus, you could use:
git-convert-objects $(git-rev-list --max-count=1 HEAD)
To do /all/ of the branches:
for branch in $(cat .git/refs/heads/* | sort | uniq); do
git-convert-objects ${branch}
done
It should work on tags, too, although I only tested on my own git stuff
which was converted from cvs.
--
Jon Nelson <jnelson-git@jamponi.net>
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Jacob Kroon @ 2006-02-20 1:21 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602191729100.6352@gheavc.wnzcbav.cig>
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
After some more private discussion (I forgot to CC the mailing list)
with Jon Nelson,
he came up with this strategy for fixing the author/email part of commit
messages:
0. Make a backup copy of the repository, just in case.
1. Setup your GIT_AUTHOR_xxx/GIT_COMMITTER_xxx env. variables correctly.
2. Apply the attached patch to recent git sources. (patch made by Jon
Nelson).
3. Run the patched git-convert-objects, passing HEAD as argument.
4. Run "git-update-ref HEAD 'newsha1'", where 'newsha1' is the output
from the previous command.
5. Run "git-prune" to get rid of the old stale object files.
This worked for me, but I guess there are no warranties 8)
In case you have multiple branches you might need to repeat the
procedure for each branch.
thanks Jon
//Jacob
[-- Attachment #2: convert-objects.diff --]
[-- Type: text/x-patch, Size: 9372 bytes --]
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..109bfb0 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -263,7 +263,156 @@ static void convert_date(void *buffer, u
newlen += size;
write_sha1_file(new, newlen, "commit", result_sha1);
- free(new);
+ free(new);
+}
+
+static int convert_email_line(char *dst, void **buf, unsigned long *sp, const char *name, const char *new_email)
+{
+ unsigned long size = *sp;
+ char *line = *buf;
+ char *space = strchr(line, ' ');
+ char *next = strchr(line, '\n');
+ char *email_start = strchr(line, '<');
+ char *email_end = strchr(line, '>');
+ int len, total = 0;
+
+ // "author|committer xyz <xyz> date"
+ // "committer xyz <xyz> date"
+ if (!space || !next || !email_start || !email_end)
+ die("missing or bad author/committer line %s", line);
+
+ ++space;
+ ++email_start;
+ ++next;
+
+ //fprintf(stderr, "yikes: size; %lu \"%s\"\n", size, line);
+
+ *buf = next;
+ *sp = size - (next - line);
+
+ /* copy the stuff from before the name */
+ len = space - line;
+ memcpy(dst, line, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* copy the new name */
+ len = strlen(name);
+ memcpy(dst, name, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* put a space in there */
+ *dst = ' ';
+ ++dst;
+ ++total;
+ --size;
+
+ /* put a '<' in there */
+ *dst = '<';
+ ++dst;
+ ++total;
+ --size;
+
+ /* copy the new email */
+ len = strlen(new_email);
+ memcpy(dst, new_email, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ /* copy the rest of the line */
+ len = next - email_end;
+ memcpy(dst, email_end, len);
+ dst += len;
+ total += len;
+ size -= len;
+
+ return total;
+}
+
+static void convert_authorcommitter(void *buffer, unsigned long size, unsigned char *result_sha1)
+{
+ char *new = xmalloc(size + 100);
+ unsigned long newlen = 0;
+ char *author_info = strdup(git_author_info());
+ char *committer_info = strdup(git_committer_info());
+ char *author_name, *author_email;
+ char *committer_name, *committer_email;
+ char *temp;
+
+//#define TESTING
+#ifdef TESTING
+ fprintf(stderr, "author_info: \"%s\"\n",
+ author_info);
+ fprintf(stderr, "committer_info: \"%s\"\n",
+ committer_info);
+#endif
+ author_name = author_info;
+ temp = strchr(author_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ author_email = temp;
+ temp = strrchr(author_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ committer_name = committer_info;
+ temp = strchr(committer_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ committer_email = temp;
+ temp = strrchr(committer_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+#ifdef TESTING
+ fprintf(stderr, "author_name: \"%s\"\n", author_name);
+ fprintf(stderr, "author_email: \"%s\"\n", author_email);
+ fprintf(stderr, "committer_name: \"%s\"\n", committer_name);
+ fprintf(stderr, "committer_email: \"%s\"\n", committer_email);
+ exit(0);
+#endif
+
+ // "tree <sha1>\n"
+ memcpy(new + newlen, buffer, 46);
+ newlen += 46;
+ buffer += 46;
+ size -= 46;
+
+ // "parent <sha1>\n"
+ while (!memcmp(buffer, "parent ", 7)) {
+ memcpy(new + newlen, buffer, 48);
+ newlen += 48;
+ buffer += 48;
+ size -= 48;
+ }
+
+ // "author xyz <xyz> date"
+ // "committer xyz <xyz> date"
+ newlen += convert_email_line(new + newlen, &buffer, &size, author_name, author_email);
+ newlen += convert_email_line(new + newlen, &buffer, &size, committer_name, committer_email);
+
+ // Rest
+ memcpy(new + newlen, buffer, size);
+ newlen += size;
+
+ write_sha1_file(new, newlen, "commit", result_sha1);
+ free(new);
+ free(author_info);
+ free(committer_info);
}
static void convert_commit(void *buffer, unsigned long size, unsigned char *result_sha1)
@@ -279,7 +428,117 @@ static void convert_commit(void *buffer,
convert_ascii_sha1(buffer+7);
buffer += 48;
}
- convert_date(orig_buffer, orig_size, result_sha1);
+ convert_authorcommitter(orig_buffer, orig_size, result_sha1);
+}
+
+static void convert_tag(void *buffer, unsigned long size, unsigned char *result_sha1)
+{
+ void *orig_buffer = buffer;
+
+ char *new = xmalloc(size + 100);
+ unsigned long newlen = 0;
+
+ char *author_info = strdup(git_author_info());
+ char *committer_info = strdup(git_committer_info());
+ char *author_name, *author_email;
+ char *committer_name, *committer_email;
+ char *temp;
+ unsigned long len = 0;
+ char *email_start;
+ char *email_end;
+ char *author_start;
+ int has_author = 1;
+
+ author_name = author_info;
+ temp = strchr(author_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ author_email = temp;
+ temp = strrchr(author_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ committer_name = committer_info;
+ temp = strchr(committer_name, '<');
+ if (!temp)
+ die("Unable to find valid name address.");
+ --temp;
+ *temp = '\0';
+ temp += 2;
+
+ committer_email = temp;
+ temp = strrchr(committer_email, '>');
+ if (!temp)
+ die("Unable to find valid email address.");
+ *temp = '\0';
+
+ //* START *//
+
+ if (memcmp(buffer, "object ", 7))
+ die("Bad tag '%s'", (char*) buffer);
+ convert_ascii_sha1(buffer+7);
+// fprintf(stderr, "converting %s", (char *) (buffer + 7));
+ buffer += 7 + 40 + 1; /* "object " + "hex sha1" + "\n" */
+ /* type commit
+ tag boa-0.94.14rc6
+ tagger...
+ */
+ /* with tagger, we check for tagger author_name <author_email>
+ * and if so, we convert that, too
+ */
+ temp = strchr(buffer, '\n'); /* end of commit line */
+ if (!temp) {
+ die("Bad tag '%s'", (char *) buffer);
+ }
+ ++temp;
+ temp = strchr(temp, '\n'); /* end of tag line */
+ if (!temp) {
+ die("Bad tag '%s'", (char *) buffer);
+ }
+ ++temp;
+ if (memcmp(temp, "tagger ", 7))
+ die("Bad tag '%s'", (char *) buffer);
+ temp += 7; /* just after 'tagger ' */
+
+ len = (temp - (char *) orig_buffer);
+ memcpy(new, orig_buffer, len);
+ newlen += len;
+ ++temp;
+
+ /* check to see if the next item looks like an name + email */
+ email_start = strchr(temp, '<');
+ if (email_start) {
+ email_end = strchr(email_start, '>');
+ if (email_end) {
+ author_start = strchr(temp, ' ');
+ if (author_start && author_start < email_start) {
+ has_author = 1;
+ newlen += sprintf(new + newlen,
+ "%s <%s>\n",
+ author_name,
+ author_email);
+ len = (email_end - (char *) buffer) + 2;
+ }
+
+ }
+ }
+
+ if (len > size) {
+ memcpy(new + newlen, orig_buffer + len, size - len);
+ newlen += (size - len);
+ }
+// fprintf(stderr, "About to write: %s", new);
+// exit(0);
+
+ write_sha1_file(new, newlen, "tag", result_sha1);
+ free(new);
+ free(author_info);
+ free(committer_info);
}
static struct entry * convert_entry(unsigned char *sha1)
@@ -297,13 +556,15 @@ static struct entry * convert_entry(unsi
buffer = xmalloc(size);
memcpy(buffer, data, size);
-
+
if (!strcmp(type, "blob")) {
write_sha1_file(buffer, size, "blob", entry->new_sha1);
- } else if (!strcmp(type, "tree"))
- convert_tree(buffer, size, entry->new_sha1);
- else if (!strcmp(type, "commit"))
- convert_commit(buffer, size, entry->new_sha1);
+ } else if (!strcmp(type, "tree"))
+ convert_tree(buffer, size, entry->new_sha1);
+ else if (!strcmp(type, "commit"))
+ convert_commit(buffer, size, entry->new_sha1);
+ else if (!strcmp(type, "tag"))
+ convert_tag(buffer, size, entry->new_sha1);
else
die("unknown object type '%s' in %s", type, sha1_to_hex(sha1));
entry->converted = 1;
@@ -318,6 +579,7 @@ int main(int argc, char **argv)
struct entry *entry;
setup_git_directory();
+ setup_ident();
if (argc != 2 || get_sha1(argv[1], sha1))
usage("git-convert-objects <sha1>");
^ permalink raw reply related
* [PATCH] Convert the git faq to asciidoc
From: Jonas Fonseca @ 2006-02-20 1:45 UTC (permalink / raw)
To: Thomas Riboulet; +Cc: git
In-Reply-To: <22e91bb0602151636r2e70e60cpa5038f4b6caccc9c@mail.gmail.com>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Thomas Riboulet <riboulet@gmail.com> wrote Thu, Feb 16, 2006:
> Comments and suggestions are welcome (on the content, the form, format, etc ...)
> I'll try to add questions from the archives of this ml, I'm also open
> to any suggestions.
As promissed on the #git channel this patch converts the faq to asciidoc
format, with a few enhancements such as links to manpages and a TOC.
Previews at
http://www.diku.dk/hjemmesider/studerende/fonseca/git/git-faq.{html,txt,xml}.
---
Makefile | 23 ++++++++
faq.conf | 19 +++++++
faq.txt | 175 ++++++++++++++++++++++++++++++++++++++++++--------------------
3 files changed, 161 insertions(+), 56 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..09f6978
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,23 @@
+all: git-faq.html git-faq.xml git-faq.txt
+
+clean:
+ rm -f git-faq.html git-faq.xml git-faq.txt faq-toc.txt
+
+git-faq.html git-faq.xml git-faq.txt: faq.txt faq-toc.txt
+
+git-faq.xml:
+ asciidoc -f faq.conf -b docbook -d article -o $@ faq.txt
+
+git-faq.html: faq.txt faq-toc.txt
+ asciidoc -f faq.conf -b xhtml11 -d article -o $@ faq.txt
+
+git-faq.txt: git-faq.html
+ elinks --no-numbering --no-references --dump $< > $@
+
+faq-toc.txt: faq.txt
+ sed -n '/^\[\[/,/--/p' < $< | while read line; do \
+ case "$$line" in \
+ "[["*"]]") echo -n ". <<$$line, " | sed 's/\[\[\(.*\)\]\]/\1/' ;; \
+ --*) echo ">>" ;; \
+ *) echo -n "$$line " ;; \
+ esac; done > $@
diff --git a/faq.conf b/faq.conf
new file mode 100644
index 0000000..fa16ad6
--- /dev/null
+++ b/faq.conf
@@ -0,0 +1,19 @@
+# AsciiDoc FAQ definitions
+
+[attributes]
+gitdoc-base=http://kernel.org/pub/software/scm/git/docs/
+cgdoc-base=http://kernel.org/pub/software/scm/cogito/docs/
+
+ifdef::backend-docbook[]
+[gitdoc-inlinemacro]
+<ulink url="{gitdoc-base}{target}.html">{0}</ulink>
+[cgdoc-inlinemacro]
+<ulink url="{cgdoc-base}{target}.html">{0}</ulink>
+endif::backend-docbook[]
+
+ifdef::backend-xhtml11[]
+[gitdoc-inlinemacro]
+<a href="{gitdoc-base}{target}.html">{0}</a>
+[cgdoc-inlinemacro]
+<a href="{cgdoc-base}{target}.html">{0}</a>
+endif::backend-xhtml11[]
diff --git a/faq.txt b/faq.txt
index e719d04..9c7baa0 100644
--- a/faq.txt
+++ b/faq.txt
@@ -1,68 +1,131 @@
-Why the 'git' name ?
-
-As Linus' own words as the inventor of git : "git" can mean anything, depending on your mood.
-
-* random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
-* stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
-* global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
-* "goddamn idiotic truckload of sh*t": when it breaks
-
-
-Can I share a git public repository and use it in a CVS way ?
-
-Use cg-admin-setuprepo -g or do git-init-db --shared and some additional stuff. It's ok that refs aren't group writable, it's enough the directory is. See Cogito README or GIT's cvs-migration doc, "Emulating the CVS Development Model" for details.
-
-
-Git commit is dying telling me "fatal : empty ident <user@myhost> not allowed" , what's wrong ?
-
-Make sure your Full Name is not empty in chsh or the 5th field of your user line in /etc/passwd isn't empty. You can also set the GIT_AUTHOR_NAME environment variable. If you @myhost is empty make sure your hostname is correctly set.
-What's the difference between fetch and pull ?
-
-Fetch : download objects and a head from another repository.
-Pull : fetch (as defined above) and merge with the current development.
-See man git-fetch and git-pull or the tutorials for more details.
-
-
-
-Can I tell git to ignore files ?
-
-Yes. If you want to ignore files localy (only for you in your local work copy) put the files path in the repository in the .git/info/exclude file.
-
-If you want to make the ignore matters for all and everyone who checkouts the project you have to put the files path in the .gitignore in the tree itself.
-
-
-Can I import from cvs ?
-
-Yes. Use git-cvsimport. See the cvs-migration doc for more details.
-
-
-Can I import from svn ?
-
-Yes. Use git-svnimport. See the svn-import doc for more details.
+The git FAQ
+===========
+:Author: Thomas Riboulet
+:CorpAuthor: git mailing list
+
+//////////////////////////////////////////////////////////////////////////////
+A note about required info for FAQ entries. Please use the following template:
+
+ [[question-id]]
+ question?
+ ---------
+ answer.
+
+The question-id + question will be used for generating a table of contents.
+//////////////////////////////////////////////////////////////////////////////
+
+// DocBook derived output will (hopefully) have it's own TOC
+ifdef::backend-xhtml11[]
+include::faq-toc.txt[]
+endif::backend-xhtml11[]
+
+[[git-name]]
+Why the 'git' name?
+-------------------
+In Linus' own words as the inventor of git: "git" can mean anything, depending
+on your mood:
+
+ - random three-letter combination that is pronounceable, and not actually
+ used by any common UNIX command. The fact that it is a mispronunciation of
+ "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+ dictionary of slang.
+ - global information tracker": you're in a good mood, and it actually works
+ for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+
+[[repo-sharing]]]
+Can I share a git public repository and use it in a CVS way?
+------------------------------------------------------------
+Use cg-admin-setuprepo -g or do git-init-db --shared and some additional
+stuff. It's ok that refs aren't group writable, it's enough the directory is.
+See Cogito README or GIT's cvs-migration doc, "Emulating the CVS Development
+Model" for details.
+
+
+[[empty-ident]]
+Git commit is dying telling me "fatal: empty ident <user@myhost> not allowed", what's wrong?
+--------------------------------------------------------------------------------------------
+Make sure your Full Name is not empty in chsh or the 5th field of your user
+line in `/etc/passwd` isn't empty. You can also set the `GIT_AUTHOR_NAME`
+environment variable. If your @myhost is empty make sure your hostname is
+correctly set. Use gitdoc:git-var[`git-var -l`] to make git display user
+identity variables.
+
+
+[[fetch-vs-pull]]
+What's the difference between fetch and pull?
+---------------------------------------------
+The short definition is:
+
+Fetch:: Download objects and a head from another repository.
+Pull:: Fetch (as defined above) and merge with the current development.
+
+See the gitdoc:git-fetch[git-fetch(1)] and gitdoc:git-pull[git-pull(1)]
+manpages or the tutorials for more details.
+
+
+[[gitignore]]
+Can I tell git to ignore files?
+-------------------------------
+Yes. If you want to ignore files localy (only for you in your local work copy)
+put the files path in the repository in the `.git/info/exclude` file.
+
+If you want to make the ignore matters for all and everyone who checkouts the
+project you have to put the files path in the `.gitignore` in the tree itself.
+
+
+[[import-cvs]]
+Can I import from CVS?
+----------------------
+Yes. Use git-cvsimport. See the gitdoc:git-cvsimport[git-cvsimport(1)] or
+gitdoc:cvs-migration[the CVS migration doc] for more detail.
+
+
+[[import-svn]]
+Can I import from svn?
+----------------------
+Yes. Use git-svnimport. See gitdoc:git-svnimport[git-svnimport(1)] for more
+details.
+[[import-arch]]
Can I import from arch/baz/tla?
-
-Yes. Use git-archimport.
+-------------------------------
+Yes. Use git-svnimport. See gitdoc:git-archimport[git-archimport(1)] for more
+details.
+[[import-others]]
Can I import from others?
+-------------------------
+Maybe -- check if http://www.darcs.net/DarcsWiki/Tailor[tailor.py] can do it.
-Maybe -- check if tailor.py can do it. Check http://www.darcs.net/DarcsWiki/Tailor.
-
-
-How old linus bk repos have been import to git ?
+[[linux-bk]]
+How was the old Linux BitKeeper repository imported into git?
+-------------------------------------------------------------
Using the CVS gateway, via git-cvsimport.
-What can I use to setup a public repository ?
-
-A ssh server, an http server, or the git-daemon. See the tutorial for more details.
-
-
-Why won't git let me change to a different branch using "git checkout <branch>" or "git checkout -b <branch>"?
-
-Instead it just says: fatal: Entry 'foo.c' not uptodate. Cannot merge.
+[[public-repo]]
+What can I use to setup a public repository?
+--------------------------------------------
+A SSH server, an HTTP server, or the gitdoc:git-daemon[git-daemon]. See the
+tutorial for more details.
+
+
+[[change-branch]]
+Why won't git let me change to a different branch?
+--------------------------------------------------
+Using "git checkout <branch>" or "git checkout -b <branch>" it just says:
+
+ fatal: Entry 'foo.c' not uptodate. Cannot merge.
+
+You have changes to files in your working directory that will be overwritten,
+removed or otherwise lost if the checkout and change to the new branch were to
+proceed. To fix this you may either check your changes in, create a patch of
+your changes and revert your files, or use the "-m" flag like this:
-You have changes to files in your working directory that will be overwritten, removed or otherwise lost if the checkout and change to the new branch were to proceed. To fix this you may either check your changes in, create a patch of your changes and revert your files, or use the "-m" flag like this: git checkout -m -b my-branch
+ git checkout -m -b my-branch
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Jonas Fonseca @ 2006-02-20 2:01 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, junkio
In-Reply-To: <e5bfff550602190200j1ef3858as6a1564064dc81fef@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote Sun, Feb 19, 2006:
> + - *gitview* (contrib/)
> +
> + gitview is a GTK based repository browser for git
> +
> +
> + - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
> +
> + GITweb provides full-fledged web interface for GIT repositories.
You can make it more asciidoc-friendly if you convert the list to use
the format:
*gitview* (contrib)::
gitview is a GTK based repository browser for git
ftp://ftp.kernel.org/pub/software/scm/gitweb/[*gitweb*]::
GITweb provides full-fledged web interface for GIT repositories.
--
Jonas Fonseca
^ permalink raw reply
* Re: New shiny gitk
From: walt @ 2006-02-20 2:04 UTC (permalink / raw)
To: git
In-Reply-To: <17400.23434.724188.649656@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> I just created a branch called "new" in my gitk repository at
>
> git://git.kernel.org/pub/scm/gitk/gitk.git
Thanks. The new version seems to fix a bug I posted about
last week concerning searching on filenames. I like it!
^ permalink raw reply
* Re: [PATCH] git-rev-list --help anywhere
From: Junio C Hamano @ 2006-02-20 5:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, linux, git
In-Reply-To: <Pine.LNX.4.63.0602192023270.11855@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> can someone please enlighten me why you need to see the usage, when you
> cannot execute the command anyway?
I think Pasky gave rev-list just as an example, as I am sure
there are other lowlevel core tools, that share this same
unfriendliness. Primarily, these tools are meant for scripting,
and not for end-user interactive use. For this reason, it is
not high on my priority list to add --help to the lowlevel core
tools, although it would be nicer to have.
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-20 6:21 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, junkio
In-Reply-To: <20060220020147.GB8759@diku.dk>
On 2/20/06, Jonas Fonseca <fonseca@diku.dk> wrote:
> Marco Costalba <mcostalba@gmail.com> wrote Sun, Feb 19, 2006:
> > + - *gitview* (contrib/)
> > +
> > + gitview is a GTK based repository browser for git
> > +
> > +
> > + - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
> > +
> > + GITweb provides full-fledged web interface for GIT repositories.
>
> You can make it more asciidoc-friendly if you convert the list to use
> the format:
>
> *gitview* (contrib)::
>
> gitview is a GTK based repository browser for git
>
> ftp://ftp.kernel.org/pub/software/scm/gitweb/[*gitweb*]::
>
> GITweb provides full-fledged web interface for GIT repositories.
>
> --
> Jonas Fonseca
>
Thanks, I will change the format.
I am waiting to collect some more comments so to change git-tools.txt only once.
Marco
^ permalink raw reply
* git-svnimport -- http/dav authentication notes
From: Martin Langhoff @ 2006-02-20 7:24 UTC (permalink / raw)
To: Git Mailing List
After a lot of trial and error against a server I don't control (so I
can't log things on) I've managed to use svn-import on it and it
mostly seems to work. Kind of. It's slowly grinding through the
commits.
To make it short, I seem to be doing well with:
git-svnimport -t tags -T trunk -b branches -o svntrunk -v
'http://martin%40catalyst.net.nz:password@nameless.server.org/svn/someproject'
The repo has LDAP authentication, and the username is my email
address, so I guessed that url-encoding would work, and it did.
svnimport is a bit of a mistery actually. I often know if it's really
doing the import or the files are going to be there but empty. SVN is
so flexible in its "everything is a directory" way of thinking that if
I mess up -t or -b I get the commits alright... but no files.
Strange world, svn ;-)
martin
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-02-20 7:57 UTC (permalink / raw)
To: git
The updated pack-object series is now in "next" branch, and
seems to be cooking nicely. The "reuse from existing pack"
change seems to be a huge win and I haven't found problems in
there.
There now is further performance improvements for git-send-pack
to avoid sending a huge blob or tree object in its full
representation when we know the other end has a suitable object
to use as the base; instead we can just send it out deltified.
The other end would expand it to a loose object and this would
not make abit of difference in the resulting repository -- only
the bandwidth requirement reduction is visible [*1*].
In principle, this is also applicable for fetch-pack, but it
involves a bit of pack protocol change. The protocol extension
mechanism was done nicely by Johannes a while ago, and we can
use it to implement this with full backward compatibility.
After a bit more testing, we might want to make --thin transfer
the default (even without an option to turn it off -- I just do
not see a point not to use it if it is bug-free).
* The 'master' branch has these since the last announcement.
Junio C Hamano:
fmt-merge-msg: say which branch things were merged into unless 'master'
Allow git-mv to accept ./ in paths.
Documentation: fix typo in rev-parse --short option description.
fmt-merge-msg: do not add excess newline at the end.
Merge branch 'jc/mv'
Merge branch 'jc/merge-msg'
* The 'next' branch, in addition, has these.
Johannes Schindelin:
Fixes for ancient versions of GNU make
avoid makefile override warning
Really honour NO_PYTHON
Junio C Hamano:
Merge branch 'jc/merge-msg' into next
Merge branch 'js/portable' into next
rev-list --objects-edge
Merge branch 'jc/rev-list' into next
Thin pack - create packfile with missing delta base.
send-pack --thin: use "thin pack" delta transfer.
Merge branch 'jc/pack-thin' into next
[Footnote]
*1* The version of the patch I earlier sent to the list had a
grave performance bug; please do not use it. The one in "next"
branch has the bug fixed already.
^ permalink raw reply
* Re: What's in git.git
From: Andreas Ericsson @ 2006-02-20 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bieea32.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The updated pack-object series is now in "next" branch, and
> seems to be cooking nicely. The "reuse from existing pack"
> change seems to be a huge win and I haven't found problems in
> there.
>
Wonderful news. I'll cherry-pick them and do some further testing.
> There now is further performance improvements for git-send-pack
> to avoid sending a huge blob or tree object in its full
> representation when we know the other end has a suitable object
> to use as the base; instead we can just send it out deltified.
> The other end would expand it to a loose object and this would
> not make abit of difference in the resulting repository -- only
> the bandwidth requirement reduction is visible [*1*].
>
How likely is this to increase the CPU-power needed on the server-side?
If there is a blob on the server-side, but far from the deltified object
I suppose we have to look at each commit, perhaps only to discover that
the client doesn't have them and we need to construct the blob anyways.
>
> After a bit more testing, we might want to make --thin transfer
> the default (even without an option to turn it off -- I just do
> not see a point not to use it if it is bug-free).
>
If the answer to my question above is "minimal to none", I agree most
vehemently. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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