Re: [PATCH v2 3/6] generate-cmdlist.sh: keep all information in common-cmds.h

[Øystein Walle]

Junio C Hamano  writes:

> Nguyễn Thái Ngọc Duy   writes:
> 
> > +category_list () {
> > +   command_list "$1" | awk '{print $2;}' | sort | uniq
> > +}
> 
> Piping output of awk to sort/uniq, instead of processing all inside
> awk within the END block of the script, means that we are wasting
> two processes---I do not think we care too much about it, but some
> people might.
> 

Can be written as:

command_list "$1" | awk '!seen[$2]++ {print $2}'

This doesn't actually sort it, though, which I'm not sure whether is a
good thing or a bad thing in this case. But it is less work, and being fast is
nice for completion scripts.

Øsse

Re: [PATCH] rev-parse: rev-parse: add --is-shallow-repository

[Øystein Walle]

> Hm, can you say more about the context?  From a certain point of view,
> it might make sense for that command to succeed instead: if the repo
> is already unshallow, then why should't "fetch --unshallow" complain
> instead of declaring victory?

A fellow in #git on Freenode was writing a script for automation and
encountered this error, and asked how to find out whether a repo was
shallow. My *first instinct* was to check if rev-parse had a flag for
it; I wouldn't have been surprised if it did.

I agree that treating it as a fatal error is a bit much in the first
place, but I also think having a way to check can be useful. I also
wonder if a lot of the stuff rev-parse is used for now should be moved
to some sort of `git misc` command, but that's a different can of worms,
so into rev-parse a new flag went.

> What does git-path mean here?  I wonder if it's a copy/paste error.
> ...
> Reviewed-by: Jonathan Nieder 

Yeah, the titles were copy-pasted without adjusting, thanks for fixing,
Jonathan! ;)

> I agree with the fixes to the test titles suggested, so I'll queue the
> patch with the fixes squashed in.  Hearing "yeah, the titles were
> copy-pasted without adjusting, thanks for fixing, Jonathan!" sent by
> =C3=98ystein would be super nice.

Sounds good. Thanks for queueing my patch. My fourth!

�sse

[PATCH] rev-parse: rev-parse: add --is-shallow-repository

[Øystein Walle]

Running `git fetch --unshallow` on a repo that is not in fact shallow
produces a fatal error message. Add a helper to rev-parse that scripters
can use to determine whether a repo is shallow or not.

Signed-off-by: Øystein Walle <oys...@gmail.com>
---
 Documentation/git-rev-parse.txt |  3 +++
 builtin/rev-parse.c |  5 +
 t/t1500-rev-parse.sh| 15 +++
 3 files changed, 23 insertions(+)

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index b1293f24b..0917b8207 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -235,6 +235,9 @@ print a message to stderr and exit with nonzero status.
 --is-bare-repository::
When the repository is bare print "true", otherwise "false".
 
+--is-shallow-repository::
+   When the repository is shallow print "true", otherwise "false".
+
 --resolve-git-dir ::
Check if  is a valid repository or a gitfile that
points at a valid repository, and print the location of the
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 2bd28d3c0..c923207f2 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -868,6 +868,11 @@ int cmd_rev_parse(int argc, const char **argv, const char 
*prefix)
: "false");
continue;
}
+   if (!strcmp(arg, "--is-shallow-repository")) {
+   printf("%s\n", is_repository_shallow() ? "true"
+   : "false");
+   continue;
+   }
if (!strcmp(arg, "--shared-index-path")) {
if (read_cache() < 0)
die(_("Could not read the index"));
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 03d3c7f6d..9d3433a30 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -116,6 +116,21 @@ test_expect_success 'git-path inside sub-dir' '
test_cmp expect actual
 '
 
+test_expect_success 'git-path shallow repository' '
+   test_commit test_commit &&
+   echo true >expect &&
+   git clone --depth 1 --no-local . shallow &&
+   test_when_finished "rm -rf shallow" &&
+   git -C shallow rev-parse --is-shallow-repository >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'git-path notshallow repository' '
+   echo false >expect &&
+   git rev-parse --is-shallow-repository >actual &&
+   test_cmp expect actual
+'
+
 test_expect_success 'showing the superproject correctly' '
git rev-parse --show-superproject-working-tree >out &&
test_must_be_empty out &&
-- 
2.11.0.485.g4e59582

Re: [PATCH] stash: allow ref of a stash by index

[Øystein Walle]

Pasting text into Gmail's web interface is not conducive to sending tabs
through the intertubes. But you get the idea..

Øsse

Re: [PATCH] stash: allow ref of a stash by index

[Øystein Walle]

Hi, guys

I like this idea. It makes stash easier and quicker to use, and it
"hides" the fact that it uses the reflog for keeping track of the made
stashes. *Not* to say I discourage interested people from peeking under
the hood. I just think it's nice to sometimes think of the stash as a
separate concept instead of being built on top of strange merge
commits constructed in temporary indexes :)

The bash-specific code is a no-go, so here's a way to do it in a way
that I think is in line with Git's code style for shell scripts. I took
the liberty of removing the '|| exit 1' since the rev is verified later
on anyway, as can be seen in the last piece of context. That way the
argument munging can be done at a later stage where we don't have to
loop over multiple ones. The first rev-parse's purpose is just to apply
--sq.

(Besides, the only way to do it at the top like in the original patch
was   for arg in bleh "$@"   where bleh is a marker to indicate that the
positional arguments should be cleared in a separate case branch so that
they can be rebuilt with multiple invocations of set later. Not pretty,
in my opinion.)

Regards,
Øsse

diff --git a/git-stash.sh b/git-stash.sh
index 826af18..b026288 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -384,7 +384,7 @@ parse_flags_and_rev()
 i_tree=
 u_tree=

-REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1
+REV=$(git rev-parse --no-flags --symbolic --sq "$@" 2>/dev/null)

 FLAGS=
 for opt
@@ -422,6 +422,15 @@ parse_flags_and_rev()
 ;;
 esac

+case "$1" in
+*[!0-9]*)
+:
+;;
+*)
+set -- "${ref_stash}@{$1}"
+;;
+esac
+
 REV=$(git rev-parse --symbolic --verify --quiet "$1") || {
 reference="$1"
 die "$(eval_gettext "\$reference is not a valid reference")"

Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs

[Øystein Walle]

On 25 August 2016 at 07:56, Karthik Nayak  wrote:
>
> I'm thinking more on the lines of `%(upstream)` being an atom and the
> `:track` being an option under that atom. I like sub-atom though ;)
>

On second thought maybe "quark" is better :P

> On Thu, Aug 25, 2016 at 12:03 AM, Jeff King  wrote:
>>
>> Ah, right. I was feeling like this was all vaguely familiar. I think
>> it would be better to push forward kn/ref-filter-branch-list.
>> According to the last "what's cooking", I think that topic is waiting
>> on more review. If you're willing and able to do so, that would be a
>> big help.
>>
>
> It's been waiting for review for a _long_ time now.
>

To be perfectly honest my C skills and familiarity with the git source
code is not much to speak of. I very much want to take a close look but
I cannot promise anything worth your time...

But if I do find something I'd like to point out should I just reply
directly to the e-mails containing the patches as one usually does even
though they're months old at this point?


Øsse
--
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 v2] for-each-ref: add %(upstream:gone) to mark missing refs

[Øystein Walle]

Hi, Peff

On 24 August 2016 at 20:07, Jeff King  wrote
>
> Whoops, your v2 spurred me to review, but I accidentally read and
> responded to v1.
>

Thanks for the review! I was worried this patch had been buried :-)

In the mean time, however, I have discovered that this conflicts with
kn/ref-filter-branch-list in pu. In that topic this specific feature is
implemented as well. They incorporate it into %(upstream:track) instead
of having a separate "sub-atom" (what's the correct nomenclature, by the
way?) more in line with with branch -vv and your idea.

I recall seeing discussions about this work earlier, but I based my
patch on master and forgot to check pu. (It was a spur-of-the-moment
thing fueled by a question in #git about how to parse branch -vv to
delete all local branch who had their remote counter-parts removed after
a fetch --prune.)

Unless that topic gets rejected, or is known to not be merged for a
_long_ while, my patch doesn't add much value.

Regards,
Øsse
--
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

[PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs

[Øystein Walle]

git branch -vv will show "gone" next to a remote tracking branch if it
does not exist. for-each-ref is suitable for parsing but had no way of
showing this information.

This introduces "%(upstream:gone)" to display "gone" in the formatted
output if the ref does not exist or an empty string otherwise, analogous
to git branch -vv.

Signed-off-by: Øystein Walle <oys...@gmail.com>
---
I took the liberty of sending in a v2 on my own. Removed the last argument to
stat_tracking_info() and used test_config instead of test_when_finished.

 Documentation/git-for-each-ref.txt |  5 +++--
 ref-filter.c   |  9 -
 t/t6300-for-each-ref.sh| 11 +++
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index f57e69b..039a86b 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -114,8 +114,9 @@ upstream::
`refname` above.  Additionally respects `:track` to show
"[ahead N, behind M]" and `:trackshort` to show the terse
version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
-   or "=" (in sync).  Has no effect if the ref does not have
-   tracking information associated with it.
+   or "=" (in sync) and `:gone` to show "gone" if the remote ref
+   does not exist, or an empty string if it does. Has no effect if
+   the ref does not have tracking information associated with it.
 
 push::
The name of a local ref which represents the `@{push}` location
diff --git a/ref-filter.c b/ref-filter.c
index bc551a7..757f473 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -37,7 +37,7 @@ static struct used_atom {
union {
char color[COLOR_MAXLEN];
struct align align;
-   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT }
+   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_GONE }
remote_ref;
struct {
enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, 
C_SUB } option;
@@ -67,6 +67,8 @@ static void remote_ref_atom_parser(struct used_atom *atom, 
const char *arg)
atom->u.remote_ref = RR_TRACK;
else if (!strcmp(arg, "trackshort"))
atom->u.remote_ref = RR_TRACKSHORT;
+   else if (!strcmp(arg, "gone"))
+   atom->u.remote_ref = RR_GONE;
else
die(_("unrecognized format: %%(%s)"), atom->name);
 }
