* Re: [PATCH] Document git-svn's first-parent rule
From: Eric Wong @ 2009-11-17 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vd43his6n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Thomas Rast <trast@student.ethz.ch> wrote:
> >> git-svn has the following rule to detect the SVN base for its
> >> operations: find the first git-svn-id line reachable through
> >> first-parent ancestry. IOW,
> >>
> >> git log --grep=^git-svn-id: --first-parent -1
> >>
> >> Document this, as it is very important when using merges with git-svn.
> >>
> >> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> >
> > Thanks Thomas,
> >
> > Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Thanks; is it a good time to pull from your bogomips repository to get
> accumulated changes?
Now is, I just pushed to it:
Eric Wong (3):
git svn: read global+system config for clone+init
git svn: add authorsfile test case for ~/.gitconfig
git svn: attempt to create empty dirs on clone+rebase
Thomas Rast (1):
Document git-svn's first-parent rule
Toby Allsopp (1):
git svn: handle SVN merges from revisions past the tip of the branch
HEAD=ce45a45f24cc7b3ccc7f6ebcd0025559b4421bda
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Jeff King @ 2009-11-17 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Collins, Nanako Shiraishi, git
In-Reply-To: <7v639am2uq.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 04:06:37PM -0800, Junio C Hamano wrote:
> By the way, I would suggest updating the test like the attached.
>
> By looking for rEtUrN, you will catch a bug that breaks "-i"-ness
> of the grep, but your test does not catch breakages in "-F"-ness.
Your change looks good to me.
-Peff
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jeff King @ 2009-11-17 7:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
On Mon, Nov 16, 2009 at 11:07:40AM +0100, Matthieu Moy wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d1e2120..c37b51d 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
> core.excludesfile::
> In addition to '.gitignore' (per-directory) and
> '.git/info/exclude', git looks into this file for patterns
> - of files which are not meant to be tracked. See
> + of files which are not meant to be tracked. "~" and "~user"
> + are expanded to the user's home directory. See
> linkgit:gitignore[5].
Reading this, it is not clear to me if:
1. "~" and "~user" are expanded to the home directory of "user", where
"user" is the user running git
or
2. "~" is expanded to the home directory of the user running git, and
an arbitrary "~user" is expanded to that user's home directory.
I would expect (2), since that is how everything else works. And it
seems from the code that is what you do. But something about the way it
is written makes me think of (1). I also recall having this same
question during the last round, so at the very least it is not me just
mis-reading it once. ;)
Maybe:
A leading path component of "~user" is expanded to the home directory
of "user"; "~" is expanded to the home directory of the user running
git.
would be more clear?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] ls-tree: migrate to parse-options
From: Stephen Boyd @ 2009-11-17 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr7hisc7.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> @@ -24,7 +24,7 @@ static int chomp_prefix;
> static const char *ls_tree_prefix;
>
> static const char * const ls_tree_usage[] = {
> - "git ls-tree [-d] [-r] [-t] [-l | --long] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]",
> + "git ls-tree <options> <tree-ish> [path...]",
> NULL
> };
>
Is it [<options>] or [<options>...] or <options> or even <options>...
though?
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-17 6:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <7v3a4enkzt.fsf@alter.siamese.dyndns.org>
I'd like to squash this to your patch, based on the earlier review
comments.
I didn't mention about the first hunk; it is just a style. An opening
brace that begins a function body comes at column 1.
Also first_slash and to_copy are made const pointers, as they do not have
to touch the region of memory they point to (otherwise you cannot assign
path to to_copy without getting warned).
config.c | 3 ++-
path.c | 32 ++++++++++++++------------------
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/config.c b/config.c
index 0fcc4ce..b3d1ff4 100644
--- a/config.c
+++ b/config.c
@@ -351,7 +351,8 @@ int git_config_string(const char **dest, const char *var, const char *value)
return 0;
}
-int git_config_pathname(const char **dest, const char *var, const char *value) {
+int git_config_pathname(const char **dest, const char *var, const char *value)
+{
if (!value)
return config_error_nonbool(var);
*dest = expand_user_path(value);
diff --git a/path.c b/path.c
index 009c8e0..2470f78 100644
--- a/path.c
+++ b/path.c
@@ -208,11 +208,8 @@ int validate_headref(const char *path)
return -1;
}
-static inline struct passwd *getpw_str(const char *username, size_t len)
+static struct passwd *getpw_str(const char *username, size_t len)
{
- if (len == 0)
- return getpwuid(getuid());
-
struct passwd *pw;
char *username_z = xmalloc(len + 1);
memcpy(username_z, username, len);
@@ -223,18 +220,18 @@ static inline struct passwd *getpw_str(const char *username, size_t len)
}
/*
- * Return a string with ~ and ~user expanded via getpw*. If buf != NULL, then
- * it is a newly allocated string. Returns NULL on getpw failure or if
- * path is NULL.
+ * Return a string with ~ and ~user expanded via getpw*. If buf != NULL,
+ * then it is a newly allocated string. Returns NULL on getpw failure or
+ * if path is NULL.
*/
char *expand_user_path(const char *path)
{
struct strbuf user_path = STRBUF_INIT;
- char * first_slash = strchrnul(path, '/');
- char * to_copy;
+ const char *first_slash = strchrnul(path, '/');
+ const char *to_copy = path;
+
if (path == NULL)
goto return_null;
-
if (path[0] == '~') {
const char *username = path + 1;
size_t username_len = first_slash - username;
@@ -243,8 +240,6 @@ char *expand_user_path(const char *path)
goto return_null;
strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
to_copy = first_slash;
- } else if (path[0] != '/') {
- to_copy = path;
}
strbuf_add(&user_path, to_copy, strlen(to_copy));
return strbuf_detach(&user_path, NULL);
@@ -300,14 +295,15 @@ char *enter_repo(char *path, int strict)
if (path[0] == '~') {
char *newpath = expand_user_path(path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
- if (path != newpath)
- free(newpath);
+ free(newpath);
return NULL;
}
- /* Copy back into the static buffer. A pity
- since newpath was not bounded, but other
- branches of the if are limited by PATH_MAX
- anyway. */
+ /*
+ * Copy back into the static buffer. A pity
+ * since newpath was not bounded, but other
+ * branches of the if are limited by PATH_MAX
+ * anyway.
+ */
strcpy(used_path, newpath); free(newpath);
strcpy(validated_path, path);
path = used_path;
--
1.6.5.3.283.g4b054
^ permalink raw reply related
* bash completion on 4.0 broken?
From: Stephen Boyd @ 2009-11-17 6:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
When I try
git show --pretty=<TAB><TAB>
I get a list of filenames and not the list of pretty formats.
I've debugged a little and see that the cur variable in _git_show () is
set to '=' when it should be '--pretty='. So it looks like something is
causing the command line to be split weirdly. Looking at the bash
NEWS[1] for 4.0 I see
i. The programmable completion code now uses the same set of characters as
readline when breaking the command line into a list of words.
which causes me to believe this is why it's broken now. I've tried
removing '=' from COMP_WORDBREAKS and that shows the list of formats
correctly, but then causes the entire '--pretty=' to be replaced with
the selected format.
Anyone else seeing the same problem or is my system just b0rked?
$ bash --version
GNU bash, version 4.0.35(2)-release (x86_64-pc-linux-gnu)
References:
[1] http://tiswww.case.edu/php/chet/bash/NEWS
^ permalink raw reply
* Re: [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Junio C Hamano @ 2009-11-17 6:37 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: Nanako Shiraishi, git, gitster
In-Reply-To: <20091117035945.GA1728@comcast.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> On Mon, Nov 16, 2009 at 07:50:48PM +0900, Nanako Shiraishi wrote:
>> Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
>>
>> > The reverse reference has long existed, and the autocrlf description
>> > was actually obsolete and wrong (saying only file content is used),
>> > not just incomplete.
>>
>> What do you mean by "reverse reference"?
>
> I'm refering to the fact that the "crlf" section of
> Documentation/gitattributes.txt mentions core.autocrlf,
> which is in the opposite (reverse) direction as this new reference
> I'm adding.
> ...
> Do I need to resubmit the patch, in order to rephrase the commit
> message?
Thanks; I heard you, as your response was Cc'ed to me as well ;-)
How about this? I didn't touch the patch text (other than dropping
trailing whitespaces).
commit ff68668695486b72b5f06146eddf85b70841088a
Author: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Date: Sat Nov 14 11:35:00 2009 -0700
core.autocrlf documentation: mention the crlf attribute
The description of the configuration variable is obsolete and
wrong (saying only file content is used), not just incomplete.
It has used the attribute mechanism for a long time.
The documentation of gitattributes mentions the core.autocrlf
configuration variable in its description of crlf attribute.
Refer to the gitattributes documentation from here as well.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH 2/2] ls-tree: migrate to parse-options
From: Stephen Boyd @ 2009-11-17 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr7hisc7.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thanks.
>
> As parse-options infrastructure gives much better per-option help text,
> there is not much point to keep the list of options that can go stale
> in the usage text.
>
> I'd squash this to yours. Ok?
>
I like this style too. Less usage update patches are better. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] t3101: test more ls-tree options
From: Stephen Boyd @ 2009-11-17 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws1piscw.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thanks. I'd squash this patch in for the following reasons; Ok?
Looks good. Thanks.
I figured reusing the test_output function would be a bad idea.
^ permalink raw reply
* Re: [PATCH] Document git-svn's first-parent rule
From: Junio C Hamano @ 2009-11-17 6:25 UTC (permalink / raw)
To: Eric Wong; +Cc: Thomas Rast, git
In-Reply-To: <20091116231455.GA13460@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Thomas Rast <trast@student.ethz.ch> wrote:
>> git-svn has the following rule to detect the SVN base for its
>> operations: find the first git-svn-id line reachable through
>> first-parent ancestry. IOW,
>>
>> git log --grep=^git-svn-id: --first-parent -1
>>
>> Document this, as it is very important when using merges with git-svn.
>>
>> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
>
> Thanks Thomas,
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
Thanks; is it a good time to pull from your bogomips repository to get
accumulated changes?
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-17 6:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, git, Karl Chen
In-Reply-To: <m3k4xqc9qj.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index d1e2120..c37b51d 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
>> core.excludesfile::
>> In addition to '.gitignore' (per-directory) and
>> '.git/info/exclude', git looks into this file for patterns
>> - of files which are not meant to be tracked. See
>> + of files which are not meant to be tracked. "~" and "~user"
>> + are expanded to the user's home directory. See
>> linkgit:gitignore[5].
>>
>> core.editor::
>
> It would be nice to have an option to git-config which would do such
> expansion, as a separate type similar to --int and --bool, e.g.:
>
> git config --path section.key
>
> so that not only core.excludesfile could use this new feature, but for
> example also core.worktree, commit.template, gitcvs.logfile,
> mailmap.file, and perhaps also *.receivepack and *.uploadpack
What should "git config -l" do for these (and core.excludesfile)?
^ permalink raw reply
* Re: [PATCH 2/2] ls-tree: migrate to parse-options
From: Junio C Hamano @ 2009-11-17 6:22 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1258173248-31059-3-git-send-email-bebarino@gmail.com>
Thanks.
As parse-options infrastructure gives much better per-option help text,
there is not much point to keep the list of options that can go stale
in the usage text.
I'd squash this to yours. Ok?
---
builtin-ls-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 04408df..14a913a 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -24,7 +24,7 @@ static int chomp_prefix;
static const char *ls_tree_prefix;
static const char * const ls_tree_usage[] = {
- "git ls-tree [-d] [-r] [-t] [-l | --long] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]",
+ "git ls-tree <options> <tree-ish> [path...]",
NULL
};
--
1.6.5.3.283.g4b054
^ permalink raw reply related
* Re: [PATCH 1/2] t3101: test more ls-tree options
From: Junio C Hamano @ 2009-11-17 6:21 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1258173248-31059-2-git-send-email-bebarino@gmail.com>
Thanks. I'd squash this patch in for the following reasons; Ok?
- The --abbrev=n option only guarantees that at least n hexdigits are
used but the implementation is allowed to use more to avoid
ambiguities.
- The point of test_output function is that it does its own filtering
before comparison; it is misleading to feed it if the caller munges the
input.
- Redirection should be immediately followed by filename; this is just a
matter of personal taste, but being consistent in the new code is
better than resulting in blocks of lines with mixed styles (no, I won't
welcome a patch to fix the existing "cmd > file", unless it is done as
part of a patch aka "while at it" that fixes something of substance
nearby at the same time).
t/t3101-ls-tree-dirname.sh | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
index 99458e4..6ef371a 100755
--- a/t/t3101-ls-tree-dirname.sh
+++ b/t/t3101-ls-tree-dirname.sh
@@ -39,8 +39,8 @@ test_expect_success \
tree=`git write-tree` &&
echo $tree'
-_x5='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
-_x40="$_x5$_x5$_x5$_x5$_x5$_x5$_x5$_x5"
+_x05='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x05$_x05$_x05$_x05$_x05$_x05$_x05$_x05"
test_output () {
sed -e "s/ $_x40 / X /" <current >check
test_cmp expected check
@@ -145,7 +145,7 @@ test_expect_success 'ls-tree --full-name' '
(
cd path0 &&
git ls-tree --full-name $tree a
- ) > current &&
+ ) >current &&
cat >expected <<\EOF &&
040000 tree X path0/a
EOF
@@ -156,7 +156,7 @@ test_expect_success 'ls-tree --full-tree' '
(
cd path1/b/c &&
git ls-tree --full-tree $tree
- ) > current &&
+ ) >current &&
cat >expected <<\EOF &&
100644 blob X 1.txt
100644 blob X 2.txt
@@ -172,7 +172,7 @@ test_expect_success 'ls-tree --full-tree -r' '
(
cd path3/ &&
git ls-tree --full-tree -r $tree
- ) > current &&
+ ) >current &&
cat >expected <<\EOF &&
100644 blob X 1.txt
100644 blob X 2.txt
@@ -186,8 +186,8 @@ EOF
'
test_expect_success 'ls-tree --abbrev=5' '
- git ls-tree --abbrev=5 $tree > current.abbrev &&
- sed -e "s/ $_x5 / X /" < current.abbrev > current &&
+ git ls-tree --abbrev=5 $tree >current &&
+ sed -e "s/ $_x05[0-9a-f]* / X /" <current >check &&
cat >expected <<\EOF &&
100644 blob X 1.txt
100644 blob X 2.txt
@@ -196,11 +196,11 @@ test_expect_success 'ls-tree --abbrev=5' '
040000 tree X path2
040000 tree X path3
EOF
- test_output
+ test_cmp expected check
'
test_expect_success 'ls-tree --name-only' '
- git ls-tree --name-only $tree > current
+ git ls-tree --name-only $tree >current
cat >expected <<\EOF &&
1.txt
2.txt
@@ -213,7 +213,7 @@ EOF
'
test_expect_success 'ls-tree --name-only -r' '
- git ls-tree --name-only -r $tree > current
+ git ls-tree --name-only -r $tree >current
cat >expected <<\EOF &&
1.txt
2.txt
--
1.6.5.3.283.g4b054
^ permalink raw reply related
* [PATCH 1/2] replace: use a GIT_NO_REPLACE_OBJECTS env variable
From: Christian Couder @ 2009-11-17 5:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This environment variable is set when the --no-replace-objects
flag is passed to git, and it is read when other environment
variables are read.
It is useful for example for scripts, as the git commands used in
them can now be aware that they must not read replace refs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 1 +
environment.c | 2 ++
git.c | 3 +++
t/t6050-replace.sh | 17 +++++++++++++++++
4 files changed, 23 insertions(+), 0 deletions(-)
Michael J Gruber wrote:
>
> [ The example also shows that we need a way to specify
> --no-replace-objects for gitk. Would easier if gitk really
> where git something. ]
These 2 patches should fix that for gitk and many other scripted
commands. But if it doesn't for some, please tell me.
Thanks,
Christian.
diff --git a/cache.h b/cache.h
index 71a731d..bc77909 100644
--- a/cache.h
+++ b/cache.h
@@ -369,6 +369,7 @@ static inline enum object_type object_type(unsigned int mode)
#define CONFIG_ENVIRONMENT "GIT_CONFIG"
#define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
#define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
+#define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
#define ATTRIBUTE_MACRO_PREFIX "[attr]"
diff --git a/environment.c b/environment.c
index 5de6837..279a38a 100644
--- a/environment.c
+++ b/environment.c
@@ -83,6 +83,8 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = git_pathdup("info/grafts");
+ if (read_replace_refs && getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
+ read_replace_refs = 0;
}
int is_bare_repository(void)
diff --git a/git.c b/git.c
index bd2c5fe..7f7d73d 100644
--- a/git.c
+++ b/git.c
@@ -89,6 +89,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--no-replace-objects")) {
read_replace_refs = 0;
+ setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "", 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index d4818b4..82cf2ec 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -77,6 +77,11 @@ test_expect_success 'test --no-replace-objects option' '
git --no-replace-objects show $HASH2 | grep "A U Thor"
'
+test_expect_success 'test GIT_NO_REPLACE_OBJECTS env variable' '
+ GIT_NO_REPLACE_OBJECTS= git cat-file commit $HASH2 | grep "author A U Thor" &&
+ GIT_NO_REPLACE_OBJECTS= git show $HASH2 | grep "A U Thor"
+'
+
cat >tag.sig <<EOF
object $HASH2
type commit
@@ -202,6 +207,18 @@ test_expect_success 'fetch branch with replacement' '
cd ..
'
+test_expect_success 'bisect and replacements' '
+ git bisect start $HASH7 $HASH1 &&
+ test "$S" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ GIT_NO_REPLACE_OBJECTS= git bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ git --no-replace-objects bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH 2/2] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-17 5:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
gitk-git/gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..7ca7fbc 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -128,7 +128,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
+ "--no-replace-objects" {
+ set env(GIT_NO_REPLACE_OBJECTS) ""
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Tarmigan @ 2009-11-17 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7viqdb0zhs.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 10:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
>> ...
>>> Shouldn't this instead be:
>>>
>>> diff --git a/http-backend.c b/http-backend.c
>>> index 9021266..16ec635 100644
>>> --- a/http-backend.c
>>> +++ b/http-backend.c
>>> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
>>> }
>>>
>>> cmd = c;
>>> - cmd_arg = xmalloc(n);
>>> + cmd_arg = xmalloc(n + 1);
>>> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
>>> cmd_arg[n] = '\0';
>>> dir[out[0].rm_so] = 0;
>>>
>>> The cmd_arg string was simply allocated too small. Your fix is
>>> terminating the string one character too short which would cause
>>> get_loose_object and get_pack_file to break.
>>
>> Actually, from my reading, I think his fix is right, because you trim
>> the first character during the strncpy (using "out[0].rm_so + 1").
>
> Your regexps all start with leading "/", and rm_so+1 points at the
> character after the slash; the intention being that you would copy
> the rest of the matched sequence without the leading "/".
>
> So allocating n = rm_eo - rm_so is Ok. It counts the space for
> terminating NUL. But copying "up to n bytes" using strncpy(), only to NUL
> terminate immediately later, is dubious. You would want to copy only n-1
> bytes. I.e.
>
> n = out[0].rm_eo - out[0].rm_so; /* allocation */
> ... validate and fail invalid method ...
> cmd_arg = xmalloc(n);
> memcpy(cmd_arg, dir + out[0].rm_so + 1, n-1);
> cmd_arg[n-1] = '\0';
>
I think the strncpy( , ,n) would not harm anything because we won't
overflow dir because it's NUL terminated in getdir(), and the '\0'
shouldn't match the regex. But I agree that strncpy( , , n-1) is
better and memcpy( , , n-1) is better still.
Better eyes than mine have now looked at this and see different things
each time. I wonder if some parts could be made a little less subtle
(perhaps along with the dir[out[0].rm_so] = 0;)?
Thanks,
Tarmigan
^ permalink raw reply
* [ANNOUNCE] for TortoiseGit 1.2.1.0
From: Frank Li @ 2009-11-17 4:17 UTC (permalink / raw)
To: git, tortoisegit-dev, tortoisegit-users, tortoisegit-announce
http://tortoisegit.googlecode.com/files/TortoiseGit-1.2.1.0-32bit.msi
http://tortoisegit.googlecode.com/files/TortoiseGit-1.2.1.0-64bit.msi
= Release 1.2.1.0 =
== Features ==
* Add color success and fail at ProgressDlg
* Log Dialog
Show work copy to log dialog. User can commit change at log dialog.
Easy to compare with working copy difference
* Allow Alt+O in commit dialog for OK
* Sync Dialog remote URL support save history
* Add remote branch and current branch at proptery page
* Add no-commit option at merge dialog
* Enable IBugTraqProvide CheckCommit and OnCommitFinished
== Bug Fix ==
* Fixed issue #219: Blame Error when git repository is at root
directory and path use "/"
* Fixed issue #214: installer inserts unused or faulty registry key
* Fixed issue #179: Log dialog lacks information about changed files
* Fixed issue #209: High CPU usage in tortoiseproc.exe & limit line number
* Fixed issue #212: Disable the "Select items automaticlly" option
has no effect to commit files dialog
* Fixed issue #209: High CPU usage in tortoiseproc.exe & Append text
to edit ctrl
* Fixed Issue #203: Remote URL select box in sync dialog is not
populated with remotes.
* Fixed Issue #208: During push (from context menu), branches
missing from drop down list.
* Fixed issue #86: Globally sets HOME affecting third-party
applications (GNU Emacs)
* Fixed issue #188: Add Git Properties tab into Windows File Properties
^ permalink raw reply
* Re: [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Matthew Ogilvie @ 2009-11-17 3:59 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, gitster
In-Reply-To: <20091116195048.6117@nanako3.lavabit.com>
On Mon, Nov 16, 2009 at 07:50:48PM +0900, Nanako Shiraishi wrote:
> Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
>
> > The reverse reference has long existed, and the autocrlf description
> > was actually obsolete and wrong (saying only file content is used),
> > not just incomplete.
>
> What do you mean by "reverse reference"?
>
I'm refering to the fact that the "crlf" section of
Documentation/gitattributes.txt mentions core.autocrlf,
which is in the opposite (reverse) direction as this new reference
I'm adding.
The crlf section has a much more thorough description of
the various knobs and settings and how they interact. But
I just checked, and although the gitattributes crlf section
describes core.autocrlf in reasonable detail, it does not have an
actual link (reference?) to git-config or the core.autocrlf
section. So the commit message isn't as clear as it could be.
Do I need to resubmit the patch, in order to rephrase the commit
message?
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* git-svn of both trunk and tags while having no access to the 'parent' of those
From: Yaroslav Halchenko @ 2009-11-17 2:59 UTC (permalink / raw)
To: git
Dear Git People,
I've ran into a situation here:
there is a repository with trunk and releases (analog to tags there)
available for public, but the rest of directories and their parent is
not available without authentication... ie I can access
http://domain.com/svnrepo/trunk
http://domain.com/svnrepo/releases
but not
http://domain.com/svnrepo/
Whenever I use git-svn (1.6.5 in Debian):
git svn clone --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo svnrepo.gitsvn
it asks for authentication... I guess, now I can only clone trunk and
releases separately? or may be there is some way to avoid the
problem, ie avoid looking 'into root'?
Thanks in advance!
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.5.3
From: Junio C Hamano @ 2009-11-17 3:18 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.5.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.3-1.fc9.$arch.rpm (RPM)
Git v1.6.5.3 Release Notes
==========================
Fixes since v1.6.5.2
--------------------
* info/grafts file didn't ignore trailing CR at the end of lines.
* Packages generated on newer FC were unreadable by older versions of
RPM as the new default is to use stronger hash.
* output from "git blame" was unreadable when the file ended in an
incomplete line.
* "git add -i/-p" didn't handle deletion of empty files correctly.
* "git clone" takes up to two parameters, but did not complain when
given more arguments than necessary and silently ignored them.
* "git cvsimport" did not read files given as command line arguments
correctly when it is run from a subdirectory.
* "git diff --color-words -U0" didn't work correctly.
* The handling of blank lines at the end of file by "git diff/apply
--whitespace" was inconsistent with the other kinds of errors.
They are now colored, warned against, and fixed the same way as others.
* There was no way to allow blank lines at the end of file without
allowing extra blanks at the end of lines. You can use blank-at-eof
and blank-at-eol whitespace error class to specify them separately.
The old trailing-space error class is now a short-hand to set both.
* "-p" option to "git format-patch" was supposed to suppress diffstat
generation, but it was broken since 1.6.1.
* "git imap-send" did not compile cleanly with newer OpenSSL.
* "git help -a" outside of a git repository was broken.
* "git ls-files -i" was supposed to be inverse of "git ls-files" without -i
with respect to exclude patterns, but it was broken since 1.6.5.2.
* "git ls-remote" outside of a git repository over http was broken.
* "git rebase -i" gave bogus error message when the command word was
misspelled.
* "git receive-pack" that is run in response to "git push" did not run
garbage collection nor update-server-info, but in larger hosting sites,
these almost always need to be run. To help site administrators, the
command now runs "gc --auto" and "u-s-i" by setting receive.autogc
and receive.updateserverinfo configuration variables, respectively.
* Release notes spelled the package name with incorrect capitalization.
* "gitweb" did not escape non-ascii characters correctly in the URL.
* "gitweb" showed "patch" link even for merge commits.
* "gitweb" showed incorrect links for blob line numbers in pathinfo mode.
Other minor documentation updates are included.
----------------------------------------------------------------
Changes since v1.6.5.2 are as follows:
Björn Gustavsson (1):
git-clone.txt: Fix grammar and formatting
Björn Steinbrink (1):
pre-commit.sample: Diff against the empty tree when HEAD is invalid
Clemens Buchacher (1):
modernize fetch/merge/pull examples
Daniel Barkalow (2):
Require a struct remote in transport_get()
Allow curl helper to work without a local repository
Dmitry V. Levin (1):
Makefile: add compat/bswap.h to LIB_H
Gerrit Pape (1):
help -i: properly error out if no info viewer can be found
Gisle Aas (2):
More precise description of 'git describe --abbrev'
Fix documentation grammar typo
Giuseppe Bilotta (1):
gitweb: fix esc_param
Jakub Narebski (1):
gitweb: Do not show 'patch' link for merge commits
Jan Krüger (1):
rebase -i: more graceful handling of invalid commands
Jari Aalto (3):
Documentation/fetch-options.txt: order options alphabetically
Documentation/git-pull.txt: Add subtitles above included option files
Documentation/merge-options.txt: order options in alphabetical groups
Jeff King (6):
cvsimport: fix relative argument filenames
push: always load default config
add-interactive: handle deletion of empty files
ls-files: unbreak "ls-files -i"
push: fix typo in usage
format-patch: make "-p" suppress diffstat
Johannes Schindelin (3):
blame: make sure that the last line ends in an LF
help -a: do not unnecessarily look for a repository
diff --color-words -U0: fix the location of hunk headers
Jonathan Nieder (4):
clone: detect extra arguments
Add intermediate build products to .gitignore
check-ref-format: update usage string
merge: do not setup worktree twice
Junio C Hamano (22):
apply --whitespace=fix: fix handling of blank lines at the eof
apply --whitespace=fix: detect new blank lines at eof correctly
apply.c: split check_whitespace() into two
apply --whitespace=warn/error: diagnose blank at EOF
apply --whitespace: warn blank but not necessarily empty lines at EOF
diff.c: the builtin_diff() deals with only two-file comparison
diff --whitespace=warn/error: obey blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --color: color blank-at-eof
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --whitespace: fix blank lines at end
diff.c: shuffling code around
diff.c: split emit_line() from the first char and the rest of the line
diff.c: emit_add_line() takes only the rest of the line
diff -B: colour whitespace errors
info/grafts: allow trailing whitespaces at the end of line
gc --auto --quiet: make the notice a bit less verboase
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
clone: fix help on options
diff --color-words: bit of clean-up
check-ref-format -h: it does not know the --print option yet
Git 1.6.5.3
Markus Heidelberg (1):
t4034-diff-words: add a test for word diff without context
Petr Baudis (1):
gitweb: Fix blob linenr links in pathinfo mode
Sebastian Schuberth (1):
Do not try to remove directories when removing old links
Stephen Boyd (1):
git-add.txt: fix formatting of --patch section
Thomas Rast (1):
Quote ' as \(aq in manpages
Todd Zullinger (1):
Makefile: Ensure rpm packages can be read by older rpm versions
Vietor Liu (1):
imap-send.c: fix compiler warnings for OpenSSL 1.0
^ permalink raw reply
* [PATCH v3] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-17 2:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
This commit also removes the options from the first line
of the usage string (replacing them with '<options>...'
and lets them be documented in the paragraph below.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage string arrays have been created for each subcommand.
v2 fixed line wrap issues present in v1.
v3 changes include:
- Changed usage strings to use '<options>...' rather than document
the options both in the actual string and in the OPT_x array
(as recommended by Junio).
- Removed the change made to the usage string array constructed
in 'cmd_remote'. v2 was broken because that change had made
the command stop recognizing the '-v' option. Added an extra
note here which explains that '-v' is only valid when placed
after 'git remote' and before any 'subcommand'.
- Updated the man page.
Documentation/git-remote.txt | 13 +++++----
builtin-remote.c | 58 ++++++++++++++++++++++++++----------------
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..c84265a 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
-'git remote' [-v | --verbose]
-'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote' [<options>...]
+'git remote add' [<options>...] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
-'git remote set-head' <name> [-a | -d | <branch>]
-'git remote show' [-n] <name>
-'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote set-head' <name> [<options>...]
+'git remote show' [<options>...] <name>
+'git remote prune' [<options>...] <name>
+'git remote update' [<options>...] [group | remote]...
DESCRIPTION
-----------
@@ -30,6 +30,7 @@ OPTIONS
-v::
--verbose::
Be a little more verbose and show remote url after name.
+ NOTE: This must be placed between `remote` and `subcommand`.
COMMANDS
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..ee86810 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [<options>...]"
+#define REMOTE_ADD_USAGE "git remote add [<options>...] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [<options>...]"
+#define REMOTE_SHOW_USAGE "git remote show [<options>...] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [<options>...] <name>"
+#define REMOTE_UPDATE_USAGE "git remote update [<options>...]"
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = { REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = { REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = { REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = { REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = { REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = { REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = { REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -984,7 +1000,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1088,7 +1104,7 @@ static int set_head(int argc, const char **argv)
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1130,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1154,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1243,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1348,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
OPT_END()
};
int result;
--
1.6.5.2.186.g868bf.dirty
^ permalink raw reply related
* Script to tie git and Jira
From: Bill Lear @ 2009-11-17 1:44 UTC (permalink / raw)
To: git; +Cc: Patrick Schoenfeld
I have started a project on github that is essentially a script to tie
git and Jira, at http://github.com/rael/git-jira. We use it at our
company to help us with release management and it has proven useful.
See the README file for complete details. Following is a brief
overview.
The script implements a certain convention we use: developers do work
on topic branches that are named after Jira tickets and are created as
branches off of origin/master.
When you first run the script, it will prompt you for connection
parameters to your Jira server. You will then be able to create new
Jira issues and associated git branches:
% git jira open --summary "Better log filtration method"
git branch PROJ-20 created
% git branch -a
PROJ-20
* master
You can supply defaults for project, component, and issue type in your
git config file, and you can provide these as arguments to the script
as well (the README shows how to do this).
You can add a suffix when opening an issue if you like, to help you
remember the purpose of the branch:
% git jira open --summary "Better log filtration method" -x "improve_logging"
git branch PROJ-20_improve_logging created
% git branch -a
PROJ-20_improve_logging
* master
Or, you can rely on the script to tell you details of a git jira
branch (with or without a suffix):
% git jira describe -i PROJ-20_improve_logging
Data for issue: PROJ-20
Issue key . . . . . . . . . . : PROJ-20
Type . . . . . . . . . . . . : Bug(1)
Status . . . . . . . . . . . : Open(1)
Priority . . . . . . . . . . : Major(3)
Assignee . . . . . . . . . . : rael
Reporter . . . . . . . . . . : rael
Created . . . . . . . . . . . : 11/16/09 7:30 PM
Updated . . . . . . . . . . . : 11/16/09 7:30 PM
Due date . . . . . . . . . . :
Summary . . . . . . . . . . . : Better filtration method
Description . . . . . . . . . :
Components . . . . . . . . . : 'Component1'
Affects versions . . . . . . :
Fix versions . . . . . . . . :
Environment . . . . . . . . . :
Resolution . . . . . . . . . :
Votes . . . . . . . . . . . . : 0
Adding a '-v' or '--verbose' will add all comments to the output.
This will also work implicitly for the current branch:
% git checkout PROJ-20_improve_logging
% git jira describe
Data for issue: PROJ-20
Issue key . . . . . . . . . . : PROJ-20
Type . . . . . . . . . . . . : Bug(1)
[...]
You can also resolve issues you have completed:
% git jira close -i PROJ-20
Successfully progressed issue: PROJ-20 with step 'Resolve Issue'
Feel free to provide comments, criticize, suggest improvements, etc.
Bill
^ permalink raw reply
* Re: [PATCH RFC] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-17 1:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocn2klp8.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 8:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tim Henigan <tim.henigan@gmail.com> writes:
>
>> ...
>> +static const char * const builtin_remote_add_usage[] = {
>> REMOTE_ADD_USAGE, NULL };
>> ...
>
> I am not sure about the value of reusing option string like this, and for
> all other subcommands the same comment applies. For example, in the case
> of "remote add -h", you would use
>
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> from REMOTE_ADD_USAGE, but ...
Do you object to the new #defines for the strings? I added them since we now
really need to construct the usage string for 2 separate uses:
(1) When 'git remote -h' is invoked, we need to return the usage
string showing
all subcommands.
(2) When 'git remote <subcommand> -h' is invoked, we need to return the
usage for just that command.
It doesn't make sense to me to maintain separate strings for the two use cases.
>> @@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
>> int i;
>>
>> struct option options[] = {
>> - OPT_GROUP("add specific options"),
>> OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
>> OPT_CALLBACK('t', "track", &track, "branch",
>> "branch(es) to track", opt_parse_track),
>> @@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
>> OPT_END()
>> };
>>
>> - argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
>> + argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
>> 0);
>
> ... the options list is used to reproduce the information in a major part
> of that string already. So I would prefer builtin_remote_add_usage[] to
> be something like:
>
> "git remote add [<options>...] <name> <url>"
>
> It is in line with a discussion we had earlier:
>
> http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
I planned to make this change in a separate (or maybe just a later
version) patch,
but first I wanted to be sure my other changes were sound. I will send a new
version that includes this change.
Should this change be made to the man page as well?
>> @@ -1334,7 +1348,6 @@ static int show_all(void)
>> int cmd_remote(int argc, const char **argv, const char *prefix)
>> {
>> struct option options[] = {
>> - OPT__VERBOSE(&verbose),
>> OPT_END()
>> };
>> int result;
I did find one problem with the above portion of the patch. With this change
'-v' was no longer recognized as an option. I will remove this change in the
next version. Keeping it means that '-v' will still be reported in the
'git remote -h' usage string, but I don't see an easy way to remove the string
without removing the feature.
^ permalink raw reply
* Re: [PATCH RFC] git remote: Separate usage strings for subcommands
From: Junio C Hamano @ 2009-11-17 1:02 UTC (permalink / raw)
To: Tim Henigan; +Cc: git
In-Reply-To: <32c343770911151343y1ed0aak83b43a4ab57eb6ab@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> All usage strings are still only located at the top of file. However,
> separate usage string arrays have been created for each subcommand.
>
> Does this look like a sane way to structure the code?
>
> If anyone else should be added to the CC list, please let me know.
>
>
> builtin-remote.c | 57 +++++++++++++++++++++++++++++++++--------------------
> 1 files changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/builtin-remote.c b/builtin-remote.c
> index 0777dd7..ec65a4b 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -7,18 +7,35 @@
> #include "run-command.h"
> #include "refs.h"
>
> +#define REMOTE_BARE_USAGE "git remote [-v | --verbose]"
> +#define REMOTE_ADD_USAGE "git remote add [-t <branch>] [-m <master>]
> [-f] [--mirror] <name> <url>"
> +#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
> +#define REMOTE_RM_USAGE "git remote rm <name>"
> +#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
> +#define REMOTE_SHOW_USAGE "git remote show [-n] <name>"
> +#define REMOTE_PRUNE_USAGE "git remote prune [-n | --dry-run] <name>"
> +#define REMOTE_UPDATE_USAGE "git remote [-v | --verbose] update [-p |
> --prune] [group]"
> +
> static const char * const builtin_remote_usage[] = {
> - "git remote [-v | --verbose]",
> - "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
> - "git remote rename <old> <new>",
> - "git remote rm <name>",
> - "git remote set-head <name> [-a | -d | <branch>]",
> - "git remote show [-n] <name>",
> - "git remote prune [-n | --dry-run] <name>",
> - "git remote [-v | --verbose] update [-p | --prune] [group]",
> + REMOTE_BARE_USAGE,
> + REMOTE_ADD_USAGE,
> + REMOTE_RENAME_USAGE,
> + REMOTE_RM_USAGE,
> + REMOTE_SETHEAD_USAGE,
> + REMOTE_SHOW_USAGE,
> + REMOTE_PRUNE_USAGE,
> + REMOTE_UPDATE_USAGE,
> NULL
> };
> ...
> +static const char * const builtin_remote_add_usage[] = {
> REMOTE_ADD_USAGE, NULL };
> ...
I am not sure about the value of reusing option string like this, and for
all other subcommands the same comment applies. For example, in the case
of "remote add -h", you would use
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
from REMOTE_ADD_USAGE, but ...
> @@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
> int i;
>
> struct option options[] = {
> - OPT_GROUP("add specific options"),
> OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
> OPT_CALLBACK('t', "track", &track, "branch",
> "branch(es) to track", opt_parse_track),
> @@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
> OPT_END()
> };
>
> - argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
> + argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
> 0);
... the options list is used to reproduce the information in a major part
of that string already. So I would prefer builtin_remote_add_usage[] to
be something like:
"git remote add [<options>...] <name> <url>"
It is in line with a discussion we had earlier:
http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ permalink raw reply
* [PATCH RFC v2] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-17 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This is a resend -- v1 had line wrap issues. Sorry for the noise.
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage string arrays have been created for each subcommand.
Does this look like a sane way to structure the code?
builtin-remote.c | 57 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..ec65a4b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [-v | --verbose]"
+#define REMOTE_ADD_USAGE "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
+#define REMOTE_SHOW_USAGE "git remote show [-n] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [-n | --dry-run] <name>"
+#define REMOTE_UPDATE_USAGE "git remote [-v | --verbose] update [-p | --prune] [group]"
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = { REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = { REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = { REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = { REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = { REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = { REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = { REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -984,7 +1000,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1088,7 +1104,7 @@ static int set_head(int argc, const char **argv)
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1130,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1154,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1243,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1348,6 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
OPT_END()
};
int result;
-- 1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox