Re: [PATCH] clean: new option --exclude-from

[Jeff King]

On Sat, Dec 05, 2015 at 07:51:03PM -0800, Junio C Hamano wrote:

> In any case, what we've been discussing may be an interesting and
> potentially important tangent, but it still is a tangent while
> evaluating the patch in question.  I do not think I'd be using the
> new "--exclude-from=" option to "clean" (simply because I do
> not think I've ever used the existing "-e" option to it unless I am
> merely testing the command to make sure it works as advertised)
> myself, but I do not immediately see how it would hurt us in the
> future to add it now.  So...

I think that is OK. The reason I brought it up was "let's stop and make
sure we don't want to go this other route before we add more potentially
redundant options that we cannot get rid of later". But based on this
discussion it is not at all clear that "clean --exclude-from" would
become redundant, so let's cross that off as an objection.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Junio C Hamano]

Jeff King  writes:

> My motivation isn't exactly code sharing. It is that you sometimes want
> to affect sub-commands of a program, and cannot pass command line
> options to them yourself.
>
> For instance, "git-stash --include-untracked" will call "git clean"
> under the hood. There is no way to say "...and treat foo.* as ignored
> for this invocation". It could grow its own "-e" option, but that does
> not help any other third-party scripts which call "git clean".
>
> So IMHO this is not really about command-line options, but about the
> environment in which a command is executed. Environment variables are
> the obvious way to do that; "git --foo" options are just syntactic sugar
> to set the variables. We could just add variables without matching
> options.

I'd be even more wary of that, as different commands use ignore
patterns for different purposes.  A script may invoke "clean" and
"add" and would want to use different sets of ignore patterns to
emulate "precious" class (which we do not have), for example, by
giving a wider ignore pattern for "add" to prevent a file that must
be kept untracked outside the index while telling "clean -X" that
that file is not expendable with a narrower ignore pattern.  That is
just one example that comes to me without thinking about the issues
too hard, so I am reasonably sure that it would hurt the ecosystem
to promote that the ignore pattern can be used for specifying
important per-invocation input to a script.

In any case, what we've been discussing may be an interesting and
potentially important tangent, but it still is a tangent while
evaluating the patch in question.  I do not think I'd be using the
new "--exclude-from=" option to "clean" (simply because I do
not think I've ever used the existing "-e" option to it unless I am
merely testing the command to make sure it works as advertised)
myself, but I do not immediately see how it would hurt us in the
future to add it now.  So...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Junio C Hamano]

Jeff King  writes:

> On Tue, Dec 01, 2015 at 06:18:30PM -0800, Junio C Hamano wrote:
>
>> It is likely that existing users are already using $HOME/.gitconfig
>> that sets core.excludesfile=$HOME/.gitconfig as the personal
>> fallback, that is overriden, not tweaked, by project specific
>> settings of the same variable in .git/config, so that would not fly
>> very well, I suspect.
>
> Maybe. I would think the more common setup is:
>
>   1. Personal exclude files (e.g., your editor's backup files) come from
>  ~/.gitconfig.
>
>   2. Per-project personal excludes go directly into .git/info/exclude.
>
> But you're right that it would be a backwards-incompatible change.

No question about it, but at the same time I can sort of see how
useful being able to read from more than one would be.

But for this particular one, I viewed the topic as adding a new
option as a shorter way for passing multiple -e  options on
the command line.  When viewed that way, even if core.excludesfile
were multi-valued, I wouldn't have imagined that people would try to
use that mechanism for such a purpose--for one thing, the precedence
order is wrong for that purpose, isn't it?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Jeff King]

On Wed, Dec 02, 2015 at 09:25:24AM -0800, Junio C Hamano wrote:

> I do not think we should liberally add options that apply to
> anything "git" in the first place [*1*].  Limit them to ones that
> are really special and fundamental that changes the way Git
> operates, i.e. "Where is our $GIT_DIR?" is a good thing for users to
> be able to tell "git" itself.  Compared to that, the ignore patterns
> is a fringe that is used only by commands that care about the
> working tree (e.g. the global option in "git --exclude='*.o'
> ls-tree" would be meaningless).
> 
> 
> [Footnote]
> 
> *1* It would add unnecessary confusion to the end users; they have
> to decide if they need to pass an option before or after the
> subcommand name.  If the motivation behind the "git --option cmd"
> is to share code and semantics for common "--option", we should
> instead further refactor command line option handling, just like
> the code for config handling allows us to share config_default.

My motivation isn't exactly code sharing. It is that you sometimes want
to affect sub-commands of a program, and cannot pass command line
options to them yourself.

For instance, "git-stash --include-untracked" will call "git clean"
under the hood. There is no way to say "...and treat foo.* as ignored
for this invocation". It could grow its own "-e" option, but that does
not help any other third-party scripts which call "git clean".

So IMHO this is not really about command-line options, but about the
environment in which a command is executed. Environment variables are
the obvious way to do that; "git --foo" options are just syntactic sugar
to set the variables. We could just add variables without matching
options.

I agree that we could end up proliferating such options (or environment
variables). Using the logic above, you could argue that I should be able
to affect any option of any sub-command in a script, which just gets
silly. My rule of thumb would be that if there is some implicit state in
the on-disk repo (e.g., what is in your .git/config) that you
might want to override for a one-shot invocation, then it may be a
reasonable candidate. The "git -c" config override is such an example.

In this case, it is basically adding to ".git/info/exclude", which
follows the same rule.

But like I said, I do not feel all that strongly about this particular
option. I would not use it myself. Just trying to make my reasoning
clear. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Jeff King]

On Wed, Dec 02, 2015 at 08:40:05AM -0800, Junio C Hamano wrote:

> But for this particular one, I viewed the topic as adding a new
> option as a shorter way for passing multiple -e  options on
> the command line.  When viewed that way, even if core.excludesfile
> were multi-valued, I wouldn't have imagined that people would try to
> use that mechanism for such a purpose--for one thing, the precedence
> order is wrong for that purpose, isn't it?

Good point. I didn't think about precedence at all.

I perhaps shouldn't have brought up core.excludesfile as all. I only
meant it as "you maybe can hack your way through to this without adding
any code".

I think a real option to do git-wide excludes would probably be more
like:

  git --exclude-from=/path/to/file clean ...

and that in turn would probably set GIT_EXCLUDE_FROM to a
colon-separated list of paths (or similar) so that sub-processes would
respect it, too.

On the other hand, one could make the same argument about the existing
"-e". You cannot do:

  git add --exclude='*.o' .

right now. So maybe "clean" is really the only place where people care
about such ad-hoc exclusion. Or maybe this an opportunity to add:

  git --exclude='*.o' clean

I dunno. I cannot think of a time when I would have used any of those
options myself.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Junio C Hamano]

Jeff King  writes:

>  So maybe "clean" is really the only place where people care
> about such ad-hoc exclusion. Or maybe this an opportunity to add:
>
>   git --exclude='*.o' clean
>
> I dunno. I cannot think of a time when I would have used any of those
> options myself.

Me either and I do not think I ever wanted to use -e to "clean".

I do not think we should liberally add options that apply to
anything "git" in the first place [*1*].  Limit them to ones that
are really special and fundamental that changes the way Git
operates, i.e. "Where is our $GIT_DIR?" is a good thing for users to
be able to tell "git" itself.  Compared to that, the ignore patterns
is a fringe that is used only by commands that care about the
working tree (e.g. the global option in "git --exclude='*.o'
ls-tree" would be meaningless).


[Footnote]

*1* It would add unnecessary confusion to the end users; they have
to decide if they need to pass an option before or after the
subcommand name.  If the motivation behind the "git --option cmd"
is to share code and semantics for common "--option", we should
instead further refactor command line option handling, just like
the code for config handling allows us to share config_default.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Eric Sunshine]

On Tue, Dec 1, 2015 at 4:36 PM, James Rouzier  wrote:
> Eric thank you for the feedback.

[re-adding git@vger.kernel.org to recipient list since this response
was likely intended to be public]

> On Sun, Nov 29, 2015 at 9:24 PM, Eric Sunshine 
> wrote:
>> On Thu, Nov 26, 2015 at 9:44 AM, James  wrote:
>> > From: James Rouzier 
>> >
>> > Specify a file to read for exclude patterns.
>> > ---
>> > @@ -61,6 +61,9 @@ OPTIONS
>> > $GIT_DIR/info/exclude, also consider these patterns to be in the
>> > set of the ignore rules in effect.
>> >
>> > +--exclude-from=::
>> > +   Read exclude patterns from ; 1 per line.
>>
>> s/;/,/ maybe?
>
> I copied this from Documentation/git-ls-files.txt to try and keep the
> documentation style consistent.
> However if it is believed to be better I will change it here and also in a
> separate patch for Documentation/git-ls-files.txt