@@ -923,6 +925,11 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
*s = ">";
else
*s = "<>";
+   } else if (atom->u.remote_ref == RR_GONE) {
+   if (stat_tracking_info(branch, _ours, _theirs, NULL) < 
0)
+   *s = "gone";
+   else
+   *s = "";
} else /* RR_NORMAL */
*s = refname;
 }
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 19a2823..f99bfd0 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -383,6 +383,17 @@ test_expect_success 'Check that :track[short] works when 
upstream is invalid' '
test_cmp expected actual
 '
 
+test_expect_success 'Check that :gone produces expected results' '
+   cat >expected <<-\EOF &&
+gone
+   EOF
+   test_config branch.master.merge refs/heads/does-not-exist &&
+   git for-each-ref \
+   --format="%(upstream:gone)" \
+   refs/heads >actual &&
+   test_cmp expected actual
+'
+
 test_expect_success 'Check for invalid refname format' '
test_must_fail git for-each-ref --format="%(refname:INVALID)"
 '
-- 
2.9.2

--
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

[PATCH] for-each-ref: add %(upstream:gone) to mark missing refs

[Øystein Walle]

git branch -vv will show "gone" next to a remote tracking branch if it
does not exist. for-each-ref is suitable for parsing but had no way of
showing this information.

This introduces "%(upstream:gone)" to display "gone" in the formatted
output if the ref does not exist or an empty string otherwise, analogous
to git branch -vv.

Signed-off-by: Øystein Walle <oys...@gmail.com>
---
 Documentation/git-for-each-ref.txt |  5 +++--
 ref-filter.c   | 10 +-
 t/t6300-for-each-ref.sh| 12 
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index f57e69b..039a86b 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -114,8 +114,9 @@ upstream::
`refname` above.  Additionally respects `:track` to show
"[ahead N, behind M]" and `:trackshort` to show the terse
version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
-   or "=" (in sync).  Has no effect if the ref does not have
-   tracking information associated with it.
+   or "=" (in sync) and `:gone` to show "gone" if the remote ref
+   does not exist, or an empty string if it does. Has no effect if
+   the ref does not have tracking information associated with it.
 
 push::
The name of a local ref which represents the `@{push}` location
diff --git a/ref-filter.c b/ref-filter.c
index bc551a7..5402052 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -37,7 +37,7 @@ static struct used_atom {
union {
char color[COLOR_MAXLEN];
struct align align;
-   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT }
+   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_GONE }
remote_ref;
struct {
enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, 
C_SUB } option;
@@ -67,6 +67,8 @@ static void remote_ref_atom_parser(struct used_atom *atom, 
const char *arg)
atom->u.remote_ref = RR_TRACK;
else if (!strcmp(arg, "trackshort"))
atom->u.remote_ref = RR_TRACKSHORT;
+   else if (!strcmp(arg, "gone"))
+   atom->u.remote_ref = RR_GONE;
else
die(_("unrecognized format: %%(%s)"), atom->name);
 }
@@ -923,6 +925,12 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
*s = ">";
else
*s = "<>";
+   } else if (atom->u.remote_ref == RR_GONE) {
+   const char *upstream;
+   if (stat_tracking_info(branch, _ours, _theirs, 
) < 0)
+   *s = "gone";
+   else
+   *s = "";
} else /* RR_NORMAL */
*s = refname;
 }
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 19a2823..1fc5d1d 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -383,6 +383,18 @@ test_expect_success 'Check that :track[short] works when 
upstream is invalid' '
test_cmp expected actual
 '
 
+test_expect_success 'Check that :gone produces expected results' '
+   cat >expected <<-\EOF &&
+gone
+   EOF
+   test_when_finished "git config branch.master.merge refs/heads/master" &&
+   git config branch.master.merge refs/heads/does-not-exist &&
+   git for-each-ref \
+   --format="%(upstream:gone)" \
+   refs/heads >actual &&
+   test_cmp expected actual
+'
+
 test_expect_success 'Check for invalid refname format' '
test_must_fail git for-each-ref --format="%(refname:INVALID)"
 '
-- 
2.9.2

--
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] Pass amend to pre-commit hook

[Øystein Walle]

Jeff King  peff.net> writes:

> 
> On Mon, Sep 14, 2015 at 01:14:20PM +0100, Alan Clucas wrote:
> 
> > Pass a single parameter 'amend' to the pre-commit hook when performing a
> > commit amend.
> 
> I think this is a sensible thing to want, and it has come up a few
> times. I'm not sure why the last round didn't get merged, though. Looks
> like it just slipped through the cracks.
> 
> Here are the relevant threads:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/260122
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/260245
> 
> Looks like there was some question of what to pass in the normal,
> non-amend case. I've added interested parties from the original thread
> to the cc here.
> 
> -Peff
> 

There were so many different ways of solving them that we weren't able
to decide between them:

Assuming we give the string "amend" as the hook's argv[1], what to do
when --amend is not used? We can pass nothing, or the empty string, or
the string "noamend". Then there was the suggestion of exporting
GIT_AMEND=1 or something like that. In any case, what to do when we want
to pass more arguments? Should we let the hook check argv[1] to decide
whether --amend was used, argv[2] to check whether {some scenario here}
is the case? Or make the hook author effectively implement options
parsing?

And then it died out...

In my totally unprofessional opinion anything more complex than maybe
passing "amend" in argv[1] is unwarranted. Since I posted my first patch
almost a year ago there has been no discussion regarding passing other
information along to pre-commit. Furthermore --amend is the only thing I
know of that a pre-commit hook cannot discover on its own. On the other
hand the desire for this has popped up at least twice on #git in the
same time span.

Alan Clucas' solution looks fine to me. It is essentially the same as
mine. But mine had tests and whatnot ;-)

Øsse

[PATCH] fetch: add configuration for making --all default

[Øystein Walle]

Fetching from all remotes by default is useful if you're working on a
repo with few and/or fast remotes. It also lets you fetch from origin
even if the current branch's upstream is elsewhere without specifying it
explicitly.

Signed-off-by: Øystein Walle oys...@gmail.com
---
This is scratching a itch I have. Most of the time I just want to fetch
everything, wherever it may be, and fetch's behavour of using the current
upstream's remote sometimes doesn't read my mind as well as I'd like it to.
It's not particularly useful. But more destructive behaviours (--prune) can
be made default, so think this could be as well.

 Documentation/config.txt|  5 +
 Documentation/fetch-options.txt |  4 +++-
 Documentation/git-fetch.txt |  3 ++-
 builtin/fetch.c | 21 -
 t/t5514-fetch-multiple.sh   | 23 +++
 5 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..c40654f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1170,6 +1170,11 @@ fetch.prune::
If true, fetch will automatically behave as if the `--prune`
option was given on the command line.  See also `remote.name.prune`.
 
+fetch.all::
+   If true, fetch will automatically behave as if the `--all`
+   option was given on the command line uness a remote was given. The
+   default is false.
+
 format.attach::
Enable multipart/mixed attachments as the default for
'format-patch'.  The value can also be a double quoted string
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 45583d8..aa95a30 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,5 +1,7 @@
 --all::
-   Fetch all remotes.
+   Fetch all remotes. This can be configured to be the default behaviour
+   when no remotes are given explicitly. See the `fetch.all` configuration
+   variable in linkgit:git-config[1].
 
 -a::
 --append::
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index e62d9a0..584f3fb 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -36,7 +36,8 @@ there is a remotes.group entry in the configuration file.
 (See linkgit:git-config[1]).
 
 When no remote is specified, by default the `origin` remote will be used,
-unless there's an upstream branch configured for the current branch.
+unless there's an upstream branch configured for the current branch, or the
+`fetch.all` configuration variable is set to true.
 
 The names of refs that are fetched, together with the object names
 they point at, are written to `.git/FETCH_HEAD`.  This information
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8d5b2db..715ea82 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -30,10 +30,12 @@ enum {
 };
 
 static int fetch_prune_config = -1; /* unspecified */
+static int fetch_all_config = -1; /* unspecified */
 static int prune = -1; /* unspecified */
+static int all = -1; /* unspecified */
 #define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
 
-static int all, append, dry_run, force, keep, multiple, update_head_ok, 
verbosity;
+static int append, dry_run, force, keep, multiple, update_head_ok, verbosity;
 static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
 static int tags = TAGS_DEFAULT, unshallow, update_shallow;
 static const char *depth;
@@ -67,6 +69,10 @@ static int git_fetch_config(const char *k, const char *v, 
void *cb)
fetch_prune_config = git_config_bool(k, v);
return 0;
}
+   if (!strcmp(k, fetch.all)) {
+   fetch_all_config = git_config_bool(k, v);
+   return 0;
+   }
return git_default_config(k, v, cb);
 }
 
@@ -1168,7 +1174,7 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
git_config(submodule_config, NULL);
}
 
