* [PATCHv2 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.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
* [PATCHv2 4/5] branch: introduce --list option
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.git.git@drmicha.warpmail.net>
Currently, there is no way to invoke the list mode explicitly.
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>
---
Documentation/git-branch.txt | 9 +++++++--
builtin/branch.c | 12 +++++++++---
t/t3203-branch-output.sh | 14 ++++++++++++++
3 files changed, 30 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/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
* [PATCHv2 3/5] git-branch: introduce missing long forms for the options
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.git.git@drmicha.warpmail.net>
Long forms are better to memoize, and more reliably uniform across
commands.
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
* [PATCHv2 2/5] git-tag: introduce long forms for the options
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.git.git@drmicha.warpmail.net>
Long forms are better to memoize, 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
* [PATCHv2 1/5] t6040: test branch -vv
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.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
* [PATCHv2 0/5] patterns for branch list
From: Michael J Gruber @ 2011-08-26 14:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <20110825175301.GC519@sigill.intra.peff.net>
In this iteration, I have incorporated Jeffs and Junios suggestions and Junios
patches. Thanks!
So:
git branch --list is introduced before the patterns (though it is not needed at
that point)
Multiple patterns are allowed.
The -v/vv/vvv changing patches are gone.
Also, the independent test for "-vv" is put first (which certainly can go in
now). Next come long option names for "git tag" and "git branch", then the
pattern related patches.
I have also rebased on next with nk/branch-v-abbrev (which conflicts, though
"trivially").
"-l -> -g" migration for "git branch" and such are issues for a later series.
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/t3203-branch-output.sh | 24 +++++++++++++++++++++
t/t6040-tracking-info.sh | 16 ++++++++++++++
6 files changed, 108 insertions(+), 22 deletions(-)
--
1.7.6.845.gc3c05
^ permalink raw reply
* Re: [PATCH 2/2] revision: do not include sibling history in --ancestry-path output
From: Brad King @ 2011-08-26 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heiko Voigt
In-Reply-To: <7v7h61gf5i.fsf_-_@alter.siamese.dyndns.org>
On 8/25/2011 9:00 PM, Junio C Hamano wrote:
> If the commit specified as the bottom of the commit range has a direct
> parent that has another child commit that contributed to the resulting
> history, "rev-list --ancestry-path" was confused and listed that side
> history as well.
>
> D---E
> / \
> ---X---A---B---C
>
> In this history, "rev-list --ancestry-path A..C" should list among what
> the corresponding command without --ancestry-path option would produce,
> namely, D, E, B and C, but limiting the result to those that are
> descendant of A (i.e. B and C). Due to the command line parser subtlety
> corrected by the previous commit, it also listed those that are descendant
> of X as well.
>
> Signed-off-by: Junio C Hamano<gitster@pobox.com>
> ---
> * And this should fix the breakage you demonstrated.
Yes it does, thanks. It also makes the submodule search during recursive
merge work as I expect after the fix I tried (only run the search if
o->call_depth == 0). I'll submit that patch separately when I find time.
Tested-by: Brad King <brad.king@kitware.com>
Thanks,
-Brad
^ permalink raw reply
* Files that cannot be added to the index
From: seanh @ 2011-08-26 12:26 UTC (permalink / raw)
To: git
Can anyone guess what's going on when I have a modified file that
shows up in `git status`, but the file cannot be added to the index
(or committed)? `git add FILE` does nothing, the file still shows as
modified but not added in `git status`.
I have two different repos that have each developed this problem with
two different files. I don't know how it happened. The problem occurs
wherever the repos are cloned. Even if I delete the local copy (where
I'm seeing the problem) and clone the repo again from elsewhere,
problem persists.
^ permalink raw reply
* Re: [RFC PATCH] diff: use $COLUMNS if available for default stat_width
From: Mikael Magnusson @ 2011-08-26 11:20 UTC (permalink / raw)
To: Kris Shannon; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1314337647-29270-1-git-send-email-kris@shannon.id.au>
On 26 August 2011 07:47, Kris Shannon <kris@shannon.id.au> wrote:
> If the COLUMNS environment variable is set use it's value
> as the default stat_width.
>
> Also set the stat_name_width default to 2/3 of the full width.
>
> This does change the default from 50 to 53 when using the
> original 80 column stat_width fallback.
You probably only want to do this when stdout is a terminal.
--
Mikael Magnusson
^ permalink raw reply
* Re: Re* git clean --exclude broken?
From: Thomas Rast @ 2011-08-26 10:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd Rinaldo
In-Reply-To: <7vpqjtl4yi.fsf_-_@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The documentation and the implementation of "git clean" is quite confused.
> > ...
>
> So here is a patch to fix the confusion.
>
> It does not add a new "--except=C" I alluded to, but at least it should
> be the right first step to make the document clearly describe what the
> existing option does.
>
> -- >8 --
> Subject: [PATCH] Documentation: clarify "git clean -e <pattern>"
It's not exclusively a doc patch, is it?
> + if (ignored && exclude_list.nr)
> + die(_("adding exclude with -e and ignoring it with -x is crazy"));
Please also add something like the following patch, so that 'git clean -h'
does not confuse the user either.
diff --git i/builtin/clean.c w/builtin/clean.c
index 75697f7..33a3df9 100644
--- i/builtin/clean.c
+++ w/builtin/clean.c
@@ -54,7 +54,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('d', NULL, &remove_directories,
"remove whole directories"),
{ OPTION_CALLBACK, 'e', "exclude", &exclude_list, "pattern",
- "exclude <pattern>", PARSE_OPT_NONEG, exclude_cb },
+ "add <pattern> to ignore rules", PARSE_OPT_NONEG, exclude_cb },
OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
OPT_BOOLEAN('X', NULL, &ignored_only,
"remove only ignored files"),
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Thomas Rast @ 2011-08-26 9:44 UTC (permalink / raw)
To: Jeff King; +Cc: Boaz Harrosh, git
In-Reply-To: <20110825204047.GA9948@sigill.intra.peff.net>
Jeff King wrote:
> We already provide sane hunk-header patterns for specific
> languages. However, the user has to manually map common
> extensions to use them. It's not that hard to do, but it's
> an extra step that the user might not even know is an
> option. Let's be nice and do it automatically.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I tried to think of negative side effects.
>
> The userdiff drivers we have are pretty conservative; they just specify
> hunk headers.
And word-diff regexes.
In my book this is a plus for your patch, but I'm just saying. It
will trigger the slightly slower mode of word-diffing that splits at
far more places than the default.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Marat Radchenko @ 2011-08-26 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vy5yhi4eq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> An interesting comparison may be to run this once:
>
> $ git show branch:file >fileI
>
> and then compare between these two:
>
> $ diff -u fileI file
> $ git diff --no-index fileI file
In all times below, "file" is the same file i used in original report.
$ time diff -u fileI file > /dev/null
real 0m0.002s
user 0m0.000s
sys 0m0.000s
$ time git diff --no-index fileI file > /dev/null
real 0m0.331s
user 0m0.270s
sys 0m0.060s
Same with "pu" branch (has 27af01d):
$ time ~/git/git-diff --no-index fileI file > /dev/null
real 0m0.307s
user 0m0.220s
sys 0m0.080s
>
> If the latter is slower than the former in the same way as the original
> experiment, that would mean that the tree traversal time does not have
> anything to do with it (iow, your "The way 'git diff' is now, it does
> that" is not just incorrect---we don't read the full tree to begin
> with---but irrelevant).
I still suspect tree traversal. Original report with "pu" branch is still 30s.
^ permalink raw reply
* Re: git diff annoyance / feature request
From: Miles Bader @ 2011-08-26 9:08 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Junio C Hamano, git discussion list
In-Reply-To: <4E56C58E.4080905@panasas.com>
Boaz Harrosh <bharrosh@panasas.com> writes:
>> Personally, I would have to say that the source wouldn't be using too many
>> labels with the same name for this behaviour to be problematic, especially
>> if it is not freaking BASIC ;-), so...
>
> The Linux Kernel is full of "goto out" or "goto err" its a common error handling
> practice. I actually like it because it taps onto a known pattern.
>
> Now the patch tell me @@@ lable out: !! that's not very useful I would say
>
> Thanks I'm sure I can shape it up the way I like it
Incidentally, if these annoyances were inherited from GNU diff, it would
be good to send a bug report there too,... I doubt anybody likes the
behavior any better with diff!
[I know I've been annoyed by such things before...]
Thanks,
-Miles
--
Innards, n. pl. The stomach, heart, soul, and other bowels.
^ permalink raw reply
* Re: [PATCH 0/5] RFC: patterns for branch list
From: Michael J Gruber @ 2011-08-26 8:30 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Michael Schubert
In-Reply-To: <20110825175301.GC519@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 25.08.2011 19:53:
> On Thu, Aug 25, 2011 at 10:30:16AM +0200, Michael J Gruber wrote:
>
>> This mini series is about introducing patterns to the list mode of
>> 'git branch' much like the pattern for 'git tag -l'. There are several
>> related things which are to be considered for the ui design:
>
>> [log vs tag vs branch]
>
> I agree that the ideal UI change would be to move git-branch's "-l" to
> "-g", and make "-l|--list" work the same as it does for git-tag.
>
> Even though branch is generally considered a porcelain, I worry a little
> about making that change. A script that wants to create a branch has no
> real choice other than to use "git branch" (OK, they can use
> "update-ref" themselves, but I seriously doubt that most scripts do so).
> However, I kind of doubt anyone actually uses "-l"; it is mostly
> pointless in the default config, so maybe it is safe.
>
> Searching google code for "git.branch.*-l" turns up only one hit, and it
> is somebody who apparently thought that "-l" meant "list".
;)
Thanks for doing the search.
>> Analogous to "git tag", "branch" has several modes, one of which is list mode.
>> It is currently activated (and possibly modified) by "-v" and "-vv", and when
>> there are no arguments. So, at the least,
>>
>> git branch -v[v] <pattern>
>>
>> should match just like "git tag -l <pattern>" does. And that is what the first
>> patch in my series does.
>
> The order of your patches seems backwards to me. You add
> pattern-matching for "-v", but there is no way to get pattern-matching
> for the non-verbose case. Shouldn't "--list" come first?
>
> Maybe I am just nitpicking, as I think the end result after the series
> is the same. I just found the first patch very confusing.
It's an RFC series to revive the discussion about what to aim for.
Agreement about "--list" seems to be growing, so a natural first patch
would introduce that.
>> "git tag" should probably learn the same long option and others. And why not
>> verify tags given by a pattern?
>
> Yeah, having them both do --list makes sense. Whether it is appropriate
> to glob for other operations, I don't know. I think you'd have to
> look at each operation individually.
>
>> Both "tag" and "branch" could activate list mode automatically on an invalid
>> tag name rather than dieing:
>>
>> git tag v1.7.6\*
>> Warning: tag 'v1.7.6*' not found.
>> v1.7.6
>> v1.7.6-rc0
>> v1.7.6-rc1
>> v1.7.6-rc2
>> v1.7.6-rc3
>> v1.7.6.1
>
> That just seems confusing to me. What is the exit status? Shouldn't the
> warning be "error: tag 'v1.7.6*' is not a valid tag name"?
Sure, and sorry, copied the wrong one. I'd just like to have the simple
way to say "git branch peff/\*" at least as long as we don't have "-l"
for "--list".
>> -v[v] sanity
>> ============
>>
>> '-v' and '-vv' both take considerable time (because they need to walk).
>> It makes more sense to have '-v' display cheap output (upstream name)
>> and '-vv' add expensive output (ahead/behind info). '-vvv' could add super
>> expensive info (ahead/equivalent/behind a la cherry-mark).
>
> I think the original rationale was not so much "how much time does it
> take", but rather "how much space do you want each line to take on your
> terminal". For many people, the upstream name in "-vv" is just
> cluttering noise.
According to my experience, the ahead/behind computations take so much
time (in a git.git clone with my devel branches) that they render all
"-v" versions unusable, unless I use a restrictive pattern.
On the other hand, I have branches based on all of origin/{master,next}
and others, so having the upstream name is valuable.
Seems that I'm an outlier, though.
> Tag and branch listing are really just specialized versions of
> for-each-ref. I wonder if it makes sense to do:
>
> 1. Teach for-each-ref formats replacement tokens for ahead/behind
> counts.
>
> 2. Let the user specify a for-each-ref format for tag and branch
> listing output. Then the various levels of "-v" just become some
> special format strings, and the user is free to ask for whatever
> they want (or even have "branch.defaultListFormat" to get it
> without typing over and over).
for-each-peff ;)
For a moment, the use of the walker in builtin/branch.c even tricked me
into thinking that it might not use for-each-ref at all. God forbid!
I actually like the format suggestion. Then we only need to discuss the
default format, which is hopefully less of a problem. But that is
something for later, I'll discard the -v[v[v]] patches for now. Have we
unified log formats and for-each-ref formats and parsers already, btw? I
recall some efforts.
Michael
^ permalink raw reply
* Re: [PATCH] replace: List replacement along with the object
From: Christian Couder @ 2011-08-26 8:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <4E574D61.8050501@drmicha.warpmail.net>
On Fri, Aug 26, 2011 at 9:38 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Christian Couder venit, vidit, dixit 25.08.2011 18:29:
>> On Thu, Aug 25, 2011 at 4:39 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> The documentation could be misunderstood as if "git replace -l" lists
>>> the replacements of the specified objects. Currently, it lists the
>>> replaced objects.
>>
>> You could just change the documentation to make it more explicit.
>
> Well, sure. I just didn't find the current form that useful.
>
>>> Change the output to the form "<object> <replacement>" so that there is
>>> an easy way to find the replacement, besides the more difficult to find
>>> git show-ref $(git replace -l).
>>
>> I shamelessly copied the "-l <pattern>" feature and the documentation
>> from "git tag". If you just change the output of "git replace -l" it
>> will make the UI inconsistent between both commands.
>
> I don't think many people will expect consistency between branch and tag
> on the one hand, and replace refs on the other hand. It requires the
> knowledge that a replacement is basically a lightweight tag stored in a
> different namespace in refs/, which I would actually consider an
> implementation detail.
It is an implementation detail, but anyway UI consistency is important
and I would suggest the same behavior even if it was implemented in
another way.
By the way it would be nice to make "git remote" more similar to "git
branch", "git tag" and "git replace" while you are at it.
>> Maybe you could add a "-L <pattern>" feature to "git replace", "git
>> tag" and "git branch" that would output "<ref name> <ref content>"?
>
> I'd use "-v" then if this is about consistency, because that *always*
> means "verbose", and migrate the misnamed "git tag -v"...
Yeah, but "git branch -v" is decribed like this:
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.
So if you implement it in "git replace" and "git tag", you should at
least show the commit subject line too.
Thanks,
Christian.
^ permalink raw reply
* [PATCHv2] git-replace.txt: Clarify list mode
From: Michael J Gruber @ 2011-08-26 7:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder
In-Reply-To: <4E574D61.8050501@drmicha.warpmail.net>
Clarify that in list mode, "git replace" outputs the shortened ref
names, not their values.
Also, point to the difficult to find git show-ref $(git replace -l).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-replace.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 17df525..cd00837 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -61,6 +61,13 @@ OPTIONS
all if no pattern is given).
Typing "git replace" without arguments, also lists all replace
refs.
++
+Note that this lists the names of the replace refs, not their values
+(not their replacements). You can get the latter like this, e.g.:
+
+------------------------------------------------
+$ git show-ref $(git replace -l)
+------------------------------------------------
BUGS
----
@@ -76,6 +83,7 @@ replaced by a commit).
SEE ALSO
--------
+linkgit:git-show-ref[1]
linkgit:git-tag[1]
linkgit:git-branch[1]
linkgit:git[1]
--
1.7.6.845.gc3c05
^ permalink raw reply related
* Re: [PATCH] replace: List replacement along with the object
From: Michael J Gruber @ 2011-08-26 7:38 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano
In-Reply-To: <CAP8UFD2Cr4UQjWa=pRvcqgyX_Ed+qjts=TujWRdyk4dUZsd_7Q@mail.gmail.com>
Christian Couder venit, vidit, dixit 25.08.2011 18:29:
> On Thu, Aug 25, 2011 at 4:39 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> The documentation could be misunderstood as if "git replace -l" lists
>> the replacements of the specified objects. Currently, it lists the
>> replaced objects.
>
> You could just change the documentation to make it more explicit.
Well, sure. I just didn't find the current form that useful.
>> Change the output to the form "<object> <replacement>" so that there is
>> an easy way to find the replacement, besides the more difficult to find
>> git show-ref $(git replace -l).
>
> I shamelessly copied the "-l <pattern>" feature and the documentation
> from "git tag". If you just change the output of "git replace -l" it
> will make the UI inconsistent between both commands.
I don't think many people will expect consistency between branch and tag
on the one hand, and replace refs on the other hand. It requires the
knowledge that a replacement is basically a lightweight tag stored in a
different namespace in refs/, which I would actually consider an
implementation detail.
> Maybe you could add a "-L <pattern>" feature to "git replace", "git
> tag" and "git branch" that would output "<ref name> <ref content>"?
I'd use "-v" then if this is about consistency, because that *always*
means "verbose", and migrate the misnamed "git tag -v"...
Junio C Hamano venit, vidit, dixit 25.08.2011 21:07:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> The documentation could be misunderstood as if "git replace -l" lists
>> the replacements of the specified objects. Currently, it lists the
>> replaced objects.
> Seeing that you had to change existing tests, I do not think this is an
> improvement. The existing scripts can read the list of objects and find
> replacement themselves (if they want to find that out, that is), no?
If "replace -l" is considered fair game for scripts then the output
should probably not change, though I left the meaning of "$1" for each
line of the output as is on purpose.
But, how would scripts find the replacement? rev-parse does not do it,
rev-list does not do it, and using show-ref requires the user to know
about the actual implementation as refs under refs/replace.
Seems that the doc change is the only option.
Michael
^ permalink raw reply
* Re: [PATCH 0/2] Add an update=none option for 'loose' submodules
From: Junio C Hamano @ 2011-08-26 6:27 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Jens Lehmann, git
In-Reply-To: <20110824193007.GC45292@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
>> That is definitely a huge semantics change.
>
> Ok seeing it that way. You are right. How about this?
Actually I had an update to Documentation/git-submodule.txt in mind. For
example, we say this for "update":
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
I know you added "yes, we earlier said this will clone missing ones and
checkout, but if this configuration is set to none then none of that
happens" much later in the section, but that feels backwards.
Thinking about it more, I am starting to think that this backwardness may
be an indication that we are describing a wrong solution to a wrong
problem.
Isn't the root cause of the issue that a "submodule init" without pathspec
limit adds everything to .git/config, ending up with all submodules fully
instantiated, and it is too easy to run such a lazy "submodule init"?
If we allowed the project managers (i.e. the ones who write .gitmodules)
to specify the default set of submodules to be initialized with such a
"submodule init", omitting some submodules from even getting registered to
the recipients' .git/config in the first place, wouldn't that solve the
issue you are trying to address equally well, without anything to worry
about this semantic change at all? I am trying to see if we can come up
with a solution with which we do not even have to add any entry for a
submodule to .git/config of the superproject, if it is "don't care" kind
of submodule for the copy of the superproject repository the user has.
The way in which the project managers specify that a module is not meant
to be "init"ed by default may be to have "submodule.$name.update = none"
in the .gitmodules file they ship, so externally there may not be huge
difference from the behaviour (but not the implementation) of your patch,
even though submodule.$name.update probably is not a good variable name to
be used for this purpose.
Another thing we may want to consider is to make .gitmodules describe
submodule dependencies. If your hypothetical superproject is about a
library, which consists of doc/, include/, and libsrc/ submodules, with
pre-built binary perhaps shipped as part of the superproject itself, those
who work on documentation may want to populate only doc/, those who are
interested in using the library may want to populate only include/ and
possibly doc/, and those who work on the library itself would populate
include/ and libsrc/, possibly with doc/ submodules. It wouldn't make any
sense to populate libsrc/ without populating include/ submodule, as the
source would not be buildable without the includes.
Now if we imagine that much more people are interested in using the
library than working on it, it is plausible that the project may want to
suggest:
- Majority of people may want to omit libsrc/ submodule; and
- If you populate libsrc/, then you would definitely want to populate
include/ submodule.
Your "submodule.libsrc.update = none" in .gitmodules can express the
former, and I think it is natural to express the latter (i.e. submodule
dependency) in the same file, to be propagated in the same way to the
consumers.
^ permalink raw reply
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Junio C Hamano @ 2011-08-26 5:52 UTC (permalink / raw)
To: Jeff King; +Cc: Boaz Harrosh, git
In-Reply-To: <20110826025913.GC17625@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> No, certainly not since 122aa6f (diff: introduce diff.<driver>.binary,
> 2008-10-05). That commit's message claims that we did before it, but
> looking at the patch, I am not so sure. But I'm not about to start
> testing a 3-year-old patch to see if it really was the source of the
> fix; the point is that it is correct now. :)
Violently agreed ;-)
> I think it could be a problem in the future if the builtin userdiff
> drivers started growing more invasive options, like automatically
> claiming to be non-binary (i.e., setting diff.cpp.binary = false by
> default).
Well, I think we can be careful when we start thinking about doing
something complex like that, then. Mentioning the above consideration in
the commit message of the final version of this patch would probably be a
good idea, I presume.
Thanks.
^ permalink raw reply
* [RFC PATCH] diff: use $COLUMNS if available for default stat_width
From: Kris Shannon @ 2011-08-26 5:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
If the COLUMNS environment variable is set use it's value
as the default stat_width.
Also set the stat_name_width default to 2/3 of the full width.
This does change the default from 50 to 53 when using the
original 80 column stat_width fallback.
Signed-off-by: Kris Shannon <kris@shannon.id.au>
---
diff.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
This has bugged me for a long time. I finally decided to see how hard it would
be to fix.
I thought about getting the COLUMNS value once but I'm not sure it's worth the
extra code.
diff --git a/diff.c b/diff.c
index 9038f19..6954134 100644
--- a/diff.c
+++ b/diff.c
@@ -1329,8 +1329,16 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
line_prefix = msg->buf;
}
- width = options->stat_width ? options->stat_width : 80;
- name_width = options->stat_name_width ? options->stat_name_width : 50;
+ width = options->stat_width;
+ if (!width) {
+ char *cols = getenv("COLUMNS");
+
+ if (cols)
+ width = strtoul(cols, NULL, 10);
+ if (!width)
+ width = 80;
+ }
+ name_width = options->stat_name_width ? options->stat_name_width : ((width * 2 + 1) / 3);
/* Sanity: give at least 5 columns to the graph,
* but leave at least 10 columns for the name.
--
1.7.6.1
^ permalink raw reply related
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Eric Sunshine @ 2011-08-26 3:58 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Boaz Harrosh, git
In-Reply-To: <20110826024533.GB17625@sigill.intra.peff.net>
On 08/25/2011 10:45 PM, Jeff King wrote:
> Should all of our matches be case-insensitive? That is, should we be
> matching both .HTML and .html? Clearly lowercase is the One True Way,
> but I don't know what kind of junk people with case-insensitive
> filesystems have, or whether we should even worry about it.
In the Windows world, uppercase extensions are common. Also, one often
finds .htm on Windows rather than .html.
Speaking of other platforms, on Mac OS X:
Objective-C is .m
Objective-C++ is .mm (and long-deprecated .M is probably not relevant)
-- ES
^ permalink raw reply
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-08-26 2:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Boaz Harrosh, git
In-Reply-To: <7v8vqhhzgd.fsf@alter.siamese.dyndns.org>
On Thu, Aug 25, 2011 at 03:57:06PM -0700, Junio C Hamano wrote:
> > If you have any matching attribute line in your own files, it should
> > override. So:
> >
> > foo/* -diff
> >
> > will still mark foo/bar.c as binary, even with this change.
> >
> > Can anyone think of other possible side effects?
> >
> > Also, any other extensions that would go into such a list? I have no
> > idea what the common extension is for something like pascal or csharp.
>
> As long as the builtin ones are the lowest priority fallback, we should be
> Ok.
>
> Do we say anywhere that "Ah, this has 'diff' attribute defined, so it must
> be text"? If so, we should fix _that_. In other words, having this one
> extra entry
>
> "* diff=default"
>
> in the builtin_attr[] array should be a no-op, I think.
No, certainly not since 122aa6f (diff: introduce diff.<driver>.binary,
2008-10-05). That commit's message claims that we did before it, but
looking at the patch, I am not so sure. But I'm not about to start
testing a 3-year-old patch to see if it really was the source of the
fix; the point is that it is correct now. :)
I think it could be a problem in the future if the builtin userdiff
drivers started growing more invasive options, like automatically
claiming to be non-binary (i.e., setting diff.cpp.binary = false by
default). In other words, I think we have two options:
1. Builtin drivers like "cpp" can stay minimal, only setting funcname
and color-words headers that aren't going to produce terrible
results if we are wrong about detecting by extension.
2. We force the user to identify file types manually, so we can't be
wrong. The "cpp" diff driver means "you are a text C file", and if
a user mis-marks a binary file with that diff driver, they are the
one who is wrong.
So if it's an either/or situation, we should decide not only that
extension auto-detection is a good feature, but that it trumps adding
more advanced features to the builtin drivers in the future.
Or we could decide that the extensions really are good enough, and if
you really do have binary files named "foo.c", it's your problem to
override the defaults with "*.c -diff".
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-08-26 2:45 UTC (permalink / raw)
To: Brandon Casey; +Cc: Boaz Harrosh, git
In-Reply-To: <5qgbkjmEZ8jSRkpVNieElg1bcVbuEStD525CFu1hZPQ7F03R3EzjXwQdDKQBOnR1zWDiZBsGu53K20rbOGpYd6rmp2-e-ZI3Z42BKT01TVI@cipher.nrlssc.navy.mil>
On Thu, Aug 25, 2011 at 05:29:36PM -0500, Brandon Casey wrote:
> > Also, any other extensions that would go into such a list?
>
> *.bib diff=bibtex
> *.tex diff=tex
I had those ones already. ;P
> *.[Ff] diff=fortran
> *.[Ff][0-9][0-9] diff=fortran
Thanks, I'll add those. I don't see a big problem with generalizing
f[0-9][0-9] to always be fortran, even though many of those numbers
aren't used. I don't think I've ever seen one used for anything else.
Should all of our matches be case-insensitive? That is, should we be
matching both .HTML and .html? Clearly lowercase is the One True Way,
but I don't know what kind of junk people with case-insensitive
filesystems have, or whether we should even worry about it.
> Wikipedia says that .for is an extension for fortran, but I've never
> seen that in the wild. Maybe it's a windows thing (3-char ext).
We can leave it out. It's easy enough for somebody to add their own
gitattribute if they want, or to even complain that it should be in the
default set. I was trying to keep this list to the utterly common, not
become a catalogue of obscure fortran customs. :)
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-08-26 2:39 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Boaz Harrosh, git
In-Reply-To: <4E56DE59.5050601@sunshineco.com>
On Thu, Aug 25, 2011 at 07:44:25PM -0400, Eric Sunshine wrote:
> >How well do our cpp patterns do with header files? I imagine they're
> >better than the default, but I don't think I've ever really tried
> >anything tricky.
>
> I scanned through a number of revisions for one of my long-running
> C++ projects comparing the diff of header files with and without "*.h
> diff=cpp". In some header files in this project, the oft-used C++
> keywords public:, protected:, and private: appear at start-of-line.
> In such cases, the default diff emits a less-than-useful hunk header:
>
> @@ -19,8 +19,8 @@ public:
>
> whereas, "diff=cpp" emits:
>
> @@ -19,8 +19,8 @@ class Foobar
Thanks. My C++ is so rusty that I didn't think immediately of how often
those keywords appear in header files. Also, code in inline
functions in either C or C++ will be found in header files. So I think
defaulting *.h and *.hpp to cpp is sensible.
-Peff
^ permalink raw reply
* [PATCH] Documentation/show-ref: correct order of --heads and --tags
From: pangyanhan @ 2011-08-26 2:26 UTC (permalink / raw)
To: git; +Cc: Pang Yan Han
From: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
Documentation/git-show-ref.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 3c45895..5a646e4 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -34,8 +34,8 @@ OPTIONS
Show the HEAD reference.
---tags::
--heads::
+--tags::
Limit to only "refs/heads" and "refs/tags", respectively. These
options are not mutually exclusive; when given both, references stored
--
1.7.6
^ 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