* [PATCHv3 0/5] patterns for branch list
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.git.git@drmicha.warpmail.net>
v3 has reworded commit messages for 2,3,4 and tests for combinations
of branch options in 4, as suggested.
No code changes (besides the additional tests in 4).
Michael J Gruber (5):
t6040: test branch -vv
git-tag: introduce long forms for the options
git-branch: introduce missing long forms for the options
branch: introduce --list option
branch: allow pattern arguments
Documentation/git-branch.txt | 20 +++++++++++++++--
Documentation/git-tag.txt | 8 +++++++
builtin/branch.c | 46 +++++++++++++++++++++++++++++++----------
builtin/tag.c | 16 +++++++-------
t/t3200-branch.sh | 32 +++++++++++++++++++++++++++++
t/t3203-branch-output.sh | 24 +++++++++++++++++++++
t/t6040-tracking-info.sh | 16 ++++++++++++++
7 files changed, 140 insertions(+), 22 deletions(-)
--
1.7.6.845.gc3c05
^ permalink raw reply
* [PATCHv3 1/5] t6040: test branch -vv
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314543252.git.git@drmicha.warpmail.net>
t6040 has a test for 'git branch -v' but not for 'git branch -vv'.
Add one.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t6040-tracking-info.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 19de5b1..19272bc 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -51,6 +51,22 @@ test_expect_success 'branch -v' '
test_i18ncmp expect actual
'
+cat >expect <<\EOF
+b1 origin/master: ahead 1, behind 1
+b2 origin/master: ahead 1, behind 1
+b3 origin/master: behind 1
+b4 origin/master: ahead 2
+EOF
+
+test_expect_success 'branch -vv' '
+ (
+ cd test &&
+ git branch -vv
+ ) |
+ sed -n -e "$script" >actual &&
+ test_i18ncmp expect actual
+'
+
test_expect_success 'checkout' '
(
cd test && git checkout b1
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCHv3 2/5] git-tag: introduce long forms for the options
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314543252.git.git@drmicha.warpmail.net>
Long forms are better to memorize and more reliably uniform across
commands.
Design notes:
-u,--local-user is named following the analogous gnupg option.
-l,--list is not an argument taking option but a mode switch.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-tag.txt | 8 ++++++++
builtin/tag.c | 16 ++++++++--------
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index fb1c0ac..c83cb13 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -43,12 +43,15 @@ GnuPG key for signing.
OPTIONS
-------
-a::
+--annotate::
Make an unsigned, annotated tag object
-s::
+--sign::
Make a GPG-signed tag, using the default e-mail address's key
-u <key-id>::
+--local-user=<key-id>::
Make a GPG-signed tag, using the given key
-f::
@@ -56,9 +59,11 @@ OPTIONS
Replace an existing tag with the given name (instead of failing)
-d::
+--delete::
Delete existing tags with the given names.
-v::
+--verify::
Verify the gpg signature of the given tag names.
-n<num>::
@@ -69,6 +74,7 @@ OPTIONS
If the tag is not annotated, the commit message is displayed instead.
-l <pattern>::
+--list <pattern>::
List tags with names that match the given pattern (or all if no
pattern is given). Running "git tag" without arguments also
lists all tags. The pattern is a shell wildcard (i.e., matched
@@ -79,6 +85,7 @@ OPTIONS
Only list tags which contain the specified commit.
-m <msg>::
+--message=<msg>::
Use the given tag message (instead of prompting).
If multiple `-m` options are given, their values are
concatenated as separate paragraphs.
@@ -86,6 +93,7 @@ OPTIONS
is given.
-F <file>::
+--file=<file>::
Take the tag message from the given file. Use '-' to
read the message from the standard input.
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
diff --git a/builtin/tag.c b/builtin/tag.c
index 667515e..9d89616 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -429,21 +429,21 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
struct option options[] = {
- OPT_BOOLEAN('l', NULL, &list, "list tag names"),
+ OPT_BOOLEAN('l', "list", &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, "n",
"print <n> lines of each tag message",
PARSE_OPT_OPTARG, NULL, 1 },
- OPT_BOOLEAN('d', NULL, &delete, "delete tags"),
- OPT_BOOLEAN('v', NULL, &verify, "verify tags"),
+ OPT_BOOLEAN('d', "delete", &delete, "delete tags"),
+ OPT_BOOLEAN('v', "verify", &verify, "verify tags"),
OPT_GROUP("Tag creation options"),
- OPT_BOOLEAN('a', NULL, &annotate,
+ OPT_BOOLEAN('a', "annotate", &annotate,
"annotated tag, needs a message"),
- OPT_CALLBACK('m', NULL, &msg, "message",
+ OPT_CALLBACK('m', "message", &msg, "message",
"tag message", parse_msg_arg),
- OPT_FILENAME('F', NULL, &msgfile, "read message from file"),
- OPT_BOOLEAN('s', NULL, &sign, "annotated and GPG-signed tag"),
- OPT_STRING('u', NULL, &keyid, "key-id",
+ OPT_FILENAME('F', "file", &msgfile, "read message from file"),
+ OPT_BOOLEAN('s', "sign", &sign, "annotated and GPG-signed tag"),
+ OPT_STRING('u', "local-user", &keyid, "key-id",
"use another key to sign the tag"),
OPT__FORCE(&force, "replace the tag if exists"),
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCHv3 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314543252.git.git@drmicha.warpmail.net>
Currently, there is no way to invoke the list mode explicitly, without
giving -v to force verbose output.
Introduce a --list option which invokes the list mode. This will be
beneficial for invoking list mode with pattern matching, which otherwise
would be interpreted as branch creation.
Along with --list, test also combinations of existing options.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 9 +++++++--
builtin/branch.c | 12 +++++++++---
t/t3200-branch.sh | 32 ++++++++++++++++++++++++++++++++
t/t3203-branch-output.sh | 14 ++++++++++++++
4 files changed, 62 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4c64ac9..ac278fb 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
- [-v [--abbrev=<length> | --no-abbrev]]
+ [--list] [-v [--abbrev=<length> | --no-abbrev]]
[(--merged | --no-merged | --contains) [<commit>]]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
@@ -20,7 +20,8 @@ DESCRIPTION
With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both.
+branches to be listed, and option `-a` shows both. This list mode is also
+activated by the `--list` and `-v` options (see below).
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -110,11 +111,15 @@ OPTIONS
--all::
List both remote-tracking branches and local branches.
+--list::
+ Activate the list mode.
+
-v::
--verbose::
Show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the name of the upstream branch, as well.
+ `--list` is implied by all verbosity options.
--abbrev=<length>::
Alter the sha1's minimum display length in the output listing.
diff --git a/builtin/branch.c b/builtin/branch.c
index 94e41ae..4a33b07 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -608,7 +608,7 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, rename = 0, force_create = 0;
+ int delete = 0, rename = 0, force_create = 0, list = 0;
int verbose = 0, abbrev = -1, detached = 0;
int reflog = 0;
enum branch_track track;
@@ -647,6 +647,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
OPT_BIT('m', "move", &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
+ OPT_BOOLEAN(0, "list", &list, "list branch names"),
OPT_BOOLEAN('l', "create-reflog", &reflog, "create the branch's reflog"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
@@ -686,7 +687,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
- if (!!delete + !!rename + !!force_create > 1)
+
+ if (!delete && !rename && !force_create &&
+ (argc == 0 || (verbose && argc)))
+ list = 1;
+
+ if (!!delete + !!rename + !!force_create + !!list > 1)
usage_with_options(builtin_branch_usage, options);
if (abbrev == -1)
@@ -694,7 +700,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
+ else if (list)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index cb6458d..931373c 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -98,6 +98,38 @@ test_expect_success 'git branch -m q r/q should fail when r exists' '
test_must_fail git branch -m q r/q
'
+test_expect_success 'git branch -v -d t should work' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ git branch -v -d t &&
+ test ! -f .git/refs/heads/t
+'
+
+test_expect_success 'git branch -v -m t s should work' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ git branch -v -m t s &&
+ test ! -f .git/refs/heads/t &&
+ test -f .git/refs/heads/s &&
+ git branch -d s
+'
+
+test_expect_success 'git branch -m -d t s should fail' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ test_must_fail git branch -m -d t s &&
+ git branch -d t &&
+ test ! -f .git/refs/heads/t
+'
+
+test_expect_success 'git branch --list -d t should fail' '
+ git branch t &&
+ test .git/refs/heads/t &&
+ test_must_fail git branch --list -d t &&
+ git branch -d t &&
+ test ! -f .git/refs/heads/t
+'
+
test_expect_success 'git branch -M foo bar should fail when bar is checked out' '
git branch bar &&
git checkout -b foo &&
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 6b7c118..61e095c 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -32,6 +32,20 @@ test_expect_success 'git branch shows local branches' '
test_cmp expect actual
'
+test_expect_success 'git branch --list shows local branches' '
+ git branch --list >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+ branch-one
+ branch-two
+EOF
+test_expect_success 'git branch --list pattern shows matching local branches' '
+ git branch --list branch* >actual &&
+ test_cmp expect actual
+'
+
cat >expect <<'EOF'
origin/HEAD -> origin/branch-one
origin/branch-one
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCHv3 3/5] git-branch: introduce missing long forms for the options
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314543252.git.git@drmicha.warpmail.net>
Long forms are better to memorize and more reliably uniform across
commands.
Names follow precedents, e.g. "git log --remotes".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
I'm somewhat torn between --move and --rename for -m. We have no real precedent
besides "git remote rename".
I left out -M and -D because I feel they should really be -m -f resp. -d -f.
---
Documentation/git-branch.txt | 5 +++++
builtin/branch.c | 10 +++++-----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 507b8d0..4c64ac9 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -64,6 +64,7 @@ way to clean up all obsolete remote-tracking branches.
OPTIONS
-------
-d::
+--delete::
Delete a branch. The branch must be fully merged in its
upstream branch, or in `HEAD` if no upstream was set with
`--track` or `--set-upstream`.
@@ -72,6 +73,7 @@ OPTIONS
Delete a branch irrespective of its merged status.
-l::
+--create-reflog::
Create the branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
based sha1 expressions such as "<branchname>@\{yesterday}".
@@ -84,6 +86,7 @@ OPTIONS
already. Without `-f` 'git branch' refuses to change an existing branch.
-m::
+--move::
Move/rename a branch and the corresponding reflog.
-M::
@@ -100,9 +103,11 @@ OPTIONS
Same as `--color=never`.
-r::
+--remotes::
List or delete (if used with -d) the remote-tracking branches.
-a::
+--all::
List both remote-tracking branches and local branches.
-v::
diff --git a/builtin/branch.c b/builtin/branch.c
index aa705a0..94e41ae 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -624,7 +624,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_SET_INT( 0, "set-upstream", &track, "change upstream info",
BRANCH_TRACK_OVERRIDE),
OPT__COLOR(&branch_use_color, "use colored output"),
- OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
+ OPT_SET_INT('r', "remotes", &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
{
OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
@@ -641,13 +641,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT__ABBREV(&abbrev),
OPT_GROUP("Specific git-branch actions:"),
- OPT_SET_INT('a', NULL, &kinds, "list both remote-tracking and local branches",
+ OPT_SET_INT('a', "all", &kinds, "list both remote-tracking and local branches",
REF_REMOTE_BRANCH | REF_LOCAL_BRANCH),
- OPT_BIT('d', NULL, &delete, "delete fully merged branch", 1),
+ OPT_BIT('d', "delete", &delete, "delete fully merged branch", 1),
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
- OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
+ OPT_BIT('m', "move", &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
- OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
+ OPT_BOOLEAN('l', "create-reflog", &reflog, "create the branch's reflog"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCHv3 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314543252.git.git@drmicha.warpmail.net>
Allow pattern arguments for the list mode just like for git tag -l.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 8 ++++++--
builtin/branch.c | 24 +++++++++++++++++++++---
t/t3203-branch-output.sh | 10 ++++++++++
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index ac278fb..2b8bc84 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[--list] [-v [--abbrev=<length> | --no-abbrev]]
- [(--merged | --no-merged | --contains) [<commit>]]
+ [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
@@ -22,6 +22,9 @@ With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
branches to be listed, and option `-a` shows both. This list mode is also
activated by the `--list` and `-v` options (see below).
+<pattern> restricts the output to matching branches, the pattern is a shell
+wildcard (i.e., matched using fnmatch(3))
+Multiple patterns may be given; if any of them matches, the tag is shown.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -112,7 +115,8 @@ OPTIONS
List both remote-tracking branches and local branches.
--list::
- Activate the list mode.
+ Activate the list mode. `git branch <pattern>` would try to create a branch,
+ use `git branch --list <pattern>` to list matching branches.
-v::
--verbose::
diff --git a/builtin/branch.c b/builtin/branch.c
index 4a33b07..e6bef49 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -260,9 +260,22 @@ static char *resolve_symref(const char *src, const char *prefix)
struct append_ref_cb {
struct ref_list *ref_list;
+ const char **pattern;
int ret;
};
+static int match_patterns(const char **pattern, const char *refname)
+{
+ if (!*pattern)
+ return 1; /* no pattern always matches */
+ while (*pattern) {
+ if (!fnmatch(*pattern, refname, 0))
+ return 1;
+ pattern++;
+ }
+ return 0;
+}
+
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct append_ref_cb *cb = (struct append_ref_cb *)(cb_data);
@@ -297,6 +310,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
+ if (!match_patterns(cb->pattern, refname))
+ return 0;
+
commit = NULL;
if (ref_list->verbose || ref_list->with_commit || merge_filter != NO_FILTER) {
commit = lookup_commit_reference_gently(sha1, 1);
@@ -492,7 +508,7 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char **pattern)
{
int i;
struct append_ref_cb cb;
@@ -506,6 +522,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
cb.ref_list = &ref_list;
+ cb.pattern = pattern;
cb.ret = 0;
for_each_rawref(append_ref, &cb);
if (merge_filter != NO_FILTER) {
@@ -523,7 +540,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached)
+ if (detached && match_patterns(pattern, "HEAD"))
show_detached(&ref_list);
for (i = 0; i < ref_list.index; i++) {
@@ -701,7 +718,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (list)
- return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
+ return print_ref_list(kinds, detached, verbose, abbrev,
+ with_commit, argv);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 61e095c..f2b294b 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -81,6 +81,16 @@ test_expect_success 'git branch -v shows branch summaries' '
'
cat >expect <<'EOF'
+two
+one
+EOF
+test_expect_success 'git branch -v pattern shows branch summaries' '
+ git branch -v branch* >tmp &&
+ awk "{print \$NF}" <tmp >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
* (no branch)
branch-one
branch-two
--
1.7.6.845.gc3c05
^ permalink raw reply related
* Re: [PATCHv2 2/5] git-tag: introduce long forms for the options
From: Michael J Gruber @ 2011-08-28 14:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vpqjsdrnp.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 26.08.2011 19:11:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Long forms are better to memoize, and more reliably uniform across
>> commands.
>
> I think people "memorize" and machines "memoize"; machines will do so just
> fine without long forms, but I think you are talking about helping people.
Yep.
> The part after ", and" lacks a verb, making it a non-sentence.
They are better to memorize, and they are more reliably uniform... Maybe
drop the comma?
>
>> Design notes:
>>
>> -u,--local-user is named following the analogous gnupg option.
>>
>> -l,--list is not an argument taking option but a mode switch.
>
> Ok.
>
> The remainder looks good. Thanks.
^ permalink raw reply
* Re: [PATCHv2 3/5] git-branch: introduce missing long forms for the options
From: Michael J Gruber @ 2011-08-28 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vk4a0drjj.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 26.08.2011 19:13:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> @@ -100,9 +103,11 @@ OPTIONS
>> Same as `--color=never`.
>>
>> -r::
>> +--remotes::
>> List or delete (if used with -d) the remote-tracking branches.
>
> I am not sure if this should be "--remoteS".
like "git log --remotes".
^ permalink raw reply
* Re: [PATCHv2 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-08-28 14:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vfwkodq5s.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 26.08.2011 19:43:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Currently, there is no way to invoke the list mode explicitly.
>
> ..., without giving -v to force verbose output.
>
>> Introduce a --list option which invokes the list mode. This will be
>> beneficial for invoking list mode with pattern matching, which otherwise
>> would be interpreted as branch creation.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>
>> @@ -20,7 +20,8 @@ DESCRIPTION
>>
>> With no arguments, existing branches are listed and the current branch will
>> be highlighted with an asterisk. Option `-r` causes the remote-tracking
>> -branches to be listed, and option `-a` shows both.
>> +branches to be listed, and option `-a` shows both. This list mode is also
>> +activated by the `--list` and `-v` options (see below).
>
> Very good to mention "and -v" here ;-)
>
>> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
>> index 6b7c118..61e095c 100755
>> --- a/t/t3203-branch-output.sh
>> +++ b/t/t3203-branch-output.sh
>> @@ -32,6 +32,20 @@ test_expect_success 'git branch shows local branches' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_success 'git branch --list shows local branches' '
>> + git branch --list >actual &&
>> + test_cmp expect actual
>> +'
>> +
>> +cat >expect <<'EOF'
>> + branch-one
>> + branch-two
>> +EOF
>> +test_expect_success 'git branch --list pattern shows matching local branches' '
>> + git branch --list branch* >actual &&
>> + test_cmp expect actual
>> +'
>> +
>
> Could we have a test to check the code you updated to sanity check the
> combination of options as well? I suspect the reason your initial round
> botched the "branch -v -m foo" without realizing may be because we do not
> cover the error checking.
Currently, "-m -d" is forbidden", but "-m -v" is "-m", same for "-d -v".
Do we want to keep it like that? Probably. I'll add the tests to 4/5.
Michael
^ permalink raw reply
* Re: git fast-import : How to change parent during import?
From: Vitor Antunes @ 2011-08-28 15:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20110308024427.GA21471@elie>
On Mon, 7 Mar 2011 20:44:27 -0600
Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Is it possible to change the parent of a commit during fast import?
> > I've tried using "reset" command and making a new commit pointing to a
> > new parent, but in both cases I get a "new tip ... does not contain
> > ..." error message.
>
> Have you tried "git fast-import --force"?
I know this is an old topic, but I'm looking into this again now. What I'm
now trying to do is to stop using "--force".
Is there a way to manually force fast-import to drop an old commit that the
frontend script decided it was no longer necessary?
Thanks,
--
Vitor Antunes
^ permalink raw reply
* git project patch workflow
From: Michael Haggerty @ 2011-08-28 15:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, cmn, Michael J Gruber
In-Reply-To: <7vty92adv0.fsf@alter.siamese.dyndns.org>
On 08/27/2011 08:30 PM, Junio C Hamano wrote:
> It sometimes gets frustrating to see a re-rolled submission that ignores
> the fix-ups to messages and patches I make locally before queued to 'pu'.
>
> It is easy for me to say that they should fetch 'pu' to see what is queued
> before resubmitting [...]
I usually try to do this, but it is awkward (or maybe I am doing it
wrong). If I run git fetch and notice that one of the upstream branches
was updated, then I still have to do a semi-manual step to see whether
any of the new commits are from a patch series that I submitted,
possibly which version of the patch series they are from, and whether
the patch or commit message was edited by you. Sometimes it is not even
clear which branch you will choose to apply a patch series to (maint vs
master). Contrast that, for example, with the ease of determining in
github whether a patch series has made it upstream.
In this particular case your email mentioned your code improvement, and
I obviously checked that your change made sense and squashed it onto my
own patch. But your email didn't mention your changes to the commit
message, so I did not think to look for any. Given that we, the
unwashed masses, have to transact all of our git patches through the
mailing list, I naively assumed that you would also mention your changes
on the mailing list.
I am amazed at the volume, quality, promptness, and patience of your
feedback (thanks!) and we should all bend over backwards to make your
life easier even at the expense of some extra work for ourselves. Junio
doesn't scale :-) So my suggestions below should only be considered if
they do not increase your bureaucratic work at the expense of your
technical work.
> [...] but I've been wondering if there is a better way to
> communicate back such differences, so that submitters can easily sanity
> check to see if my fix-ups are sensible, and to ensure that the re-rolled
> patches do not discard them by mistake before submitting.
>
> I could post what are queued in new topics back to the list as part of
> ack, but that would make the list too noisy to read.
I personally would find it helpful if you would mention any changes that
you made in an acknowledgment email. Ideally, the email would also
mention the branch name that you have chosen for the feature branch, to
make it easier to grep for the commit in your repo where it was merged
into pu and in your "What's cooking" messages. In your case it would be
enough to *mention* that you made a change because we can see the change
itself in your repo. I wouldn't worry too much about mailing list
traffic, because the acknowledgement would presumably be in the same
thread as the original patch series and thus easily ignorable by people
who are not interested in the subject.
Taking a step back, the real irony is that the git project hardly use
the distributed features of git *for the development of git itself*. I
was flabbergasted when I first realized that fact. Why is that? It
seems that the kind of fork/pull request/merge workflow that github
makes so easy would be more convenient (and if not, the dogfooding would
force us to *make* it more convenient). I personally found it vastly
easier to contribute my first patch to a github-based project than to git.
What would it take to make a git-centered workflow meet all of the
requirements that are satisfied by the mailing-list centered workflow
that is used currently?
ISTM that if there were a pull request procedure that automatically sent
PATCH emails to the mailing list for review (including the
non-log-message comments), then we would already be 95% of the way
there. The goal would be to make git the definitive store of
information, and the patch emails a side-product. That's the real
reason I started the thread "'git format-patch' should get more
information out of git": if all necessary information were in git then
there would be no need for all changes to be serialized through the
mailing list.
1. Author creates v1 of patch series
2. Author pushes changes to any publicly-visible git repo, including
non-log-message comments as notes
3. Author creates v1 tag and submits pull request, which results in
emails being sent to the mailing list as now (but with links to the git
repo and tag containing the patches)
4. Reviewers submit feedback via the mailing list. They can either work
directly with the patch emails or can fetch the patches directly from
the author. The feedback is handled informally as now, but might
include links to changed versions in their own public repo).
5. Author responds to feedback via the mailing list as now. Goto 1 if
needed, creating tags for v2, v3 etc. of the patch series.
6. When satisfied, maintainer pulls branch to shared repo. *The
author's commits retain their SHA1s.*
Pie in the sky?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] checkout: add --verbose, and restrict progress reporting (was: Re: [PATCH] checkout: be quiet if not on isatty())
From: Steffen Daode Nurpmeso @ 2011-08-28 17:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: martin f krafft, Tay Ray Chuan, git, sdaoden
In-Reply-To: <7vaaau9hso.fsf@alter.siamese.dyndns.org>
This commit adds support for the -v/--verbose pair of options,
and thus offers the possibility to be more specific in deciding
which purely informational feedback message is displayed or not.
Without any of --verbose and --quiet involved, the progress
reporting is now restricted to interactive sessions, i.e. only
shown if the output is send to a terminal.
Analyzed-by: Junio C Hamano <gitster@pobox.com>
Inspired-by: martin f krafft <madduck@madduck.net>
Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
Well i was stepping down from my hill, actually singing my
sunday's song (was it Elvis..), but i didn't dare to implement the
behaviour Martin suggested. But isn't he right?
This thing here was also tested a bit.
Documentation/git-checkout.txt | 13 +++++++++----
builtin/checkout.c | 12 +++++++++---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..77ad4f3 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,9 +8,9 @@ git-checkout - Checkout a branch or paths to the working tree
SYNOPSIS
--------
[verse]
-'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] [--detach] [<commit>]
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
+'git checkout' [-v] [-q] [-f] [-m] [<branch>]
+'git checkout' [-v] [-q] [-f] [-m] [--detach] [<commit>]
+'git checkout' [-v] [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
@@ -66,9 +66,14 @@ file can be discarded to re-create the original conflicted merge result.
OPTIONS
-------
+-v::
+--verbose::
+ Be verbose, force progress reporting.
+
-q::
--quiet::
- Quiet, suppress feedback messages.
+ Be quiet, suppress feedback messages and progress reporting.
+ Overrides "--verbose", if given.
-f::
--force::
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 4eaedff..7297843 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -27,6 +27,7 @@ static const char * const checkout_usage[] = {
};
struct checkout_opts {
+ int verbose;
int quiet;
int merge;
int force;
@@ -325,7 +326,7 @@ static int reset_tree(struct tree *tree, struct checkout_opts *o, int worktree)
opts.reset = 1;
opts.merge = 1;
opts.fn = oneway_merge;
- opts.verbose_update = !o->quiet;
+ opts.verbose_update = o->verbose;
opts.src_index = &the_index;
opts.dst_index = &the_index;
parse_tree(tree);
@@ -402,7 +403,7 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.update = 1;
topts.merge = 1;
topts.gently = opts->merge && old->commit;
- topts.verbose_update = !opts->quiet;
+ topts.verbose_update = opts->verbose;
topts.fn = twoway_merge;
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
@@ -927,7 +928,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
int patch_mode = 0;
int dwim_new_local_branch = 1;
struct option options[] = {
- OPT__QUIET(&opts.quiet, "suppress progress reporting"),
+ OPT__VERBOSE(&opts.verbose, "force progress reporting"),
+ OPT__QUIET(&opts.quiet, "suppress feedback reporting"),
OPT_STRING('b', NULL, &opts.new_branch, "branch",
"create and checkout a new branch"),
OPT_STRING('B', NULL, &opts.new_branch_force, "branch",
@@ -958,6 +960,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
gitmodules_config();
git_config(git_checkout_config, &opts);
+ if (opts.quiet)
+ opts.verbose = 0;
+ else if (!opts.verbose)
+ opts.verbose = isatty(2);
opts.track = BRANCH_TRACK_UNSPECIFIED;
argc = parse_options(argc, argv, prefix, options, checkout_usage,
--
1.7.7.rc0.dirty
^ permalink raw reply related
* Re: branch practice in my project
From: PJ Weisberg @ 2011-08-28 19:42 UTC (permalink / raw)
To: Lynn Lin; +Cc: git
In-Reply-To: <CAPgpnMQmLUcxfNBDO53=s1SfigJtq2zk4H+npZeX0B_Vf0FAuA@mail.gmail.com>
On Sun, Aug 28, 2011 at 2:23 AM, Lynn Lin <lynn.xin.lin@gmail.com> wrote:
> how to get the data back to master branch? I suggest we can merge
> release branch back, and others are afraid that merge conflict will be
> a big deal for us so they suggest we can double commit into master and
> release branch
I don't see how anyone would think "double commits" would be *less*
work than resolving merge conflicts. (Espically if most changes don't
even conflict.)
The only reason I can think of for not merging release back into
master is if there are some changes on release that you don't want in
master.
-PJ
^ permalink raw reply
* Re: obstack fails to compile on OS X 10.7
From: Fredrik Kuivinen @ 2011-08-28 20:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Brian Gernhardt, Git List
In-Reply-To: <20110827101418.GA8074@gmail.com>
On Sat, Aug 27, 2011 at 03:14:43AM -0700, David Aguilar wrote:
> On Sat, Aug 27, 2011 at 02:21:40AM -0400, Brian Gernhardt wrote:
> > Some of the errors look like things I could track down, but some just confuse me. If anyone else could take a look into this, it would be much appreciated.
> >
> > ~~ Brian G.
> >
> > gcc -o compat/obstack.o -c -MF compat/.depend/obstack.o.d -MMD -MP -Wall -Wdeclaration-after-statement -Werror -Wno-deprecated-declarations -I. -DUSE_ST_TIMESPEC -DSHA1_HEADER='"block-sha1/sha1.h"' -DNO_MEMMEM compat/obstack.c
> > In file included from compat/obstack.c:30:
> > compat/obstack.h:190: error: __block attribute can be specified on variables only
> > compat/obstack.c:70: error: expected specifier-qualifier-list before ‘uintmax_t’
> > compat/obstack.c:111:24: error: exitfail.h: No such file or directory
> > cc1: warnings being treated as errors
> > compat/obstack.c: In function ‘print_and_abort’:
> > compat/obstack.c:436: warning: implicit declaration of function ‘gettext’
> > compat/obstack.c:436: warning: incompatible implicit declaration of built-in function ‘gettext’
> > compat/obstack.c:438: error: ‘exit_failure’ undeclared (first use in this function)
> > compat/obstack.c:438: error: (Each undeclared identifier is reported only once
> > compat/obstack.c:438: error: for each function it appears in.)
> > compat/obstack.c:439: warning: ‘noreturn’ function does return
> > make: *** [compat/obstack.o] Error 1
> >
> > $ gcc --version
> > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
>
> I ran into the same thing.
>
> This fixes it for me, but we might want to rearrange the
> #includes a bit. I think this needs more work.. including
> compat/obstack.h from kwset.c seems wrong.
> Should we just include obstack.h in git-compat-util instead?
>
> I suspect that more exotic platforms may have problems
> with obstack.h as well. This probably needs some testing
> on SunOS, AIX, IRIX, etc.
How about doing something a bit simpler instead and changing obstack.c
to not make use of exit.h and exitfail.h? Then we don't have to update
Makefile for all platforms needing NEEDS_OBSTACK and NEEDS_EXITFAIL.
I don't understand why the ELIDE_CODE check is not sufficient. Care to
explain?
Something like this (tested on Linux and SunOS 5.10):
-- 8< --
Subject: [PATCH RFC] obstack: Fix portability issues
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, SunOS 5.10, and possibly
others do not have exit.h and exitfail.h. Remove the use of these in
obstack.c.
The __block variable was renamed to block to avoid a gcc error:
compat/obstack.h:190: error: __block attribute can be specified on variables only
Initial-patch-by: David Aguilar <davvid@gmail.com>
Reported-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
---
compat/obstack.c | 35 ++++-------------------------------
compat/obstack.h | 5 +----
kwset.c | 2 +-
3 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/compat/obstack.c b/compat/obstack.c
index 75440d9..a89ab5b 100644
--- a/compat/obstack.c
+++ b/compat/obstack.c
@@ -18,17 +18,9 @@
Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
-
-#ifdef HAVE_CONFIG_H
-# include <config.h>
-#endif
-
-#ifdef _LIBC
-# include <obstack.h>
-# include <shlib-compat.h>
-#else
-# include "obstack.h"
-#endif
+#include "git-compat-util.h"
+#include <gettext.h>
+#include "obstack.h"
/* NOTE BEFORE MODIFYING THIS FILE: This version number must be
incremented whenever callers compiled using an old obstack.h can no
@@ -103,15 +95,6 @@ enum
static void print_and_abort (void);
void (*obstack_alloc_failed_handler) (void) = print_and_abort;
-/* Exit value used when `print_and_abort' is used. */
-# include <stdlib.h>
-# ifdef _LIBC
-int obstack_exit_failure = EXIT_FAILURE;
-# else
-# include "exitfail.h"
-# define obstack_exit_failure exit_failure
-# endif
-
# ifdef _LIBC
# if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_3_4)
/* A looong time ago (before 1994, anyway; we're not sure) this global variable
@@ -400,16 +383,6 @@ _obstack_memory_used (struct obstack *h)
return nbytes;
}
\f
-/* Define the error handler. */
-# ifdef _LIBC
-# include <libintl.h>
-# else
-# include "gettext.h"
-# endif
-# ifndef _
-# define _(msgid) gettext (msgid)
-# endif
-
# ifdef _LIBC
# include <libio/iolibio.h>
# endif
@@ -435,7 +408,7 @@ print_and_abort (void)
# else
fprintf (stderr, "%s\n", _("memory exhausted"));
# endif
- exit (obstack_exit_failure);
+ exit (1);
}
#endif /* !ELIDE_CODE */
diff --git a/compat/obstack.h b/compat/obstack.h
index 449070e..c3b681f 100644
--- a/compat/obstack.h
+++ b/compat/obstack.h
@@ -187,7 +187,7 @@ extern int _obstack_begin_1 (struct obstack *, int, int,
void (*) (void *, void *), void *);
extern int _obstack_memory_used (struct obstack *);
-void obstack_free (struct obstack *__obstack, void *__block);
+void obstack_free (struct obstack *obstack, void *block);
\f
/* Error handler called when `obstack_chunk_alloc' failed to allocate
@@ -195,9 +195,6 @@ void obstack_free (struct obstack *__obstack, void *__block);
should either abort gracefully or use longjump - but shouldn't
return. The default action is to print a message and abort. */
extern void (*obstack_alloc_failed_handler) (void);
-
-/* Exit value used when `print_and_abort' is used. */
-extern int obstack_exit_failure;
\f
/* Pointer to beginning of object being allocated or to be allocated next.
Note that this might not be the final address of the object
diff --git a/kwset.c b/kwset.c
index fd4515a..956ae72 100644
--- a/kwset.c
+++ b/kwset.c
@@ -37,7 +37,7 @@
#include "cache.h"
#include "kwset.h"
-#include "obstack.h"
+#include "compat/obstack.h"
#define NCHAR (UCHAR_MAX + 1)
#define obstack_chunk_alloc xmalloc
--
1.7.6.557.gcee4
^ permalink raw reply related
* [PATCH v4 0/4] git-p4: Improve branch support
From: Vitor Antunes @ 2011-08-28 21:58 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
Include test case patches from Pete Wyckoff.
Vitor Antunes (4):
git-p4: Correct branch base depot path detection
git-p4: Allow filtering Perforce branches by user
git-p4: Allow branch definition with git config
git-p4: Add simple test case for branch import
contrib/fast-import/git-p4 | 40 +++++++++++++++++++++++--
contrib/fast-import/git-p4.txt | 13 ++++++++
t/t9800-git-p4.sh | 61 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 110 insertions(+), 4 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH v4 1/4] git-p4: Correct branch base depot path detection
From: Vitor Antunes @ 2011-08-28 21:58 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314568710-6472-1-git-send-email-vitor.hda@gmail.com>
When branch detection is enabled each branch is named in git after their
relative depot path in Perforce. To do this the depot paths are compared against
each other to find their common base path. The current algorithm makes this
comparison on a character by character basis.
Assuming we have the following branches:
//depot/branches/featureA
//depot/branches/featureB
Then the base depot path would be //depot/branches/feature, which is an invalid
depot path.
The current patch fixes this by splitting the path into a list and comparing the
list entries, making it choose correctly //depot/branches as the base path.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 0db3e72..72a5b6c 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1829,12 +1829,14 @@ class P4Sync(Command, P4UserMap):
else:
paths = []
for (prev, cur) in zip(self.previousDepotPaths, depotPaths):
- for i in range(0, min(len(cur), len(prev))):
- if cur[i] <> prev[i]:
+ prev_list = prev.split("/")
+ cur_list = cur.split("/")
+ for i in range(0, min(len(cur_list), len(prev_list))):
+ if cur_list[i] <> prev_list[i]:
i = i - 1
break
- paths.append (cur[:i + 1])
+ paths.append ("/".join(cur_list[:i + 1]))
self.previousDepotPaths = paths
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 2/4] git-p4: Allow filtering Perforce branches by user
From: Vitor Antunes @ 2011-08-28 21:58 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314568710-6472-1-git-send-email-vitor.hda@gmail.com>
All branches in the Perforce server are downloaded to allow branch detection. If
you have a centralized server on a remote location and there is a big number of
branches this operation can take some time.
This patch adds the configuration option git-p4.branchUser to allow filtering
the branch list by user. Although this limits the branch maintenance in Perforce
to be done by a single user, it might be an advantage when the number of
branches being used in a specific depot is very small when compared with the
branches available in the server.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 8 +++++++-
contrib/fast-import/git-p4.txt | 6 ++++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 72a5b6c..6314c20 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1455,7 +1455,13 @@ class P4Sync(Command, P4UserMap):
def getBranchMapping(self):
lostAndFoundBranches = set()
- for info in p4CmdList("branches"):
+ user = gitConfig("git-p4.branchUser")
+ if len(user) > 0:
+ command = "branches -u %s" % user
+ else:
+ command = "branches"
+
+ for info in p4CmdList(command):
details = p4Cmd("branch -o %s" % info["branch"])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 2ffbccc..97b66b9 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -257,6 +257,12 @@ Perforce server. Will enable --find-copies-harder git argument.
git config [--global] git-p4.detectCopies true
+git-p4.branchUser
+
+Only use branch specifications defined by the selected username.
+
+ git config [--global] git-p4.branchUser username
+
Implementation Details...
=========================
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 3/4] git-p4: Allow branch definition with git config
From: Vitor Antunes @ 2011-08-28 21:58 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314568710-6472-1-git-send-email-vitor.hda@gmail.com>
Perforce does not strictly require the usage of branch specifications to create
branches. In these cases the branch detection code of git-p4 will not be able to
import them.
This patch adds support for git-p4.branchList configuration option, allowing
branches to be defined in git config.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 24 ++++++++++++++++++++++++
contrib/fast-import/git-p4.txt | 7 +++++++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6314c20..2f7b270 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -342,6 +342,11 @@ def gitConfig(key, args = None): # set args to "--bool", for instance
_gitConfig[key] = read_pipe(cmd, ignore_error=True).strip()
return _gitConfig[key]
+def gitConfigList(key):
+ if not _gitConfig.has_key(key):
+ _gitConfig[key] = read_pipe("git config --get-all %s" % key, ignore_error=True).strip().split(os.linesep)
+ return _gitConfig[key]
+
def p4BranchesInGit(branchesAreInRemotes = True):
branches = {}
@@ -1490,6 +1495,25 @@ class P4Sync(Command, P4UserMap):
if source not in self.knownBranches:
lostAndFoundBranches.add(source)
+ # Perforce does not strictly require branches to be defined, so we also
+ # check git config for a branch list.
+ #
+ # Example of branch definition in git config file:
+ # [git-p4]
+ # branchList=main:branchA
+ # branchList=main:branchB
+ # branchList=branchA:branchC
+ configBranches = gitConfigList("git-p4.branchList")
+ for branch in configBranches:
+ if branch:
+ (source, destination) = branch.split(":")
+ self.knownBranches[destination] = source
+
+ lostAndFoundBranches.discard(destination)
+
+ if source not in self.knownBranches:
+ lostAndFoundBranches.add(source)
+
for branch in lostAndFoundBranches:
self.knownBranches[branch] = branch
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 97b66b9..52003ae 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -263,6 +263,13 @@ Only use branch specifications defined by the selected username.
git config [--global] git-p4.branchUser username
+git-p4.branchList
+
+List of branches to be imported when branch detection is enabled.
+
+ git config [--global] git-p4.branchList main:branchA
+ git config [--global] --add git-p4.branchList main:branchB
+
Implementation Details...
=========================
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 4/4] git-p4: Add simple test case for branch import
From: Vitor Antunes @ 2011-08-28 21:58 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314568710-6472-1-git-send-email-vitor.hda@gmail.com>
Create a basic branch structure in P4 and clone it with git-p4.
Also, make an update on P4 side and check if git-p4 imports it correctly.
The branch structure is created in such a way that git-p4 will fail to import
updates if patch "git-p4: Correct branch base depot path detection" is not
applied.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4.sh | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index 9d4d4bf..01ba041 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -405,6 +405,67 @@ test_expect_success 'detect copies' '
p4 filelog //depot/file13 | grep -q "branch from //depot/file"
'
+# Create a simple branch structure in P4 depot to check if it is correctly
+# cloned.
+test_expect_success 'add simple p4 branches' '
+ cd "$cli" &&
+ mkdir branch1 &&
+ cd branch1 &&
+ echo file1 >file1 &&
+ echo file2 >file2 &&
+ p4 add file1 file2 &&
+ p4 submit -d "branch1" &&
+ p4 integrate //depot/branch1/... //depot/branch2/... &&
+ p4 submit -d "branch2" &&
+ echo file3 >file3 &&
+ p4 add file3 &&
+ p4 submit -d "add file3 in branch1" &&
+ p4 open file2 &&
+ echo update >>file2 &&
+ p4 submit -d "update file2 in branch1" &&
+ p4 integrate //depot/branch1/... //depot/branch3/... &&
+ p4 submit -d "branch3" &&
+ cd "$TRASH_DIRECTORY"
+'
+
+# Configure branches through git-config and clone them.
+# All files are tested to make sure branches were cloned correctly.
+# Finally, make an update to branch1 on P4 side to check if it is imported
+# correctly by git-p4.
+test_expect_success 'git-p4 clone simple branches' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ cd "$git" &&
+ git config git-p4.branchList branch1:branch2 &&
+ git config --add git-p4.branchList branch1:branch3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch1 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch2 &&
+ test -f file1 &&
+ test -f file2 &&
+ test ! -f file3 &&
+ ! grep -q update file2 &&
+ git reset --hard p4/depot/branch3 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ cd "$cli" &&
+ cd branch1 &&
+ p4 edit file2 &&
+ echo file2_ >>file2 &&
+ p4 submit -d "update file2 in branch1" &&
+ cd "$git" &&
+ git reset --hard p4/depot/branch1 &&
+ "$GITP4" rebase &&
+ grep -q file2_ file2
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.5.4
^ permalink raw reply related
* Re: git fast-import : How to change parent during import?
From: Jonathan Nieder @ 2011-08-28 23:39 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, David Barr, Sverre Rabbelier
In-Reply-To: <20110828162325.5f479ef7@fenix.utopia.dhis.org>
Vitor Antunes wrote:
> Is there a way to manually force fast-import to drop an old commit that the
> frontend script decided it was no longer necessary?
Sure --- patch fast-import (I'd be happy to review such a patch). :)
^ permalink raw reply
* Re: git fast-import : How to change parent during import?
From: Sverre Rabbelier @ 2011-08-29 1:13 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Vitor Antunes, git, David Barr
In-Reply-To: <20110828233931.GD29351@elie.gateway.2wire.net>
Heya,
On Mon, Aug 29, 2011 at 01:39, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Vitor Antunes wrote:
>> Is there a way to manually force fast-import to drop an old commit that the
>> frontend script decided it was no longer necessary?
>
> Sure --- patch fast-import (I'd be happy to review such a patch). :)
That's actually a feature that we need for remote-helpers as well (to
be able to drop refs). Would be nice to have a 'drop ref' command in
fast export :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-config: case insensitivity for subsections
From: Alex Vandiver @ 2011-08-29 0:50 UTC (permalink / raw)
To: milki; +Cc: Jeff King, git
In-Reply-To: <20110825215757.GA94231@hal.rescomp.berkeley.edu>
On Thu, 2011-08-25 at 14:57 -0700, milki wrote:
> This was simply surprising as I was trying to figure out what exactly
> case sensitivity meant and how it affected sections. This definitely
> clears this up for me. I'm actually working on a config parser because I
> don't think I've seen a complete implementation besides git-config in a
> different language.
For reference, https://github.com/bestpractical/config-gitlike/ is a
complete parser for git config files written in perl, which passes git's
config test suite (among other tests). Which is not terribly
surprising, since its parsing algorithm is strongly derived from
config.c's.
- Alex
^ permalink raw reply
* [ANNOUNCE] tig-0.18
From: Jonas Fonseca @ 2011-08-29 3:10 UTC (permalink / raw)
To: git
Hello,
This release brings several diff and blame view improvements, as well as
a handful of bug fixes. It also marks that the tig repository now sports
1001 commits. The full list of noteable changes are listed below. Enjoy!
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Incompatibilities:
- Remove support for the deprecated TIG_{MAIN,DIFF,LOG,TREE,BLOB}_CMD
environment variables.
Improvements:
- Pressing enter on diff stat file lines will jump to file's diff.
- Naïvely color blame IDs to distinguish lines.
- Document palette color options used for revision graph and blame IDs.
- Add support for blaming diff lines.
- Add diff-context option and bindings to increase the diff context in
the diff and stage view.
- (GH-6) Make blame configurable via extra options passed from the command
line and blame-options setting from ~/.tigrc. For example:
set blame-options = -C -C -C
Bug fixes:
- Expand browsing state variables for prompt. (LP #694780, Debian #635546)
- Fix segfault when sorting the branch view by author.
- Expand %(directory) to . for the root directory. (GH-3)
- Accept 'utf-8' for the line-graphics option as indicated in the docs.
- Use erasechar() to check for the correct backspace character.
Change summary
--------------
The diffstat and log summary for changes made in this release.
Makefile | 7 +-
NEWS | 31 +-
VERSION | 2 +-
contrib/aspell.dict | 9 +-
io.c | 7 +
manual.txt | 2 +
tig.1.txt | 7 +-
tig.c | 1614 +++++++++++++++++++++++++++----------------
tig.h | 27 +-
tigrc.5.txt | 76 ++-
10 files changed, 1124 insertions(+), 658 deletions(-)
58 Jonas Fonseca
1 Ozan Çağlayan
1 Pierre Habouzit
2 Sebastian Harl
3 Sven Wegener
1 Tony Miller
1 Von Fugal
--
Jonas Fonseca
^ permalink raw reply
* Re: [tig] [PATCH] Display line numbers in main view
From: Jonas Fonseca @ 2011-08-29 3:16 UTC (permalink / raw)
To: git
In-Reply-To: <20110805010616.GA16045@146653177.ece.utexas.edu>
Applied, thanks!
On Thu, Aug 4, 2011 at 21:06, Kumar Appaiah <a.kumar@alumni.iitm.ac.in> wrote:
> When line numbers are enabled, this enables the display of line
> numbers in the main view as well. This is useful for cases where one
> would want to quickly navigate to a particular commit by the ordering
> displayed in tig, using the `:<num>' approach.
> ---
> tig.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/tig.c b/tig.c
> index ed92400..92091ab 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -6194,6 +6194,9 @@ main_draw(struct view *view, struct line *line, unsigned int lineno)
> if (!commit->author)
> return FALSE;
>
> + if (opt_line_number && draw_lineno(view, lineno))
> + return TRUE;
> +
> if (draw_date(view, &commit->time))
> return TRUE;
>
> --
> 1.7.2.5
>
--
Jonas Fonseca
^ permalink raw reply
* Re: obstack fails to compile on OS X 10.7
From: David Aguilar @ 2011-08-29 3:18 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Brian Gernhardt, Git List
In-Reply-To: <20110828200846.GA10754@fredrik-Q430-Q530>
On Sun, Aug 28, 2011 at 10:08:46PM +0200, Fredrik Kuivinen wrote:
> On Sat, Aug 27, 2011 at 03:14:43AM -0700, David Aguilar wrote:
> > On Sat, Aug 27, 2011 at 02:21:40AM -0400, Brian Gernhardt wrote:
> > > Some of the errors look like things I could track down, but some just confuse me. If anyone else could take a look into this, it would be much appreciated.
> > >
> > > ~~ Brian G.
> > >
> > > gcc -o compat/obstack.o -c -MF compat/.depend/obstack.o.d -MMD -MP -Wall -Wdeclaration-after-statement -Werror -Wno-deprecated-declarations -I. -DUSE_ST_TIMESPEC -DSHA1_HEADER='"block-sha1/sha1.h"' -DNO_MEMMEM compat/obstack.c
> > > In file included from compat/obstack.c:30:
> > > compat/obstack.h:190: error: __block attribute can be specified on variables only
> > > compat/obstack.c:70: error: expected specifier-qualifier-list before ‘uintmax_t’
> > > compat/obstack.c:111:24: error: exitfail.h: No such file or directory
> > > cc1: warnings being treated as errors
> > > compat/obstack.c: In function ‘print_and_abort’:
> > > compat/obstack.c:436: warning: implicit declaration of function ‘gettext’
> > > compat/obstack.c:436: warning: incompatible implicit declaration of built-in function ‘gettext’
> > > compat/obstack.c:438: error: ‘exit_failure’ undeclared (first use in this function)
> > > compat/obstack.c:438: error: (Each undeclared identifier is reported only once
> > > compat/obstack.c:438: error: for each function it appears in.)
> > > compat/obstack.c:439: warning: ‘noreturn’ function does return
> > > make: *** [compat/obstack.o] Error 1
> > >
> > > $ gcc --version
> > > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
> >
> > I ran into the same thing.
> >
> > This fixes it for me, but we might want to rearrange the
> > #includes a bit. I think this needs more work.. including
> > compat/obstack.h from kwset.c seems wrong.
> > Should we just include obstack.h in git-compat-util instead?
> >
> > I suspect that more exotic platforms may have problems
> > with obstack.h as well. This probably needs some testing
> > on SunOS, AIX, IRIX, etc.
>
>
> How about doing something a bit simpler instead and changing obstack.c
> to not make use of exit.h and exitfail.h? Then we don't have to update
> Makefile for all platforms needing NEEDS_OBSTACK and NEEDS_EXITFAIL.
I like this much better. Less code is better code.
> I don't understand why the ELIDE_CODE check is not sufficient. Care to
> explain?
I can't say I know. The intention of the check is to avoid
pulling in that section of code when it is already built-in to
the C library. Maybe that check doesn't quite mean the same
thing when the file is used alone outside of its original
context?
> -void obstack_free (struct obstack *__obstack, void *__block);
> +void obstack_free (struct obstack *obstack, void *block);
Tiny nit: I know it's just a declaration but would it be
advisable to drop the variable names altogether here?
Having a pointer and a structure with the same "obstack"
name could be confusing.
This looks good otherwise. I was a bit iffy about my patch
when I had to bring in the extra headers.
Doing without them is much better.
I tried your patch on top of my recent
"Improve compiler header dependency check" and it worked fine.
So...
Tested-by: David Aguilar <davvid@gmail.com>
--
David
^ 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