-   if (all) {
+   if (all == 1) {
if (argc == 1)
die(_(fetch --all does not take a repository 
argument));
else if (argc  1)
@@ -1176,9 +1182,14 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
(void) for_each_remote(get_one_remote_for_fetch, list);
result = fetch_multiple(list);
} else if (argc == 0) {
-   /* No arguments -- use default remote */
-   remote = remote_get(NULL);
-   result = fetch_one(remote, argc, argv);
+   if (fetch_all_config  all != 0) {
+   (void) for_each_remote(get_one_remote_for_fetch, list);
+   result = fetch_multiple(list);
+   } else {
+   /* No arguments and no --all -- use default remote */
+   remote = remote_get(NULL);
+   result = fetch_one(remote, argc, argv

[PATCH v2] fetch: add configuration for making --all default

[Øystein Walle]

Fetching from all remotes by default is useful if you're working on a
repo with few and/or fast remotes. It also lets you fetch from origin
even if the current branch's upstream is elsewhere without specifying it
explicitly.

Signed-off-by: Øystein Walle oys...@gmail.com
---
Thanks for the quick feedback, Remi. There's a fixed version.

 Documentation/config.txt|  5 +
 Documentation/fetch-options.txt |  4 +++-
 Documentation/git-fetch.txt |  3 ++-
 builtin/fetch.c | 21 -
 t/t5514-fetch-multiple.sh   | 23 +++
 5 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..997a8d9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1170,6 +1170,11 @@ fetch.prune::
If true, fetch will automatically behave as if the `--prune`
option was given on the command line.  See also `remote.name.prune`.
 
+fetch.all::
+   If true, fetch will automatically behave as if the `--all`
+   option was given on the command line unless a remote was given. The
+   default is false.
+
 format.attach::
Enable multipart/mixed attachments as the default for
'format-patch'.  The value can also be a double quoted string
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 45583d8..aa95a30 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,5 +1,7 @@
 --all::
-   Fetch all remotes.
+   Fetch all remotes. This can be configured to be the default behaviour
+   when no remotes are given explicitly. See the `fetch.all` configuration
+   variable in linkgit:git-config[1].
 
 -a::
 --append::
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index e62d9a0..584f3fb 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -36,7 +36,8 @@ there is a remotes.group entry in the configuration file.
 (See linkgit:git-config[1]).
 
 When no remote is specified, by default the `origin` remote will be used,
-unless there's an upstream branch configured for the current branch.
+unless there's an upstream branch configured for the current branch, or the
+`fetch.all` configuration variable is set to true.
 
 The names of refs that are fetched, together with the object names
 they point at, are written to `.git/FETCH_HEAD`.  This information
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8d5b2db..715ea82 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -30,10 +30,12 @@ enum {
 };
 
 static int fetch_prune_config = -1; /* unspecified */
+static int fetch_all_config = -1; /* unspecified */
 static int prune = -1; /* unspecified */
+static int all = -1; /* unspecified */
 #define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
 
-static int all, append, dry_run, force, keep, multiple, update_head_ok, 
verbosity;
+static int append, dry_run, force, keep, multiple, update_head_ok, verbosity;
 static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
 static int tags = TAGS_DEFAULT, unshallow, update_shallow;
 static const char *depth;
@@ -67,6 +69,10 @@ static int git_fetch_config(const char *k, const char *v, 
void *cb)
fetch_prune_config = git_config_bool(k, v);
return 0;
}
+   if (!strcmp(k, fetch.all)) {
+   fetch_all_config = git_config_bool(k, v);
+   return 0;
+   }
return git_default_config(k, v, cb);
 }
 
@@ -1168,7 +1174,7 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
git_config(submodule_config, NULL);
}
 
-   if (all) {
+   if (all == 1) {
if (argc == 1)
die(_(fetch --all does not take a repository 
argument));
else if (argc  1)
@@ -1176,9 +1182,14 @@ int cmd_fetch(int argc, const char **argv, const char 
*prefix)
(void) for_each_remote(get_one_remote_for_fetch, list);
result = fetch_multiple(list);
} else if (argc == 0) {
-   /* No arguments -- use default remote */
-   remote = remote_get(NULL);
-   result = fetch_one(remote, argc, argv);
+   if (fetch_all_config  all != 0) {
+   (void) for_each_remote(get_one_remote_for_fetch, list);
+   result = fetch_multiple(list);
+   } else {
+   /* No arguments and no --all -- use default remote */
+   remote = remote_get(NULL);
+   result = fetch_one(remote, argc, argv);
+   }
} else if (multiple) {
/* All arguments are assumed to be remotes or groups */
for (i = 0; i  argc; i++)
diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple.sh
index 4b4b667..e0fb744 100755
--- a/t/t5514-fetch-multiple.sh
+++ b/t

Re: Question on for-each-ref and --contains

[Øystein Walle]

St. Blind st.s.blind at gmail.com writes:

 
 The  git-branch --contains and --merged are not very handy too,
 because the output is not really flexible, and the --merged works
 on HEAD only.
 
 
`git branch --merged foo` will list branches that are merged in the history
of 'foo'. And the equivalent is true for `--contains`. Not sure if that will
solve everything, though.

Øsse



--
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

[BUG] git rebase -X fails with merge-recursive error

[Øystein Walle]

Hi,

I discovered this while rebasing a branch after having converted files
to use LF line endings. I got around the problem by using
--ignore-whitespace but the error still seems strange to me so I'm
reporting it.

The following script is equivalent: it creates a repo with a CRLF file,
creates a feature branch, converts the file and then tries to rebase
the feature branch with git rebase -X ignore-whitespace-at-eol:

git init
echo That's some catch, that Catch-1984 file.txt
unix2dos file.txt
git add file.txt
git commit -m 'Initial commit'
git checkout -b feature
ex -sc 's/1984/22/|x' file.txt
git commit -m Fix literary confusion file.txt
git checkout master
echo '* text=auto'  .gitattributes
dos2unix file.txt
git add .
git commit -m 'CRLF to LF'
git checkout feature
gti config merge.renormalize true
git rebase -X ignore-space-at-eol master

While rebasing the following error appears:

error: addinfo_cache failed for path 'file.txt'

It comes from the git-merge-recursive invocation git-rebase performs[1]
and is printed because make_cache_entry() fails[2]. I also get this
error when using the other 'ignore-*' strategy options, as well as
'theirs'.

At this point file.txt still has its CRLF terminator, but simply:

git add file.txt
git rebase --continue

has the desired effect (as it did in my real life situation). I've
tested this on Git 2.2.0, 2.1.3 and 1.9.0.

I don't know whether this is actually related to git-rebase. It's a way
to reproduce it if nothing else. I haven't tried any experiments with
git-merge-recursive directly, I get the impression I'm not supposed to
since it doesn't have a manpage ;) Interestingly, removing the creation
of .gitattributes makes the problem go away.

Additionally, git-merge-recursive exits with status 0. This confuses
git-rebase which will continue and then complain about the state of the
index. (Interestingly, at this point my prompt thingy complains that
.git/rebase-merge/done isn't there).

Regards,
Øsse

[1]: https://github.com/git/git/blob/master/git-rebase--merge.sh#L70
[2]: https://github.com/git/git/blob/master/merge-recursive.c#L209


--
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

[PATCH 0/2] pre-commit hook updates

[Øystein Walle]

The first patch changes t/t7503-pre-commit-hook.sh to use write_script
everywhere, as was suggested by Jeff King in the discussion of the
previous patch.

The second patch is v2 of the patch I sent earlier. I've incorporated
Eric Sunshine's suggestions. I didn't do enough digging; I found
test_expect_failure and assumed this was test_expect_success's twin
brother, but it marked stuff as known breakages so I went with the '!'.
I also found it a bit strange that test_must_fail has a different
signature (to the extent a shell function has one at all). Is my use of
test_must_fail correct?

I agree with Junio Hamano that it's better to provide no argument at all
rather than an empty one. I also agree with Jeff King that noamend is
better than an empty argument. I went with the second one since Jeff
seemed to get the last word :)

I'm not sure I like the ternary inside the function call like that, but
I went with it because it gave the smallest footprint (which is probably
not a good argument). I suppose I could have done:

if (amend)
hook_arg1 = amend
else
hook_arg1 = noamend
...
... run_commit_hook(use_editor, index_file, pre-commit, hook_arg1, NULL);

or create a hook_amend variable.

I'm happy to send a v3.

Øystein Walle (2):
  t7503: use write_script to generate hook scripts
  commit: inform pre-commit that --amend was used

 Documentation/githooks.txt |  3 ++-
 builtin/commit.c   |  3 ++-
 t/t7503-pre-commit-hook.sh | 20 ++--
 3 files changed, 18 insertions(+), 8 deletions(-)

-- 
2.2.0.rc2.23.gca0107e

--
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

[PATCH 1/2] t7503: use write_script to generate hook scripts

[Øystein Walle]

Signed-off-by: Øystein Walle oys...@gmail.com
---
 t/t7503-pre-commit-hook.sh | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
index 984889b..99ed967 100755
--- a/t/t7503-pre-commit-hook.sh
+++ b/t/t7503-pre-commit-hook.sh
@@ -24,8 +24,7 @@ test_expect_success '--no-verify with no hook' '
 HOOKDIR=$(git rev-parse --git-dir)/hooks
 HOOK=$HOOKDIR/pre-commit
 mkdir -p $HOOKDIR
-cat  $HOOK EOF
-#!/bin/sh
+write_script $HOOK EOF
 exit 0
 EOF
 chmod +x $HOOK
@@ -47,8 +46,7 @@ test_expect_success '--no-verify with succeeding hook' '
 '
 
 # now a hook that fails
-cat  $HOOK EOF
-#!/bin/sh
+write_script $HOOK EOF
 exit 1
 EOF
 
@@ -88,8 +86,7 @@ chmod +x $HOOK
 
 # a hook that checks $GIT_PREFIX and succeeds inside the
 # success/ subdirectory only
-cat  $HOOK EOF
-#!/bin/sh
+write_script $HOOK EOF
 test \$GIT_PREFIX = success/
 EOF
 
-- 
2.2.0.rc3

--
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

[PATCH 2/2] commit: inform pre-commit that --amend was used

[Øystein Walle]

When a commit is amended a pre-commit hook that verifies the commit's
contents might not find what it's looking for if it looks at the
differences against HEAD when HEAD~1 might be more appropriate. Inform
the commit hook that --amend is being used so that hook authors can do
e.g.

if test $1 = amend; then
...
else
...
fi

to handle these situations.

Signed-off-by: Øystein Walle oys...@gmail.com
---
 Documentation/githooks.txt |  3 ++-
 builtin/commit.c   |  3 ++-
 t/t7503-pre-commit-hook.sh | 11 +++
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 9ef2469..fb3e71e 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -73,7 +73,8 @@ pre-commit
 ~~
 
 This hook is invoked by 'git commit', and can be bypassed
-with `--no-verify` option.  It takes no parameter, and is
+with `--no-verify` option.  It takes one parameter which is amend if
+`--amend` was used when committing and noamend if not. It is
 invoked before obtaining the proposed commit log message and
 making a commit.  Exiting with non-zero status from this script
 causes the 'git commit' to abort.
diff --git a/builtin/commit.c b/builtin/commit.c
index e108c53..f9e5d27 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -694,7 +694,8 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
/* This checks and barfs if author is badly specified */
determine_author_info(author_ident);
 
-   if (!no_verify  run_commit_hook(use_editor, index_file, pre-commit, 
NULL))
+   if (!no_verify  run_commit_hook(use_editor, index_file, pre-commit,
+ amend ? amend : noamend, NULL))
return 0;
 
if (squash_message) {
diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
index 99ed967..b400afe 100755
--- a/t/t7503-pre-commit-hook.sh
+++ b/t/t7503-pre-commit-hook.sh
@@ -133,4 +133,15 @@ test_expect_success 'check the author in hook' '
git show -s
 '
 
+# a hook that checks if amend is passed as an argument
+write_script $HOOK EOF
+test \$1 = amend
+EOF
+
+test_expect_success 'check that amend argument is given' '
+   git commit --amend --allow-empty
+'
+
+test_must_fail git commit --allow-empty
+
 test_done
-- 
2.2.0.rc3

--
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

[PATCH] commit: inform pre-commit if --amend is used

[Øystein Walle]

When a commit is amended a pre-commit hook that verifies the commit's
contents might not find what it's looking for if for example it looks at
the differences against HEAD when HEAD~1 might be more appropriate.
Inform the commit hook that --amend is being used so that hook authors
can do e.g.

if test $1 = amend
then
...
else
...
fi

to handle these situations.

Signed-off-by: Øystein Walle oys...@gmail.com
---
 Documentation/githooks.txt |  3 ++-
 builtin/commit.c   |  3 ++-
 t/t7503-pre-commit-hook.sh | 14 ++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 9ef2469..e113027 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -73,7 +73,8 @@ pre-commit
 ~~
 
 This hook is invoked by 'git commit', and can be bypassed
-with `--no-verify` option.  It takes no parameter, and is
+with `--no-verify` option.  It takes one parameter which is amend if
+`--amend` was used when committing and empty otherwise. It is
 invoked before obtaining the proposed commit log message and
 making a commit.  Exiting with non-zero status from this script
 causes the 'git commit' to abort.
diff --git a/builtin/commit.c b/builtin/commit.c
index e108c53..e38dd4a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -694,7 +694,8 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
/* This checks and barfs if author is badly specified */
determine_author_info(author_ident);
 
-   if (!no_verify  run_commit_hook(use_editor, index_file, pre-commit, 
NULL))
+   if (!no_verify  run_commit_hook(use_editor, index_file,
+ pre-commit, amend ? amend : , 
NULL))
return 0;
 
if (squash_message) {
diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
index 984889b..be97676 100755
--- a/t/t7503-pre-commit-hook.sh
+++ b/t/t7503-pre-commit-hook.sh
@@ -136,4 +136,18 @@ test_expect_success 'check the author in hook' '
git show -s
 '
 
+# a hook that checks if amend is passed as an argument
+cat  $HOOK EOF
+#!/bin/sh
+test \$1 = amend
+EOF
+
+test_expect_success 'check that amend argument is given' '
+   git commit --amend --allow-empty
+'
+
+test_expect_success 'check that amend argument is NOT given' '
+   ! git commit --allow-empty
+'
+
 test_done
-- 
2.0.3

--
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 v4] completion: ignore chpwd_functions when cding on zsh

[Øystein Walle]

Brandon Turner bt at brandonturner.net writes:

 
 On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano gitster at pobox.com wrote:
  Actually the patch was slightly wrong.  It did not quite matter as
  cd '' is a no-op, but git -C '' cmd is not that lenient (which
  may be something we may want to fix) and breaks t9902 by exposing
  an existing breakage in the callchain.
 
  Here is a replacement.
 
 I did some more testing on this iteration as well - looks good. 
 

Sorry, for the late reply, guys...

I've tested it too and it seems to work just fine.

As for my comments about using $=2 instead of $2: When zsh runs through
this code it does so while emulating ksh. Thus the reliance on splitting
unquoted expansions is not a problem. I was unaware of this until ten
minutes ago. 

Øsse


--
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 v3] completion: ignore chpwd_functions when cding on zsh

[Øystein Walle]

Brandon Turner bt at brandonturner.net writes:

 
 Software, such as RVM (ruby version manager), may set chpwd functions
 that result in an endless loop when cding.  chpwd functions should be
 ignored.

Now that it has moved to the zsh-specific script you can achieve this more
simply by using cd -q.

Øsse

--
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 v3] completion: ignore chpwd_functions when cding on zsh

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
 Øystein Walle oystwa at gmail.com writes:
 
  Brandon Turner bt at brandonturner.net writes:
 
  
  Software, such as RVM (ruby version manager), may set chpwd functions
  that result in an endless loop when cding.  chpwd functions should be
  ignored.
 
  Now that it has moved to the zsh-specific script you can achieve this more
  simply by using cd -q.
 
 
 
 Is the way we defeat CDPATH for POSIX shells sufficient, or does it
 also need to be customized for zsh?
 

That is fine (to the best of my knowledge). If the current directory is not
part of CDPATH at all then Zsh will try the current directory first, so if
anything Zsh should fail more seldom here than others (but not *never*, so
the hack is still needed).

Øsse

--
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 v4] completion: ignore chpwd_functions when cding on zsh

[Øystein Walle]

Brandon Turner bt at brandonturner.net writes:

 +__git_ls_files_helper ()
 +{
 + (
 + test -n ${CDPATH+set}  unset CDPATH
 + cd -q $1
 + if [ $2 == --committable ]; then
 + git diff-index --name-only --relative HEAD
 + else
 + # NOTE: $2 is not quoted in order to support multiple 
 options
 + git ls-files --exclude-standard $2
 + fi
 + ) 2/dev/null
 +}
 +

(Sorry about this; I should've caught it the first time around). Zsh
does not split string expansions into several words by default. For
example:

$ str1='hello world'
$ str2='goodbye moon'
$ printf '%s\n' $str1 $str2
hello world
goodbye moon

This can be enabled on a per-expansion basis by using = while
expanding: 

$ str1='hello world'
$ str2='goodbye moon'
$ printf '%s\n' $=str1 $str2
hello
world
goodbye moon

So the $2 in your patch should be $=2.

BUT: Over a year ago Git learned the -C argument. Couldn't we use that
here? That way we would not have to unset CDPATH and can get rid of the
subshell and cd -q. If we allow the other functions to use several
arguments to pass options with we can get rid of the whole seperation
between bash and zsh altogether.

Øsse




--
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: [BUG (maybe)] git rev-parse --verify --quiet isn't quiet

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
 Junio C Hamano gitster at pobox.com writes:
 
  I would suspect that this may be fine.
 
  rev-parse --verify makes sure the named object exists, but in this
  case  at {u} does not even name any object, does it?
 
 Hmph, but rev-parse --verify no-such-branch does *not* name any
 object, we would want to see it barf, and we probably would want to
 be able to squelch the message.  So it is unclear if  at {u} barfing is
 a good idea.
 

That was my counter-argument :) The vibe I get from rev-parse --verify
--quiet is that it should handle anything.

 
 What is the reason why it is inpractical to pass 'quiet' down the
 callchain?
 

Maybe I'm missing something obvious, but wouldn't that mean changing the
signature of 9 different functions, and consequently all of their calls
throughout Git? 

That's perhaps not a good argument. Who cares whether a diff is small or
large if it fixes a bug properly?  But most (or all) of those functions
do not concern themselves with printing stuff so maybe an additional
quiet? argument would look foreign in most places and make the code
harder to read.

Øsse



--
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: stash-p broken?

[Øystein Walle]

brian m. carlson sandals at crustytoothpaste.net writes:

 
 On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote:
  Sorry for error -- I meant: git stash list -p, not git stash -p.
  
  On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol michael-spam at
migdol.net wrote:
   I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04.  After doing so,
   git stash -p stopped working.  (It apparently is ignoring the -p
   parameter).  I'm not sure what version I was using previously, but after
   some experimentation, I see that:
  
   version 1.7.12.2 : stash -p DOES work
   version 1.9.3 : doesn't work
   version 2.0.3 : doesn't work
 
 Under the hood, we do:
 
   git log --format=%gd: %gs -g $ at  refs/stash --
 
 But it looks like git log ignores -p if -g is provided.
 

Unfortunately I don't have much to add...

I have a weird issue where `git stash list -p` does not show a diff, but
`~/usr/bin/git stash list -p` does, for the exact same version of Git.
However, the underlying command does not show a diff in either case,
even though I can tell that is the one being executed (with set -x
inserted into .../libexec/git-stash).

This is so weird that I think it's my system's fault. I have to do some
more digging.

Øsse


--
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: Git autocorrect bug

[Øystein Walle]

David Turner dturner at twopensource.com writes:

 
 $ cd [some existing git repo]
 $ git git foo
 WARNING: You called a Git command named 'git', which does not exist.
 Continuing under the assumption that you meant 'init'
 in 0.1 seconds automatically...
 fatal: internal error: work tree has already been set
 Current worktree: /home/dturner/git
 New worktree: /home/dturner/git/foo
 
 (I am extremely unlikely to fix this bug myself, since it only arises in
 very rare circumstances).
 
 

You have help.autocorrect enabled. Then this is expected behaviour (it
doesn't seem out of place to me at least)

Running `git config --unset help.autocorrect` should disable it. It
may be that you enabled it for only one repo by accident.

Øsse


--
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: Git autocorrect bug

[Øystein Walle]

David Turner dturner at twopensource.com writes:

 
 (I am extremely unlikely to fix this bug myself, since it only arises in
 very rare circumstances).


I see now that `git init foo` and `git git foo` (with git corrected
to init) behave differently. Is this the bug you're referring to? 


--
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

[PATCH] config: respect '~' and '~user' in mailmap.file

[Øystein Walle]

git_config_string() does not handle '~' and '~user' as part of the
value. Using git_config_pathname() fixes this.

Signed-off-by: Øystein Walle oys...@gmail.com
---
 config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.c b/config.c
index 314d8ee..ec7af5f 100644
--- a/config.c
+++ b/config.c
@@ -963,7 +963,7 @@ static int git_default_push_config(const char *var, const 
char *value)
 static int git_default_mailmap_config(const char *var, const char *value)
 {
if (!strcmp(var, mailmap.file))
-   return git_config_string(git_mailmap_file, var, value);
+   return git_config_pathname(git_mailmap_file, var, value);
if (!strcmp(var, mailmap.blob))
return git_config_string(git_mailmap_blob, var, value);
 
-- 
2.0.0.rc4

--
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] config: respect '~' and '~user' in mailmap.file

[Øystein Walle]

Jeff King peff at peff.net writes:

 
 Makes sense. Curious if there was a reason we did not use it in the
 first place, I looked at the history. The reason is that mailmap.file
 was added in d551a48 (2009-02-08) and git_config_pathname came months
 later in 395de25 (2009-11-17). Retro-fitting it now should not cause a
 problem for any sane paths. So:
 
 Reviewed-by: Jeff King peff at peff.net
 
 -Peff

 
Thanks for the review. 

I saw it was added back in 2009 but didn't give it much thought other
than Oh, that bug has been there for a long time! :) (Not that this is
a serious bug as such, more than a slight inconsistency in how the path
is handled compared to other config values expected to be paths)

Øsse




--
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 v7 00/11] Add interpret-trailers builtin

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
   ...
 
 is easier to read and maintain if written like so (with using HT
 properly---our MUAs may damage it and turn the indentation into
 spaces):
 
   ... 
   sed -e s/ Z$/ / expect -\EOF 
 Fixes: Z
 Acked-by= Z
 Reviewed-by: Z
 Signed-off-by: Z
   EOF
   ...
 

