* [PATCH] Add 'git commit --no-signoff' option.
From: Steven Drake @ 2010-01-13 3:36 UTC (permalink / raw)
To: git
Do not add a signed-off-by line. This overrides both the `--signoff`
option and the `commit.signoff` configuration variable.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
---
Documentation/git-commit.txt | 4 ++++
builtin-commit.c | 5 ++++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 5a977b6..2dfc989 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -116,6 +116,10 @@ OPTIONS
Add Signed-off-by line by the committer at the end of the commit
log message. This overrides the `commit.signoff` configuration variable.
+--no-signoff::
+ Do not add igned-off-by line. This overrides both the `--signoff`
+ option and the `commit.signoff` configuration variable.
+
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
diff --git a/builtin-commit.c b/builtin-commit.c
index db90e7a..f236068 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -51,7 +51,7 @@ static const char *logfile, *force_author;
static const char *template_file;
static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
-static int all, edit_flag, also, interactive, only, amend, signoff;
+static int all, edit_flag, also, interactive, only, amend, signoff, no_signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static char *untracked_files_arg;
/*
@@ -103,6 +103,7 @@ static struct option builtin_commit_options[] = {
OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
OPT_BOOLEAN(0, "reset-author", &renew_authorship, "the commit is authored by me now (used with -C-c/--amend)"),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
+ OPT_BOOLEAN(0, "no-signoff", &no_signoff, "Do not add Signed-off-by:"),
OPT_FILENAME('t', "template", &template_file, "use specified template file"),
OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
@@ -797,6 +798,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (force_author && renew_authorship)
die("Using both --reset-author and --author does not make sense");
+ signoff = no_signoff ? 0 : signoff;
+
if (logfile || message.len || use_message)
use_editor = 0;
if (edit_flag)
--
1.6.4
^ permalink raw reply related
* [PATCH 1/2] Add `init-db.templatedir` configuration variable.
From: Steven Drake @ 2010-01-13 4:19 UTC (permalink / raw)
To: git
Include `init.templatedir` as an alias for `init-db.templatedir`.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
---
builtin-init-db.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..d56b3a4 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -20,6 +20,7 @@
static int init_is_bare_repository = 0;
static int init_shared_repository = -1;
+static const char *init_db_template_dir;
static void safe_create_dir(const char *dir, int share)
{
@@ -121,6 +122,8 @@ static void copy_templates(const char *template_dir)
if (!template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
if (!template_dir)
+ template_dir = init_db_template_dir;
+ if (!template_dir)
template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
if (!template_dir[0])
return;
@@ -165,6 +168,15 @@ static void copy_templates(const char *template_dir)
closedir(dir);
}
+static int git_init_db_config(const char *k, const char *v, void *cb)
+{
+ /* we will accept "init-db.templatedir" or "init.templatedir" */
+ if (!strcmp(k, "init-db.templatedir") || !strcmp(k, "init.templatedir"))
+ return git_config_pathname(&init_db_template_dir, k, v);
+
+ return 0;
+}
+
static int create_default_files(const char *template_path)
{
const char *git_dir = get_git_dir();
@@ -190,6 +202,9 @@ static int create_default_files(const char *template_path)
safe_create_dir(git_path("refs/heads"), 1);
safe_create_dir(git_path("refs/tags"), 1);
+ /* Just look for `init-db.templatedir` */
+ git_config(git_init_db_config, NULL);
+
/* First copy the templates -- we might have the default
* config file there, in which case we would want to read
* from it after installing.
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] Add a "TEMPLATE DIRECTORY" section to git-init[1].
From: Steven Drake @ 2010-01-13 4:19 UTC (permalink / raw)
To: git
In-Reply-To: <04b754c8823368ec1459c16f4aa8890cc0de0204.1263356312.git.sdrake@xnet.co.nz>
Add references to it in config.txt and git-clone[1].
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
---
Documentation/config.txt | 4 ++++
Documentation/git-clone.txt | 3 +--
Documentation/git-init.txt | 29 +++++++++++++++++++++--------
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index dd261cf..b0369c4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1178,6 +1178,10 @@ imap::
The configuration variables in the 'imap' section are described
in linkgit:git-imap-send[1].
+init-db.templatedir::
+ Specify the directory from which templates will be copied.
+ (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
+
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7ccd742..731b57e 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -143,8 +143,7 @@ objects from the source repository into a pack in the cloned repository.
--template=<template_directory>::
Specify the directory from which templates will be used;
- if unset the templates are taken from the installation
- defined default, typically `/usr/share/git-core/templates`.
+ (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index f081b24..86b5766 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -28,14 +28,8 @@ current working directory.
--template=<template_directory>::
-Provide the directory from which templates will be used. The default template
-directory is `/usr/share/git-core/templates`.
-
-When specified, `<template_directory>` is used as the source of the template
-files rather than the default. The template files include some directory
-structure, some suggested "exclude patterns", and copies of non-executing
-"hook" files. The suggested patterns and hook files are all modifiable and
-extensible.
+Specify the directory from which templates will be used. (See the "TEMPLATE
+DIRECTORY" section below.)
--shared[={false|true|umask|group|all|world|everybody|0xxx}]::
@@ -106,6 +100,25 @@ of the repository, such as installing the default hooks and
setting the configuration variables. The old name is retained
for backward compatibility reasons.
+TEMPLATE DIRECTORY
+------------------
+
+The template directory contains files and directories that will be copied to
+the `$GIT_DIR` after it is created.
+
+The template directory used will (in order of preference):
+
+ - The argument given with the `--template` option.
+
+ - The contents of the `$GIT_TEMPLATE_DIR` environment variable.
+
+ - The `init-db.templatedir` configuration variable.
+
+ - The default template directory: `/usr/share/git-core/templates`.
+
+The default template directory includes some directory structure, some
+suggested "exclude patterns", and copies of non-executing "hook" files.
+The suggested patterns and hook files are all modifiable and extensible.
EXAMPLES
--------
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] Add `commit.signoff` configuration variable.
From: Steven Drake @ 2010-01-13 4:36 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.2.00.1001131635510.16395@vqena.qenxr.bet.am>
On Wed, 13 Jan 2010, Steven Drake wrote:
> Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
I ment to make a note with that patch that the commit message Signed-off-by
was added using using the `commit.signoff` feature.
--
Steven
1: Linux - will work for fish.
2: The Linux penguin - looks stuffed to the brim with herring.
( make your own conclusions )
^ permalink raw reply
* Re: Bug? git-svn clone dies with "fatal: ambiguous argument '...': unknown revision or path not in the working tree."
From: Eric Wong @ 2010-01-13 5:29 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: git, Sam Vilain, Andrew Myrick
In-Reply-To: <36366a981001121558v5324f2fbucf096e4c82402912@mail.gmail.com>
Eric Hanchrow <eric.hanchrow@gmail.com> wrote:
> I have been using git-svn happily for many months, updating git from
> git://git.kernel.org/pub/scm/git/git.git every once in a while. I
> just updated to c0eb604330e1288300d915f25868d1eed88d3038, and tried to
> clone the same svn repo that I've been using for a long time:
>
> $ git svn clone http://svn/repos/cozi/kits --stdlayout
>
> It chugged along happily for a while, but then died like this:
>
> fatal: ambiguous argument
> '2d2df13977551168a54ffa9b706484242a58736a^..d038748d49a0de5802fe3c13f46d0e080d064290':
Hi Eric,
I suspect you're hitting a bug with the newly-added mergeinfo support.
As we see below, d038748d49a0de5802fe3c13f46d0e080d064290 is a merge
commit. So I'll Cc Sam and Andrew on this since they know their way
around the mergeinfo stuff far better than I do and will hopefully have
some insight into things.
Since it's probably related to the new mergeinfo handling, reverting to
a version without it (1.6.5.7) might be the best way to go for now.
Thanks for the report!
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
> rev-list 2d2df13977551168a54ffa9b706484242a58736a^..d038748d49a0de5802fe3c13f46d0e080d064290:
> command returned error: 128
>
> "git show 2d2df13977551168a54ffa9b706484242a58736a" shows that the
> commit in question corresponds to a commit in svn that created an
> empty directory:
>
> 15:56:46 [COZIGROUP\erich@ubuntu64-erich kits] (master)$ git show -w
> 2d2df13977551168a54ffa9b706484242a58736a
> commit 2d2df13977551168a54ffa9b706484242a58736a
> Author: cozigroup\erich <cozigroup\erich@1248e456-dc32-5a46-b6cc-76877e1dc968>
> Date: Wed Jan 14 18:35:00 2009 +0000
>
> This branch will hold work I've done to refactor the vcs backend
> stuff, and add support for Mercurial.
>
>
> git-svn-id: http://svn/repos/cozi/kits/branches/vcs-refactor@18735
> 1248e456-dc32-5a46-b6cc-76877e1dc968
>
>
> 15:41:01 [COZIGROUP\erich@ubuntu64-erich hmm]$ svn log --limit=1
> -vr18735 http://svn/repos/cozi
> ------------------------------------------------------------------------
> r18735 | cozigroup\erich | 2009-01-14 10:35:00 -0800 (Wed, 14 Jan
> 2009) | 2 lines
> Changed paths:
> A /kits/branches/vcs-refactor
>
> This branch will hold work I've done to refactor the vcs backend
> stuff, and add support for Mercurial.
>
> If I recall correctly, that commit was a mistake: I'd forgotten that
> the proper way to create a branch in svn is to copy the trunk, and not
> to create an empty directory first.
>
> Here I am creating that branch the proper way:
>
> r18736 | cozigroup\erich | 2009-01-14 10:35:30 -0800 (Wed, 14 Jan
> 2009) | 2 lines
> Changed paths:
> D /kits/branches/vcs-refactor
>
> D'oh. We branch by _copying_, not making empty directories :-|
>
> ------------------------------------------------------------------------
> r18737 | cozigroup\erich | 2009-01-14 10:36:37 -0800 (Wed, 14 Jan
> 2009) | 2 lines
> Changed paths:
> A /kits/branches/vcs-refactor (from /kits/trunk:18671)
>
> Refactoring the version-control stuff, and adding Mercurial support.
>
> ------------------------------------------------------------------------
>
> 15:56:51 [COZIGROUP\erich@ubuntu64-erich kits] (master)$ git show -w
> d038748d49a0de5802fe3c13f46d0e080d064290
> commit d038748d49a0de5802fe3c13f46d0e080d064290
> Merge: 5108824 a370f0b
> Author: cozigroup\erich <cozigroup\erich@1248e456-dc32-5a46-b6cc-76877e1dc968>
> Date: Tue Jan 20 18:34:26 2009 +0000
>
> Merged from trunk.
>
>
> git-svn-id: http://svn/repos/cozi/kits/branches/vcs-refactor@18920
> 1248e456-dc32-5a46-b6cc-76877e1dc968
>
> And here is (what might be) the first attempt to modify stuff in that directory:
>
> 15:52:52 [COZIGROUP\erich@ubuntu64-erich kits] (master)$ svn log
> --limit=1 -vr18920 http://svn/repos/cozi
> ------------------------------------------------------------------------
> r18920 | cozigroup\erich | 2009-01-20 10:34:26 -0800 (Tue, 20 Jan
> 2009) | 2 lines
> Changed paths:
> M /kits/branches/vcs-refactor
> A /kits/branches/vcs-refactor/lib/CoziPlatform/cozi/resources.py
> (from /kits/trunk/lib/CoziPlatform/cozi/resources.py:18919)
> M /kits/branches/vcs-refactor/lib/CoziSecurity/cozi/authorize.py
> M /kits/branches/vcs-refactor/lib/CoziSecurity/cozi/eguidtests.py
> M /kits/branches/vcs-refactor/lib/CoziVaultRESTServices/cozi/screen_saver_api.py
> M /kits/branches/vcs-refactor/lib/CoziVaultRESTServices/cozi/screen_saver_calendar_xml.tmpl
> M /kits/branches/vcs-refactor/lib/CoziVaultRESTServices/cozi/web_client.py
>
> Merged from trunk.
>
>
> Anyway -- I suspect that my svn repos layout is ... er ... unusual,
> and has hit some sorta edge case in git-svn. Is there some workaround
> I can use, or is this a bug?
>
> Thanks
> --
^ permalink raw reply
* Re: git-svn dcommit ignores --username if there are cached credentials
From: Eric Wong @ 2010-01-13 5:41 UTC (permalink / raw)
To: Michel Jouvin; +Cc: git
In-Reply-To: <loom.20100112T233835-324@post.gmane.org>
Michel Jouvin <jouvin@lal.in2p3.fr> wrote:
> Hi,
>
> I am new to Git and using 1.6.6. I'm very interested by using it to mirror SVN
> repositories. But I am running into troubles with the way git-svn handles SVN
> credentials.
>
> For one SVN I use I have some cached credentials that have only very restricted
> write access. With svn command, I am using --username for every commit and this
> cached credential is just ignored: I'm asked for a password.
>
> With git-svn, I use --username at init/fetch but during dcommit --username is
> ignored becaused of the cached credential. I can see in SVN logs that the
> cached credential (which doesn't have the right to commit the mods I made) has
> been used instead of the one specified during fetch. If I removed the cached
> credential, the username specified with --username is taken into account (I'm
> asked a password for it and it works) and if I ommit the --username, the one
> specified at fetch time is used.
>
> IMO, looks like a bug... Thanks in advance for any comment.
Hi Michel,
I wonder if this is because we explicitly reread the config directory
when creating Git::SVN::Editor.
Does using --no-auth-cache work for you?
Otherwise, try pointing --config-dir= to an empty directory.
Or you can try this patch to force us to not reread the config_dir:
diff --git a/git-svn.perl b/git-svn.perl
index 650c9e5..280fd15 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -550,9 +550,6 @@ sub cmd_dcommit {
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($url),
- config => SVN::Core::config_get_config(
- $Git::SVN::Ra::config_dir
- ),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
We have a good reason to read config dirs there for getting auto-props,
though, so the above patch isn't going into git.git
--
Eric Wong
^ permalink raw reply related
* [PATCH 1/2] grep: rip out support for external grep
From: Junio C Hamano @ 2010-01-13 6:48 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy
In-Reply-To: <7v63774tfd.fsf@alter.siamese.dyndns.org>
We still allow people to pass --[no-]ext-grep on the command line,
but the option is ignored.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> Ack. Works for me. And with that, I'd love for it to go in, and get rid of
>> the external grep.
> ...
> Before going forward, I found two small nits that should go to maint.
These nits out-of-way, we can now start doing this.
Makefile | 10 --
builtin-grep.c | 305 +------------------------------------------------------
t/t7002-grep.sh | 6 +-
3 files changed, 8 insertions(+), 313 deletions(-)
diff --git a/Makefile b/Makefile
index 4a1e5bc..a4b922e 100644
--- a/Makefile
+++ b/Makefile
@@ -185,10 +185,6 @@ all::
# is a simplified version of the merge sort used in glibc. This is
# recommended if Git triggers O(n^2) behavior in your platform's qsort().
#
-# Define NO_EXTERNAL_GREP if you don't want "git grep" to ever call
-# your external grep (e.g., if your system lacks grep, if its grep is
-# broken, or spawning external process is slower than built-in grep git has).
-#
# Define UNRELIABLE_FSTAT if your system's fstat does not return the same
# information on a not yet closed file that lstat would return for the same
# file after it was closed.
@@ -777,7 +773,6 @@ ifeq ($(uname_S),SunOS)
NO_MKDTEMP = YesPlease
NO_MKSTEMPS = YesPlease
NO_REGEX = YesPlease
- NO_EXTERNAL_GREP = YesPlease
THREADED_DELTA_SEARCH = YesPlease
ifeq ($(uname_R),5.7)
NEEDS_RESOLV = YesPlease
@@ -895,7 +890,6 @@ ifeq ($(uname_S),IRIX)
# NO_MMAP. If you suspect that your compiler is not affected by this
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
- NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
@@ -915,7 +909,6 @@ ifeq ($(uname_S),IRIX64)
# NO_MMAP. If you suspect that your compiler is not affected by this
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
- NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH=/usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
@@ -1322,9 +1315,6 @@ endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
COMPAT_CFLAGS += -DDIR_HAS_BSD_GROUP_SEMANTICS
endif
-ifdef NO_EXTERNAL_GREP
- BASIC_CFLAGS += -DNO_EXTERNAL_GREP
-endif
ifdef UNRELIABLE_FSTAT
BASIC_CFLAGS += -DUNRELIABLE_FSTAT
endif
diff --git a/builtin-grep.c b/builtin-grep.c
index a5b6719..4adb971 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -15,14 +15,6 @@
#include "grep.h"
#include "quote.h"
-#ifndef NO_EXTERNAL_GREP
-#ifdef __unix__
-#define NO_EXTERNAL_GREP 0
-#else
-#define NO_EXTERNAL_GREP 1
-#endif
-#endif
-
static char const * const grep_usage[] = {
"git grep [options] [-e] <pattern> [<rev>...] [[--] path...]",
NULL
@@ -215,292 +207,12 @@ static int grep_file(struct grep_opt *opt, const char *filename)
return i;
}
-#if !NO_EXTERNAL_GREP
-static int exec_grep(int argc, const char **argv)
-{
- pid_t pid;
- int status;
-
- argv[argc] = NULL;
- pid = fork();
- if (pid < 0)
- return pid;
- if (!pid) {
- execvp("grep", (char **) argv);
- exit(255);
- }
- while (waitpid(pid, &status, 0) < 0) {
- if (errno == EINTR)
- continue;
- return -1;
- }
- if (WIFEXITED(status)) {
- if (!WEXITSTATUS(status))
- return 1;
- return 0;
- }
- return -1;
-}
-
-#define MAXARGS 1000
-#define ARGBUF 4096
-#define push_arg(a) do { \
- if (nr < MAXARGS) argv[nr++] = (a); \
- else die("maximum number of args exceeded"); \
- } while (0)
-
-/*
- * If you send a singleton filename to grep, it does not give
- * the name of the file. GNU grep has "-H" but we would want
- * that behaviour in a portable way.
- *
- * So we keep two pathnames in argv buffer unsent to grep in
- * the main loop if we need to do more than one grep.
- */
-static int flush_grep(struct grep_opt *opt,
- int argc, int arg0, const char **argv, int *kept)
-{
- int status;
- int count = argc - arg0;
- const char *kept_0 = NULL;
-
- if (count <= 2) {
- /*
- * Because we keep at least 2 paths in the call from
- * the main loop (i.e. kept != NULL), and MAXARGS is
- * far greater than 2, this usually is a call to
- * conclude the grep. However, the user could attempt
- * to overflow the argv buffer by giving too many
- * options to leave very small number of real
- * arguments even for the call in the main loop.
- */
- if (kept)
- die("insanely many options to grep");
-
- /*
- * If we have two or more paths, we do not have to do
- * anything special, but we need to push /dev/null to
- * get "-H" behaviour of GNU grep portably but when we
- * are not doing "-l" nor "-L" nor "-c".
- */
- if (count == 1 &&
- !opt->name_only &&
- !opt->unmatch_name_only &&
- !opt->count) {
- argv[argc++] = "/dev/null";
- argv[argc] = NULL;
- }
- }
-
- else if (kept) {
- /*
- * Called because we found many paths and haven't finished
- * iterating over the cache yet. We keep two paths
- * for the concluding call. argv[argc-2] and argv[argc-1]
- * has the last two paths, so save the first one away,
- * replace it with NULL while sending the list to grep,
- * and recover them after we are done.
- */
- *kept = 2;
- kept_0 = argv[argc-2];
- argv[argc-2] = NULL;
- argc -= 2;
- }
-
- if (opt->pre_context || opt->post_context) {
- /*
- * grep handles hunk marks between files, but we need to
- * do that ourselves between multiple calls.
- */
- if (opt->show_hunk_mark)
- write_or_die(1, "--\n", 3);
- else
- opt->show_hunk_mark = 1;
- }
-
- status = exec_grep(argc, argv);
-
- if (kept_0) {
- /*
- * Then recover them. Now the last arg is beyond the
- * terminating NULL which is at argc, and the second
- * from the last is what we saved away in kept_0
- */
- argv[arg0++] = kept_0;
- argv[arg0] = argv[argc+1];
- }
- return status;
-}
-
-static void grep_add_color(struct strbuf *sb, const char *escape_seq)
-{
- size_t orig_len = sb->len;
-
- while (*escape_seq) {
- if (*escape_seq == 'm')
- strbuf_addch(sb, ';');
- else if (*escape_seq != '\033' && *escape_seq != '[')
- strbuf_addch(sb, *escape_seq);
- escape_seq++;
- }
- if (sb->len > orig_len && sb->buf[sb->len - 1] == ';')
- strbuf_setlen(sb, sb->len - 1);
-}
-
-static int external_grep(struct grep_opt *opt, const char **paths, int cached)
-{
- int i, nr, argc, hit, len, status;
- const char *argv[MAXARGS+1];
- char randarg[ARGBUF];
- char *argptr = randarg;
- struct grep_pat *p;
-
- if (opt->extended || (opt->relative && opt->prefix_length))
- return -1;
- len = nr = 0;
- push_arg("grep");
- if (opt->fixed)
- push_arg("-F");
- if (opt->linenum)
- push_arg("-n");
- if (!opt->pathname)
- push_arg("-h");
- if (opt->regflags & REG_EXTENDED)
- push_arg("-E");
- if (opt->ignore_case)
- push_arg("-i");
- if (opt->binary == GREP_BINARY_NOMATCH)
- push_arg("-I");
- if (opt->word_regexp)
- push_arg("-w");
- if (opt->name_only)
- push_arg("-l");
- if (opt->unmatch_name_only)
- push_arg("-L");
- if (opt->null_following_name)
- /* in GNU grep git's "-z" translates to "-Z" */
- push_arg("-Z");
- if (opt->count)
- push_arg("-c");
- if (opt->post_context || opt->pre_context) {
- if (opt->post_context != opt->pre_context) {
- if (opt->pre_context) {
- push_arg("-B");
- len += snprintf(argptr, sizeof(randarg)-len,
- "%u", opt->pre_context) + 1;
- if (sizeof(randarg) <= len)
- die("maximum length of args exceeded");
- push_arg(argptr);
- argptr += len;
- }
- if (opt->post_context) {
- push_arg("-A");
- len += snprintf(argptr, sizeof(randarg)-len,
- "%u", opt->post_context) + 1;
- if (sizeof(randarg) <= len)
- die("maximum length of args exceeded");
- push_arg(argptr);
- argptr += len;
- }
- }
- else {
- push_arg("-C");
- len += snprintf(argptr, sizeof(randarg)-len,
- "%u", opt->post_context) + 1;
- if (sizeof(randarg) <= len)
- die("maximum length of args exceeded");
- push_arg(argptr);
- argptr += len;
- }
- }
- for (p = opt->pattern_list; p; p = p->next) {
- push_arg("-e");
- push_arg(p->pattern);
- }
- if (opt->color) {
- struct strbuf sb = STRBUF_INIT;
-
- grep_add_color(&sb, opt->color_match);
- setenv("GREP_COLOR", sb.buf, 1);
-
- strbuf_reset(&sb);
- strbuf_addstr(&sb, "mt=");
- grep_add_color(&sb, opt->color_match);
- strbuf_addstr(&sb, ":sl=:cx=:fn=:ln=:bn=:se=");
- setenv("GREP_COLORS", sb.buf, 1);
-
- strbuf_release(&sb);
-
- if (opt->color_external && strlen(opt->color_external) > 0)
- push_arg(opt->color_external);
- } else {
- unsetenv("GREP_COLOR");
- unsetenv("GREP_COLORS");
- }
- unsetenv("GREP_OPTIONS");
-
- hit = 0;
- argc = nr;
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
- char *name;
- int kept;
- if (!S_ISREG(ce->ce_mode))
- continue;
- if (!pathspec_matches(paths, ce->name, opt->max_depth))
- continue;
- name = ce->name;
- if (name[0] == '-') {
- int len = ce_namelen(ce);
- name = xmalloc(len + 3);
- memcpy(name, "./", 2);
- memcpy(name + 2, ce->name, len + 1);
- }
- argv[argc++] = name;
- if (MAXARGS <= argc) {
- status = flush_grep(opt, argc, nr, argv, &kept);
- if (0 < status)
- hit = 1;
- argc = nr + kept;
- }
- if (ce_stage(ce)) {
- do {
- i++;
- } while (i < active_nr &&
- !strcmp(ce->name, active_cache[i]->name));
- i--; /* compensate for loop control */
- }
- }
- if (argc > nr) {
- status = flush_grep(opt, argc, nr, argv, NULL);
- if (0 < status)
- hit = 1;
- }
- return hit;
-}
-#endif
-
-static int grep_cache(struct grep_opt *opt, const char **paths, int cached,
- int external_grep_allowed)
+static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
{
int hit = 0;
int nr;
read_cache();
-#if !NO_EXTERNAL_GREP
- /*
- * Use the external "grep" command for the case where
- * we grep through the checked-out files. It tends to
- * be a lot more optimized
- */
- if (!cached && external_grep_allowed) {
- hit = external_grep(opt, paths, cached);
- if (hit >= 0)
- return hit;
- hit = 0;
- }
-#endif
-
for (nr = 0; nr < active_nr; nr++) {
struct cache_entry *ce = active_cache[nr];
if (!S_ISREG(ce->ce_mode))
@@ -697,8 +409,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
{
int hit = 0;
int cached = 0;
- int external_grep_allowed = 1;
int seen_dashdash = 0;
+ int external_grep_allowed__ignored;
struct grep_opt opt;
struct object_array list = { 0, 0, NULL };
const char **paths = NULL;
@@ -780,13 +492,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN(0, "all-match", &opt.all_match,
"show only matches from files that match all patterns"),
OPT_GROUP(""),
-#if NO_EXTERNAL_GREP
- OPT_BOOLEAN(0, "ext-grep", &external_grep_allowed,
- "allow calling of grep(1) (ignored by this build)"),
-#else
- OPT_BOOLEAN(0, "ext-grep", &external_grep_allowed,
- "allow calling of grep(1) (default)"),
-#endif
+ OPT_BOOLEAN(0, "ext-grep", &external_grep_allowed__ignored,
+ "allow calling of grep(1) (ignored by this build)"),
{ OPTION_CALLBACK, 0, "help-all", &options, NULL, "show usage",
PARSE_OPT_HIDDEN | PARSE_OPT_NOARG, help_callback },
OPT_END()
@@ -837,8 +544,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
argc--;
}
- if ((opt.color && !opt.color_external) || opt.funcname)
- external_grep_allowed = 0;
if (!opt.pattern_list)
die("no pattern given.");
if (!opt.fixed && opt.ignore_case)
@@ -884,7 +589,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (!list.nr) {
if (!cached)
setup_work_tree();
- return !grep_cache(&opt, paths, cached, external_grep_allowed);
+ return !grep_cache(&opt, paths, cached);
}
if (cached)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index abd14bf..c369cdb 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -302,8 +302,8 @@ test_expect_success 'grep -C1, hunk mark between files' '
test_cmp expected actual
'
-test_expect_success 'grep -C1 --no-ext-grep, hunk mark between files' '
- git grep -C1 --no-ext-grep "^[yz]" >actual &&
+test_expect_success 'grep -C1 hunk mark between files' '
+ git grep -C1 "^[yz]" >actual &&
test_cmp expected actual
'
@@ -359,7 +359,7 @@ test_expect_success 'log grep (6)' '
test_expect_success 'grep with CE_VALID file' '
git update-index --assume-unchanged t/t &&
rm t/t &&
- test "$(git grep --no-ext-grep test)" = "t/t:test" &&
+ test "$(git grep test)" = "t/t:test" &&
git update-index --no-assume-unchanged t/t &&
git checkout t/t
'
--
1.6.6.292.ge84ea.dirty
^ permalink raw reply related
* [PATCH 2/2] grep: rip out pessimization to use fixmatch()
From: Junio C Hamano @ 2010-01-13 6:51 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy
In-Reply-To: <7v63774tfd.fsf@alter.siamese.dyndns.org>
Even when running without the -F (--fixed-strings) option, we checked the
pattern and used fixmatch() codepath when it does not contain any regex
magic. Finding fixed strings with strstr() surely must be faster than
running the regular expression crud.
Not so. It turns out that on some libc implementations, using the
regcomp()/regexec() pair is a lot faster than running strstr() and
strcasestr() the fixmatch() codepath uses. Drop the optimization and use
the fixmatch() codepath only when the user explicitly asked for it with
the -F option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
I first thought that this is somewhat questionable and we might want
an option --[no-]fixed-string-optimization to control it, but there
already is an option to do so with a shorter name, namely "-F".
grep.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/grep.c b/grep.c
index 62723da..8e1f7de 100644
--- a/grep.c
+++ b/grep.c
@@ -29,13 +29,6 @@ void append_grep_pattern(struct grep_opt *opt, const char *pat,
p->next = NULL;
}
-static int is_fixed(const char *s)
-{
- while (*s && !is_regex_special(*s))
- s++;
- return !*s;
-}
-
static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
{
int err;
@@ -43,7 +36,7 @@ static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
p->word_regexp = opt->word_regexp;
p->ignore_case = opt->ignore_case;
- if (opt->fixed || is_fixed(p->pattern))
+ if (opt->fixed)
p->fixed = 1;
if (opt->regflags & REG_ICASE)
p->fixed = 0;
--
1.6.6.292.ge84ea.dirty
^ permalink raw reply related
* Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees
From: Junio C Hamano @ 2010-01-13 6:55 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20100111041318.GA9806@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> | A merge is always between the current HEAD and one or more commits
> | (usually, branch head or tag), and the index file must match the tree of
> | HEAD commit (i.e. the contents of the last commit) when it starts out. In
> | other words, git diff --cached HEAD must report no changes. (One exception
> | is when the changed index entries are already in the same state that would
> | result from the merge anyway.)
>
> The potentially problematic scenario for "git reset --merge" is this
> last one, where a changed index entry is already in the same state
> that would result from the merge. Would a "git reset --merge" reset
> the changed contents away?
It will discard the change, the one you independently picked up, but the
change agreed with what was done by the the trash history that you are
cancelling merge with. You wouldn't miss losing the same change as in
that trash history.
^ permalink raw reply
* Re: [PATCH 2/3] strbuf: add strbuf_percentquote_buf
From: Junio C Hamano @ 2010-01-13 6:55 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Megacz, git
In-Reply-To: <20100112154153.GB24957@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> +`strbuf_percentquote_buf`::
> +
> + Append the contents of one strbuf to another, quoting any
> + percent signs ("%") into double-percents ("%%") in the
> + destination. This is useful for literal data to be fed to either
> + strbuf_expand or to the *printf family of functions.
> +
> `strbuf_addf`::
>
> Add a formatted string to the buffer.
> diff --git a/strbuf.c b/strbuf.c
> index 6cbc1fc..b5183c6 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -257,6 +257,16 @@ size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
> return 0;
> }
>
> +void strbuf_percentquote_buf(struct strbuf *dest, struct strbuf *src)
> +{
Just a style thing, but please call that "dst" to be consistent. You are
already dropping vowels from the other side to spell it "src".
I wondered if the function should be just 1-arg that always quotes
in-place instead, but your [PATCH 3/3] wants to have an appending
semantics from this function, so changing it to be a 1-arg "in-place
quoter" will force the caller to run strbuf_addbuf() on the result, which
is not nice.
Since tucking a p-quoted version of the same string to its original
doesn't make sense at all, perhaps this should:
(0) be renamed to have "append" somewhere in its name;
(1) mark the src side as const; and
(2) perhaps have assert(dst != src). The loop won't terminate when
called with src == dst, I think.
There seems to be only one other strbuf function that takes two strbufs in
the suite (strbuf_addbuf), and I think it is unsafe in a different way,
which is trivial to fix.
-- >8 --
Subject: [PATCH] strbuf_addbuf(): allow passing the same buf to dst and src
If sb and sb2 are the same (i.e. doubling the string), the underlying
strbuf_add() will make sb2->buf invalid by calling strbuf_grow(sb) at
the beginning and will read from the freed buffer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
strbuf.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/strbuf.h b/strbuf.h
index fa07ecf..e272359 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -105,7 +105,13 @@ static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
strbuf_add(sb, s, strlen(s));
}
static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2) {
- strbuf_add(sb, sb2->buf, sb2->len);
+ char *buf = sb2->buf;
+ int len = sb2->len;
+ if (sb->buf == sb2->buf) {
+ strbuf_grow(sb, len);
+ buf = sb->buf;
+ }
+ strbuf_add(sb, buf, len);
}
extern void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len);
--
1.6.6.280.ge295b7.dirty
^ permalink raw reply related
* Re: Unable to get "pretty" URL aliases working
From: Junio C Hamano @ 2010-01-13 6:55 UTC (permalink / raw)
To: Adam Nielsen; +Cc: git
In-Reply-To: <4B4BB2DC.4090203@uq.edu.au>
Adam Nielsen <adam.nielsen@uq.edu.au> writes:
> What actually happens when you use the ssh:// style connection?
Be it ssh://host/full/path or host:/full/path or host:path/in/home, you
log in as whatver ssh identifies you as to the server, and start a
server-side git process over there.
With ssh://host/path notation, there is no way to specify any relative
path (i.e. "/path" part begins at root) so it will mean the same thing for
everybody (unless you are getting chrooted or something), while host:path
notation allows relative path which will be taken relative as where you
are, i.e. home directory of the user on the server.
^ permalink raw reply
* Re: [PATCHv2 1/3] lib-rebase: Provide clearer debugging info about what the editor did
From: Junio C Hamano @ 2010-01-13 6:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Johannes.Schindelin
In-Reply-To: <a6ef19853c00263c2875026cb438ce46d3fcf950.1263310175.git.mhagger@alum.mit.edu>
Very nice; thanks.
^ permalink raw reply
* Re: [PATCH] remote-curl: Fix Accept header for smart HTTP connections
From: Junio C Hamano @ 2010-01-13 6:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100112175404.GE1173@spearce.org>
Thanks.
^ permalink raw reply
* Re: [BUGFIX] Unbork remote helper execution
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ilari Liusvaara, git
In-Reply-To: <201001122053.29568.j6t@kdbg.org>
Thanks, both of you.
^ permalink raw reply
* Re: [PATCH] hg-to-git: fix COMMITTER type-o
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Stelian Pop; +Cc: Bart Trojanowski, git
In-Reply-To: <20100112111651.GC3463@calypso>
Thanks both of you.
^ permalink raw reply
* Re: [PATCH] grep: -L should show empty files
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, git, Linus Torvalds, Miles Bader, Jeff King,
Nguyen Thai Ngoc Duy
In-Reply-To: <fabb9a1e1001121327s392f7311t2a7f11081ed70ff8@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Tue, Jan 12, 2010 at 09:32, Junio C Hamano <gitster@pobox.com> wrote:
>> This optimization doesn't matter too much in practice (a tracked empty
>> file must be rare, or there is something wrong with your project);
>
> How about python projects, where there's an __init__.py file
> everywhere you turn your head? ;)
It's Ok as the price we pay for producing correct result is to open those
empty files, read them, and look for matches which we will never find ;-)
^ permalink raw reply
* Re: [PATCH] lockfile: show absolute filename in unable_to_lock_message.
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1262876050-345-1-git-send-email-Matthieu.Moy@imag.fr>
Thanks.
^ permalink raw reply
* Re: [PATCH 16/18] blob.c: remove unused function
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.1001121128410.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Mon, 11 Jan 2010, Junio C Hamano wrote:
>
>> parse_blob() is not used anywhere since a510bfa (Mark blobs as parsed when
>> they're actually parsed, 2005-04-28).
>
> Perhaps it should be replaced with a comment that blobs are never parsed,
> because they don't need to be? We don't need the actual function, but I
> think it's worth having a note where the function would be.
I tend to agree.
Care to come up with a patch, with a real description of the reason _why_
they don't need to be parsed, please?
^ permalink raw reply
* Re: [PATCH v5] Be more user-friendly when refusing to do something because of conflict.
From: Junio C Hamano @ 2010-01-13 6:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262887810-19415-1-git-send-email-Matthieu.Moy@imag.fr>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-13 6:57 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Megacz, git
In-Reply-To: <20100112154631.GC24957@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> + if (strbuf_cmp(&author_ident, &committer_ident)) {
> + strbuf_addstr(&format, "\n Author: ");
> + strbuf_percentquote_buf(&format, &author_ident);
> + }
> + if (!user_ident_explicitly_given) {
> + strbuf_addstr(&format, "\n Committer: ");
> + strbuf_percentquote_buf(&format, &committer_ident);
> + }
This is much better.
We might want an advice message inside the latter case, helping the user
learn how to spell his name correctly. This is designed to trigger for
people/repositories that are not configured, and by definition the
majority of that target audience are new people.
The extra message will disappear once committer information is explicitly
given, there is no need to protect the advice message with the usual
"advice.*" configuration.
Thanks.
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Junio C Hamano @ 2010-01-13 6:57 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Gareth Adams, git
In-Reply-To: <20100112182550.GA15696@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Ah, right. I remembered hating "%" even as I typed it, but I had
> forgotten about the followup discussion. Looking at it again, I note:
>
> 1. The last posted patch still has a misplaced free() (patch below),
> but I think otherwise is not buggy.
>
> 2. We don't complain on "git show @{usptream}" and we probably should.
> I remember there being some complications because the contents of
> @{} were passed to approxidate, but I think we can get around that
> by letting approxidate complain if _nothing_ in the date was
> useful. So "git show @{2.weeks.and.7.hot.dogs.ago}" would still
> work, but "git show @{totally.bogus.input}" would complain.
>
> 3. I have actually been running with Dscho's patch for the last couple
> of months, and I don't remember using it once. So perhaps it is not
> as useful as I might have thought. :)
I presume we are discussing this patch?
http://article.gmane.org/gmane.comp.version-control.git/128121
I'll squash the free() fix; thanks.
I wondered why it doesn't hook into interpret_branch_name(), and instead
adds itself to the static substitute_branch_name(); it forbids the use of
the syntax from by callers of strbuf_branchname().
I agree with your point #2 above.
Regarding your point #3, I don't think the notation should be that useful
if your workflow is sane. The original use case that triggered the
resurrection of the patch went like this:
git fetch &&
for local in my set of local branches
do
git checkout $local &&
git merge $local@{upstream} || {
echo failed to merge on $local
break
}
done
and the new notation might look useful in the scenario. But the thing is,
constantly merging with the other side, even if you haven't added anything
of value since you merged from there last time, is a bad practice to begin
with. I added one use case that is sane _and_ will be helped by the new
notation to the rewritten version of Dscho's patch (below).
Just to refresh our memory from the old thread and make sure we are
discussing the same patch, here is what I am planning to queue. The log
message and documentation are somewhat updated to avoid the word "track"
because it seems that everybody gets confused and starts talking different
things whenever that word is used. For the same reason, the test script
was renamed.
In this set-up, for example:
[remote "filfre"]
url = ...
fetch = +refs/heads/nitfol:refs/heads/rezrov
[branch "frotz"]
remote = filfre
merge = refs/heads/nitfol
some people say rezrov tracks nitfol from filfre but Dscho's patch says
frotz tracks nitfol from filfre. They _may_ both track, but they "track"
the other in a quite differently way, so the word has become meaningless.
I've been trying to be careful and used different words to disambiguate
whenever I had to talk about these concepts:
- The purpose of rezrov is to keep a tab on the progress of the nitfol
branch at the remote end. We say rezrov is a remote tracking branch
for nitfol from filfre.
- On the other hand, we have branch frotz that forked from nitfol that
came from filfre. It builds on top of that history by occasionally
merging with it at key points in the history. So we say frotz builds
on top of nitfol from filfre. We also say nitfol at filfre is the
upstream of frotz.
-- >8 --
Date: Thu, 10 Sep 2009 17:25:57 +0200
Subject: [PATCH] Introduce <branch>@{upstream} notation
A new notation '<branch>@{upstream}' refers to the branch <branch> is set
to build on top of. Missing <branch> (i.e. '@{upstream}') defaults to the
current branch.
This allows you to run, for example,
for l in list of local branches
do
git log --oneline --left-right $l...$l@{upstream}
done
to inspect each of the local branches you are interested in for the
divergence from its upstream.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-rev-parse.txt | 4 ++
sha1_name.c | 39 ++++++++++++++++++++--
t/t1506-rev-parse-upstream.sh | 69 +++++++++++++++++++++++++++++++++++++++
3 files changed, 109 insertions(+), 3 deletions(-)
create mode 100755 t/t1506-rev-parse-upstream.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 82045a2..923b56a 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -231,6 +231,10 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The suffix '@{upstream}' to a ref (short form 'ref@{u}') refers to
+ the branch the ref is set to build on top of. Missing ref defaults
+ to the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..fb4e214 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
+static inline int tracked_suffix(const char *string, int len)
+{
+ const char *suffix[] = { "@{upstream}", "@{u}" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(suffix); i++) {
+ int suffix_len = strlen(suffix[i]);
+ if (len >= suffix_len && !memcmp(string + len - suffix_len,
+ suffix[i], suffix_len))
+ return suffix_len;
+ }
+ return 0;
+}
+
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form <branch>@{upstream}.
*/
static char *substitute_branch_name(const char **string, int *len)
{
@@ -254,6 +270,21 @@ static char *substitute_branch_name(const char **string, int *len)
return (char *)*string;
}
+ ret = tracked_suffix(*string, *len);
+ if (ret) {
+ char *ref = xstrndup(*string, *len - ret);
+ struct branch *tracking = branch_get(*ref ? ref : NULL);
+
+ if (!tracking)
+ die ("No tracking branch found for '%s'", ref);
+ free(ref);
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
@@ -340,8 +371,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (len && str[len-1] == '}') {
for (at = len-2; at >= 0; at--) {
if (str[at] == '@' && str[at+1] == '{') {
- reflog_len = (len-1) - (at+2);
- len = at;
+ if (!tracked_suffix(str + at, len - at)) {
+ reflog_len = (len-1) - (at+2);
+ len = at;
+ }
break;
}
}
diff --git a/t/t1506-rev-parse-upstream.sh b/t/t1506-rev-parse-upstream.sh
new file mode 100755
index 0000000..5abdc13
--- /dev/null
+++ b/t/t1506-rev-parse-upstream.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+
+test_description='test <branch>@{upstream} syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{upstream})"
+'
+
+test_expect_success '@{u} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{u})"
+'
+
+test_expect_success 'my-side@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/side = "$(full_name my-side@{u})"
+'
+
+test_expect_success 'my-side@{u} resolves to correct commit' '
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject my-side@{u})"
+'
+
+test_expect_success 'not-tracking@{u} fails' '
+ test_must_fail full_name non-tracking@{u} &&
+ (cd clone && git checkout --no-track -b non-tracking) &&
+ test_must_fail full_name non-tracking@{u}
+'
+
+test_expect_success '<branch>@{u}@{1} resolves correctly' '
+ test_commit 6 &&
+ (cd clone && git fetch) &&
+ test 5 = $(commit_subject my-side@{u}@{1})
+'
+
+test_expect_success '@{u} without specifying branch fails on a detached HEAD' '
+ git checkout HEAD^0 &&
+ test_must_fail git rev-parse @{u}
+'
+
+test_done
--
1.6.6.280.ge295b7.dirty
^ permalink raw reply related
* Re: git-svn dcommit ignores --username if there are cached credentials
From: Michel Jouvin @ 2010-01-13 7:05 UTC (permalink / raw)
To: git
In-Reply-To: <20100113054138.GB23182@dcvr.yhbt.net>
Eric Wong <normalperson <at> yhbt.net> writes:
> Hi Michel,
>
> I wonder if this is because we explicitly reread the config directory
> when creating Git::SVN::Editor.
>
> Does using --no-auth-cache work for you?
>
> Otherwise, try pointing --config-dir= to an empty directory.
>
> Or you can try this patch to force us to not reread the config_dir:
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 650c9e5..280fd15 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -550,9 +550,6 @@ sub cmd_dcommit {
> my %ed_opts = ( r => $last_rev,
> log => get_commit_entry($d)->{log},
> ra => Git::SVN::Ra->new($url),
> - config => SVN::Core::config_get_config(
> - $Git::SVN::Ra::config_dir
> - ),
> tree_a => "$d~1",
> tree_b => $d,
> editor_cb => sub {
>
> We have a good reason to read config dirs there for getting auto-props,
> though, so the above patch isn't going into git.git
>
Hi Eric,
Thanks for your quick answer. Unfortunatly, none of the suggested workaround
worked for me... I even tried to clone again the SVN repository passing the
suggested options when cloning but no effect. BTW, does specifying --username
at cloning time should add something to some config file (like .git/config) ?
Cheers,
Michel
^ permalink raw reply
* Re: [RFC PATCH (WIP)] Show a dirty working tree and a detached HEAD in status for submodule
From: Junio C Hamano @ 2010-01-13 7:09 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B4CA13F.6020505@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> To avoid possible loss of commits.
> ... Or the remote branch the
> user thinks the submodule is tracking has been deleted or rebased. You
> might want to know that before e.g. committing it in the superproject.
The interaction between recursive reset/checkout and gc in submodule
repository is something I didn't think about thoroughly, but I think you
are solving the issue in a wrong place at a wrong level.
We have so far neglected the object reachability analysis across
repositories. When people use "clone --reference" to take advantage of
alternate object store, we tell them not to use any repository that
rewinds its branches as reference. Putting it the other way around, we
tell owners of repositories that somebody borrows objects from not to run
gc, because objects they themselves do not use may be used by others who
borrow from them. But we don't _enforce_ it; it is merely a social
convention. We might want to do something about it, perhaps by having
typed back-pointers from a borrowed repository to borrowing repositories.
I think commits in submodules that are pointed at by _some_ superproject
commits are in the same situation. Just like some objects in a borrowed
repository may have to be protected by refs in borrowing repositories,
some commits in a submodule repository (here I am only talking about
repositories that serve as distribution points---a private repository of a
user who is not interested in that particular submodule is excluded from
this discussion and may not follow the same rules) may have to be
protected by commits reachable by refs in its superproject repository.
The right solution to your "gc might soon remove objects from submodule
repository even when commits in the superproject uses them" may be to
teach "gc" run in the submodule repository to behave better. After all,
even if the commit were reachable from some of the refs in the submodule
when you created a commit that points at it at the superproject level,
next "git submodule update" might rewind that ref in the submodule that
reached the commit and make it unreachable; your check to be careful at
commit time wouldn't buy you much, even if the check were 100% accurate.
Also in _your_ repository you may have the submodule commit with your
check at the time you make commit in the superproject, but if you forget
to push it out from the submodule before you push the commit out from the
superproject, other people will suffer from the same issue you are trying
to guard against.
In any case, this "where in the submodule's history does the commit being
recorded lie" does not have anything to do with "diff/status" that lets
you know "has it been _modified_?" at the level of the superproject. As
you mentioned, it is more similar to "Untracked files" section in "status"
output of a flat project. It doesn't belong to "diff", nor to "Changed
but not updated" section.
>>> * This behavior is not configurable but activated by default. A config
>>> option is needed here.
>>
>> I doubt it.
>>
>> My gut feeling is that this should be _always_ on for a submodule
>> directory that has been "submodule init/update". The user is interested
>> in that particular submodule, and any change to it should be reported for
>> both classes of users. Those who meant to use the submodule read-only
>> need to be able to notice that they accidentally made the submodule dirty
>> before making a commit in the superproject. Those who wanted to work in
>> submodule needs to know if the state is in sync with what they expect
>> before making a commit in the superproject.
>
> Yes, me too thinks it should default to on for every initialized
> submodule.
>
> But this is a major change in behavior, so it might be a good idea to be
> able to turn it off (e.g. if it breaks scripts).
If scripts are broken by this change, I think it is actually a good thing.
They've been operating happily as if everything is clean when some
submodule directories are *not*, and your patch starts showing something
closer to the reality, the changes they should care about. If on the
other hand the scripts are willing to commit the index while leaving local
modifications behind, they will not be checking with "diff" output
(instead they will be checking "diff --cached") and you won't change the
output with your patch for that codepath, so they will keep working
happily.
>> But the thing is, in a distributed environment, the submodule HEAD being
>> at the tip of _some_ branch (either local or remote) you have doesn't mean
>> anything to help them. IOW, for protect others, you would need a check
>> when you _push out_ (either in 'push' or on the receiving end).
The right place to do this check is at the receiving end. Just like they
can be (and by default are) configured to reject a non ff push into the
repository, the receiving end of the superproject can inspect the incoming
history and make sure that the commits bound at submodule paths are all
available to others that might want to fetch those superproject commits
from it in associated submodule repositories. It would forbid people from
first pushing superproject and then pushing submodule projects, but I
think that is a better workflow anyway (you make sure prerequisites are
available in the submodule repositories to others first, and then make the
superproject commit that depends on the submodules).
You may also need to check at the receiving end when pushing into the
submodule repository; if the push is a non ff one, it _might_ lose commits
that are still needed by the associated superproject.
>> So I'd suggest dropping this condition in "status/diff" that is about
>> preparing to make the next commit in your _local_ history.
>
> I would rather have this patch merged without c) than not at all. But i
> think it is a worthwhile and rather cheap test.
Did I ever say "drop (c) because it is *too expensive*"?
I suggested to drop it because it is a _pointless_ check in the context of
the codepath, even though I was too polite to put it that bluntly in the
message you are responding to.
I think this topic of yours overall is going in the right direction. I
have no issue with the intent to show submodules with local changes in
"Changed but not updated" section of status, or do the "+sha1-dirty" thing
in diff.
Thanks.
^ permalink raw reply
* [PATCH] Add `format.to` configuration variable.
From: Steven Drake @ 2010-01-13 7:55 UTC (permalink / raw)
To: git
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
---
This email was address using this new configuration variable.
---
builtin-log.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 41b6df4..a608c3d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -501,6 +501,13 @@ static int git_format_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "format.suffix"))
return git_config_string(&fmt_patch_suffix, var, value);
+ if (!strcmp(var, "format.to")) {
+ if (!value)
+ return config_error_nonbool(var);
+ ALLOC_GROW(extra_to, extra_to_nr + 1, extra_to_alloc);
+ extra_to[extra_to_nr++] = xstrdup(value);
+ return 0;
+ }
if (!strcmp(var, "format.cc")) {
if (!value)
return config_error_nonbool(var);
--
1.6.6.85.ga4c31
^ permalink raw reply related
* Re: [PATCH] Add `format.to` configuration variable.
From: Johannes Sixt @ 2010-01-13 8:20 UTC (permalink / raw)
To: Steven Drake; +Cc: git
In-Reply-To: <alpine.LNX.2.00.1001132054380.24673@vqena.qenxr.bet.am>
You submitted a number of patches in the last hours, but you gave *zero*
motivation for them, i.e., the commit messages lack words about *why* the
changes are good (and what they are good for).
This particular patch lacks documentation, in particular, it's worth to
mention that format.to could be given more than once.
-- Hannes
^ 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