I don't feel strongly about it. Existing precedence may be a good
argument in its favor.

>> Also, why move the memset() all the way up here as opposed, say, to
>> moving it just before the parse_options() invocation? Is it just to
>> make it easier for the next person who comes along wanting to
>> manipulate 'dir' early on (before git_config(), for instance)?
>
> Yes I want to make sure that the 'dir' is initialized before any usage.
>
>> > +   git clean -f --exclude-from=.git/clean-exclude &&
>> > +   test -e 1 &&
>> > +   test -e 2 &&
>> > +   ! (test -e 3) &&
>>
>> I see that you copied this from the "git clean -e" test, but it's not
>> obvious why parentheses are needed or wanted, and none of the other
>> tests use parentheses when negating the return of 'test', thus they
>> probably ought to be dropped.
>
> Ok will do
>
>> > +   test -e known
>>
>> Modern scripts would normally use test_path_is_file() and
>> test_path_is_missing() instead of 'test -e', however, you are again
>> matching existing style in this script, so 'test -e' may be
>> reasonable.
>
> Since it is the standard I could just take the time to upgrade 'test -e' in
> this test file to use newer standard.

This test script is probably relatively quiescent right now, so such
cleanup may be reasonable. Since it is conceptually distinct from the
purpose of the current patch, you would want to do the cleanup as a
preparatory patch, thus making this a 2-patch series.

>> > +test_expect_success 'git clean -e --exclude-from' '
>> > +   rm -fr repo &&
>> > +   mkdir repo &&
>> > +   (
>> > +   cd repo &&
>> > +   git init &&
>> > +   touch known 1 2 3 &&
>> > +   git add known &&
>> > +   echo 1 >> .git/clean-exclude &&
>> > +   git clean -f -e 2 --exclude-from=.git/clean-exclude &&
>> > +   test -e 1 &&
>> > +   test -e 2 &&
>> > +   ! (test -e 3) &&
>> > +   test -e known
>> > +   )
>> > +'
>>
>> Should a test be added which uses --exclude-from multiple times in the
>> same git-clean invocation?
>
> That does make sense will do.
>
>> Would it make sense add a test checking the behavior when the file
>> named by --exclude-from doesn't exist or is otherwise unusable as an
>> exclusion file?
>
> At the moment the add_excludes_from_file function will exit the program if
> there is a problem loading the exclude file.
> I could add a test for that behavior. In case in the future this behavior is
> changed.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Jeff King]

On Tue, Dec 01, 2015 at 06:18:30PM -0800, Junio C Hamano wrote:

> > Should this perhaps be an option to the main "git" to append to the set
> > of excludes?
> >
> > You can kind-of do this already with:
> >
> >   git -c core.excludesfile=/path/to/whatever clean ...
> >
> > but of course you might be using core.excludesfile already. I wonder if
> > that config option should take multiple values and respect all of them,
> > rather than last-one-wins.
> 
> It is likely that existing users are already using $HOME/.gitconfig
> that sets core.excludesfile=$HOME/.gitconfig as the personal
> fallback, that is overriden, not tweaked, by project specific
> settings of the same variable in .git/config, so that would not fly
> very well, I suspect.

Maybe. I would think the more common setup is:

  1. Personal exclude files (e.g., your editor's backup files) come from
 ~/.gitconfig.

  2. Per-project personal excludes go directly into .git/info/exclude.

But you're right that it would be a backwards-incompatible change.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Junio C Hamano]

Jeff King  writes:

> On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote:
>
>> From: James Rouzier 
>> 
>> Specify a file to read for exclude patterns.
>> ---
>
> Lots of commands care about excludes (e.g., "add", "status").
>
> Should this perhaps be an option to the main "git" to append to the set
> of excludes?
>
> You can kind-of do this already with:
>
>   git -c core.excludesfile=/path/to/whatever clean ...
>
> but of course you might be using core.excludesfile already. I wonder if
> that config option should take multiple values and respect all of them,
> rather than last-one-wins.

It is likely that existing users are already using $HOME/.gitconfig
that sets core.excludesfile=$HOME/.gitconfig as the personal
fallback, that is overriden, not tweaked, by project specific
settings of the same variable in .git/config, so that would not fly
very well, I suspect.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Jeff King]