How about:

   printf '%s: \n' Fixes Acked-by Reviewed-by Signed-off-by  expect

This solution scores high marks in both readability and maintainability
in my mind.

--
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] for-each-ref: add option to omit newlines

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
 I would rather see us go in the direction to add -z output option,
 which is what everybody else that produces NUL terminated entries in
 our suite of subcommands does.
 

I agree that -z would help in this case and I very much appreciate that
option when using diff --name-only, ls-files, etc.

However, when specifying a format string it's just a matter of ending
the format string in '%00' and you're good to go. But then you get the
null byte *and* a newline. And with your proposal there would be no way
of saying you want neither.

I expected the output to be formatted according to a (repetition of) the
format string, not some variation of it that I couldn't opt out of. But
I see that git-log also shows this behavior and already has a -z option,
so I guess that's fairly ingrained.

Maybe it's just me? In that case I've no problem with throwing in the
towel.

Øsse


--
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] for-each-ref: add option to omit newlines

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
 I very well understand that.  All other commands that support -z
 to give you NUL terminated output do not consider that a downside.
 Why should for-each-ref be special?
 

After I discovered log also has this there is nothing special about
for-each-ref any longer, so my patch as-is would only make things less
consistent. What is special is that they give you the option of
supplying a format string.

ls-files, diff and others print a specific list of items (paths, shas,
...) and there's no question about how they are presented other than the
delimiter between each item, to which a selection of either a newline or
a null byte is plenty.

