* Patch which adds syslog support to git-shell
From: Gerhard Gappmeier @ 2009-12-23 17:32 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]
Hi
I'm not sure if this is the right list, but here is my first GIT patch.
I had a problem with git-shell and wanted to analyze it.
Unfortunately it does not contain any trace capabilities.
So I cloned git and added some basic syslog support.
After that I recognized that the current git version just works ;-)
but the syslog functionality is always a nice thing I think.
So here is the patch.
Merry X-Mas.
--
mit freundlichen Grüßen / best regards
Gerhard Gappmeier
ascolab GmbH - automation system communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG Key-Id: 5AAC50C4
GPG Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4
[-- Attachment #1.2: 0001-Added-syslog-functionality-to-git-shell.patch --]
[-- Type: text/x-patch, Size: 6536 bytes --]
From 0683e3a249419620abcf4363086cd53ec34972e8 Mon Sep 17 00:00:00 2001
From: Gerhard Gappmeier <gerhard.gappmeier@ascolab.com>
Date: Wed, 23 Dec 2009 17:19:34 +0100
Subject: [PATCH] Added syslog functionality to git-shell.
---
shell.c | 192 ++++++++++++++++++++++++++++++++++++++-------------------------
1 files changed, 115 insertions(+), 77 deletions(-)
diff --git a/shell.c b/shell.c
index e4864e0..4cdf385 100644
--- a/shell.c
+++ b/shell.c
@@ -1,103 +1,141 @@
+#include <syslog.h>
+#include <errno.h>
#include "cache.h"
#include "quote.h"
#include "exec_cmd.h"
#include "strbuf.h"
+/* Syslog defines */
+#define GIT_SYSLOG_IDENT "git-shell"
+#define GIT_SYSLOG_OPTION 0
+#define GIT_SYSLOG_FACILITY LOG_LOCAL0
+
static int do_generic_cmd(const char *me, char *arg)
{
- const char *my_argv[4];
+ const char *my_argv[4];
+ int ret = 0;
+
+ setup_path();
+ if (!arg || !(arg = sq_dequote(arg))) {
+ syslog(LOG_INFO, "bad argument");
+ die("bad argument");
+ }
+ if (prefixcmp(me, "git-")) {
+ syslog(LOG_INFO, "bad command");
+ die("bad command");
+ }
+
+ my_argv[0] = me + 4;
+ my_argv[1] = arg;
+ my_argv[2] = NULL;
- setup_path();
- if (!arg || !(arg = sq_dequote(arg)))
- die("bad argument");
- if (prefixcmp(me, "git-"))
- die("bad command");
+ syslog(LOG_INFO, "Executing '%s' '%s'.", my_argv[0], my_argv[1]);
- my_argv[0] = me + 4;
- my_argv[1] = arg;
- my_argv[2] = NULL;
+ ret = execv_git_cmd(my_argv);
+ if (ret == -1) {
+ syslog(LOG_ERR, " execv_git_cmd failed: %s\n", strerror(errno));
+ }
- return execv_git_cmd(my_argv);
+ return ret;
}
static int do_cvs_cmd(const char *me, char *arg)
{
- const char *cvsserver_argv[3] = {
- "cvsserver", "server", NULL
- };
+ const char *cvsserver_argv[3] = {
+ "cvsserver", "server", NULL
+ };
+ int ret = 0;
+
+ if (!arg || strcmp(arg, "server")) {
+ syslog(LOG_INFO, "git-cvsserver only handles server: %s", arg);
+ die("git-cvsserver only handles server: %s", arg);
+ }
+
+ setup_path();
- if (!arg || strcmp(arg, "server"))
- die("git-cvsserver only handles server: %s", arg);
+ syslog(LOG_INFO, "Executing '%s' '%s'.", cvsserver_argv[0], cvsserver_argv[1]);
- setup_path();
- return execv_git_cmd(cvsserver_argv);
+ ret = execv_git_cmd(cvsserver_argv);
+ if (ret == -1) {
+ syslog(LOG_ERR, " execv_git_cmd failed: %s\n", strerror(errno));
+ }
+
+ return ret;
}
static struct commands {
- const char *name;
- int (*exec)(const char *me, char *arg);
+ const char *name;
+ int (*exec)(const char *me, char *arg);
} cmd_list[] = {
- { "git-receive-pack", do_generic_cmd },
- { "git-upload-pack", do_generic_cmd },
- { "git-upload-archive", do_generic_cmd },
- { "cvs", do_cvs_cmd },
- { NULL },
+ { "git-receive-pack", do_generic_cmd },
+ { "git-upload-pack", do_generic_cmd },
+ { "git-upload-archive", do_generic_cmd },
+ { "cvs", do_cvs_cmd },
+ { NULL },
};
int main(int argc, char **argv)
{
- char *prog;
- struct commands *cmd;
- int devnull_fd;
-
- /*
- * Always open file descriptors 0/1/2 to avoid clobbering files
- * in die(). It also avoids not messing up when the pipes are
- * dup'ed onto stdin/stdout/stderr in the child processes we spawn.
- */
- devnull_fd = open("/dev/null", O_RDWR);
- while (devnull_fd >= 0 && devnull_fd <= 2)
- devnull_fd = dup(devnull_fd);
- if (devnull_fd == -1)
- die_errno("opening /dev/null failed");
- close (devnull_fd);
-
- /*
- * Special hack to pretend to be a CVS server
- */
- if (argc == 2 && !strcmp(argv[1], "cvs server"))
- argv--;
-
- /*
- * We do not accept anything but "-c" followed by "cmd arg",
- * where "cmd" is a very limited subset of git commands.
- */
- else if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
-
- prog = argv[2];
- if (!strncmp(prog, "git", 3) && isspace(prog[3]))
- /* Accept "git foo" as if the caller said "git-foo". */
- prog[3] = '-';
-
- for (cmd = cmd_list ; cmd->name ; cmd++) {
- int len = strlen(cmd->name);
- char *arg;
- if (strncmp(cmd->name, prog, len))
- continue;
- arg = NULL;
- switch (prog[len]) {
- case '\0':
- arg = NULL;
- break;
- case ' ':
- arg = prog + len + 1;
- break;
- default:
- continue;
- }
- exit(cmd->exec(cmd->name, arg));
- }
- die("unrecognized command '%s'", prog);
+ char *prog;
+ struct commands *cmd;
+ int devnull_fd;
+
+ /* Open syslog. */
+ openlog(GIT_SYSLOG_IDENT, GIT_SYSLOG_OPTION, GIT_SYSLOG_FACILITY);
+
+ /*
+ * Always open file descriptors 0/1/2 to avoid clobbering files
+ * in die(). It also avoids not messing up when the pipes are
+ * dup'ed onto stdin/stdout/stderr in the child processes we spawn.
+ */
+ devnull_fd = open("/dev/null", O_RDWR);
+ while (devnull_fd >= 0 && devnull_fd <= 2)
+ devnull_fd = dup(devnull_fd);
+ if (devnull_fd == -1)
+ die_errno("opening /dev/null failed");
+ close (devnull_fd);
+
+ /*
+ * Special hack to pretend to be a CVS server
+ */
+ if (argc == 2 && !strcmp(argv[1], "cvs server"))
+ argv--;
+
+ /*
+ * We do not accept anything but "-c" followed by "cmd arg",
+ * where "cmd" is a very limited subset of git commands.
+ */
+ else if (argc != 3 || strcmp(argv[1], "-c")) {
+ syslog(LOG_WARNING, "Invalid parameter '%s'", argv[1]);
+ die("What do you think I am? A shell?");
+ }
+
+ prog = argv[2];
+ if (!strncmp(prog, "git", 3) && isspace(prog[3]))
+ /* Accept "git foo" as if the caller said "git-foo". */
+ prog[3] = '-';
+
+ for (cmd = cmd_list ; cmd->name ; cmd++) {
+ int len = strlen(cmd->name);
+ char *arg;
+ if (strncmp(cmd->name, prog, len))
+ continue;
+ arg = NULL;
+ switch (prog[len]) {
+ case '\0':
+ arg = NULL;
+ break;
+ case ' ':
+ arg = prog + len + 1;
+ break;
+ default:
+ continue;
+ }
+ exit(cmd->exec(cmd->name, arg));
+ }
+
+ syslog(LOG_WARNING, "Somebody tried to execute an unallowed command '%s'", prog);
+ die("unrecognized command '%s'", prog);
}
+
--
1.6.4.4
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: git tag --contains <commit> -n=1 ?
From: Andreas Schwab @ 2009-12-23 17:19 UTC (permalink / raw)
To: NODA, Kai; +Cc: git
In-Reply-To: <4B324327.5010809@gmail.com>
"NODA, Kai" <nodakai@gmail.com> writes:
> Here I wonder whether "head -1" is generally correct or not when I want
> the oldest tag.
Since the output of git tag is sorted by name, generally not.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git tag --contains <commit> -n=1 ?
From: NODA, Kai @ 2009-12-23 16:19 UTC (permalink / raw)
To: git
Hi,
I'm thinking how to find the oldest tag containing a specified commit.
Eg.
$ cd /usr/src/linux-linus/Documentation
$ for i in *.txt; do
for> echo $i
for> hash=`git log -1 --format=format:%H -- $i`
for> git tag --contains $hash -l 'v2.6.[0-9][0-9]'|head -1
for> done
DMA-API.txt
v2.6.31
DMA-ISA-LPC.txt
v2.6.20
DMA-attributes.txt
v2.6.27
...
Here I wonder whether "head -1" is generally correct or not when I want
the oldest tag.
Moreover, as "git tag --contains ..." takes considerable time, I will
be happy if I can set the maximum number in searching tags containing
a commit. Or are there already some (better) ways to achieve this?
Any advice is welcome.
Thanks,
Kai
^ permalink raw reply
* Re: Atomicity of git-push operation.
From: Shawn O. Pearce @ 2009-12-23 15:25 UTC (permalink / raw)
To: Jan Zalcman; +Cc: git
In-Reply-To: <4B32044A.7010601@9livesdata.com>
Jan Zalcman <zalcman@9livesdata.com> wrote:
> I have a simple question about "push" operation but I couldn't find an
> answer: is git-push (also with --tags flag) atomic ? Especially: if refs
> changing (during push) is atomic ?
Yes, its atomic, at the per-ref level.
If you push 3 refs, and one of them updates during the push, the
other two will push successfully, but the one that was updated will
be rejected.
--
Shawn.
^ permalink raw reply
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Johannes Schindelin @ 2009-12-23 13:28 UTC (permalink / raw)
To: Greg Price; +Cc: Junio C Hamano, git
In-Reply-To: <1ac2d430912222303k6180baa6j291bb4d18c7a4968@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 966 bytes --]
Hi,
On Wed, 23 Dec 2009, Greg Price wrote:
> On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > - This seems to rewrite only branch heads; don't you want to allow
> > users to rewrite lightweight tags and possibly annotated ones as
> > well, by perhaps giving "--rewrite-refs=refs/heads/" or
> > "--rewrite-refs=refs/" to limit what parts of the ref namespace to
> > consider rewriting?
>
> Sure. I specifically left out tags because I generally think of a tag
> as something immutable that it would not make sense to rewrite.
I do agree: if you plan to rewrite a ref, you _should_ make it a branch
anyway.
A tag is not meant to be updated easily, in fact, we explicitely lack
tools to do so (and it is quite hard to get updated tags from a repository
where the tags changed anyway). So rewriting tags is something that
causes only trouble.
Why should rebase -i cause that trouble all of a sudden?
Ciao,
Dscho
^ permalink raw reply
* Atomicity of git-push operation.
From: Jan Zalcman @ 2009-12-23 11:51 UTC (permalink / raw)
To: git
Hi,
I have a simple question about "push" operation but I couldn't find an
answer: is git-push (also with --tags flag) atomic ? Especially: if refs
changing (during push) is atomic ?
Thanks,
Janek
^ permalink raw reply
* [PATCH] git-gui: handle really long error messages in updateindex.
From: Pat Thoyts @ 2009-12-20 2:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
As reported to msysGit (bug #340) it is possible to get some very long
error messages when updating the index. The use of a label to display
this prevents scrolling the output. This patch replaces the label with
a scrollable text widget configured to look like a label.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
lib/index.tcl | 34 ++++++++++++++++++----------------
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/lib/index.tcl b/lib/index.tcl
index d33896a..0b58bd8 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -14,29 +14,31 @@ proc _close_updateindex {fd after} {
toplevel $w
wm title $w [strcat "[appname] ([reponame]): " [mc "Index Error"]]
wm geometry $w "+[winfo rootx .]+[winfo rooty .]"
- pack [label $w.msg \
- -justify left \
- -anchor w \
- -text [strcat \
- [mc "Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui."] \
- "\n\n$err"] \
- ] -anchor w
-
- frame $w.buttons
- button $w.buttons.continue \
+ set s [mc "Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui."]
+ text $w.msg -yscrollcommand [list $w.vs set] \
+ -width [string length $s] -relief flat \
+ -borderwidth 0 -highlightthickness 0 \
+ -background [$w cget -background]
+ $w.msg tag configure bold -font font_uibold -justify center
+ scrollbar $w.vs -command [list $w.msg yview]
+ $w.msg insert end $s bold \n\n$err {}
+ $w.msg configure -state disabled
+
+ button $w.continue \
-text [mc "Continue"] \
-command [list destroy $w]
- pack $w.buttons.continue -side right -padx 5
- button $w.buttons.unlock \
+ button $w.unlock \
-text [mc "Unlock Index"] \
-command "destroy $w; _delete_indexlock"
- pack $w.buttons.unlock -side right
- pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+ grid $w.msg - $w.vs -sticky news
+ grid $w.unlock $w.continue - -sticky se -padx 2 -pady 2
+ grid columnconfigure $w 0 -weight 1
+ grid rowconfigure $w 0 -weight 1
wm protocol $w WM_DELETE_WINDOW update
- bind $w.buttons.continue <Visibility> "
+ bind $w.continue <Visibility> "
grab $w
- focus $w.buttons.continue
+ focus %W
"
tkwait window $w
--
1.6.2
^ permalink raw reply related
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Michael J Gruber @ 2009-12-23 8:53 UTC (permalink / raw)
To: Greg Price; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <1ac2d430912222303k6180baa6j291bb4d18c7a4968@mail.gmail.com>
Greg Price venit, vidit, dixit 23.12.2009 08:03:
> On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> - As decoration is a fairly expensive operation (which is the reason why
>> loading_ref_decorations() is called lazily by format_decoration() in
>> the first place, especially in repositories with tons of refs), you
>> shouldn't give --format=%D to rev-list when the new feature is not
>> asked for.
>
> OK, will do.
>
>
>> - This seems to rewrite only branch heads; don't you want to allow users
>> to rewrite lightweight tags and possibly annotated ones as well, by
>> perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
>> to limit what parts of the ref namespace to consider rewriting?
>
> Sure. I specifically left out tags because I generally think of a tag
> as something immutable that it would not make sense to rewrite. But
> people use Git in different ways and it makes sense to give the option
> of rewriting tags as well as heads.
>
> I do worry that passing --rewrite-refs=refs/ will set up remote refs
> for rewriting, which is likely to be confusing if the user does not
> notice them and remove them from the TODO. Perhaps it makes sense to
> accept forms like "--rewrite-refs=refs/heads/,refs/tags/" or
> "--rewrite-refs=refs/heads/ --rewrite-refs=refs/tags/". Is there a
> Git convention for accepting a sequence of arguments like this to an
> option -- one of these, or something else?
>
>
>> On the other hand, if the "partN" markers in your example workflow are
>> primarily meant to be used to mark places on a branch (as opposed to
>> arbitrary branch tips that independent development starting from them can
>> further continue), it would make a lot more sense to use lightweight or
>> annotated tags for them, and instead of "--refs" that rewrites only other
>> branch tips, it might make a lot more sense to have "--rewrite-tags" that
>> rewrites tags that point at the commits that are rewritten, without
>> touching any branch tip.
>
> I think of them as a topic branch developing one feature, then another
> branch developing a related follow-on feature, etc. I would also feel
> odd rewriting tags as a routine operation, or calling a ref a tag when
> I expect to rewrite it. So I do think they're best recorded as branch
> tips rather than tags.
>
>
>> Obviously the series also needs tests.
>
> Yes.
>
>
>> I also have to wonder if this feature should also handle a case like this:
>>
>> side
>> |
>> V
>> *
>> /
>> part1 * topic
>> | / |
>> v / v
>> A--*--*--*--*--*--*
>> \
>> B <--master
>>
>> ===>
>>
>> side
>> |
>> V
>> *
>> /
>> part1 * topic
>> A | / |
>> \ v / v
>> B--*--*--*--*--*--*
>> ^ [
>> |
>> master
>>
>> especially if it were to be specific to branch management.
>
> Huh, that's an interesting idea. I hadn't thought of that. This
> feature could be nice. But I am not sure what it would look like.
> How might the user indicate that they want both "side" and "topic" to
> be rebased? I suppose we could extend the familiar command line
> git rebase <upstream> [<branch>]
> to the form
> git rebase <upstream> [...<branches>...]
> so that your example would be
> $ git rebase -i --rewrite-heads master topic side
> If we choose this approach, it might even be independent of
> --rewrite-refs, though the implementation would presumably rely on the
> "ref" command. Was this interface what you were thinking, or do you
> have another idea?
>
> Greg
If I may jump in: I imagine this to be the more common use case, i.e.:
You have a part of the DAG which you want to rebase, with all kinds of
refs (branches, tags) pointing to commits in that part of the DAG. If
you rebase that part of the DAG you typically want some refs rewritten
(such as the head of the branch you're rebasing) but maybe not others
(say a release tag or branch). remote refs should never be rebased. So,
one would need an easy way to specify one ref, all or anything in between...
Michael
^ permalink raw reply
* Re: [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Eric Wong @ 2009-12-23 7:25 UTC (permalink / raw)
To: Florian Köberle; +Cc: git
In-Reply-To: <4B309730.5070509@fkoeberle.de>
Florian Köberle <florian@fkoeberle.de> wrote:
> Hello
>
> I haven't seen a link to a bug tracker so I am sending this bug report
> to the mailing list, I hope it's okay.
Hi Florian,
The mailing list is the bug tracker here :)
> If you try to run
> $ git svn branch foo
> in a project using a svn+ssh url, you get the following error log:
>
> Copying svn+ssh://example.org/svn/project/trunk at r1000 to
> svn+ssh://me@example.org/svn/project/branches/foo...
> Trying to use an unsupported feature: Source and dest appear not to be
> in the same repository (src: 'svn+ssh://example.org/svn/project/trunk';
> dst: 'svn+ssh://me@example.org/svn/project/branches/foo') at
> /home/florian/libexec/git-core/git-svn line 722
>
> It fails as the username is missing in the source url. If you modify the
> git-svn script and add the username it works. The bug can be reproduced
> with git-svn version 1.6.5.7 (svn 1.5.1).
Thanks for the info, the following patch should help.
I rarely get around to testing against svn+ssh servers myself
(and they don't appear too common compared to http/https).
Let us know how it goes, thanks!
From b2bc7e330209659c20d02ee0ba3785f9f59fd0b2 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 22 Dec 2009 22:40:18 -0800
Subject: [PATCH] git svn: branch/tag commands detect username in URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index dba0d12..650c9e5 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -663,7 +663,8 @@ sub cmd_branch {
}
$head ||= 'HEAD';
- my ($src, $rev, undef, $gs) = working_head_info($head);
+ my (undef, $rev, undef, $gs) = working_head_info($head);
+ my $src = $gs->full_url;
my $remote = Git::SVN::read_all_remotes()->{$gs->{repo_id}};
my $allglobs = $remote->{ $_tag ? 'tags' : 'branches' };
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Greg Price @ 2009-12-23 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vzl5awpf1.fsf@alter.siamese.dyndns.org>
On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> - As decoration is a fairly expensive operation (which is the reason why
> loading_ref_decorations() is called lazily by format_decoration() in
> the first place, especially in repositories with tons of refs), you
> shouldn't give --format=%D to rev-list when the new feature is not
> asked for.
OK, will do.
> - This seems to rewrite only branch heads; don't you want to allow users
> to rewrite lightweight tags and possibly annotated ones as well, by
> perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
> to limit what parts of the ref namespace to consider rewriting?
Sure. I specifically left out tags because I generally think of a tag
as something immutable that it would not make sense to rewrite. But
people use Git in different ways and it makes sense to give the option
of rewriting tags as well as heads.
I do worry that passing --rewrite-refs=refs/ will set up remote refs
for rewriting, which is likely to be confusing if the user does not
notice them and remove them from the TODO. Perhaps it makes sense to
accept forms like "--rewrite-refs=refs/heads/,refs/tags/" or
"--rewrite-refs=refs/heads/ --rewrite-refs=refs/tags/". Is there a
Git convention for accepting a sequence of arguments like this to an
option -- one of these, or something else?
> On the other hand, if the "partN" markers in your example workflow are
> primarily meant to be used to mark places on a branch (as opposed to
> arbitrary branch tips that independent development starting from them can
> further continue), it would make a lot more sense to use lightweight or
> annotated tags for them, and instead of "--refs" that rewrites only other
> branch tips, it might make a lot more sense to have "--rewrite-tags" that
> rewrites tags that point at the commits that are rewritten, without
> touching any branch tip.
I think of them as a topic branch developing one feature, then another
branch developing a related follow-on feature, etc. I would also feel
odd rewriting tags as a routine operation, or calling a ref a tag when
I expect to rewrite it. So I do think they're best recorded as branch
tips rather than tags.
> Obviously the series also needs tests.
Yes.
> I also have to wonder if this feature should also handle a case like this:
>
> side
> |
> V
> *
> /
> part1 * topic
> | / |
> v / v
> A--*--*--*--*--*--*
> \
> B <--master
>
> ===>
>
> side
> |
> V
> *
> /
> part1 * topic
> A | / |
> \ v / v
> B--*--*--*--*--*--*
> ^ [
> |
> master
>
> especially if it were to be specific to branch management.
Huh, that's an interesting idea. I hadn't thought of that. This
feature could be nice. But I am not sure what it would look like.
How might the user indicate that they want both "side" and "topic" to
be rebased? I suppose we could extend the familiar command line
git rebase <upstream> [<branch>]
to the form
git rebase <upstream> [...<branches>...]
so that your example would be
$ git rebase -i --rewrite-heads master topic side
If we choose this approach, it might even be independent of
--rewrite-refs, though the implementation would presumably rely on the
"ref" command. Was this interface what you were thinking, or do you
have another idea?
Greg
^ permalink raw reply
* Re: [PATCH] git svn: add (failing) test for a git svn gc followed by a git svn mkdirs
From: Eric Wong @ 2009-12-23 6:18 UTC (permalink / raw)
To: Robert Zeh; +Cc: git
In-Reply-To: <57d579150912222008j19b16b1aq88ebd0938c2553e9@mail.gmail.com>
Robert Zeh <robert.a.zeh@gmail.com> wrote:
> git svn gc will compress the unhandled.log files that git svn mkdirs reads,
> causing git svn mkdirs to skip directory creation.
> ---
> t/t9152-svn-empty-dirs-after-gc.sh | 41 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 41 insertions(+), 0 deletions(-)
> create mode 100755 t/t9152-svn-empty-dirs-after-gc.sh
Hi Robert,
I actually got impatient over the weekend and committed a test case and
fix. I believe I Cc-ed you on it... But your test case might be
cleaner, but yes, same things Junio said.
--
Eric Wong
^ permalink raw reply
* [RFC PATCH 2/2] git-difftool: Add '--gui' for selecting a GUI tool
From: David Aguilar @ 2009-12-23 5:27 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1261546034-7780-1-git-send-email-davvid@gmail.com>
Users might prefer to have git-difftool use a different
tool when run from a Git GUI.
This teaches git-difftool to honor 'diff.guitool' when
the '--gui' option is specified. This allows users to
configure their preferred command-line diff tool in
'diff.tool' and a GUI diff tool in 'diff.guitool'.
Reference: http://article.gmane.org/gmane.comp.version-control.git/133386
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is an RFC patch for a number of reasons.
* We're in RC freeze
* This introduces a new 'diff.guitool' variable.
I don't know if the name of the variable is desirable as-is.
So, I figured it's best to mark it as an RFC for now.
Documentation/git-difftool.txt | 9 +++++++++
git-difftool.perl | 13 ++++++++++++-
t/t7800-difftool.sh | 12 ++++++++++++
3 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 8e9aed6..a5bce62 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -58,6 +58,12 @@ is set to the name of the temporary file containing the contents
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
+-g::
+--gui::
+ When 'git-difftool' is invoked with the `-g` or `--gui` option
+ the default diff tool will be read from the configured
+ `diff.guitool` variable instead of `diff.tool`.
+
See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
@@ -68,6 +74,9 @@ difftool equivalents have not been defined.
diff.tool::
The default diff tool to use.
+diff.guitool::
+ The default diff tool to use when `--gui` is specified.
+
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
diff --git a/git-difftool.perl b/git-difftool.perl
index ba5e60a..8c836e4 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -15,13 +15,16 @@ use warnings;
use Cwd qw(abs_path);
use File::Basename qw(dirname);
+require Git;
+
my $DIR = abs_path(dirname($0));
sub usage
{
print << 'USAGE';
-usage: git difftool [--tool=<tool>] [-y|--no-prompt] ["git diff" options]
+usage: git difftool [-g|--gui] [-t|--tool=<tool>] [-y|--no-prompt]
+ ["git diff" options]
USAGE
exit 1;
}
@@ -63,6 +66,14 @@ sub generate_command
$ENV{GIT_DIFF_TOOL} = substr($arg, 7);
next;
}
+ if ($arg eq '-g' || $arg eq '--gui') {
+ my $tool = Git::command_oneline('config',
+ 'diff.guitool');
+ if (length($tool)) {
+ $ENV{GIT_DIFF_TOOL} = $tool;
+ }
+ next;
+ }
if ($arg eq '-y' || $arg eq '--no-prompt') {
$ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
delete $ENV{GIT_DIFFTOOL_PROMPT};
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 707a0f5..9bf6c98 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -19,6 +19,7 @@ remove_config_vars()
{
# Unset all config variables used by git-difftool
git config --unset diff.tool
+ git config --unset diff.guitool
git config --unset difftool.test-tool.cmd
git config --unset difftool.prompt
git config --unset merge.tool
@@ -77,6 +78,17 @@ test_expect_success 'difftool ignores bad --tool values' '
test "$diff" = ""
'
+test_expect_success 'difftool honors --gui' '
+ git config merge.tool bogus-tool &&
+ git config diff.tool bogus-tool &&
+ git config diff.guitool test-tool &&
+
+ diff=$(git difftool --no-prompt --gui branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
# Specify the diff tool using $GIT_DIFF_TOOL
test_expect_success 'GIT_DIFF_TOOL variable' '
git config --unset diff.tool
--
1.6.2.5
^ permalink raw reply related
* [PATCH 1/2] t7800-difftool: Set a bogus tool for use by tests
From: David Aguilar @ 2009-12-23 5:27 UTC (permalink / raw)
To: git; +Cc: gitster
If a difftool test has an error then running the git test suite
may end up invoking a GUI diff tool. We now guard against this
by setting a difftool.bogus-tool.cmd variable.
The tests already used --tool=bogus-tool in various places so
this is simply ensuring that nothing ever falls back and
finds a real diff tool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7800-difftool.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index fff6a6d..707a0f5 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -36,6 +36,7 @@ restore_test_defaults()
unset GIT_DIFFTOOL_NO_PROMPT
git config diff.tool test-tool &&
git config difftool.test-tool.cmd 'cat $LOCAL'
+ git config difftool.bogus-tool.cmd false
}
prompt_given()
@@ -71,7 +72,7 @@ test_expect_success 'custom commands' '
# Ensures that git-difftool ignores bogus --tool values
test_expect_success 'difftool ignores bad --tool values' '
- diff=$(git difftool --no-prompt --tool=bogus-tool branch)
+ diff=$(git difftool --no-prompt --tool=bad-tool branch)
test "$?" = 1 &&
test "$diff" = ""
'
--
1.6.2.5
^ permalink raw reply related
* Re: git svn mkdirs ignores compressed unhandled.log files
From: Robert Zeh @ 2009-12-23 4:12 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091217200852.GA5797@dcvr.yhbt.net>
On Dec 17, 2009, at 2:08 PM, Eric Wong wrote:
> Robert Zeh <robert.a.zeh@gmail.com> wrote:
>> It looks like there is a conflict between git svn gc and git svn
>> mkdirs. The git svn mkdirs command only looks at unhandled.log files.
>> Shouldn't it also look at any compressed unhandled.log files too?
>
> Hi Robert,
>
> Yes, an oversight. Does this patch work for you? (Highly untested)
>
> Would you mind writing a test case, been a bit busy with other stuff.
> Thanks.
Eric,
Your patch works for the existing t9146-git-svn-empty-dirs.sh test, and the test
I've sent as a patch in another email.
Robert
^ permalink raw reply
* [PATCH] git svn: add (failing) test for a git svn gc followed by a git svn mkdirs
From: Robert Zeh @ 2009-12-23 4:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.
---
t/t9152-svn-empty-dirs-after-gc.sh | 41 ++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
create mode 100755 t/t9152-svn-empty-dirs-after-gc.sh
diff --git a/t/t9152-svn-empty-dirs-after-gc.sh
b/t/t9152-svn-empty-dirs-after-gc.sh
new file mode 100755
index 0000000..9ac6ea9
--- /dev/null
+++ b/t/t9152-svn-empty-dirs-after-gc.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Robert Zeh
+
+test_description='git svn creates empty directories, calls git gc,
makes sure they are still empty'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone' 'git svn clone "$svnrepo" cloned'
+
+test_expect_success 'git svn gc runs' '
+ (
+ cd cloned &&
+ git svn gc
+ )
+'
+
+test_expect_success 'git svn mkdirs recreates empty directories after
git svn gc' '
+ (
+ cd cloned &&
+ rm -r * &&
+ git svn mkdirs &&
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
+
+test_done
--
1.6.6.rc3.dirty
^ permalink raw reply related
* Re: Regression: git-svn clone failure
From: Sam Vilain @ 2009-12-23 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Myrick, Eric Wong, git
In-Reply-To: <7vbphqzo2y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sam Vilain <sam@vilain.net> writes:
>
>> With git, merge parent relationships imply (conceptually, anyway) that all of the changes reachable from that branch are included in the commit. If someone is doing cherry-picking, then they are specifically excluding some commits, so adding a merge parent to that branch isn't right.
>> ...
>> Subject: [PATCH] git-svn: consider 90% of a branch cherry picked to be a merge
>>
>> Be slightly fuzzy when deciding if a branch is a merge or a cherry pick; ... might ... if ...
>>
>> Signed-off-by: Sam Vilain <sam@vilain.net>
>>
>
> If I were _using_ git-svn (or any other tool), I would rather be forced to ... sort out the conflict myself ... rather than an automated but unreliable operation that drops changes randomly, ... and reports "everything is peachy".
>
> That sounds horrible, as you cannot trust your merges anymore. I hope I
> am mis-interpreting what you wrote above.
>
Welcome to the world of SVN, Junio. It's a world of sunshine and
happiness, pain and despair.
Sam.
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Sam Vilain @ 2009-12-23 0:09 UTC (permalink / raw)
To: Andrew Myrick; +Cc: Eric Wong, git
In-Reply-To: <B39991E2-D632-4FD5-B5DA-0B6B502BBFC8@apple.com>
Andrew Myrick wrote:
> This makes perfect sense now. Thank you for clarifying. Unfortunately, I don't think the patch you provided will help my particular problem. Allow me to elaborate.
>
> As I mentioned before, my project's integration model is to create a separate branch for every change. Specifically, we create a branch from a recent internal tag. So, the model for a simple bug fix looks something like this:
>
> F---G branch1
> / \
> D tag1 \ E tag2
> / \ /
> A---B C trunk
>
> Revision B on trunk was tagged with tag1. A bug was found in that version, so a branch was created from tag1, a fix was committed to the branch, and then the branch was merged back to trunk. Finally, trunk is tagged with tag2.
>
> The "missing commit" messages show up when git svn fetch is fetching revision C. It warns the there is a cherry-pick from branch1, and states that commits D and F are missing. These commits are just copies, however; there is no code change. The svn:mergeinfo property on trunk also only points at commit G. Should git-svn be ignoring commits D and F, which are copy operations, not code changes?
>
> Also of note is that we very, very rarely cherry-pick commits, and never directly from a branch to trunk. Branches are always integrated back to trunk in their entirety.
>
Ok. Yes, I can see that. I guess what the code needs to do then is
figure out if the missing changes didn't touch the tree, and exclude
them if that happens.
in the check_cherry_pick function, try putting at the end something like;
for my $commit (keys %commits) {
if (has_no_changes($commit)) {
delete $commits{$commit};
}
}
Before the return. has_no_changes should be:
sub has_no_changes {
my $commit = shift;
# merges should always have no changes, but more
# importantly $commit~1 won't be defined for them, so
# don't proceed if that is the case.
my $num_parents = split / /, command_oneline(
qw(rev-list --parents -1 -m), $commit,
);
return 0 if $num_parents > 1;
return (command_oneline("rev-parse", "$commit^{tree}")
eq command_oneline("rev-parse", "$commit~1^{tree}"));
}
has_no_changes should also be memoized. Cherry picking a single commit
from a large unrelated branch will be slow (using cat-file --batch could
help here, but that's not something I can hack out off the cuff like
this), the first time, then it will remember whether particular commits
have changes or not.
Good luck,
Sam
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Andrew Myrick @ 2009-12-22 23:50 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, git
In-Reply-To: <1261516416.23944.44.camel@denix>
On Dec 22, 2009, at 1:13 PM, Sam Vilain wrote:
> On Tue, 2009-12-22 at 11:38 -0800, Andrew Myrick wrote:
>> Worked like a charm; the fetch is proceeding now. Thanks, Eric!
>>
>> Do you know what the "svn cherry-pick ignored" warnings mean, and if it's
>> something I should be concerned about? This particular project is missing
>> up to 65 commits at some revisions.
>
> With git, merge parent relationships imply (conceptually, anyway) that
> all of the changes reachable from that branch are included in the
> commit. If someone is doing cherry-picking, then they are specifically
> excluding some commits, so adding a merge parent to that branch isn't
> right. This is what the warning is saying. It's happening every commit
> because that section of code doesn't know whether a mergeinfo record is
> new or not.
>
> This wasn't happening with the old code, because it was simply not
> detecting them correctly and adding merge parents anyway.
This makes perfect sense now. Thank you for clarifying. Unfortunately, I don't think the patch you provided will help my particular problem. Allow me to elaborate.
As I mentioned before, my project's integration model is to create a separate branch for every change. Specifically, we create a branch from a recent internal tag. So, the model for a simple bug fix looks something like this:
F---G branch1
/ \
D tag1 \ E tag2
/ \ /
A---B C trunk
Revision B on trunk was tagged with tag1. A bug was found in that version, so a branch was created from tag1, a fix was committed to the branch, and then the branch was merged back to trunk. Finally, trunk is tagged with tag2.
The "missing commit" messages show up when git svn fetch is fetching revision C. It warns the there is a cherry-pick from branch1, and states that commits D and F are missing. These commits are just copies, however; there is no code change. The svn:mergeinfo property on trunk also only points at commit G. Should git-svn be ignoring commits D and F, which are copy operations, not code changes?
Also of note is that we very, very rarely cherry-pick commits, and never directly from a branch to trunk. Branches are always integrated back to trunk in their entirety.
-Andrew
^ permalink raw reply
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Junio C Hamano @ 2009-12-22 23:37 UTC (permalink / raw)
To: Greg Price; +Cc: git, Johannes Schindelin
In-Reply-To: <20091222222316.GY30538@dr-wily.mit.edu>
Greg Price <price@ksplice.com> writes:
> The new option --refs causes the TODO file to contain a "ref" command
> for each head pointing to a selected commit, other than the one we are
> already rebasing. The effect of this is that when a branch contains
> intermediate branches, like so:
>
> part1 part2 topic
> | | |
> v v v
> A--*--*--*--*--*--*
> \
> B <--master
>
> a single command like "git rebase -i --refs master topic" suffices to
> rewrite all the heads that are part of the topic, like so:
>
> part1 part2 topic
> A | | |
> \ v v v
> B--*--*--*--*--*--*
> ^
> |
> master
>
> Signed-off-by: Greg Price <price@ksplice.com>
> ---
Two comments and a half.
- As decoration is a fairly expensive operation (which is the reason why
loading_ref_decorations() is called lazily by format_decoration() in
the first place, especially in repositories with tons of refs), you
shouldn't give --format=%D to rev-list when the new feature is not
asked for.
- This seems to rewrite only branch heads; don't you want to allow users
to rewrite lightweight tags and possibly annotated ones as well, by
perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
to limit what parts of the ref namespace to consider rewriting?
- Otherwise the option should not be called "refs" but be named using the
word "branch" to clarify that it affects _only_ branches.
Obviously the series also needs tests.
I also have to wonder if this feature should also handle a case like this:
side
|
V
*
/
part1 * topic
| / |
v / v
A--*--*--*--*--*--*
\
B <--master
===>
side
|
V
*
/
part1 * topic
A | / |
\ v / v
B--*--*--*--*--*--*
^
|
master
especially if it were to be specific to branch management.
On the other hand, if the "partN" markers in your example workflow are
primarily meant to be used to mark places on a branch (as opposed to
arbitrary branch tips that independent development starting from them can
further continue), it would make a lot more sense to use lightweight or
annotated tags for them, and instead of "--refs" that rewrites only other
branch tips, it might make a lot more sense to have "--rewrite-tags" that
rewrites tags that point at the commits that are rewritten, without
touching any branch tip.
^ permalink raw reply
* [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Greg Price @ 2009-12-22 22:23 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <20091222222032.GU30538@dr-wily.mit.edu>
The new option --refs causes the TODO file to contain a "ref" command
for each head pointing to a selected commit, other than the one we are
already rebasing. The effect of this is that when a branch contains
intermediate branches, like so:
part1 part2 topic
| | |
v v v
A--*--*--*--*--*--*
\
B <--master
a single command like "git rebase -i --refs master topic" suffices to
rewrite all the heads that are part of the topic, like so:
part1 part2 topic
A | | |
\ v v v
B--*--*--*--*--*--*
^
|
master
Signed-off-by: Greg Price <price@ksplice.com>
---
git-rebase--interactive.sh | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 25ac3e3..cccb031 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -18,6 +18,7 @@ git-rebase [-i] (--continue | --abort | --skip)
Available options are
v,verbose display a diffstat of what changed upstream
onto= rebase onto given branch instead of upstream
+refs rewrite intermediate heads on branch
p,preserve-merges try to recreate merges instead of ignoring them
s,strategy= use the given merge strategy
m,merge always used (no-op)
@@ -42,6 +43,7 @@ REWRITTEN="$DOTEST"/rewritten
DROPPED="$DOTEST"/dropped
PRESERVE_MERGES=
STRATEGY=
+REWRITE_REFS=
ONTO=
VERBOSE=
OK_TO_SKIP_PRE_REBASE=
@@ -578,6 +580,9 @@ first and then run 'git rebase --continue' again."
output git reset --hard && do_rest
;;
+ --refs)
+ REWRITE_REFS=t
+ ;;
-s)
case "$#,$1" in
*,*=*)
@@ -705,11 +710,14 @@ first and then run 'git rebase --continue' again."
REVISIONS=$ONTO...$HEAD
SHORTREVISIONS=$SHORTHEAD
fi
- git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --topo-order \
+ git rev-list $MERGES_OPTION --abbrev-commit --abbrev=7 \
+ --reverse --left-right --topo-order \
+ --pretty=format:"$(printf '%%m%%h %%s\n%%m%%D')" \
$REVISIONS | \
sed -n "s/^>//p" | while read shortsha1 rest
do
+ read refs
+
if test t != "$PRESERVE_MERGES"
then
echo "pick $shortsha1 $rest" >> "$TODO"
@@ -734,6 +742,16 @@ first and then run 'git rebase --continue' again."
echo "pick $shortsha1 $rest" >> "$TODO"
fi
fi
+
+ if test t = "$REWRITE_REFS"
+ then
+ for ref in $refs
+ do
+ test ${ref#refs/heads/} != $ref &&
+ test $ref != $(cat "$DOTEST"/head-name) &&
+ echo "ref $ref" >> "$TODO"
+ done
+ fi
done
# Watch for commits that been dropped by --cherry-pick
--
1.6.6.rc1.9.g2ad41.dirty
^ permalink raw reply related
* [PATCH RFC 3/4] rebase -i: Add the "ref" command
From: Greg Price @ 2009-12-22 22:22 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <20091222222032.GU30538@dr-wily.mit.edu>
This is useful for, e.g., rewriting a branch that has ancestor
branches along the way.
Signed-off-by: Greg Price <price@ksplice.com>
---
git-rebase--interactive.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..25ac3e3 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -367,6 +367,10 @@ do_next () {
warn
exit 0
;;
+ ref)
+ mark_action_done
+ git update-ref $sha1 HEAD # $sha1 is actually a refname
+ ;;
squash|s)
comment_for_reflog squash
--
1.6.6.rc1.9.g2ad41.dirty
^ permalink raw reply related
* [PATCH 2/4] log --decorate=full: drop the "tag: " prefix
From: Greg Price @ 2009-12-22 22:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20091222222032.GU30538@dr-wily.mit.edu>
The "tag: " prefix complicates machine parsing of decorations, so we
drop it from the output formats intended to be parsed by machine,
namely --decorate=full and the %D format code.
The prefix is helpful for a human reader to see that the ref is an
(annotated) tag, especially since we omit the "refs/tags/" prefix in
the default output of "git log --decorate". In a script, however, it
is easy to use "git cat-file -t" to distinguish annotated tags from
commits when the distinction is relevant.
Signed-off-by: Greg Price <price@ksplice.com>
---
log-tree.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 0fdf159..5eb6b00 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -22,17 +22,18 @@ static void add_name_decoration(const char *prefix, const char *name, struct obj
static int add_ref_decoration(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
+ int short_refs = !!(!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS);
struct object *obj = parse_object(sha1);
if (!obj)
return 0;
- if (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)
+ if (short_refs)
refname = prettify_refname(refname);
add_name_decoration("", refname, obj);
while (obj->type == OBJ_TAG) {
obj = ((struct tag *)obj)->tagged;
if (!obj)
break;
- add_name_decoration("tag: ", refname, obj);
+ add_name_decoration(short_refs ? "tag: " : "", refname, obj);
}
return 0;
}
--
1.6.6.rc1.9.g2ad41.dirty
^ permalink raw reply related
* [PATCH 1/4] pretty: Add %D for script-friendly decoration
From: Greg Price @ 2009-12-22 22:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20091222222032.GU30538@dr-wily.mit.edu>
When in a script or porcelain one wants to identify what refs point to
which commits in a series, the functionality of 'git log --decorate'
is extremely useful. This is available with the %d format code in a
form optimized for humans, but for scripts a more raw format is better.
Make such a format available through a new format code %D.
Signed-off-by: Greg Price <price@ksplice.com>
---
Documentation/pretty-formats.txt | 1 +
pretty.c | 33 +++++++++++++++++++++++++--------
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 53a9168..b6b840e 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -119,6 +119,7 @@ The placeholders are:
- '%ct': committer date, UNIX timestamp
- '%ci': committer date, ISO 8601 format
- '%d': ref names, like the --decorate option of linkgit:git-log[1]
+- '%D': full ref names, like the --decorate=full option of linkgit:git-log[1]
- '%e': encoding
- '%s': subject
- '%f': sanitized subject line, suitable for a filename
diff --git a/pretty.c b/pretty.c
index 8f5bd1a..18ce2ff 100644
--- a/pretty.c
+++ b/pretty.c
@@ -582,21 +582,35 @@ static void parse_commit_message(struct format_commit_context *c)
c->commit_message_parsed = 1;
}
-static void format_decoration(struct strbuf *sb, const struct commit *commit)
+
+static void format_decoration(struct strbuf *sb, const struct commit *commit,
+ int decoration_style, const char *affixes[3])
{
struct name_decoration *d;
- const char *prefix = " (";
+ const char *affix = affixes[0];
- load_ref_decorations(DECORATE_SHORT_REFS);
+ load_ref_decorations(decoration_style);
d = lookup_decoration(&name_decoration, &commit->object);
while (d) {
- strbuf_addstr(sb, prefix);
- prefix = ", ";
+ strbuf_addstr(sb, affix);
+ affix = affixes[1];
strbuf_addstr(sb, d->name);
d = d->next;
}
- if (prefix[0] == ',')
- strbuf_addch(sb, ')');
+ if (affix == affixes[1])
+ strbuf_addstr(sb, affixes[2]);
+}
+
+static void format_decoration_short(struct strbuf *sb, const struct commit *commit)
+{
+ const char *affixes[3] = {" (", ", ", ")"};
+ format_decoration(sb, commit, DECORATE_SHORT_REFS, affixes);
+}
+
+static void format_decoration_full(struct strbuf *sb, const struct commit *commit)
+{
+ const char *affixes[3] = {"", " ", ""};
+ format_decoration(sb, commit, DECORATE_FULL_REFS, affixes);
}
static void strbuf_wrap(struct strbuf *sb, size_t pos,
@@ -756,7 +770,10 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
: '>');
return 1;
case 'd':
- format_decoration(sb, commit);
+ format_decoration_short(sb, commit);
+ return 1;
+ case 'D':
+ format_decoration_full(sb, commit);
return 1;
case 'g': /* reflog info */
switch(placeholder[1]) {
--
1.6.6.rc1.9.g2ad41.dirty
^ permalink raw reply related
* [PATCH RFC 0/4] rebase -i: Add --refs option to rewrite heads within branch
From: Greg Price @ 2009-12-22 22:20 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
This RFC series adds a "ref" command to rebase -i, and an option
--refs to generate "ref" commands in the original TODO file. This
makes it easy to rebase a branch together with intermediate markers,
or a series of branches.
For example, in this situation:
part1 part2 topic
| | |
v v v
A--*--*--*--*--*--*
\
B <--master
we may want to rebase 'topic' onto the new master, rewriting the
intermediate branches 'part1', 'part2' to the corresponding new
commits. This can be done with a sequence of "git rebase --onto"
commands, but it's tricky to get right.
With this series, the command
$ git rebase -i --refs master topic
suffices to produce this result:
part1 part2 topic
A | | |
\ v v v
B--*--*--*--*--*--*
^
|
master
These patches work for me. Before I recommend the last two patches
for merge, they'll need the following additional work:
- interoperate with rebase --abort
- add documentation
- probably add tests
The series begins with two patches that are independently useful, and
that I believe are ready for merge:
pretty: Add %D for script-friendly decoration
log --decorate=full: drop the "tag: " prefix
They make the functionality of 'git log --decorate' available in an
output format optimized for machine parsing. I expect other people
will find this useful for other scripts.
Greg
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Junio C Hamano @ 2009-12-22 21:38 UTC (permalink / raw)
To: Sam Vilain; +Cc: Andrew Myrick, Eric Wong, git
In-Reply-To: <1261516416.23944.44.camel@denix>
Sam Vilain <sam@vilain.net> writes:
> With git, merge parent relationships imply (conceptually, anyway) that
> all of the changes reachable from that branch are included in the
> commit. If someone is doing cherry-picking, then they are specifically
> excluding some commits, so adding a merge parent to that branch isn't
> right. This is what the warning is saying. It's happening every commit
> because that section of code doesn't know whether a mergeinfo record is
> new or not.
> ...
> Subject: [PATCH] git-svn: consider 90% of a branch cherry picked to be a merge
>
> Be slightly fuzzy when deciding if a branch is a merge or a cherry pick; in
> some instances this might indicate intentionally skipping changes as not
> required, as if they had performed a real merge and then skipped those
> files.
>
> Signed-off-by: Sam Vilain <sam@vilain.net>
If I were _using_ git-svn (or any other tool), I would rather be forced to
see overlapping changes from both branches to sort out the conflict myself
when I merge such a cherry-picked history, rather than an automated but
unreliable operation that drops changes randomly, still records that
everything from the branch is now merged, and reports "everything is
peachy".
That sounds horrible, as you cannot trust your merges anymore. I hope I
am mis-interpreting what you wrote above.
^ 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