On Thu, Nov 26, 2015 at 09:44:25AM -0500, James wrote:

> From: James Rouzier 
> 
> Specify a file to read for exclude patterns.
> ---

Lots of commands care about excludes (e.g., "add", "status").

Should this perhaps be an option to the main "git" to append to the set
of excludes?

You can kind-of do this already with:

  git -c core.excludesfile=/path/to/whatever clean ...

but of course you might be using core.excludesfile already. I wonder if
that config option should take multiple values and respect all of them,
rather than last-one-wins.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: new option --exclude-from

[Eric Sunshine]

On Thu, Nov 26, 2015 at 9:44 AM, James  wrote:
> From: James Rouzier 
>
> Specify a file to read for exclude patterns.
> ---
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> @@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
>  SYNOPSIS
>  
>  [verse]
> -'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
> +'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [--exclude-from ] 
> [-x | -X] [--] ...

Common practice seems to be to include the '=' in the synopsis:
[--exclude-from=]

>  DESCRIPTION
>  ---
> @@ -61,6 +61,9 @@ OPTIONS
> $GIT_DIR/info/exclude, also consider these patterns to be in the
> set of the ignore rules in effect.
>
> +--exclude-from=::
> +   Read exclude patterns from ; 1 per line.

s/;/,/ maybe?

> diff --git a/builtin/clean.c b/builtin/clean.c
> @@ -875,6 +875,16 @@ static void interactive_main_loop(void)
> +static int option_parse_exclude_from(const struct option *opt,
> +const char *arg, int unset)

For consistency with the other callback function in this file, you'd
probably want to name this function exclude_from_cb().

> +{
> +   struct dir_struct *dir = opt->value;
> +
> +   add_excludes_from_file(dir, arg);
> +
> +   return 0;

Style: You can drop the blank line before 'return'.

> +}
> @@ -898,11 +908,15 @@ int cmd_clean(int argc, const char **argv, const char 
> *prefix)
> N_("remove whole directories")),
> { OPTION_CALLBACK, 'e', "exclude", _list, 
> N_("pattern"),
>   N_("add  to ignore rules"), PARSE_OPT_NONEG, 
> exclude_cb },
> +   { OPTION_CALLBACK, 0, "exclude-from", , N_("file"),
> +   N_("exclude patterns are read from "),

The existing descriptions all use imperative mood. This probably ought
to follow suit:

N_("read exclude patterns from file"),

> +   0, option_parse_exclude_from },
> OPT_BOOL('x', NULL, , N_("remove ignored files, 
> too")),
> OPT_BOOL('X', NULL, _only,
> N_("remove only ignored files")),
> OPT_END()
> };
> +   memset(, 0, sizeof(dir));

Style: Leave a blank line after the final declaration (before the memset).

Also, why move the memset() all the way up here as opposed, say, to
moving it just before the parse_options() invocation? Is it just to
make it easier for the next person who comes along wanting to
manipulate 'dir' early on (before git_config(), for instance)?

> git_config(git_clean_config, NULL);
> if (force < 0)
> @@ -913,7 +927,6 @@ int cmd_clean(int argc, const char **argv, const char 
> *prefix)
> argc = parse_options(argc, argv, prefix, options, builtin_clean_usage,
>  0);
>
> -   memset(, 0, sizeof(dir));
> if (ignored_only)
> dir.flags |= DIR_SHOW_IGNORED;
>
> diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
> @@ -630,6 +630,41 @@ test_expect_success 'git clean -e' '
> +test_expect_success 'git clean --exclude-from' '
> +   rm -fr repo &&
> +   mkdir repo &&
> +   (
> +   cd repo &&
> +   git init &&
> +   touch known 1 2 3 &&

Unless the timestamp is significant, we normally avoid using 'touch'
and instead just use redirection to create empty files:

>1
>2
>3

In this case, though, you're merely matching existing style in this
script, so 'touch' may be okay.

> +   git add known &&
> +   echo 1 >> .git/clean-exclude &&
> +   echo 2 >> .git/clean-exclude &&

Style: no space after redirection operator.

A here-doc may be cleaner and easier to maintain:

cat >.git/clean-exclude <<-\EOF
1
2
EOF

> +   git clean -f --exclude-from=.git/clean-exclude &&
> +   test -e 1 &&
> +   test -e 2 &&
> +   ! (test -e 3) &&

I see that you copied this from the "git clean -e" test, but it's not
obvious why parentheses are needed or wanted, and none of the other
tests use parentheses when negating the return of 'test', thus they
probably ought to be dropped.

> +   test -e known

Modern scripts would normally use test_path_is_file() and
test_path_is_missing() instead of 'test -e', however, you are again
matching existing style in this script, so 'test -e' may be
reasonable.

> +   )
> +'
> +
> +test_expect_success 'git clean -e --exclude-from' '
> +   rm -fr repo &&
> +   mkdir repo &&
> +   (
> +   cd repo &&
> +   git init &&
> +   touch known 1 2 3 &&
> +   git add known &&
> +   echo 1 >> .git/clean-exclude &&
> +   git clean -f -e 2 --exclude-from=.git/clean-exclude &&
> +   test -e 1 &&
> +   test -e 2 &&
> + 

[PATCH] clean: new option --exclude-from

[James]

From: James Rouzier 

Specify a file to read for exclude patterns.
---
 Documentation/git-clean.txt |  5 -
 builtin/clean.c | 15 ++-
 t/t7300-clean.sh| 35 +++
 3 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 641681f..ccd0aa4 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 
 [verse]
-'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [--exclude-from ] 
[-x | -X] [--] ...
 
 DESCRIPTION
 ---
@@ -61,6 +61,9 @@ OPTIONS
$GIT_DIR/info/exclude, also consider these patterns to be in the
set of the ignore rules in effect.
 
+--exclude-from=::
+   Read exclude patterns from ; 1 per line.
+
 -x::
Don't use the standard ignore rules read from .gitignore (per
directory) and $GIT_DIR/info/exclude, but do still use the ignore
diff --git a/builtin/clean.c b/builtin/clean.c
index d7acb94..e4995a3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -875,6 +875,16 @@ static void interactive_main_loop(void)
}
 }
 