With log, for-each-ref and rev-list (any others?) that sort of breaks
down. With the format string you're given the power to make the command
print basically anything you like, however you like; no longer only a
question of mere delimiters. It only makes sense then (to me, at least)
that the command does not meddle with the format the user has chosen.

Maybe it's all subjective... I'm okay with just leaving things as they
are. There are ways around 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

[PATCH] for-each-ref: add option to omit newlines

[Øystein Walle]

Even when having specified a format string for-each-ref still prints a
newline after printing each ref according to the format. This breaks
splitting the output on newlines, for example.

Signed-off-by: Øystein Walle oys...@gmail.com
---
I was somewhat surprised by this behaviour; I expected to be in full control of
the output but I could not get rid of the newlines.

As far as I'm *personally* concerned the line putchar('\n'); could just as
well be removed completely and an '\n' appended to the default format string.
But since this command (and this behaviour) as been around since 2006 I assume
that it's in Git's best interest to not change the default behaviour. Hence the
introduction of this option. Although I was taken aback by this behaviour, is
it patch-worthy? The fix isn't very pretty.

On to the patch itself: I contemplated putting '\n' in the default format and
removing it if -n was given, which would get rid of the need to pass an exta
argument to show_ref(). But that means we would need to *insert it* when a
format is given and -n is not...

I've changed how the default format is assigned so that we can check if it's
NULL after option parsing to spit out an error. Alternatively we could just
allow it.

 Documentation/git-for-each-ref.txt |  3 +++
 builtin/for-each-ref.c | 20 +++-
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 4240875..805914a 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -62,6 +62,9 @@ OPTIONS
the specified host language.  This is meant to produce
a scriptlet that can directly be `eval`ed.
 
+-n::
+--no-newlines::
+   Do not print a newline after printing each formatted ref.
 
 FIELD NAMES
 ---
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 51798b4..32d6b12 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -998,7 +998,8 @@ static void emit(const char *cp, const char *ep)
}
 }
 
-static void show_ref(struct refinfo *info, const char *format, int quote_style)
+static void show_ref(struct refinfo *info, const char *format, int quote_style,
+int no_newlines)
 {
const char *cp, *sp, *ep;
 
@@ -1023,7 +1024,8 @@ static void show_ref(struct refinfo *info, const char 
*format, int quote_style)
resetv.s = color;
print_value(resetv, quote_style);
}
-   putchar('\n');
+   if (!no_newlines)
+   putchar('\n');
 }
 
 static struct ref_sort *default_sort(void)
@@ -1067,9 +1069,9 @@ static char const * const for_each_ref_usage[] = {
 int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
 {
int i, num_refs;
-   const char *format = %(objectname) %(objecttype)\t%(refname);
+   const char *format = NULL;
struct ref_sort *sort = NULL, **sort_tail = sort;
-   int maxcount = 0, quote_style = 0;
+   int maxcount = 0, quote_style = 0, no_newlines = 0;
struct refinfo **refs;
struct grab_ref_cbdata cbdata;
 
@@ -1082,6 +1084,8 @@ int cmd_for_each_ref(int argc, const char **argv, const 
char *prefix)
N_(quote placeholders suitably for python), 
QUOTE_PYTHON),
OPT_BIT(0 , tcl,  quote_style,
N_(quote placeholders suitably for tcl), QUOTE_TCL),
+   OPT_BOOL('n' , no-newlines,  no_newlines,
+   N_(do not output a newline after each ref)),
 
OPT_GROUP(),
OPT_INTEGER( 0 , count, maxcount, N_(show only n matched 
refs)),
@@ -1100,6 +1104,12 @@ int cmd_for_each_ref(int argc, const char **argv, const 
char *prefix)
error(more than one quoting style?);
usage_with_options(for_each_ref_usage, opts);
}
+   if (no_newlines  !format) {
+   error(--no-newlines without --format does not make sense);
+   usage_with_options(for_each_ref_usage, opts);
+   }
+   if (!format)
+   format = %(objectname) %(objecttype)\t%(refname);
if (verify_format(format))
usage_with_options(for_each_ref_usage, opts);
 
@@ -1120,6 +1130,6 @@ int cmd_for_each_ref(int argc, const char **argv, const 
char *prefix)
if (!maxcount || num_refs  maxcount)
maxcount = num_refs;
for (i = 0; i  maxcount; i++)
-   show_ref(refs[i], format, quote_style);
+   show_ref(refs[i], format, quote_style, no_newlines);
return 0;
 }
-- 
1.8.5

--
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] for-each-ref: add option to omit newlines

[Øystein Walle]

Øystein Walle oystwa at gmail.com writes:

 
 splitting the output on newlines, for example.
 

Ugh, I mean on null bytes, naturally.

Øsse.


--
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: git best strategy for two version development

[Øystein Walle]

