* Re: [PATCH] Add a Documentation/git-tools.txt
From: Alan Chandler @ 2006-02-19 12:25 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, junkio
In-Reply-To: <e5bfff550602190200j1ef3858as6a1564064dc81fef@mail.gmail.com>
On Sunday 19 February 2006 10:00, Marco Costalba wrote:
> +
> +Alternative/Argumentative Porcelains
> +------------------------------------
Aren't these "Augmentative Procelains" rather than ones that argue a lot.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-19 12:39 UTC (permalink / raw)
To: Alan Chandler; +Cc: git, junkio
In-Reply-To: <200602191225.54311.alan@chandlerfamily.org.uk>
Alan Chandler ha scritto:
> On Sunday 19 February 2006 10:00, Marco Costalba wrote:
>
>>+
>>+Alternative/Argumentative Porcelains
>>+------------------------------------
>
>
> Aren't these "Augmentative Procelains" rather than ones that argue a lot.
>
Yes, you are arguing correctly!
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Karl Hasselström @ 2006-02-19 13:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <43F84D9A.2010905@gmail.com>
On 2006-02-19 10:51:06 +0000, Catalin Marinas wrote:
> Karl Hasselström wrote:
>
> > diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
> > new file mode 100644
> > index 0000000..4ac0dfb
> > --- /dev/null
> > +++ b/stgit/commands/uncommit.py
> > @@ -0,0 +1,80 @@
> > +__copyright__ = """
> > +Copyright (C) 2006, Catalin Marinas <catalin.marinas@gmail.com>
>
> 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.
:-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: gitk patch display corner-case bug
From: Karl Hasselström @ 2006-02-19 14:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17400.20764.131417.903578@cargo.ozlabs.ibm.com>
On 2006-02-19 22:06:04 +1100, Paul Mackerras wrote:
> Karl Hasselström writes:
>
> > Totally correct except that it omitted the line consisting of only
> > three dashes.
>
> Could you check that the missing line is present in the output from
> git-rev-list --header --parents --topo-order please?
I'm not sure I follow you. The affected commit is listed first by
"git-rev-list --header --parents --topo-order 51cb39db", but that
commad doesn't show diffs, so the missing line is not there.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Karl Hasselström @ 2006-02-19 14:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060219134558.GA4784@diana.vm.bytemark.co.uk>
On 2006-02-19 14:45:58 +0100, Karl Hasselström wrote:
> On 2006-02-19 10:51:06 +0000, Catalin Marinas 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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] So... are people happy with commit/status -v?
From: Christian Biesinger @ 2006-02-19 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvevhj6x4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I usually never do commits from a subdirectory, also I rarely do
> partial commits, so this is not a big issue to me, but are
> people happy with the current commit/status?
The part that annoyed me most was that "git-status --only ." completely
ignores the specified path and tells me about the whole tree, rather
than just the current directory and subdirectories. While I think I'd
prefer it if the commands limited themselves to the current directory by
default, I don't mind the current behaviour, as long as I still have the
possibility to limit to the subdirectory.
^ permalink raw reply
* Re: New shiny gitk
From: Alex Riesen @ 2006-02-19 18:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17400.23434.724188.649656@cargo.ozlabs.ibm.com>
Paul Mackerras, Sun, Feb 19, 2006 12:50:34 +0100:
> 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).
aside from speedup and broken Update (both of which I didn't really
notice yet in the linux tree), I really like the new layout. I suggest
to try it on ACPI monster merge and gits "next" branch. It's simplier
to understand now (because of how the lines are highlighted when you
click on them). Well the latter is a hopeless maze anyway, but you
often can see more of the patch description now.
Thanks!
^ permalink raw reply
* Fixing author/email fields in commit messages
From: Jacob Kroon @ 2006-02-19 18:45 UTC (permalink / raw)
To: git
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 know how to make the future commits look as expected.
//Jacob
^ permalink raw reply
* Re: [PATCH] git-rev-list --help anywhere
From: Alex Riesen @ 2006-02-19 18:39 UTC (permalink / raw)
To: linux; +Cc: Junio C Hamano, git
In-Reply-To: <20060219112627.18989.qmail@science.horizon.com>
linux@horizon.com, Sun, Feb 19, 2006 12:26:27 +0100:
> >+ for (i = 1 ; i < argc; i++)
> >+ if ( !strcmp(argv[i], "--help") )
> >+ usage(rev_list_usage);
>
> You might want to try something more like:
>
> + for (i = 1 ; i < argc; i++) {
> + if ( !strcmp(argv[i], "--help") )
> + usage(rev_list_usage);
> + if ( !strcmp(argv[i], "--") )
> + break;
> + }
>
> So that you don't break in the perverse but legal case of
> having a file named "--help".
Of course. Thanks!
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
diff --git a/rev-list.c b/rev-list.c
index f2d1105..bcb492e 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -755,11 +755,20 @@ static void handle_all(struct commit_lis
int main(int argc, const char **argv)
{
- const char *prefix = setup_git_directory();
+ const char *prefix;
struct commit_list *list = NULL;
int i, limited = 0;
for (i = 1 ; i < argc; i++) {
+ if ( !strcmp(argv[i], "--help") )
+ usage(rev_list_usage);
+ if ( !strcmp(argv[i], "--") )
+ break;
+ }
+
+ prefix = setup_git_directory();
+
+ for (i = 1 ; i < argc; i++) {
int flags;
const char *arg = argv[i];
char *dotdot;
--
1.2.2.gbc57
^ permalink raw reply related
* Re: [PATCH] git-rev-list --help anywhere
From: Johannes Schindelin @ 2006-02-19 19:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: linux, Junio C Hamano, git
In-Reply-To: <20060219183930.GB10010@steel.home>
Hi,
can someone please enlighten me why you need to see the usage, when you
cannot execute the command anyway?
Puzzled,
Dscho
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Johannes Schindelin @ 2006-02-19 19:27 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <43F8BCB1.2010701@gmail.com>
Hi,
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 ?
Unfortunately not.
However, I'd rather start by enhancing git-rebase. You do not really need
to rewrite *all* objects, but only the *commit objects*. Two things seem
to be lacking for what you want:
- an option to rebase "onto an empty commit", and
- an optional filter command to run on the commit messages.
Hth,
Dscho
^ permalink raw reply
* 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
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