+static int option_parse_exclude_from(const struct option *opt,
+const char *arg, int unset)
+{
+   struct dir_struct *dir = opt->value;
+
+   add_excludes_from_file(dir, arg);
+
+   return 0;
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
int i, res;
@@ -898,11 +908,15 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
N_("remove whole directories")),
{ OPTION_CALLBACK, 'e', "exclude", _list, N_("pattern"),
  N_("add  to ignore rules"), PARSE_OPT_NONEG, 
exclude_cb },
+   { OPTION_CALLBACK, 0, "exclude-from", , N_("file"),
+   N_("exclude patterns are read from "),
+   0, option_parse_exclude_from },
OPT_BOOL('x', NULL, , N_("remove ignored files, too")),
OPT_BOOL('X', NULL, _only,
N_("remove only ignored files")),
OPT_END()
};
+   memset(, 0, sizeof(dir));
 
git_config(git_clean_config, NULL);
if (force < 0)
@@ -913,7 +927,6 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
argc = parse_options(argc, argv, prefix, options, builtin_clean_usage,
 0);
 
-   memset(, 0, sizeof(dir));
if (ignored_only)
dir.flags |= DIR_SHOW_IGNORED;
 
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 86ceb38..9b648b9 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -630,6 +630,41 @@ test_expect_success 'git clean -e' '
)
 '
 
+test_expect_success 'git clean --exclude-from' '
+   rm -fr repo &&
+   mkdir repo &&
+   (
+   cd repo &&
+   git init &&
+   touch known 1 2 3 &&
+   git add known &&
+   echo 1 >> .git/clean-exclude &&
+   echo 2 >> .git/clean-exclude &&
+   git clean -f --exclude-from=.git/clean-exclude &&
+   test -e 1 &&
+   test -e 2 &&
+   ! (test -e 3) &&
+   test -e known
+   )
+'
+
+test_expect_success 'git clean -e --exclude-from' '
+   rm -fr repo &&
+   mkdir repo &&
+   (
+   cd repo &&
+   git init &&
+   touch known 1 2 3 &&
+   git add known &&
+   echo 1 >> .git/clean-exclude &&
+   git clean -f -e 2 --exclude-from=.git/clean-exclude &&
+   test -e 1 &&
+   test -e 2 &&
+   ! (test -e 3) &&
+   test -e known
+   )
+'
+
 test_expect_success SANITY 'git clean -d with an unreadable empty directory' '
mkdir foo &&
chmod a= foo &&
-- 
2.3.6

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html