Carlos Pereira jose.carlos.pereira at ist.utl.pt writes:

 
 Hello,
 
 I am a git and CVS newbie, I bought and red most of the excellent Pro 
 Git book by Scott Chacon, but I still have a doubt. I have a package 
 that I distribute in two versions differing only in one library: 
 version_A uses this library, version_B uses my own code to replace it. 
 For strategic reasons I want to keep it this way for the time being. 
 Both versions have the same documentation, the same data files, and 99% 
 of the source code is the same (a few makefile changes, two additional 
 files in version_B and some minor changes: a diff -r has only 170 
 lines). The question is what is the best strategy to manage a situation 
 like this with git?
 
 Shall I maintain two different repositories? I don't think so...
 

If the changes are as small as you say, is it an option to use just one
branch but have two possible build configurations? That seems like the
easiest way to do it, in my opinion. E.g.:

$ make LIB=versionA
$ make LIB=versionB

Consider the above as pseudo-code, though. I don't know what build
system you use or even if your package is even something that is
built. But you get the idea.

Øsse



--
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

[PATCH] Documentation: fix typos in man pages

[Øystein Walle]

Signed-off-by: Øystein Walle oys...@gmail.com
---

In July I sent in some typo fixes but it halted in a discussion on UK
vs. US English and so forth ($gmane/231331). There were some actual typo
fixes in there though (in addition to the opinionated typo fixes).

Powering up my old laptop for the first time in months I noticed that I
had them idling in a branch, and that incidentally none of them has been
fixed. Hopefully I've managed to seperate the genuine typo fixes from
the rest.

 Documentation/git-clone.txt   | 2 +-
 Documentation/git-diff.txt| 2 +-
 Documentation/gitcli.txt  | 2 +-
 Documentation/githooks.txt| 2 +-
 Documentation/gitweb.conf.txt | 4 ++--
 Documentation/user-manual.txt | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 4987857..bf3dac0 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -208,7 +208,7 @@ objects from the source repository into a pack in the 
cloned repository.
 --separate-git-dir=git dir::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
-   then make a filesytem-agnostic Git symbolic link to there.
+   then make a filesystem-agnostic Git symbolic link to there.
The result is Git repository can be separated from working
tree.
 
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 33fbd8c..56fb7e5 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -44,7 +44,7 @@ two blob objects, or changes between two files on disk.
commit relative to the named commit.  Typically you
would want comparison with the latest commit, so if you
do not give commit, it defaults to HEAD.
-   If HEAD does not exist (e.g. unborned branches) and
+   If HEAD does not exist (e.g. unborn branches) and
commit is not given, it shows all staged changes.
--staged is a synonym of --cached.
 
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 3f33ca5..1c3e109 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -28,7 +28,7 @@ arguments.  Here are the rules:
they can be disambiguated by placing `--` between them.
E.g. `git diff -- HEAD` is, I have a file called HEAD in my work
tree.  Please show changes between the version I staged in the index
-   and what I have in the work tree for that file. not show difference
+   and what I have in the work tree for that file, not show difference
between the HEAD commit and the work tree as a whole.  You can say
`git diff HEAD --` to ask for the latter.
 
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index d48bf4d..d954bf6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -251,7 +251,7 @@ three parameters:
 
  - the name of the ref being updated,
  - the old object name stored in the ref,
- - and the new objectname to be stored in the ref.
+ - and the new object name to be stored in the ref.
 
 A zero exit from the update hook allows the ref to be updated.
 Exiting with a non-zero status prevents 'git-receive-pack'
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index db4154f..952f503 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -630,13 +630,13 @@ need to set this element to empty list i.e. `[]`.
 
 override::
If this field has a true value then the given feature is
-   overriddable, which means that it can be configured
+   overridable, which means that it can be configured
(or enabled/disabled) on a per-repository basis.
 +
 Usually given feature is configurable via the `gitweb.feature`
 config variable in the per-repository Git configuration file.
 +
-*Note* that no feature is overriddable by default.
+*Note* that no feature is overridable by default.
 
 sub::
Internal detail of implementation.  What is important is that
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 248dcab..d4f9804 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3795,7 +3795,7 @@ like so:
 $ git update-index filename
 -
 
-but to avoid common mistakes with filename globbing etc, the command
+but to avoid common mistakes with filename globbing etc., the command
 will not normally add totally new entries or remove old entries,
 i.e. it will normally just update existing cache entries.
 
-- 
1.8.5

--
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

[PATCH v3] stash: handle specifying stashes with spaces

[Øystein Walle]

When trying to pop/apply a stash specified with an argument containing
spaces git-stash will throw an error:

$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}

This happens because word splitting is used to count non-option
arguments. Make use of rev-parse's --sq option to quote the arguments
for us to ensure a correct count. Add quotes where necessary.

Also add a test that verifies correct behaviour.

Helped-by: Thomas Rast t...@thomasrast.ch
Signed-off-by: Øystein Walle oys...@gmail.com
---
v3 uses the same eval/--sq technique as v2, suggested by Thomas Rast.
This is basically a resend except that I added a missing '' in the
test that Eric Sunshine noticed when reading v1.

 git-stash.sh | 14 +++---
 t/t3903-stash.sh | 11 +++
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..f0a94ab 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -358,7 +358,7 @@ parse_flags_and_rev()
i_tree=
u_tree=
 
-   REV=$(git rev-parse --no-flags --symbolic $@) || exit 1
+   REV=$(git rev-parse --no-flags --symbolic --sq $@) || exit 1
 
FLAGS=
for opt
@@ -376,7 +376,7 @@ parse_flags_and_rev()
esac
done
 
-   set -- $REV
+   eval set -- $REV
 
case $# in
0)
@@ -391,13 +391,13 @@ parse_flags_and_rev()
;;
esac
 
-   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
+   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
reference=$1
die $(eval_gettext \$reference is not valid reference)
}
 
-   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
-   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2/dev/null) 
+   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
+   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 
2/dev/null) 
s=$1 
w_commit=$1 
b_commit=$2 
@@ -408,8 +408,8 @@ parse_flags_and_rev()
test $ref_stash = $(git rev-parse --symbolic-full-name ${REV%@*}) 

IS_STASH_REF=t
 
-   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
-   u_tree=$(git rev-parse $REV^3: 2/dev/null)
+   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
+   u_tree=$(git rev-parse $REV^3: 2/dev/null)
 }
 
 is_stash_like()
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..7eb011c 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
 '
 
+test_expect_success 'handle stash specification with spaces' '
+   git stash clear 
+   echo pig  file 
+   git stash 
+   test_tick 
+   echo cow  file 
+   git stash 
+   git stash apply stash@{Thu Apr 7 15:17:13 2005 -0700} 
+   grep pig file
+'
+
 test_done
-- 
1.8.5

--
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 v3] stash: handle specifying stashes with spaces

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 
 Thomas Rast tr at thomasrast.ch writes:
 
  Junio C Hamano gitster at pobox.com writes:
 
 
  This is brittle.  If new tests are added before this, the test_tick
  will give you different timestamp and this test will start failing.
 
  Perhaps grab the timestamp out of the stash that was created [...]
 
  Hmm, now that I stare at this, why not simply use something like
 
git stash apply stash at { 0 }
 
  It seems to refer to the same as stash at {0} as one would expect, while
  still triggering the bug with unpatched git-stash.
 
 Yeah, that is fine as well.  For the record, here is what I
 tentatively queued.
 

I completely agree that it's brittle. I mentioned it when I submitted v1
but at the time it didn't occur to me that new tests might be added
before it. And of course I agree with your proposed changes to the test.
I must say I like Thomas' solution because of its simplicity and the
whole test could be made much shorter: just create stash and try to pop
it.

But it's seems the spaces trigger some other way of interpreting the
selector. In my git.git, git rev-parse HEAD{0} gives me the same result
as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different. Is this
intentional? If not, can this impact the reliability of the test if we
use HEAD@{ 0 } ?

Thanks for queuing!

Regards,
Øsse


--
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] Improve user-manual html and pdf formatting

[Øystein Walle]

Jonathan Nieder jrnieder at gmail.com writes:

 
 Hi,
 
 Thomas Ackermann wrote:
 
  --- a/Documentation/user-manual.txt
  +++ b/Documentation/user-manual.txt
   at  at  -1,5 +1,5  at  at 
  -Git User Manual
  +#65279;Git User Manual
 
 Why?
 
 Puzzled,
 Jonathan
 

That's a Unicode Byte Order Mark. In UTF-8 it serves no purpose except
to indicate that a file is in fact UTF-8. A job which most editors
don't need help with.

See http://en.wikipedia.org/wiki/Byte_order_mark

Øsse

--
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] Improve user-manual html and pdf formatting

[Øystein Walle]

Andreas Schwab schwab at linux-m68k.org writes:

  That's a Unicode Byte Order Mark.
 
 No, its an ampersand, a hash, a number and a semicolon.  Definitely not
 a BOM.
 
 Andreas.
 

You're right, of course :) I was a bit hasty.

#65279; is a HTML entity (or at least something like looks like one) for the
character U+FEFF, which also serves as the Byte Order Mark. I assume the
entity was added to the file by mistake.

Øsse

--
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: git stash doesn't honor --work-tree or GIT_WORK_TREE

[Øystein Walle]

Duy Nguyen pclouds at gmail.com writes:

 It should. At the beginning of cmd_rev_parse(), setup_git_directory()
 is called, which will check and follow all GIT_* or their command line
 equivalent. I'll look into this some time later.

I think I was wrong and rev-parse --is-inside-work-tree *does* honor
them. It prints 'false'. If it hadn't honored them it would have printed
fatal: Not a git repository (...).

