* 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
* 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: 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: 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: 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: 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: [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
* [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: 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
* 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: [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: 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: 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: [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
* 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: 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
* 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: [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: 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 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: [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] 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:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkw7iphb.fsf@assigned-by-dhcp.cox.net>
On 2/19/06, Junio C Hamano <junkio@cox.net> wrote:
>
> Thanks for starting this.
>
> Briefly mentioning tool's strength and weakness without being
> too subjective would be very helpful to potential users. We
> would encourage competition without making other tools sound
> inferiour on subjective terms. So "this is similar to foobar
> tool, but runs much faster, but has these limitations" would be
> a good style, but "this draws much nicer picture than barboz"
> without substantiating why it is nicer may be suboptimal.
Ok, I resend the patch with 'encouraged competition' comments on,
guess what, qgit.
It is a little bit biased but provable. I speak only for tools I know
well. I would like each tool author writes it's own advertising ;-)
Also added the freshly new contrib/ emacs interface, called pcl-cvs,
as in revision log message.
> I am a bit afraid that the summary can become stale unless
> maintained actively.
This is unavoidable but also a useful 'watchdog' to test active maintenance.
> I am of two minds about mentioning things available from the git
> repository, but I think it makes the survey more complete and
> more useful in general to include them in the list.
>
I agree, we don't have hundreds of tools around, so list all in just
one place perhaps is
not the cleanest thing, but it is more user friendly.
-------------------------- cut ----------------------------------
From: Marco Costalba <mcostalba@gmail.com>
Date: Sun Feb 19 12:52:07 2006 +0100
Subject: [PATCH] Add a Documentation/git-tools.txt
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Documentation/git-tools.txt | 97 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-tools.txt
ce159730f858f50046186301f2d8668c66526627
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000..93a8d8b
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,97 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding link.
+
+
+Alternative/Argumentative Porcelains
+------------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of
use, providing
+ generally smoother user experience than the "raw" Core GIT itself and indeed
+ many other version control systems.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but
it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://homepage.ntlworld.com/cmarinas/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the GIT
+ environment. You can easily manage your patches in the
scope of GIT until they
+ get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple TK GUI for browsing history of GIT
repositories easily.
+
+
+ - *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.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+ Currently it is the fastest and most feature rich among
the git viewers
+ and commit tools.
+
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (contrib/)
+
+ git-svn is a simple conduit for changesets between a
single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt
repository and commit
+ series in git back and forth.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select
which files
+ to committed (or ignored / reverted) write commit
messages and perform
+ the commit itself.
+
+ - *pcl-cvs* (contrib/)
+
+ This is an Emacs interface for git. The user interface is
modeled on
+ pcl-cvs. It has been developed on Emacs 21 and will
probably need some
+ tweaking to work on XEmacs.
+
--
1.2.0.g709a
^ permalink raw reply related
* New shiny gitk
From: Paul Mackerras @ 2006-02-19 11:50 UTC (permalink / raw)
To: git
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).
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.
Paul.
^ permalink raw reply
* Re: gitk patch display corner-case bug
From: Paul Mackerras @ 2006-02-19 11:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060218233618.GA29025@diana.vm.bytemark.co.uk>
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?
Paul.
^ 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