Øsse


--
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 v2] stash: handle specifying stashes with spaces

[Øystein Walle]

Thomas Rast tr at thomasrast.ch writes:

 I wonder what we would lose by dropping the --symbolic in the line I
 quoted above (which is the second parsing pass), so that it resolves
 to a SHA1.  We would gain some robustness, as I'm not sure $REV:
 works correctly in the face of weird revision expressions like
 :/foo.

If I drop --symbolic then all hell breaks loose. Removing it very
naively led to 29 failed tests. I managed to get that down quite a bit
though.

After the function ends $REV is supposed to expand to a symbolic
reference, and the test for whether the given argument is a valid stash
reference is to see if running `git rev-parse --symbolic-full-name
${REV%@*}` expands to 'refs/stash' or not. So we have to do both with
and without --symbolic and keep both around. For example `git stash
drop` had problems because git-reflog doesn't let you remove entries in
the log by SHA1:


$ git reflog delete --updateref --rewrite $(git rev-parse stash@{0})
error: Not a reflog: 418af27beea220ad8a2fd3b8286959b1ec9c8852

I think a not entirely accurate but succinct way of putting it is that
if foo is a valid ref or valid entry in the reflog then

git rev-parse --symbolic $(git rev-parse foo) 

does *not* output 'foo' but the SHA1 of 'foo'. So we cannot simply
convert everything to hashes and proceed from there.

Øsse




--
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: git stash doesn't honor --work-tree or GIT_WORK_TREE

[Øystein Walle]

Aaron Brooks aaron at brooks1.net writes:

 
 Unlike other commands, git stash doesn't work outside of the worktree,
 even when --work-tree is specified:
 
 (...)
 
 It looks like the require_work_tree function should check the
 environment variables in addition to the status of the PWD (via
 git-rev-parse).
 
 Having looked through several of the other git-*.sh scripts, I think
 other shell based git commands will have similar problems.
 
 Thanks,
 
 Aaron
 

The environment variables are properly exported. I verified this by
adding 'echo $GIT_WORK_TREE; echo $GIT_DIR' at the top of git-stash.sh.
So these should propagate to child gits just fine, and so it shouldn't
be necessary to test them explicitly.

The problem seems to be that git rev-parse --is-inside-work-tree does
not honor these. In fact it doesn't even honor --git-dir or --work-tree.
Judging by the name this may be intentional.

In the mean time, if you are able to use Git 1.8.5, `git -C test-repo
stash` will work just fine.

Øsse


--
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

[PATCH] stash: handle specifying stashes with spaces

[Øystein Walle]

When trying to pop/apply a stash specified with an argument containing
spaces the user will see an error:

$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}

This happens because word splitting is used to count non-option
arguments. Instead shift the positional arguments as the options are
processed; the number of arguments left is then the number we're after.
Add quotes where necessary.

Also add a test that verifies correct behaviour.

Signed-off-by: Øystein Walle oys...@gmail.com
---
This is perhaps an esoteric use case but it's still worth fixing in my opinion.
It also saves a fork/exec so I see it as a win-win :)

Comments welcome, of course. Especially on the test. I couldn't use a relative
date spec since the commits and stashes are made with bogus timestamps and the
spec is compared to the local time. It looks a bit icky the way it's written
now.

 git-stash.sh | 20 ++--
 t/t3903-stash.sh | 11 +++
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..0a48d42 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -358,26 +358,25 @@ parse_flags_and_rev()
i_tree=
u_tree=
 
-   REV=$(git rev-parse --no-flags --symbolic $@) || exit 1
-
FLAGS=
for opt
do
case $opt in
-q|--quiet)
GIT_QUIET=-t
+   shift
;;
--index)
INDEX_OPTION=--index
+   shift
;;
-*)
FLAGS=${FLAGS}${FLAGS:+ }$opt
+   shift
;;
esac
done
 
-   set -- $REV
-
case $# in
0)
have_stash || die $(gettext No stash found.)
@@ -387,17 +386,18 @@ parse_flags_and_rev()
:
;;
*)
-   die $(eval_gettext Too many revisions specified: 
\$REV)
+   refs=$*
+   die $(eval_gettext Too many revisions specified: 
\$refs)
;;
esac
 
-   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
+   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
reference=$1
die $(eval_gettext \$reference is not valid reference)
}
 
-   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
-   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2/dev/null) 
+   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
+   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 
2/dev/null) 
s=$1 
w_commit=$1 
b_commit=$2 
@@ -408,8 +408,8 @@ parse_flags_and_rev()
test $ref_stash = $(git rev-parse --symbolic-full-name ${REV%@*}) 

IS_STASH_REF=t
 
-   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
-   u_tree=$(git rev-parse $REV^3: 2/dev/null)
+   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
+   u_tree=$(git rev-parse $REV^3: 2/dev/null)
 }
 
 is_stash_like()
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..0568ec5 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
 '
 
+test_expect_success 'handle stash specification with spaces' '
+   git stash clear
+   echo pig  file 
+   git stash 
+   test_tick 
+   echo cow  file 
+   git stash 
+   git stash apply stash@{Thu Apr 7 15:17:13 2005 -0700} 
+   grep pig file
+'
+
 test_done
-- 
1.8.5.1.g359345f

--
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

[PATCH v2] stash: handle specifying stashes with spaces

[Øystein Walle]

When trying to pop/apply a stash specified with an argument containing
spaces git-stash will throw an error:

$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}

This happens because word splitting is used to count non-option
arguments. Make use of rev-parse's --sq option to quote the arguments
for us to ensure a correct count. Add quotes where necessary.

Also add a test that verifies correct behaviour.

Helped-by: Thomas Rast t...@thomasrast.ch
Signed-off-by: Øystein Walle oys...@gmail.com
---
Many thanks to Thomas Rast for helping me with this approach.

 git-stash.sh | 14 +++---
 t/t3903-stash.sh | 11 +++
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..f0a94ab 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -358,7 +358,7 @@ parse_flags_and_rev()
i_tree=
u_tree=
 
-   REV=$(git rev-parse --no-flags --symbolic $@) || exit 1
+   REV=$(git rev-parse --no-flags --symbolic --sq $@) || exit 1
 
FLAGS=
for opt
@@ -376,7 +376,7 @@ parse_flags_and_rev()
esac
done
 
-   set -- $REV
+   eval set -- $REV
 
case $# in
0)
@@ -391,13 +391,13 @@ parse_flags_and_rev()
;;
esac
 
-   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
+   REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
reference=$1
die $(eval_gettext \$reference is not valid reference)
}
 
-   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
-   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2/dev/null) 
+   i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
+   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 
2/dev/null) 
s=$1 
w_commit=$1 
b_commit=$2 
@@ -408,8 +408,8 @@ parse_flags_and_rev()
test $ref_stash = $(git rev-parse --symbolic-full-name ${REV%@*}) 

IS_STASH_REF=t
 
-   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
-   u_tree=$(git rev-parse $REV^3: 2/dev/null)
+   u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
+   u_tree=$(git rev-parse $REV^3: 2/dev/null)
 }
 
 is_stash_like()
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..0568ec5 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
 '
 
+test_expect_success 'handle stash specification with spaces' '
+   git stash clear
+   echo mook  file 
+   git stash 
+   test_tick 
+   echo kleb  file 
+   git stash 
+   git stash apply stash@{Thu Apr 7 15:17:13 2005 -0700} 
+   grep mook file
+'
+
 test_done
-- 
1.8.5.rc0.23.gaa27064.dirty

--
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: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

[Øystein Walle]

Ville Walveranta walveranta at gmail.com writes:

 
 git-rev-parse --is-inside-git-dir outputs fatal: Not a git
 repository (or any of the parent directories): .git, instead of
 false when outside of a git directory.  --is-inside-work-tree
 behaves the same way. Both commands work correctly (i.e. output
 true) when inside a git directory, or inside a work tree,
 respectively.
 
 To test, I installed git 1.8.4.2 initially from
 https://launchpad.net/~git-core/+archive/ppa for Ubuntu 12.04.3, and
 then also compiled it from source, but both seem to behave the same
 way. The problem is not yet present in version 1.7.9.5.
 
 Thanks,
 
 Ville Walveranta


Hi,

I thought I'd try to bisect this but I ended up discovering that I get
the exact same behaviour with both 1.7.9.5 and 1.8.4.2. 1.7.9.5 will
also output 'fatal: ...' like 1.8.4.2 does.

Both version will however behave as expected if you provide --git-dir
and --work-tree:

$ pwd
/home/osse
$ git --version
git version 1.8.4.2
$ git --git-dir=/home/osse/git/.git \
  --work-tree=/home/osse/git\
rev-parse  --is-inside-work-tree
false

Ditto for --is-inside-git-dir.

Incidentally I discovered that the new -C option does *not* behave this
way:

$ git --version
git version 1.8.5.rc0.23.gaa27064
$ git -C /home/osse/git rev-parse --is-inside-work-tree
true

But given that the purpose of the -C option is to make Git behave as if
you were in that directory this is perhaps expected behaviour.

Regards,
Øsse



--
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

[PATCH] Documentation: fix typos in man pages

[Øystein Walle]

Signed-off-by: Øystein Walle oys...@gmail.com
---
I thought I'd take part in the typo fixing frenzy :)

I have some other potential typos lines up. Right now the docs refer to both
'filesystem' and 'file system', as well as both 'testsuite' and 'test suite'. I
think words like these are generally split in English but I'm not sure.

There are also some words that I think look better with with a dash, e.g.
'trade-off'. Should I just send these as a patch too instead of jabbering on
about it?

 Documentation/git-check-ignore.txt | 2 +-
 Documentation/git-clone.txt| 2 +-
 Documentation/git-daemon.txt   | 2 +-
 Documentation/git-diff.txt | 2 +-
 Documentation/gitcli.txt   | 2 +-
 Documentation/githooks.txt | 2 +-
 Documentation/gitweb.conf.txt  | 4 ++--
 Documentation/user-manual.txt  | 2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-check-ignore.txt 
b/Documentation/git-check-ignore.txt
index d2df487..5354301 100644
--- a/Documentation/git-check-ignore.txt
+++ b/Documentation/git-check-ignore.txt
@@ -35,7 +35,7 @@ OPTIONS
Read file names from stdin instead of from the command-line.
 
 -z::
-   The output format is modified to be machine-parseable (see
+   The output format is modified to be machine-parsable (see
below).  If `--stdin` is also given, input paths are separated
with a NUL character instead of a linefeed character.
 
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 450f158..3865658 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -213,7 +213,7 @@ objects from the source repository into a pack in the 
cloned repository.
 --separate-git-dir=git dir::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
-   then make a filesytem-agnostic Git symbolic link to there.
+   then make a filesystem-agnostic Git symbolic link to there.
The result is Git repository can be separated from working
tree.
 
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 223f731..a3283e1 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -189,7 +189,7 @@ Git configuration files in that directory are readable by 
`user`.
service by exiting with a non-zero status (or to allow it by
exiting with a zero status).  It can also look at the $REMOTE_ADDR
and $REMOTE_PORT environment variables to learn about the
-   requestor when making this decision.
+   requester when making this decision.
 +
 The external command can optionally write a single line to its
 standard output to be sent to the requestor as an error message when
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 78d6d50..fe42bf6 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -39,7 +39,7 @@ directories. This behavior can be forced by --no-index.
commit relative to the named commit.  Typically you
would want comparison with the latest commit, so if you
do not give commit, it defaults to HEAD.
-   If HEAD does not exist (e.g. unborned branches) and
+   If HEAD does not exist (e.g. unborn branches) and
commit is not given, it shows all staged changes.
--staged is a synonym of --cached.
 
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 9ac5088..670c285 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -28,7 +28,7 @@ arguments.  Here are the rules:
they can be disambiguated by placing `--` between them.
E.g. `git diff -- HEAD` is, I have a file called HEAD in my work
tree.  Please show changes between the version I staged in the index
-   and what I have in the work tree for that file. not show difference
+   and what I have in the work tree for that file, not show difference
between the HEAD commit and the work tree as a whole.  You can say
`git diff HEAD --` to ask for the latter.
 
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index d48bf4d..d954bf6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -251,7 +251,7 @@ three parameters:
 
  - the name of the ref being updated,
  - the old object name stored in the ref,
- - and the new objectname to be stored in the ref.
+ - and the new object name to be stored in the ref.
 
 A zero exit from the update hook allows the ref to be updated.
 Exiting with a non-zero status prevents 'git-receive-pack'
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 305db63..5945d7a 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -630,13 +630,13 @@ need to set this element to empty list i.e. `[]`.
 
 override::
If this field has a true value then the given feature is
-   overriddable, which means

Re: [PATCH 2/4] git-prompt.sh: refactor colored prompt code

[Øystein Walle]

Eduardo R. D'Avila erdavila at gmail.com writes:

 + local c_red='\[\e[31m\]'
 + local c_green='\[\e[32m\]'
 + local c_lblue='\[\e[1;34m\]'
 + local c_clear='\[\e[0m\]'
   fi
 - local c_red='\e[31m'
 - local c_green='\e[32m'
 - local c_lblue='\e[1;34m'
 - local c_clear='\e[0m'

I've gotten the impression it's better to use tput to generate the escape 
sequences instead of hardcoding them. So something like:

local c_red='\['$(tput setaf 1)'\]'
local c_green='\['$(tput setaf 2)'\]'
local c_green='\['$(tput setaf 4)'\]'
local c_clear='\['$(tput sgr0)'\]'

which is technically cleaner, if not visually.
 
The problem with that approach is that tput will be run several times for 
each prompt, so it would be best if the color variables were global. Another 
thing is that you rely on tput being available.

Øsse

--
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

[PATCH RFC] show-branch: use pager

[Øystein Walle]

This is for consistency with other porcelain commands such as 'log'.

Signed-off-by: Øystein Walle oys...@gmail.com
---
The rationale for this patch I hope is consicely explained in the commit
message. I was rather surprised it didn't use a pager as I've gotten used to it
for most commands.

I marked this as an RFC because of Jeff King's comments in
daa0c3d97 where I got the impression this this might not be a good idea.
However I haven't found any bugs and all the tests pass. It is more a huble
suggestion than anything but I thought I might as well send it as a patch.

setup_pager() is already pulled in via cache.h so there was no need to add any
#include directive. I suppose this is as close to a one-liner as it gets :)

Best regards,
Øsse

 builtin/show-branch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 90fc6b1..bd3e10c 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -683,6 +683,7 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
};
 
git_config(git_show_branch_config, NULL);
+   setup_pager();
 
/* If nothing is specified, try the default first */
if (ac == 1  default_num) {
-- 
1.8.2.2

--
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

[PATCH v2] show-branch: use pager

[Øystein Walle]

This is for consistency with other porcelain commands such as 'log'.

Signed-off-by: Øystein Walle oys...@gmail.com
---
Hi, Jeff

Thanks for the (fast!) feedback and good to hear it won't cause any trouble.

I hadn't actually noticed this mechanism of setting up the pager before now but
I fully agree. Here's an updated version. 

Øsse

 git.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git.c b/git.c
index 4359086..6d1f6ca 100644
--- a/git.c
+++ b/git.c
@@ -406,7 +406,7 @@ static void handle_internal_command(int argc, const char 
**argv)
{ send-pack, cmd_send_pack, RUN_SETUP },
{ shortlog, cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },
{ show, cmd_show, RUN_SETUP },
-   { show-branch, cmd_show_branch, RUN_SETUP },
+   { show-branch, cmd_show_branch, RUN_SETUP | USE_PAGER },
{ show-ref, cmd_show_ref, RUN_SETUP },
{ stage, cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ status, cmd_status, RUN_SETUP | NEED_WORK_TREE },
-- 
1.8.2.2

--
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: What's cooking in git.git (May 2013, #09; Wed, 29)

[Øystein Walle]

Junio C Hamano gitster at pobox.com writes:

 * kb/status-ignored-optim-2 (2013-05-29) 1 commit
  - dir.c: fix ignore processing within not-ignored directories
 
  Fix 1.8.3 regressions in the .gitignore path exclusion logic.

Hi,

I see that the Tested-by line in kb/status-ignored-optim-2 (3973cbd)
doesn't contain my e-mail address. I personally have no particular
preference whether it's there or not, but I noticed that it usually is
on Tested-by lines, so I'm wondering if I have slipped on some standard
practice. Would be useful to know in case I get the chance to help out
more :)

Thanks,
Øsse


--
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: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?

[Øystein Walle]

Karsten Blees karsten.blees at gmail.com writes:

  at Øystein: in the meantime, could you check if this fixes the problem 
for you?
 
 --- 8 ---
 diff --git a/dir.c b/dir.c
 index a5926fb..13858fe 100644
 --- a/dir.c
 +++ b/dir.c
  at  at  -821,6 +821,9  at  at  static void prep_exclude(struct 
dir_struct *dir, const char *base, int baselen)
   dir-basebuf, stk-baselen - 1,
   dir-basebuf + current, dt);
   dir-basebuf[stk-baselen - 1] = '/';
 + if (dir-exclude 
 + dir-exclude-flags  EXC_FLAG_NEGATIVE)
 + dir-exclude = NULL;
   if (dir-exclude) {
   dir-basebuf[stk-baselen] = 0;
   dir-exclude_stack = stk;

Hi, Karsten

I applied your fix on v1.8.3 on both systems I mentioned earlier and
from my tests the issue I reported is fixed.

Thank you very much! :)

Regards
Øsse



--
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: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?

[Øystein Walle]

Misty De Meo misty at brew.sh writes:

 
 Hi,
 
 Gitignore parsing no longer seems to work properly in git 1.8.3.
 
 One of my repositories has the following gitignore:
 
 /*
 !/.gitignore
 !/Library/
 !/CONTRIBUTING.md
 !/README.md
 !/SUPPORTERS.md
 !/bin
 /bin/*
 !/bin/brew
 !/share/man/man1/brew.1
 .DS_Store
 /Library/LinkedKegs
 /Library/PinnedKegs
 /Library/Taps
 /Library/Formula/.gitignore
 
 In 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm
 seeing every file in /bin/ being marked as an untracked file.
 
 I asked about this in #git, and was told that the culprit was the
 regex support; apparently recompiling without regex support fixes the
 specific gitignore issue. However, this doesn't seem to have been
 reported anywhere on the mailing list that I can see. I was also told
 that the issue is OS X-specific, and doesn't happen on other
 platforms.
 
 Thanks,
 Misty De Meo
 

I see a similar problem using e.g. the following .gitignore to exclude
everything except C source files and header files:

*
!*/
!*.c
!*.h

In Git 1.8.3 'git status' will show other files as untracked while in
Git 1.8.2.3 I don't have that problem. I bisected to find that the
offending commit is v1.8.2.1-402-g95c6f27. 

I am not on OSX, however, but on Linux (Ubuntu 12.04 and RHEL 5.8) so
this may be a separate issue. I've also gotten the impression that this
is intentional. In any case I cannot create a .gitignore that achieves
the same for both older and newer versions of Git.

Best regards,
Øystein Walle


--
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