Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Jeff King]

On Tue, Mar 15, 2016 at 09:57:16PM -0700, Linus Torvalds wrote:

> On Tue, Mar 15, 2016 at 9:46 PM, Junio C Hamano  wrote:
> >
> > It also ignores that byte counts of non-HT bytes may not necessarily
> > match display columns.  There is utf8_width() function exported from
> > utf8.c for that purpose.
> 
> Hmm. I did that to now make it horribly slower. Doing the
> per-character widths really does horrible things for performance.
> 
> That said, I think I can make it do the fast thing for lines that have
> no tabs at all, which is the big bulk of it. So it would do the width
> calculations only in the rare "yes, I found a tab" case.
> 
> I already wrote it in a way that non-tab lines end up just looping
> over the line looking for a tab and then fall back to the old code.
> 
> I might just have to make that behavior a bit more explicit. Let me
> stare at it a bit, but it won't happen until tomorrow, I think.

I wondered about performance when reading yours, and measured a straight
"git log >/dev/null" on the kernel at about 3% slower (best-of-five and
average). We can get most of that back by sticking a

memchr(line, '\t', linelen);

in front and skipping the loop if it returns NULL. You can also
implement your loop in terms of memchr() calls to skip to the next tab,
but I don't know if it's worth it. It's really only worth spending time
optimizing the non-tab case (and even then, only worth it for trivial
things like "use the already optimized-as-hell memchr").

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

Re: [PATCH 2/2] pull --rebase: add --[no-]autostash flag

[Mehul Jain]

On Wed, Mar 16, 2016 at 3:13 AM, Eric Sunshine  wrote:
>> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
>> @@ -128,6 +128,15 @@ unless you have read linkgit:git-rebase[1] carefully.
>> +--autostash::
>> +--no-autostash::
>> +   Before starting rebase, stash local modifications away (see
>> +   linkgit:git-stash.txt[1]) if needed, and apply the stash when
>> +   done (this option is only valid when "--rebase" is used).
>> ++
>> +`--no-autostash` is useful to override the `rebase.autoStash`
>> +configuration variable (see linkgit:git-config[1]).
>
> The last couple sentences seem reversed. It feels odd to have the bit
> about --rebase dropped dead in the middle of the description of
> --autostash and --no-autostash. I'd have expected to see --autostash
> and --no-autostash discussed together, and then, as a follow-on,
> mention them being valid only with --rebase.

So you are suggesting something like this:

--autostash::
--no-autostash::
Before starting rebase, stash local modifications away (see
linkgit:git-stash.txt[1]) if needed, and apply the stash when
done. `--no-autostash` is useful to override the `rebase.autoStash`
configuration variable (see linkgit:git-config[1]).
+
This option is only valid when "--rebase" is used.

Can be done and it make more sense to talk about the validity of the
option in a seperate line.

>> diff --git a/builtin/pull.c b/builtin/pull.c
>> @@ -851,12 +855,17 @@ int cmd_pull(int argc, const char **argv, const char 
>> *prefix)
>> if (is_null_sha1(orig_head) && !is_cache_unborn())
>> die(_("Updating an unborn branch with changes added 
>> to the index."));
>>
>> -   if (config_autostash)
>> +   if (opt_autostash == -1)
>
> In patch 1/2, this changed from 'if (autostash)' to 'if
> (config_autostash)'; it's a bit sad that patch 2/2 then has to touch
> the same code to change it yet again, this time to 'if
> (opt_autostash)'. Have you tried just keeping the original 'autostash'
> variable and modifying its value based upon config_autostash and
> opt_autostash instead? (Not saying that this would be better, but
> interested in knowing if the result is as clean or cleaner or worse.)

Yes, I tried that. Things looked something like this:

In patch 1/2
...

-int autostash = 0;
+int autostash = config_autoshash;

if (is_null_sha1(orig_head) && !is_cache_unborn())
die(_("Updating ..."));

-git_config_get_bool("rebase.autostash", &autostash);
if (!autostash)
die_on_unclean_work_tree(prefix);

...

In patch 2/2
...
int autostash = config_autoshash;

if (is_null_sha1(orig_head) && !is_cache_unborn())
die(_("Updating ..."));

+if (opt_autostash != -1)
+autostash = opt_autostash;

if (!autostash)
die_on_unclean_work_tree(prefix);
...

This implementation looks much more cleaner but we are using some
extra space (autostash) to do the task. If everyone is fine with this
trade off then I can re-roll a new patch with this method. Comments please.

>> +   opt_autostash = config_autostash;
>> +
>> +   if (!opt_autostash)
>> die_on_unclean_work_tree(prefix);
>>
>> if (get_rebase_fork_point(rebase_fork_point, repo, 
>> *refspecs))
>> hashclr(rebase_fork_point);
>> -   }
>> +   } else
>> +   if (opt_autostash != -1)
>> +die(_("--[no-]autostash option is only valid with 
>> --rebase."));
>
> How about formatting this as a normal 'else if'?
>
> } else if (opt_autostash != -1)

I thought of it earlier but voted against it as it may reduce the readability of
the code.

> On the other hand, this error case hanging off the 'rebase'
> conditional is somewhat more difficult to reason about than perhaps it
> ought to be. It might be easier to see what's going on if you get the
> error case out of the way early, and then handle the normal case. That
> is, something like this:
>
> if (!opt_rebase && opt_autostash != -1)
> die(_("... is only valid with --rebase"));
>
> if (opt_rebase) {
> ...
> }

This is good. I'll make the changes accordingly.

Thanks for the comments.

Mehul
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Linus Torvalds]

On Tue, Mar 15, 2016 at 9:46 PM, Junio C Hamano  wrote:
>
> It also ignores that byte counts of non-HT bytes may not necessarily
> match display columns.  There is utf8_width() function exported from
> utf8.c for that purpose.

Hmm. I did that to now make it horribly slower. Doing the
per-character widths really does horrible things for performance.

That said, I think I can make it do the fast thing for lines that have
no tabs at all, which is the big bulk of it. So it would do the width
calculations only in the rare "yes, I found a tab" case.

I already wrote it in a way that non-tab lines end up just looping
over the line looking for a tab and then fall back to the old code.

I might just have to make that behavior a bit more explicit. Let me
stare at it a bit, but it won't happen until tomorrow, I think.

 Linus
--
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: Can't git stash after using git add -N

[Junio C Hamano]

Josh Triplett  writes:

> As far as I can tell, if I run "git add -N" on a file, and then commit
> without adding the file contents, it gets committed as an empty file.

Is that true?  Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.

> Could stash save it exactly as if I'd done "git add" of an empty file at
> that path and then filled in the contents without adding them?

As I said, there is no space for a tree object to say "this one
records an empty blob but it actually was an intent-to-add entry"
and "this other one records an empty blob and it indeed is an empty
blob".  So "stash pop" (or "stash apply") would fundamentally be
unable to resurrect the exact state after "add -N".

>> "git rm --cached" the path and then running "stash save" would be a
>> workaround, but then you'd probably need to use "--untracked" hack
>> when you run "stash save" if you are stashing because you are going
>> to do something to the same path in the cleaned-up working tree.
>
> Right; I do specifically want to save the working-tree files.

Then "git add" that path before "stash save" would probably be a
better workaround.
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Junio C Hamano]

Linus Torvalds  writes:

> Here's a first try at it. It does tab expansion only for the cases
> that indent the commit message, so for things like "pretty=email" it
> makes no difference at all.

It also ignores that byte counts of non-HT bytes may not necessarily
match display columns.  There is utf8_width() function exported from
utf8.c for that purpose.

I think it is fine to make it default for the pretty=medium, but it
would be nicer to introduce a new command line option --no-untabify
to optionally disable the expansion.

>  pretty.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/pretty.c b/pretty.c
> index 92b2870a7eab..dcd6105d1eb2 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1652,8 +1652,26 @@ void pp_remainder(struct pretty_print_context *pp,
>   first = 0;
>  
>   strbuf_grow(sb, linelen + indent + 20);
> - if (indent)
> + if (indent) {
> + int i, last = 0, pos = 0;
> +
>   strbuf_addchars(sb, ' ', indent);
> + for (i = 0; i < linelen; i++) {
> + int expand;
> + if (line[i] != '\t')
> + continue;
> + strbuf_add(sb, line+last, i-last);
> + pos += i-last;
> + expand = (pos + 8) & ~7;
> + strbuf_addchars(sb, ' ', expand - pos);
> + pos = expand;
> + last = i+1;
> + }
> +
> + // Handle the tail non-tab content
> + line += last;
> + linelen -= last;
> + }
>   strbuf_add(sb, line, linelen);
>   strbuf_addch(sb, '\n');
>   }
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Linus Torvalds]

On Tue, Mar 15, 2016 at 5:48 PM, Linus Torvalds
 wrote:
> On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano  wrote:
>>
>> Wouldn't it be nicer to do this kind of thing at the output side?  A
>> stupid way would be to have an option to indent the log text with a
>> tab instead of 4-spaces, but a more sensible way would be to keep
>> the visual 4-space-indent and do the expand-tab for each line of
>> text.
>
> Yes, that would certainly work for me too. It's just the "ascii boxes
> don't line up" that is problematic..

Ok, that actually turns out to be pretty easy.

Here's a first try at it. It does tab expansion only for the cases
that indent the commit message, so for things like "pretty=email" it
makes no difference at all.

However, it hardcodes the hardtab size to 8, and makes this all
unconditional. That's how a vt100 terminal works, but fancer terminals
may allow you set actual tab-stops, and if you're in emacs you can
probably do just about anything)

Comments? This does make the kernel commit 0dc8c730c98a look fine, so
it would make me happy.

I can write a commit log etc if people think this is ok, but right now
this is just a silly raw patch in the attachement..

   Linus
 pretty.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/pretty.c b/pretty.c
index 92b2870a7eab..dcd6105d1eb2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1652,8 +1652,26 @@ void pp_remainder(struct pretty_print_context *pp,
first = 0;
 
strbuf_grow(sb, linelen + indent + 20);
-   if (indent)
+   if (indent) {
+   int i, last = 0, pos = 0;
+
strbuf_addchars(sb, ' ', indent);
+   for (i = 0; i < linelen; i++) {
+   int expand;
+   if (line[i] != '\t')
+   continue;
+   strbuf_add(sb, line+last, i-last);
+   pos += i-last;
+   expand = (pos + 8) & ~7;
+   strbuf_addchars(sb, ' ', expand - pos);
+   pos = expand;
+   last = i+1;
+   }
+
+   // Handle the tail non-tab content
+   line += last;
+   linelen -= last;
+   }
strbuf_add(sb, line, linelen);
strbuf_addch(sb, '\n');
}

Re: Can't git stash after using git add -N

[Josh Triplett]

On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote:
> Josh Triplett  writes:
> > After using "git add -N", "git stash" can no longer stash:
> 
> I think this is unfortunately one of the fundamental limitations
> that comes from the way how "stash" is implemented.  It uses three
> tree objects (i.e. HEAD's tree that represents where you started at,
> the tree that results by writing the index out as a tree, and
> another tree that would result if you added all the changes you made
> to the working tree to the index and then writing the resulting
> index out as a tree), but there are some states in the index that
> cannot be represented as a tree object.  "I know I would eventually
> want to add this new path, but I cannot decide with what contents
> just yet" aka "git add -N" is one of them (the other notable state
> that cannot be represented as a tree object is paths with unresolved
> conflicts in the index).

As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Could stash save it exactly as if I'd done "git add" of an empty file at
that path and then filled in the contents without adding them?

> "git rm --cached" the path and then running "stash save" would be a
> workaround, but then you'd probably need to use "--untracked" hack
> when you run "stash save" if you are stashing because you are going
> to do something to the same path in the cleaned-up working tree.

Right; I do specifically want to save the working-tree files.
--
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 3/3] clone: Add t5614 to test cloning submodules with shallowness involved

[Stefan Beller]

There are some inherent issues with shallow clones and submodules, such
as having not having a commit available the superproject may point to
in the submodule due to being shallow. Use the new file t5614 to document
and test expectations in this area.

Signed-off-by: Stefan Beller 
---

Notes:
$gmane/288916 does renaming operations,
"[PATCH] clone tests: rename t57* => t56*",
such that the first 13 spots in t56* are taken.
So we'll go with ..14 to not cause conflicts.
(If not having that renaming patch in mind, you
may end up aksing yourself "why ..14?")

 t/t5614-clone-submodules.sh | 82 +
 1 file changed, 82 insertions(+)
 create mode 100755 t/t5614-clone-submodules.sh

diff --git a/t/t5614-clone-submodules.sh b/t/t5614-clone-submodules.sh
new file mode 100755
index 000..a66c2db
--- /dev/null
+++ b/t/t5614-clone-submodules.sh
@@ -0,0 +1,82 @@
+#!/bin/sh
+
+test_description='Test shallow cloning of repos with submodules'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+   git checkout -b master &&
+   test_commit commit1 &&
+   test_commit commit2 &&
+   mkdir sub &&
+   (
+   cd sub &&
+   git init &&
+   test_commit subcommit1 &&
+   test_commit subcommit2
+   ) &&
+   git submodule add ./sub &&
+   git commit -m "add submodule"
+'
+
+test_expect_success 'nonshallow clone implies nonshallow submodule' '
+   test_when_finished "rm -rf super_clone" &&
+   git clone --recurse-submodules . super_clone &&
+   (
+   cd super_clone &&
+   git log --oneline >lines &&
+   test_line_count = 3 lines
+   ) &&
+   (
+   cd super_clone/sub &&
+   git log --oneline >lines &&
+   test_line_count = 2 lines
+   )
+'
+
+test_expect_success 'shallow clone implies shallow submodule' '
+   test_when_finished "rm -rf super_clone" &&
+   git clone --recurse-submodules --no-local --depth 1 . super_clone &&
+   (
+   cd super_clone &&
+   git log --oneline >lines &&
+   test_line_count = 1 lines
+   ) &&
+   (
+   cd super_clone/sub &&
+   git log --oneline >lines &&
+   test_line_count = 1 lines
+   )
+'
+
+test_expect_success 'shallow clone with non shallow submodule' '
+   test_when_finished "rm -rf super_clone" &&
+   git clone --recurse-submodules --no-local --depth 1 
--no-shallow-submodules . super_clone &&
+   (
+   cd super_clone &&
+   git log --oneline >lines &&
+   test_line_count = 1 lines
+   ) &&
+   (
+   cd super_clone/sub &&
+   git log --oneline >lines &&
+   test_line_count = 2 lines
+   )
+'
+
+test_expect_success 'non shallow clone with shallow submodule' '
+   test_when_finished "rm -rf super_clone" &&
+   git clone --recurse-submodules --no-local --shallow-submodules . 
super_clone &&
+   (
+   cd super_clone &&
+   git log --oneline >lines &&
+   test_line_count = 3 lines
+   ) &&
+   (
+   cd super_clone/sub &&
+   git log --oneline >lines &&
+   test_line_count = 1 lines
+   )
+'
+
+test_done
-- 
2.7.0.rc0.42.g8e9204f.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

[PATCH 0/3] Towards sane shallow clones with submodules

[Stefan Beller]

This is a first real series following the RFC-y $gmane/288720.

For using submodules as they are now, I would imagine this is a strict
improvement.  See the tests in last patch to see what a workflow would
look like.

Thanks,
Stefan

Stefan Beller (3):
  clone: add `--shallow-submodules` flag
  submodule clone: pass along `local` option
  clone: Add t5614 to test cloning submodules with shallowness involved

 Documentation/git-clone.txt | 13 +--
 builtin/clone.c | 21 
 builtin/submodule--helper.c | 22 ++--
 git-submodule.sh|  7 
 t/t5614-clone-submodules.sh | 82 +
 5 files changed, 139 insertions(+), 6 deletions(-)
 create mode 100755 t/t5614-clone-submodules.sh

-- 
2.7.0.rc0.42.g8e9204f.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

[PATCH 1/3] clone: add `--shallow-submodules` flag

[Stefan Beller]

When creating a shallow clone of a repository with submodules, the depth
argument does not influence the submodules, i.e. the submodules are done
as non-shallow clones. It is unclear what the best default is for the
depth of submodules of a shallow clone, so we need to have the possibility
to do all kinds of combinations:

* shallow super project with shallow submodules
  e.g. build bots starting always from scratch. They want to transmit
  the least amount of network data as well as using the least amount
  of space on their hard drive.
* shallow super project with unshallow submodules
  e.g. The superproject is just there to track a collection of repositories
  and it is not important to have the relationship between the repositories
  intact. However the history of the individual submodules matter.
* unshallow super project with shallow submodules
  e.g. The superproject is the actual project and the submodule is a
  library which is rarely touched.

The new switch to select submodules to be shallow or unshallow supports
all of these three cases.

It is easy to transition from the first to the second case by just
unshallowing the submodules (`git submodule foreach git fetch
--unshallow`), but it is not possible to transition from the second to the
first case (as we wouldd have already transmitted the non shallow over
the network). That is why we want to make the first case the default in
case of a shallow super project. This leads to the inconvenience in the
second case with the shallow super project and unshallow submodules,
as you need to pass `--no-shallow-submodules`.

Signed-off-by: Stefan Beller 
---
 Documentation/git-clone.txt | 13 ++---
 builtin/clone.c |  7 +++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 6db7b6d..20a4577 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -14,8 +14,8 @@ SYNOPSIS
  [-o ] [-b ] [-u ] [--reference ]
  [--dissociate] [--separate-git-dir ]
  [--depth ] [--[no-]single-branch]
- [--recursive | --recurse-submodules] [--jobs ] [--] 
- []
+ [--recursive | --recurse-submodules] [--[no-]shallow-submodules]
+ [--jobs ] [--]  []
 
 DESCRIPTION
 ---
@@ -190,7 +190,11 @@ objects from the source repository into a pack in the 
cloned repository.
 
 --depth ::
Create a 'shallow' clone with a history truncated to the
-   specified number of revisions.
+   specified number of revisions. Implies `--single-branch` unless
+   `--no-single-branch` is given to fetch the histories near the
+   tips of all branches. This implies `--shallow-submodules`. If
+   you want to have a shallow clone, but full submodules, also pass
+   `--no-shallow-submodules`.
 
 --[no-]single-branch::
Clone only the history leading to the tip of a single branch,
@@ -214,6 +218,9 @@ objects from the source repository into a pack in the 
cloned repository.
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
 
+--shallow-submodules::
+   All submodules which are cloned, will be shallow.
+
 --separate-git-dir=::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
diff --git a/builtin/clone.c b/builtin/clone.c
index b004fb4..ecdf308 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -40,6 +40,7 @@ static const char * const builtin_clone_usage[] = {
 
 static int option_no_checkout, option_bare, option_mirror, 
option_single_branch = -1;
 static int option_local = -1, option_no_hardlinks, option_shared, 
option_recursive;
+static int option_shallow_submodules = -1;
 static char *option_template, *option_depth;
 static char *option_origin = NULL;
 static char *option_branch = NULL;
@@ -91,6 +92,8 @@ static struct option builtin_clone_options[] = {
N_("create a shallow clone of that depth")),
OPT_BOOL(0, "single-branch", &option_single_branch,
N_("clone only one branch, HEAD or --branch")),
+   OPT_BOOL(0, "shallow-submodules", &option_shallow_submodules,
+   N_("any cloned submodules will be shallow")),
OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
   N_("separate git dir from working tree")),
OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
@@ -727,6 +730,10 @@ static int checkout(void)
struct argv_array args = ARGV_ARRAY_INIT;
argv_array_pushl(&args, "submodule", "update", "--init", 
"--recursive", NULL);
 
+   if (option_shallow_submodules == 1
+   || (option_shallow_submodules == -1 && option_depth))
+   argv_array_push(&args, "--depth=1");
+
if (max_jobs != -1)
   

[PATCH 2/3] submodule clone: pass along `local` option

[Stefan Beller]

When cloning a local repository, the user may choose to use an optimization
such that the transfer uses a Git agnostic protocol. Propagate the users
choice to submodules or if they don't choose, propagate nothing.
A test will be added in a later patch.

Signed-off-by: Stefan Beller 
---

Notes:
Alternative commit message:
When writing tests (as they appear in a later patch), I was forced to 
make
a decision: Either use the file:// protocol and pretend like I never run
into problems using the local option when writing tests, or support the
local option as a first class citizen and give it some test coverage in
combination with the shallow clones. I choose the later as for the
file:// protocol I would have needed to muck around with path names.
c.f. $gmane/282779

 builtin/clone.c | 14 ++
 builtin/submodule--helper.c | 22 +++---
 git-submodule.sh|  7 +++
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/builtin/clone.c b/builtin/clone.c
index ecdf308..0980386 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -734,6 +734,20 @@ static int checkout(void)
|| (option_shallow_submodules == -1 && option_depth))
argv_array_push(&args, "--depth=1");
 
+   switch (option_local) {
+   case 1:
+   argv_array_push(&args, "--local");
+   break;
+   case 0:
+   argv_array_push(&args, "--no-local");
+   break;
+   case -1:
+   /* pass nothing */
+   break;
+   default:
+   die("BUG: option_local out of range");
+   }
+
if (max_jobs != -1)
argv_array_pushf(&args, "--jobs=%d", max_jobs);
 
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index a484945..822ec69 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -125,7 +125,8 @@ static int module_name(int argc, const char **argv, const 
char *prefix)
return 0;
 }
 static int clone_submodule(const char *path, const char *gitdir, const char 
*url,
-  const char *depth, const char *reference, int quiet)
+  const char *depth, const char *reference, int quiet,
+  int local)
 {
struct child_process cp;
child_process_init(&cp);
@@ -140,6 +141,10 @@ static int clone_submodule(const char *path, const char 
*gitdir, const char *url
argv_array_pushl(&cp.args, "--reference", reference, NULL);
if (gitdir && *gitdir)
argv_array_pushl(&cp.args, "--separate-git-dir", gitdir, NULL);
+   if (local == 1)
+   argv_array_push(&cp.args, "--local");
+   else if (!local)
+   argv_array_push(&cp.args, "--no-local");
 
argv_array_push(&cp.args, url);
argv_array_push(&cp.args, path);
@@ -156,6 +161,7 @@ static int module_clone(int argc, const char **argv, const 
char *prefix)
const char *path = NULL, *name = NULL, *url = NULL;
const char *reference = NULL, *depth = NULL;
int quiet = 0;
+   int local = -1;
FILE *submodule_dot_git;
char *sm_gitdir, *cwd, *p;
struct strbuf rel_path = STRBUF_INIT;
@@ -180,6 +186,8 @@ static int module_clone(int argc, const char **argv, const 
char *prefix)
OPT_STRING(0, "depth", &depth,
   N_("string"),
   N_("depth for shallow clones")),
+   OPT_BOOL(0, "local", &local,
+N_("to clone from a local repository")),
OPT__QUIET(&quiet, "Suppress output for cloning a submodule"),
OPT_END()
};
@@ -200,7 +208,8 @@ static int module_clone(int argc, const char **argv, const 
char *prefix)
if (!file_exists(sm_gitdir)) {
if (safe_create_leading_directories_const(sm_gitdir) < 0)
die(_("could not create directory '%s'"), sm_gitdir);
-   if (clone_submodule(path, sm_gitdir, url, depth, reference, 
quiet))
+   if (clone_submodule(path, sm_gitdir, url, depth, reference,
+   quiet, local))
die(_("clone of '%s' into submodule path '%s' failed"),
url, path);
} else {
@@ -266,6 +275,7 @@ struct submodule_update_clone {
 
/* configuration parameters which are passed on to the children */
int quiet;
+   int local;
const char *reference;
const char *depth;
const char *recursive_prefix;
@@ -278,7 +288,7 @@ struct submodule_update_clone {
unsigned quickstop : 1;
 };
 #define SUBMODULE_UPDATE_CLONE_INIT {0, MODULE_LIST_INIT, 0, \
-   SUBMODUL

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Stefan Beller]

On Tue, Mar 15, 2016 at 6:00 PM, Stefan Beller  wrote:
>
> Instead of converting to whitespaces in Git, we could make use of the
> set_tabs capability for ttys and setup the terminal for having tabs align
> to 12,+8,+8,+8...

Or rather read in the existing tabs configuration and shift it by a constant.
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Stefan Beller]

On Tue, Mar 15, 2016 at 5:48 PM, Linus Torvalds
 wrote:
> On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano  wrote:
>>
>> Wouldn't it be nicer to do this kind of thing at the output side?  A
>> stupid way would be to have an option to indent the log text with a
>> tab instead of 4-spaces, but a more sensible way would be to keep
>> the visual 4-space-indent and do the expand-tab for each line of
>> text.
>
> Yes, that would certainly work for me too. It's just the "ascii boxes
> don't line up" that is problematic..

I would also rather side to correct the display side rather than the
applying side. [I still want to send and apply patches with git written in
the white space language ;]

Instead of converting to whitespaces in Git, we could make use of the
set_tabs capability for ttys and setup the terminal for having tabs align
to 12,+8,+8,+8... such that it looks like an indented terminal.
That way we would also preserve the tabs in case you'd want to
copy the message as is.

Thanks,
Stefan

>
> (Also people including example source code etc, where the first tab
> looks wildly different from the second one)
>
> Linus
> --
> 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
--
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] t/lib-httpd: pass through GIT_CONFIG_NOSYSTEM env

[Jeff King]

We set GIT_CONFIG_NOSYSTEM in our test scripts so that we do
not accidentally read /etc/gitconfig and have it influence
the outcome of the tests. But when running smart-http tests,
Apache will clean the environment, including this variable,
and the "server" side of our http operations will read it.

You can see this breakage by doing something like:

  make
  ./git config --system http.getanyfile false
  make test

which will cause t5561 to fail when it tests the
fallback-to-dumb operation.

We can fix this by instructing Apache to pass through the
variable. Unlike with other variables (e.g., 89c57ab3's
GIT_TRACE), we don't need to set a dummy value to prevent
warnings from Apache. test-lib.sh already makes sure that
GIT_CONFIG_NOSYSTEM is set and exported.

Signed-off-by: Jeff King 
---
Obviously trivial enough for "maint", but not at all urgent; it has
been this way for ages. I only noticed because I happened to recently
munge my system config to replicate a particular server config which
disables http.getanyfile.

 t/lib-httpd/apache.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index f667e7c..9317ba0 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -74,6 +74,7 @@ PassEnv GIT_VALGRIND_OPTIONS
 PassEnv GNUPGHOME
 PassEnv ASAN_OPTIONS
 PassEnv GIT_TRACE
+PassEnv GIT_CONFIG_NOSYSTEM
 
 Alias /dumb/ www/
 Alias /auth/dumb/ www/auth/dumb/
-- 
2.8.0.rc2.331.ga574393
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Linus Torvalds]

On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano  wrote:
>
> Wouldn't it be nicer to do this kind of thing at the output side?  A
> stupid way would be to have an option to indent the log text with a
> tab instead of 4-spaces, but a more sensible way would be to keep
> the visual 4-space-indent and do the expand-tab for each line of
> text.

Yes, that would certainly work for me too. It's just the "ascii boxes
don't line up" that is problematic..

(Also people including example source code etc, where the first tab
looks wildly different from the second one)

Linus
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Junio C Hamano]

Linus Torvalds  writes:

> Do people hate that idea? I may not get around to it for a while (it's
> the kernel merge window right now), but I can write the patch
> eventually - I just wanted to do an RFC first.

Wouldn't it be nicer to do this kind of thing at the output side?  A
stupid way would be to have an option to indent the log text with a
tab instead of 4-spaces, but a more sensible way would be to keep
the visual 4-space-indent and do the expand-tab for each line of
text.

That way, your viewing of existing commits that use 8-space HT to
align (and worse yet, mixture of 8-space HT and 8 spaces and assume
the end result would align in the output) would become more pleasant
without you having to run filter-branch ;-)
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Linus Torvalds]

On Tue, Mar 15, 2016 at 5:23 PM, Stefan Beller  wrote:
>
> Could you point at some example to better understand the problem?

So in the kernel repo, I just randomly looked for tabs that show this
problem, and take for example commit
ff9a9b4c4334b53b52ee9279f30bd5dd92ea9bdd.

You can see how the original lined up, by doing

git show --pretty=email ff9a9b4c4334

because the email format doesn't indent the commit message. But if you do just

git show ff9a9b4c4334

and get the usual indentation, you'll see things not line up at all.

In case you don't want to bother with the kernel repo, here's what it
looks like:

email format:

--- snip snip 8< ---
A microbenchmark calling an invalid syscall number 10 million
times in a row speeds up an additional 30% over the numbers
with just the previous patches, for a total speedup of about
40% over 4.4 and 4.5-rc1.

Run times for the microbenchmark:

 4.43.8 seconds
 4.5-rc13.7 seconds
 4.5-rc1 + first patch  3.3 seconds
 4.5-rc1 + first 3 patches  3.1 seconds
 4.5-rc1 + all patches  2.3 seconds

A non-NOHZ_FULL cpu (not the housekeeping CPU):

 all kernels1.86 seconds
--- snip snip 8< ---

Normal "git show" format:

--- snip snip 8< ---
A microbenchmark calling an invalid syscall number 10 million
times in a row speeds up an additional 30% over the numbers
with just the previous patches, for a total speedup of about
40% over 4.4 and 4.5-rc1.

Run times for the microbenchmark:

 4.43.8 seconds
 4.5-rc13.7 seconds
 4.5-rc1 + first patch  3.3 seconds
 4.5-rc1 + first 3 patches  3.1 seconds
 4.5-rc1 + all patches  2.3 seconds

A non-NOHZ_FULL cpu (not the housekeeping CPU):

 all kernels1.86 seconds
--- snip snip 8< ---

which hopefully clarifies.

In the above case, it really isn't very annoying. It's just slightly
ugly. In some other cases, it can get quite hard to see what's up, but
the ones that come through me I actually tend to try to edit, so many
of them have been corrected.

For other examples (again, in the kernel), look at 19b2c30d3cce, or
0dc8c730c98a.

Linus
--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Randall S. Becker]

On March 15, 2016 8:17 PM Linus Torvalds wrote:
> So I end up doing this manually when I notice, but I was wondering ig maybe
> git could just have an option to "git am" and friends to de-tabify the commit
> message.
> 
> It's particularly noticeable when people line things up using tabs (for the
> kernel, it's often things like "cpu1 does X, cpu2 does Y"), and then when you
> do "git log" it looks like a unholy mess, because the 4-char indentation of 
> the
> log message ends up causing those things to not line up at all after all.
> 
> The natural thing to do would be to pass in a "tab size" parameter to
> strbuf_stripspace(), and default it to 0 (for no change), but have some way to
> let people say "expand tabs to spaces at 8-character tab-stops" or similar
> (but let people use different tab-stops if they want).
> 
> Do people hate that idea? I may not get around to it for a while (it's the
> kernel merge window right now), but I can write the patch eventually - I just
> wanted to do an RFC first.

Speaking partly as a consumer of the comments and partly as someone who 
generates the commits through APIs, I would ask that the commit tab handling 
semantic be more formalized than just tab size to strbuf_stripspace(). While it 
might seem a bit unfair to have to worry about non-git git clients, the 
detabbing can impact the other commit implementers (e.g., SourceTree, EGit, 
JGit, and the raft of process automation bits out there using JGit for cool 
stuff). Personally, I would prefer to have a normalized behaviour so that any 
bit of automation building a commit message would have a specific definition to 
go to (and hopefully comply with) in order to properly format the message for 
posterity and across all consumers. It might also be useful to have some 
ability to be presentation-compatible with legacy commits (done after this type 
of enhancement) so that a reasonable presentation can be done for those 8 year 
old commits that still have embedded tabs. Personally, I don't encourage tabs 
in commits myself and do see the value of this, but is this really restricted 
just to git am?

Just my $0.02,

Randall

-- Brief whoami: NonStop&UNIX developer since approximately 
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.



--
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: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Stefan Beller]

On Tue, Mar 15, 2016 at 5:16 PM, Linus Torvalds
 wrote:
> Do people hate that idea? I may not get around to it for a while (it's
> the kernel merge window right now), but I can write the patch
> eventually - I just wanted to do an RFC first.

Could you point at some example to better understand the problem?

Thanks,
Stefan

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

Tabs in commit messages - de-tabify option in strbuf_stripspace()?

[Linus Torvalds]

So I end up doing this manually when I notice, but I was wondering ig
maybe git could just have an option to "git am" and friends to
de-tabify the commit message.

It's particularly noticeable when people line things up using tabs
(for the kernel, it's often things like "cpu1 does X, cpu2 does Y"),
and then when you do "git log" it looks like a unholy mess, because
the 4-char indentation of the log message ends up causing those things
to not line up at all after all.

The natural thing to do would be to pass in a "tab size" parameter to
strbuf_stripspace(), and default it to 0 (for no change), but have
some way to let people say "expand tabs to spaces at 8-character
tab-stops" or similar (but let people use different tab-stops if they
want).

Do people hate that idea? I may not get around to it for a while (it's
the kernel merge window right now), but I can write the patch
eventually - I just wanted to do an RFC first.

Linus
--
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: Can't git stash after using git add -N

[Junio C Hamano]

Josh Triplett  writes:

> After using "git add -N", "git stash" can no longer stash:

I think this is unfortunately one of the fundamental limitations
that comes from the way how "stash" is implemented.  It uses three
tree objects (i.e. HEAD's tree that represents where you started at,
the tree that results by writing the index out as a tree, and
another tree that would result if you added all the changes you made
to the working tree to the index and then writing the resulting
index out as a tree), but there are some states in the index that
cannot be represented as a tree object.  "I know I would eventually
want to add this new path, but I cannot decide with what contents
just yet" aka "git add -N" is one of them (the other notable state
that cannot be represented as a tree object is paths with unresolved
conflicts in the index).

"git rm --cached" the path and then running "stash save" would be a
workaround, but then you'd probably need to use "--untracked" hack
when you run "stash save" if you are stashing because you are going
to do something to the same path in the cleaned-up working tree.
--
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

Can't git stash after using git add -N

[Josh Triplett]

After using "git add -N", "git stash" can no longer stash:

/tmp/temp$ git init
Initialized empty Git repository in /tmp/temp/.git/
/tmp/temp$ echo a > a
/tmp/temp$ git add a
/tmp/temp$ git commit -m 'Initial commit of a'
[master (root-commit) d7242c4] Initial commit of a
 1 file changed, 1 insertion(+)
 create mode 100644 a
/tmp/temp$ echo b > b
/tmp/temp$ git add -N b
/tmp/temp$ git stash
error: Entry 'b' not uptodate. Cannot merge.
Cannot save the current worktree state

- Josh Triplett
--
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 04/16] ref-filter: modify "%(objectname:short)" to take length

[Jacob Keller]

On Tue, Mar 15, 2016 at 9:47 AM, Karthik Nayak  wrote:
> Add support for %(objectname:short=) which would print the
> abbreviated unique objectname of given length. When no length is
> specified 7 is used. The minimum length is 'MINIMUM_ABBREV'.
>

Isn't the default abbreviation value used here, not hard coded to 7?
Thus user can configure this?

Description should also mention that length may be exceeded if it is
not long enough to be a unique identifier.

> Add tests and documentation for the same.
>

Also I didn't see any update to the documentation here..

> Mentored-by: Christian Couder 
> Mentored-by: Matthieu Moy 
> Signed-off-by: Karthik Nayak 
> ---
>  ref-filter.c| 25 +++--
>  t/t6300-for-each-ref.sh | 10 ++
>  2 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 857a8b5..17f781d 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -55,7 +55,10 @@ static struct used_atom {
> const char *if_equals,
> *not_equals;
> } if_then_else;
> -   enum { O_FULL, O_SHORT } objectname;
> +   struct {
> +   enum { O_FULL, O_LENGTH, O_SHORT } option;
> +   unsigned int length;
> +   } objectname;
> } u;
>  } *used_atom;
>  static int used_atom_cnt, need_tagged, need_symref;
> @@ -118,10 +121,17 @@ static void contents_atom_parser(struct used_atom 
> *atom, const char *arg)
>  static void objectname_atom_parser(struct used_atom *atom, const char *arg)
>  {
> if (!arg)
> -   atom->u.objectname = O_FULL;
> +   atom->u.objectname.option = O_FULL;
> else if (!strcmp(arg, "short"))
> -   atom->u.objectname = O_SHORT;
> -   else
> +   atom->u.objectname.option = O_SHORT;
> +   else if (skip_prefix(arg, "short=", &arg)) {
> +   atom->u.contents.option = O_LENGTH;
> +   if (strtoul_ui(arg, 10, &atom->u.objectname.length) ||
> +   atom->u.objectname.length == 0)
> +   die(_("positive value expected objectname:short=%s"), 
> arg);
> +   if (atom->u.objectname.length < MINIMUM_ABBREV)
> +   atom->u.objectname.length = MINIMUM_ABBREV;

Should this error instead of accepting and upgrading it to the minimum?

> +   } else
> die(_("unrecognized %%(objectname) argument: %s"), arg);
>  }
>
> @@ -591,12 +601,15 @@ static int grab_objectname(const char *name, const 
> unsigned char *sha1,
>struct atom_value *v, struct used_atom *atom)
>  {
> if (starts_with(name, "objectname")) {
> -   if (atom->u.objectname == O_SHORT) {
> +   if (atom->u.objectname.option == O_SHORT) {
> v->s = xstrdup(find_unique_abbrev(sha1, 
> DEFAULT_ABBREV));

Yes, here we are using DEFAULT_ABBREV, so you should mention that
instead of using 7 in the commit message.

> return 1;
> -   } else if (atom->u.objectname == O_FULL) {
> +   } else if (atom->u.objectname.option == O_FULL) {
> v->s = xstrdup(sha1_to_hex(sha1));
> return 1;
> +   } else if (atom->u.objectname.option == O_LENGTH) {
> +   v->s = xstrdup(find_unique_abbrev(sha1, 
> atom->u.objectname.length));
> +   return 1;
> } else
> die("BUG: unknown %%(objectname) option");
> }
> diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> index 19a2823..2be0a3f 100755
> --- a/t/t6300-for-each-ref.sh
> +++ b/t/t6300-for-each-ref.sh
> @@ -60,6 +60,8 @@ test_atom head objecttype commit
>  test_atom head objectsize 171
>  test_atom head objectname $(git rev-parse refs/heads/master)
>  test_atom head objectname:short $(git rev-parse --short refs/heads/master)
> +test_atom head objectname:short=1 $(git rev-parse --short=1 
> refs/heads/master)
> +test_atom head objectname:short=10 $(git rev-parse --short=10 
> refs/heads/master)
>  test_atom head tree $(git rev-parse refs/heads/master^{tree})
>  test_atom head parent ''
>  test_atom head numparent 0
> @@ -99,6 +101,8 @@ test_atom tag objecttype tag
>  test_atom tag objectsize 154
>  test_atom tag objectname $(git rev-parse refs/tags/testtag)
>  test_atom tag objectname:short $(git rev-parse --short refs/tags/testtag)
> +test_atom head objectname:short=1 $(git rev-parse --short=1 
> refs/heads/master)
> +test_atom head objectname:short=10 $(git rev-parse --short=10 
> refs/heads/master)
>  test_atom tag tree ''
>  test_atom tag parent ''
>  test_atom tag numparent ''
> @@ -164,6 +168,12 @@ test_expect_success 'Check invalid format specifiers are 
> errors' '
> test_must_fail git for-each-ref --format="%(authordate:INVALID)" 
> refs/heads
>  '
>
> 

Re: [PATCH] clone tests: rename t57* => t56*

[Jeff King]

On Tue, Mar 15, 2016 at 03:00:09PM -0700, Stefan Beller wrote:

> Talking about ordering, I have two use cases
> 
> 1) Before sending out patches: "git rebase -i -x make -x 'make test' "
>   to catch myself for doing stupid things.
> 
> 2) When developing new code, I alternate between running an indivdual test
>   "cd t && GIT_TRACE=1 ./t7400... -d -i -x -v " and running prove for all 
> tests
>   to have a good check if there are other niches I missed.

Yep, that is roughly my workflow, too (with the occasional "make test &&
make install" thrown in). :)

> So I do not really have strong preference for the right order, I even
> thought about omitting the paragraph from the commit message and
> wanted to put it into the notes below, but then I figured I want to
> record it as I was frustrated about the commit messages from 2006 as
> they don't answer simple questions like "Why did you use a different
> second digit?", so I figured if anyone digs up my commit eventually I
> want to record as much of my current reasoning even if it is minor to
> help a future developer?

I agree it is worth mentioning that you considered the order. I think
what you wrote was fine, though I probably would have said something
like:

  Moving t57* to higher digits in t56* preserves the existing ordering.
  That may or may not matter to anyone, but it does not hurt to keep it.

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

Re: [PATCH v2 00/16] port branch.c to use ref-filter's printing options

[Jacob Keller]

On Tue, Mar 15, 2016 at 9:47 AM, Karthik Nayak  wrote:
> diff --git a/Documentation/git-for-each-ref.txt 
> b/Documentation/git-for-each-ref.txt
> index 193e99e..578bbd1 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -116,10 +116,12 @@ 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).  Append `:track,nobracket` to show tracking
> -   information without brackets (i.e "ahead N, behind M").  Has
> -   no effect if the ref does not have tracking information
> -   associated with it.
> +   or "=" (in sync).  Has no effect if the ref does not have
> +   tracking information associated with it. `:track` also prints
> +   "[gone]" whenever unknown upstream ref is encountered. Append
> +   `:track,nobracket` to show tracking information without
> +   brackets (i.e "ahead N, behind M").  Has no effect if the ref
> +   does not have tracking information associated with it.
>

It looks like you duplicated "Has no effect if the ref does not have
tracking information associated with it"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clone tests: rename t57* => t56*

[Stefan Beller]

On Tue, Mar 15, 2016 at 2:51 PM, Jeff King  wrote:
> On Tue, Mar 15, 2016 at 02:25:50PM -0700, Stefan Beller wrote:
>
>> When trying to find a good spot for testing clone with submodules, I
>> got confused where to add a new test file. There are both tests in t560*
>> as well as t57* both testing the clone command. t/README claims the
>> second digit is to indicate the command, which is inconsistent to the
>> current naming structure.
>>
>> Rename all t57* tests to be in t56* to follow the pattern of the digits
>> as laid out in t/README.
>>
>> It would have been less work to rename t56* => t57* because there are less
>> files, but the tests in t56* look more basic and I assumed the higher the
>> last digits the more complicated niche details are tested, so with the patch
>> now it looks more in order to me.
>
> This seems like a good change to me. There definitely is a general sense
> of "more complex things should come later" in the test suite[1], so
> preserving the existing ordering seems reasonable.
>
>> If there is a reason to have 2 separate spaces for clone testing,
>> and I missed it, we should document that why it is important to keep
>> them separate.
>
> It looks like it was just carelessness from long ago. 5600 was added by
> 5508a616 (Feb 2006), and then t5700 in cf9dc653 (May 2006). For the
> later ones, everybody probably just found or the other and built on top
> (some of us even found both at various times; looks like I added t5708
> in 2011 and t5603 last year).
>
> I checked whether there were any stragglers in topics in flight with:
>
>   git log --oneline --name-status --diff-filter=A origin..origin/pu t
>
> but I think we are good.
>
> -Peff
>
> [1] I actually don't think the test ordering matters all that much. I
> guess if you run the tests directly from the Makefile, it will stop
> at the most basic test that fails.
>
> Personally, I run them in longest-to-shortest via "prove", which
> helps parallelism, and gives you the full list of failed tests.
> Which is often a good piece of knowledge by itself (is it just one
> test, or did I horribly break some fundamental part of git?). And
> then I pick one of the failures to study based on what seems simple
> to debug, and/or the area I've been making changes in.
>
> But I dunno. Maybe other people really do care about the order. It
> doesn't hurt to roughly follow the "simplest comes first" ordering.

Talking about ordering, I have two use cases

1) Before sending out patches: "git rebase -i -x make -x 'make test' "
  to catch myself for doing stupid things.

2) When developing new code, I alternate between running an indivdual test
  "cd t && GIT_TRACE=1 ./t7400... -d -i -x -v " and running prove for all tests
  to have a good check if there are other niches I missed.

So I do not really have strong preference for the right order, I even
thought about
omitting the paragraph from the commit message and wanted to put it into
the notes below, but then I figured I want to record it as I was
frustrated about
the commit messages from 2006 as they don't answer simple questions like
"Why did you use a different second digit?", so I figured if anyone digs up my
commit eventually I want to record as much of my current reasoning even
if it is minor to help a future developer?
--
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] submodule-config: use hashmap_iter_first()

[Jeff King]

On Tue, Mar 15, 2016 at 12:21:36PM -0700, Stefan Beller wrote:

> On Tue, Mar 15, 2016 at 12:13 PM, Alexander Kuleshov
>  wrote:
> > from the  for simplification.
> 
> I think what Eric wanted to point out, was to not have a continuous sentence
> from commit message header to body.
> 
> Either leave the body blank (as it is obvious) or write a whole sentence 
> there:
> 
>   [PATCH v2] submodule-config: use hashmap_iter_first()
> 
>   The hashmap API offers the `hashmap_iter_first` function as initializing and
>   getting the first entry is a common pattern. Use that instead of
> doing initialization
>   by hand and then get the first entry.

While we are nitpicking...:)

As a reader (either reviewing now, or looking at the change later in
git-log), I think my biggest question is: why?  Do we expect this to
change behavior, or is this just a cleanup? There's nothing wrong with
"just" a cleanup, but knowing that is the intent is helpful.

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

Re: [PATCH] clone tests: rename t57* => t56*

[Jeff King]

On Tue, Mar 15, 2016 at 02:25:50PM -0700, Stefan Beller wrote:

> When trying to find a good spot for testing clone with submodules, I
> got confused where to add a new test file. There are both tests in t560*
> as well as t57* both testing the clone command. t/README claims the
> second digit is to indicate the command, which is inconsistent to the
> current naming structure.
> 
> Rename all t57* tests to be in t56* to follow the pattern of the digits
> as laid out in t/README.
> 
> It would have been less work to rename t56* => t57* because there are less
> files, but the tests in t56* look more basic and I assumed the higher the
> last digits the more complicated niche details are tested, so with the patch
> now it looks more in order to me.

This seems like a good change to me. There definitely is a general sense
of "more complex things should come later" in the test suite[1], so
preserving the existing ordering seems reasonable.

> If there is a reason to have 2 separate spaces for clone testing,
> and I missed it, we should document that why it is important to keep
> them separate.

It looks like it was just carelessness from long ago. 5600 was added by
5508a616 (Feb 2006), and then t5700 in cf9dc653 (May 2006). For the
later ones, everybody probably just found or the other and built on top
(some of us even found both at various times; looks like I added t5708
in 2011 and t5603 last year).

I checked whether there were any stragglers in topics in flight with:

  git log --oneline --name-status --diff-filter=A origin..origin/pu t

but I think we are good.

-Peff

[1] I actually don't think the test ordering matters all that much. I
guess if you run the tests directly from the Makefile, it will stop
at the most basic test that fails.

Personally, I run them in longest-to-shortest via "prove", which
helps parallelism, and gives you the full list of failed tests.
Which is often a good piece of knowledge by itself (is it just one
test, or did I horribly break some fundamental part of git?). And
then I pick one of the failures to study based on what seems simple
to debug, and/or the area I've been making changes in.

But I dunno. Maybe other people really do care about the order. It
doesn't hurt to roughly follow the "simplest comes first" ordering.
--
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 checkout --theirs fails

[Junio C Hamano]

Stefan Beller  writes:

> On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi  wrote:
>> I'm doing a rebase and got some conflicts.  I just want to take their
>> version of all files, but git checkout --theirs complains:
>>
>> --ours/--theirs' cannot be used with switching branches
>>
>> What gives?  I'm not *trying* to switch branches.  I just want to
>> resolve the conflict by taking their version.  If I try git checkout
>> --theirs ., then it complains that not every single file in the
>> directory has a "their" version.  So?  Take the ones that do.
>
> I think for checking out files you'd need to add the file names.
> In case of a collision between branch name and file name, even add
> a double dash:
>
> git checkout --theirs -- file/name

That is true, but notice that the last example by Phil gives a dot
as the pathspec to match all available files.

Having said that,

$ git checkout --theirs -- file/name

would fail when the path file/name is unmerged and does not have
stage #3 entry, wouldn't it?  So with ".", unless all paths that
match that pathspec (i.e. all available files) are either merged
(i.e. without conflict) or have stage #3 entry, it is expected that
the command would fail consistently to the case where a pathspec
"file/name" that happens to match only one path is given, and that
is the behaviour Phil saw, I would think.

--
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 2/2] pull --rebase: add --[no-]autostash flag

[Eric Sunshine]

On Tue, Mar 15, 2016 at 1:11 PM, Mehul Jain  wrote:
> If rebase.autoStash configuration variable is set, there is no way to
> override it for "git pull --rebase" from the command line.
>
> Teach "git pull --rebase" the --[no-]autostash command line flag which
> overrides the current value of rebase.autoStash, if set. As "git rebase"
> understands the --[no-]autostash option, it's just a matter of passing
> the option to underlying "git rebase" when "git pull --rebase" is called.

The below comments may or may not be worth a re-roll (you decide)...

> Signed-off-by: Mehul Jain 
> ---
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> @@ -128,6 +128,15 @@ unless you have read linkgit:git-rebase[1] carefully.
> +--autostash::
> +--no-autostash::
> +   Before starting rebase, stash local modifications away (see
> +   linkgit:git-stash.txt[1]) if needed, and apply the stash when
> +   done (this option is only valid when "--rebase" is used).
> ++
> +`--no-autostash` is useful to override the `rebase.autoStash`
> +configuration variable (see linkgit:git-config[1]).

The last couple sentences seem reversed. It feels odd to have the bit
about --rebase dropped dead in the middle of the description of
--autostash and --no-autostash. I'd have expected to see --autostash
and --no-autostash discussed together, and then, as a follow-on,
mention them being valid only with --rebase.

> diff --git a/builtin/pull.c b/builtin/pull.c
> @@ -851,12 +855,17 @@ int cmd_pull(int argc, const char **argv, const char 
> *prefix)
> if (is_null_sha1(orig_head) && !is_cache_unborn())
> die(_("Updating an unborn branch with changes added 
> to the index."));
>
> -   if (config_autostash)
> +   if (opt_autostash == -1)

In patch 1/2, this changed from 'if (autostash)' to 'if
(config_autostash)'; it's a bit sad that patch 2/2 then has to touch
the same code to change it yet again, this time to 'if
(opt_autostash)'. Have you tried just keeping the original 'autostash'
variable and modifying its value based upon config_autostash and
opt_autostash instead? (Not saying that this would be better, but
interested in knowing if the result is as clean or cleaner or worse.)

> +   opt_autostash = config_autostash;
> +
> +   if (!opt_autostash)
> die_on_unclean_work_tree(prefix);
>
> if (get_rebase_fork_point(rebase_fork_point, repo, *refspecs))
> hashclr(rebase_fork_point);
> -   }
> +   } else
> +   if (opt_autostash != -1)
> +die(_("--[no-]autostash option is only valid with 
> --rebase."));

How about formatting this as a normal 'else if'?

} else if (opt_autostash != -1)

On the other hand, this error case hanging off the 'rebase'
conditional is somewhat more difficult to reason about than perhaps it
ought to be. It might be easier to see what's going on if you get the
error case out of the way early, and then handle the normal case. That
is, something like this:

if (!opt_rebase && opt_autostash != -1)
die(_("... is only valid with --rebase"));

if (opt_rebase) {
...
}

> if (run_fetch(repo, refspecs))
> return 1;
--
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 checkout --theirs fails

[Stefan Beller]

On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi  wrote:
> I'm doing a rebase and got some conflicts.  I just want to take their
> version of all files, but git checkout --theirs complains:
>
> --ours/--theirs' cannot be used with switching branches
>
> What gives?  I'm not *trying* to switch branches.  I just want to
> resolve the conflict by taking their version.  If I try git checkout
> --theirs ., then it complains that not every single file in the
> directory has a "their" version.  So?  Take the ones that do.

I think for checking out files you'd need to add the file names.
In case of a collision between branch name and file name, even add
a double dash:

git checkout --theirs -- file/name

>
> --
> 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
--
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: Gsoc 16

[Stefan Beller]

On Tue, Mar 15, 2016 at 2:23 PM, Pranit Bauva  wrote:
> Hey,
>
> Open Source projects run because of people who contribute in their
> free time (mainly). It might not be possible for someone to be active
> all times Sometimes it may take around 2-3 days. Give it a little more
> time.

Adding to that: Not everybody reads the whole list.
The first mail you sent, was deep down in the thread for rewriting
rebase --interactive in C instead of shell. The libgit2 maintainer (Carlos)
is highly unlikely to read that as it doesn't affect libgit2.

Posting as a separate thread here increases the chance for him to spot this
message.

Usually you'd cc the people you're addressing as that has highest chance that
the relevant people see your message. (I cc'd Carlos in this message, no need
to resend a third time from you.)

Stefan

>
> On Wed, Mar 16, 2016 at 2:30 AM, Saurabh Jain
>  wrote:
>> hi,
>>
>> I am Saurabh Jain, 3rd year Computer Science and Engineering student
>> studying at Indian Institute of Technology, Roorkee. I am quite fluent with
>> C programming.
>>
>> I would like to apply for GSoC 2016 under Git in libgit2. I read the list of
>> possible projects and microprojects to be done.
>> I tried to fix this, "Fix the examples/diff.c implementation of the -B"
>> given in Starter Projects, I made some changes to the code and created a
>> Issue on the libgit2's Github repository. But no one seems to reply to that,
>> also the IRC channel for libgit2 seems to be inactive. Please someone
>> concerned have a look.
>>
>> 
>>
>> I would also like to know who will be going to mentor GSoC 2016, libgit2
>> projects so that I would be able to discuss my ideas with them.
>>
>> All the concerned Mentors you can drop me a mail at 
>> saurabhsunilj...@gmail.com
>>
>> Hoping for a positive response from your side.
>>
>> Have a nice day !
>>
>> --
>> 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
> --
> 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
--
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] clone tests: rename t57* => t56*

[Stefan Beller]

When trying to find a good spot for testing clone with submodules, I
got confused where to add a new test file. There are both tests in t560*
as well as t57* both testing the clone command. t/README claims the
second digit is to indicate the command, which is inconsistent to the
current naming structure.

Rename all t57* tests to be in t56* to follow the pattern of the digits
as laid out in t/README.

It would have been less work to rename t56* => t57* because there are less
files, but the tests in t56* look more basic and I assumed the higher the
last digits the more complicated niche details are tested, so with the patch
now it looks more in order to me.

Signed-off-by: Stefan Beller 
---

If there is a reason to have 2 separate spaces for clone testing,
and I missed it, we should document that why it is important to keep
them separate.

Thanks,
Stefan

 t/{t5700-clone-reference.sh => t5604-clone-reference.sh} | 0
 t/{t5701-clone-local.sh => t5605-clone-local.sh} | 0
 t/{t5702-clone-options.sh => t5606-clone-options.sh} | 0
 t/{t5704-bundle.sh => t5607-clone-bundle.sh} | 0
 t/{t5705-clone-2gb.sh => t5608-clone-2gb.sh} | 0
 t/{t5706-clone-branch.sh => t5609-clone-branch.sh}   | 0
 t/{t5707-clone-detached.sh => t5610-clone-detached.sh}   | 0
 t/{t5708-clone-config.sh => t5611-clone-config.sh}   | 0
 t/{t5709-clone-refspec.sh => t5612-clone-refspec.sh} | 0
 t/{t5710-info-alternate.sh => t5613-info-alternate.sh}   | 0
 10 files changed, 0 insertions(+), 0 deletions(-)
 rename t/{t5700-clone-reference.sh => t5604-clone-reference.sh} (100%)
 rename t/{t5701-clone-local.sh => t5605-clone-local.sh} (100%)
 rename t/{t5702-clone-options.sh => t5606-clone-options.sh} (100%)
 rename t/{t5704-bundle.sh => t5607-clone-bundle.sh} (100%)
 rename t/{t5705-clone-2gb.sh => t5608-clone-2gb.sh} (100%)
 rename t/{t5706-clone-branch.sh => t5609-clone-branch.sh} (100%)
 rename t/{t5707-clone-detached.sh => t5610-clone-detached.sh} (100%)
 rename t/{t5708-clone-config.sh => t5611-clone-config.sh} (100%)
 rename t/{t5709-clone-refspec.sh => t5612-clone-refspec.sh} (100%)
 rename t/{t5710-info-alternate.sh => t5613-info-alternate.sh} (100%)

diff --git a/t/t5700-clone-reference.sh b/t/t5604-clone-reference.sh
similarity index 100%
rename from t/t5700-clone-reference.sh
rename to t/t5604-clone-reference.sh
diff --git a/t/t5701-clone-local.sh b/t/t5605-clone-local.sh
similarity index 100%
rename from t/t5701-clone-local.sh
rename to t/t5605-clone-local.sh
diff --git a/t/t5702-clone-options.sh b/t/t5606-clone-options.sh
similarity index 100%
rename from t/t5702-clone-options.sh
rename to t/t5606-clone-options.sh
diff --git a/t/t5704-bundle.sh b/t/t5607-clone-bundle.sh
similarity index 100%
rename from t/t5704-bundle.sh
rename to t/t5607-clone-bundle.sh
diff --git a/t/t5705-clone-2gb.sh b/t/t5608-clone-2gb.sh
similarity index 100%
rename from t/t5705-clone-2gb.sh
rename to t/t5608-clone-2gb.sh
diff --git a/t/t5706-clone-branch.sh b/t/t5609-clone-branch.sh
similarity index 100%
rename from t/t5706-clone-branch.sh
rename to t/t5609-clone-branch.sh
diff --git a/t/t5707-clone-detached.sh b/t/t5610-clone-detached.sh
similarity index 100%
rename from t/t5707-clone-detached.sh
rename to t/t5610-clone-detached.sh
diff --git a/t/t5708-clone-config.sh b/t/t5611-clone-config.sh
similarity index 100%
rename from t/t5708-clone-config.sh
rename to t/t5611-clone-config.sh
diff --git a/t/t5709-clone-refspec.sh b/t/t5612-clone-refspec.sh
similarity index 100%
rename from t/t5709-clone-refspec.sh
rename to t/t5612-clone-refspec.sh
diff --git a/t/t5710-info-alternate.sh b/t/t5613-info-alternate.sh
similarity index 100%
rename from t/t5710-info-alternate.sh
rename to t/t5613-info-alternate.sh
-- 
2.7.0.rc0.46.g8f16ed4.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: Gsoc 16

[Pranit Bauva]

Hey,

Open Source projects run because of people who contribute in their
free time (mainly). It might not be possible for someone to be active
all times Sometimes it may take around 2-3 days. Give it a little more
time.

On Wed, Mar 16, 2016 at 2:30 AM, Saurabh Jain
 wrote:
> hi,
>
> I am Saurabh Jain, 3rd year Computer Science and Engineering student
> studying at Indian Institute of Technology, Roorkee. I am quite fluent with
> C programming.
>
> I would like to apply for GSoC 2016 under Git in libgit2. I read the list of
> possible projects and microprojects to be done.
> I tried to fix this, "Fix the examples/diff.c implementation of the -B"
> given in Starter Projects, I made some changes to the code and created a
> Issue on the libgit2's Github repository. But no one seems to reply to that,
> also the IRC channel for libgit2 seems to be inactive. Please someone
> concerned have a look.
>
> 
>
> I would also like to know who will be going to mentor GSoC 2016, libgit2
> projects so that I would be able to discuss my ideas with them.
>
> All the concerned Mentors you can drop me a mail at saurabhsunilj...@gmail.com
>
> Hoping for a positive response from your side.
>
> Have a nice day !
>
> --
> 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
--
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] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 2:46 AM, Junio C Hamano  wrote:
> Pranit Bauva  writes:
>
>> ... But then I am still not convinced for the
>> requirement of another variable `opt-verbose` as I believe that the
>> `verbose` and `config_verbose` are quite enough for this.
>> ... Or is there something else which I forgot to
>> consider?
>
> I do not think we need three variables.  If there is one "verbose"
> that is initialized to "unspecified" (which must be different from
> "no", "yes", "even more verbose"), then it is perfectly fine to
> reuse that as if it were "opt-verbose" in my outline.  I just used
> that name to make it clear where the value comes from for these two
> entities, i.e. to contrast "opt vs config" (as opposed to "(nothing)
> vs config").

I just wanted to clear out the confusion! I will send the updated
patch with tests soon!
--
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] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva  writes:

> ... But then I am still not convinced for the
> requirement of another variable `opt-verbose` as I believe that the
> `verbose` and `config_verbose` are quite enough for this.
> ... Or is there something else which I forgot to
> consider?

I do not think we need three variables.  If there is one "verbose"
that is initialized to "unspecified" (which must be different from
"no", "yes", "even more verbose"), then it is perfectly fine to
reuse that as if it were "opt-verbose" in my outline.  I just used
that name to make it clear where the value comes from for these two
entities, i.e. to contrast "opt vs config" (as opposed to "(nothing)
vs config").
--
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

Gsoc 16

[Saurabh Jain]

hi,

I am Saurabh Jain, 3rd year Computer Science and Engineering student
studying at Indian Institute of Technology, Roorkee. I am quite fluent with
C programming.

I would like to apply for GSoC 2016 under Git in libgit2. I read the list of
possible projects and microprojects to be done. 
I tried to fix this, "Fix the examples/diff.c implementation of the -B"
given in Starter Projects, I made some changes to the code and created a
Issue on the libgit2's Github repository. But no one seems to reply to that,
also the IRC channel for libgit2 seems to be inactive. Please someone
concerned have a look.



I would also like to know who will be going to mentor GSoC 2016, libgit2
projects so that I would be able to discuss my ideas with them.

All the concerned Mentors you can drop me a mail at saurabhsunilj...@gmail.com

Hoping for a positive response from your side.

Have a nice day !

--
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] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 1:54 AM, Junio C Hamano  wrote:
> Pranit Bauva  writes:
>
>> First one to introduce a new variable `config_verbose` to store the
>> value read by the config. Till then the value of verbose can be set
>> through command line options. Depending on the situation as you
>> described, it can then make the modification. Another approach would
>> be to swap the places where the configuration file is read and where
>> arguments are parsed. I personally think the first approach as more
>> appropriate as in the latter one, there might be some parts of code
>> which can break.
>
> Changing config-first-and-then-command-line is likely to break
> things, unless you do a lot more work to avoid breakage ;-)

I had guessed this correctly! :)

> Wouldn't it be the simplest to do:
>
>  * initialize opt-verbose to "unspecified";
>  * initialize config-verbosity to "unspecified";
>  * let git_config() update config-verbosity;
>  * let parse_options() update opt-verbose.
>
> and then
>
>  * if opt-verbose is still "unspecified", then overwrite it with
>config-verbosity.
>
>  * if opt-verbose is still "unspecified" after that, then neither
>the command line nor the configuration gave you verbosity.
>
>  * otherwise opt-verbose at this point has what verbosity level to
>use.
>
> ?
I just realized that both of our approaches breaks the condition with
no-verbose.
If commit.verbose is set to true and --no-verbose is passed, then it
should not give verbose output.
But I suppose that is the reason you are saying "unspecified". If
`opt-verbose` is 0 then it would mean --no-verbose is activated. If it
is still "unspecified" then there would not be any such option. But
now the question is how do you set a variable as "unspecified". I can
set `opt-verbose` as -1. But then I am still not convinced for the
requirement of another variable `opt-verbose` as I believe that the
`verbose` and `config_verbose` are quite enough for this. First
`config_verbose` will read from configuration file. Then `verbose`
will read from command line options. If `verbose` is unspecified then
it will use `config_verbose`, else if `verbose` is 0 it will ignore
`config_verbose` else if `verbose` has a value greater than 0 then it
will stay as it is. Or is there something else which I forgot to
consider?
--
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 0/1] Introduce a way to create a branch and worktree at the same time

[Johannes Sixt]

Am 11.03.2016 um 03:57 schrieb Mikael Magnusson:

You can have /usr/src/git/master, /usr/src/git/some-work-tree, etc,
and /usr/src/git itself is not a git repository at all. That way
/usr/src only has one git-related directory and no worktrees are
nested.


I started using separate worktrees recently, and I chose the layout you 
sketch here. I didn't ask someone or read any documentation to find out 
about a recommended layout. I chose the layout because it felt the most 
natural.


Never in my life would I have considered nesting worktrees inside other 
worktrees.


-- Hannes

--
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] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva  writes:

> First one to introduce a new variable `config_verbose` to store the
> value read by the config. Till then the value of verbose can be set
> through command line options. Depending on the situation as you
> described, it can then make the modification. Another approach would
> be to swap the places where the configuration file is read and where
> arguments are parsed. I personally think the first approach as more
> appropriate as in the latter one, there might be some parts of code
> which can break.

Changing config-first-and-then-command-line is likely to break
things, unless you do a lot more work to avoid breakage ;-)

Wouldn't it be the simplest to do:

 * initialize opt-verbose to "unspecified";
 * initialize config-verbosity to "unspecified";
 * let git_config() update config-verbosity;
 * let parse_options() update opt-verbose.

and then

 * if opt-verbose is still "unspecified", then overwrite it with
   config-verbosity.

 * if opt-verbose is still "unspecified" after that, then neither
   the command line nor the configuration gave you verbosity.

 * otherwise opt-verbose at this point has what verbosity level to
   use.

?
--
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: [ANNOUNCE] Git for Windows 2.7.3

[Junio C Hamano]

Thanks.

On Tue, Mar 15, 2016 at 1:17 PM, Johannes Schindelin
 wrote:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.7.3 is available from:
>
> https://git-for-windows.github.io/
>
> Changes since Git for Windows v2.7.2 (February 23rd 2016)
>
> New Features
>
>   • Git for Windows now ships with the Git Credential Manager for
> Windows.
>
> Bug Fixes
>
>   • We now handle UTF-8 merge and squash messages correctly in Git GUI.
>   • When trying to modify a repository config outside of any Git
> worktree, git config no longer creates a .git/ directory but prints
> an appropriate error message instead.
>   • A new version of Git for Windows' SDK was released.
>   • We no longer show asterisks when reading the username for
> credentials.
>
> Filename | SHA-256  | --- Git-2.7.3-64-bit.exe |
> 382d30d38b5c88690864bb46be0a9c5f53b7046e7a6485dbcede602c41cae9a2
> Git-2.7.3-32-bit.exe |
> e38ddcc2c17390ffec0ca4d5c4fb948b5b4874ea0c522d5180cf2ee7e63f76bd
> PortableGit-2.7.3-64-bit.7z.exe |
> f5b39244869efcfac57c9a9f1d75119de0121bc8aa260d1824dfe5902f9a3f60
> PortableGit-2.7.3-32-bit.7z.exe |
> 82df6b1e8ca8550d7267641e32c6b736f0687e35dc3b772b21914706f13cdea4
> Git-2.7.3-64-bit.tar.bz2 |
> dd81fe03c83e255382816a5db1427b284288fe21b4f89cbe3b1ff21af8d0ef1c
> Git-2.7.3-32-bit.tar.bz2 |
> 3b845331cf91e2a1677ba959d07491c6b04b8bdfc7900236a201d0f8c9863197
--
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

[ANNOUNCE] Git for Windows 2.7.3

[Johannes Schindelin]

Dear Git users,

It is my pleasure to announce that Git for Windows 2.7.3 is available from:

https://git-for-windows.github.io/

Changes since Git for Windows v2.7.2 (February 23rd 2016)

New Features

  ??? Git for Windows now ships with the Git Credential Manager for
Windows.

Bug Fixes

  ??? We now handle UTF-8 merge and squash messages correctly in Git GUI.
  ??? When trying to modify a repository config outside of any Git
worktree, git config no longer creates a .git/ directory but prints
an appropriate error message instead.
  ??? A new version of Git for Windows' SDK was released.
  ??? We no longer show asterisks when reading the username for
credentials.

Filename | SHA-256  | --- Git-2.7.3-64-bit.exe |
382d30d38b5c88690864bb46be0a9c5f53b7046e7a6485dbcede602c41cae9a2
Git-2.7.3-32-bit.exe |
e38ddcc2c17390ffec0ca4d5c4fb948b5b4874ea0c522d5180cf2ee7e63f76bd
PortableGit-2.7.3-64-bit.7z.exe |
f5b39244869efcfac57c9a9f1d75119de0121bc8aa260d1824dfe5902f9a3f60
PortableGit-2.7.3-32-bit.7z.exe |
82df6b1e8ca8550d7267641e32c6b736f0687e35dc3b772b21914706f13cdea4
Git-2.7.3-64-bit.tar.bz2 |
dd81fe03c83e255382816a5db1427b284288fe21b4f89cbe3b1ff21af8d0ef1c
Git-2.7.3-32-bit.tar.bz2 |
3b845331cf91e2a1677ba959d07491c6b04b8bdfc7900236a201d0f8c9863197

Re: [PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 12:54 AM, Eric Sunshine  wrote:
>> As Eric Sunshine mentioned ($gmane.org/288811), it would react
>> according to the multiple verbosity level and since its not currently
>> defined in `commit` it will react as it is reacting when verbosity
>> level is 1.
>
> I get the feeling that you missed SZEDER's point which was that
> git-commit already behaves differently when --verbose is specified
> multiple times. (I hadn't gotten around to reviewing that part of the
> code yet, so I'm glad that SZEDER saved me the effort.)

My bad! I missed SZEDER's point.

> The new config variable, which is boolean, doesn't mesh well with
> multiple verbosity levels. For instance, with a combination of
> commit.verbose=true and a single --verbose, the code will think that
> --verbose was given twice and use verbosity level 2, which is not at
> all intuitive and would be surprising for the user. So, SZEDER was
> asking how this impedance mismatch can be rectified.
>
> A possibly sane approach would be to make commit.verbose be a
> verbosity level rather than boolean, and behave as follows:
>
> 1. if --verbose is used (one or more), completely ignore commit.verbose.
> 2. else, if commit.verbose is set, use it.
> 3. else, default behavior.
>
> I'm not sure if this makes sense, but as a convenience, maybe also
> recognize "true" and "false" as aliases for 1 and 0, respectively, for
> values of commit.verbose.
>
> And, of course you'd want to test these behaviors.

This seems a good approach to me. I have two ideas of implementing it.
First one to introduce a new variable `config_verbose` to store the
value read by the config. Till then the value of verbose can be set
through command line options. Depending on the situation as you
described, it can then make the modification. Another approach would
be to swap the places where the configuration file is read and where
arguments are parsed. I personally think the first approach as more
appropriate as in the latter one, there might be some parts of code
which can break. As for the part of alias, I can use the method
git_config_bool_or_int() which takes care about aliasing for me. I
will also write tests for this behavior.
--
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 1/3] submodule: add test to demonstrate that shallow recursive clones fail

[Junio C Hamano]

Stefan Beller  writes:

>> +test_expect_failure shallow-clone-recursive '
>> +   URL="file://$(pwd | sed "s/[[:space:]]/%20/g")/repo" &&
>
> This would break if the test suite is in a path containing any other white 
> space
> than U+0020 such as a tab? (Not that I am encouraging using such paths...)

Good spotting.

I thought use of [[:named character classes:]] is explicitly
disallowed by CodingGuidelines.

--
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 1/4] lib-gpg: drop unnecessary "missing GPG" warning

[Eric Sunshine]

On Tue, Mar 15, 2016 at 3:33 PM, Johannes Schindelin
 wrote:
> On Sun, 6 Mar 2016, Eric Sunshine wrote:
>> I also sneaked in a minor style cleanup.
>
> Isn't this "snuck"?

I'm no grammarian, but [1] says either would be fine (and we know that
the Internet never lies).

[1]: http://grammarist.com/usage/sneaked-snuck/
--
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 1/3] submodule: add test to demonstrate that shallow recursive clones fail

[Stefan Beller]

On Sun, Dec 20, 2015 at 3:19 PM,   wrote:
> From: Lars Schneider 
>
> "git clone --recursive --depth 1 --single-branch " clones the
> submodules successfully. However, it does not obey "--depth 1" for
> submodule cloning.

I am about to resend "[RFC/PATCH] clone: add `--shallow-submodules` flag"
which would need tests and I thought about this series as tests.

I assume patch 2 (fixing a broken && chain in tests) made it through,
but patch 1 and 3 did not? I may pick up ideas from here as it will be
slightly different tests I'd guess.


> +test_expect_failure shallow-clone-recursive '
> +   URL="file://$(pwd | sed "s/[[:space:]]/%20/g")/repo" &&

This would break if the test suite is in a path containing any other white space
than U+0020 such as a tab? (Not that I am encouraging using such paths...)

Thanks,
Stefan


> +   echo $URL &&
> +   git clone --recursive --depth 1 --single-branch $URL clone-recursive 
> &&
> +   (
> +   cd "clone-recursive" &&
> +   git log --oneline >lines &&
> +   test_line_count = 1 lines
> +   ) &&
> +   (
> +   cd "clone-recursive/submodule" &&
> +   git log --oneline >lines &&
> +   test_line_count = 1 lines
> +   )
> +'
> +
> +test_done
> --
> 2.5.1
>
--
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/RFC/GSoC 17/17] rebase-interactive: introduce interactive backend for builtin rebase

[Johannes Schindelin]

Hi Paul,

On Wed, 16 Mar 2016, Paul Tan wrote:

> Even with interactive rebase out-of-bounds,

It is not really "out-of-bounds". It's more like: hold off integrating it
until I'm done with v1 of the rebase--helper that does interactive
rebase's heavy lifting (which should happen pretty soon).

> I don't think it's a dead end though:
> 
> 1. git-rebase--am.sh, git-rebase--merge.sh and git-rebase.sh can be
> rewritten to C, and call git-rebase--interactive.sh externally, like
> what Duy demonstrated in his patch series. The timings show that am
> and merge rebase still benefit, and that way we will be closer to a
> git-rebase in full C.
> 
> 2. git-commit can be libified, so that we can access its functionality
> directly. (sequencer.c runs it once per commit, rebase-interactive
> uses it for squashes etc.)

Both look sound. With 1) I would also suggest a rebase--helper approach,
though. That way, you do not need to break the test suite at all but can
flip the switch at the end of the patch series.

> Or would that be stepping on your toes?

Nope. 2) is related to what I do, but I modified sequencer.c's
run_git_commit() (which uses run_command()). Your plan would make that
even better (although the edit phase is of course not the
performance-critical part that we want to enhance).

Ciao,
Dscho
--
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] l10n: de.po: translate 22 new messages

[Matthias Rüster]

Acked-by: Matthias Rüster 

Am 15.03.2016 um 18:12 schrieb Ralf Thielow:

Translate 22 new messages came from git.pot update in f1522b2
(l10n: git.pot: v2.8.0 round 2 (21 new, 1 removed)) and a5a4168
(l10n: git.pot: Add one new message for Git 2.8.0).

Signed-off-by: Ralf Thielow 
---
  po/de.po | 68 
  1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/po/de.po b/po/de.po
index edee6db..7093139 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1150,14 +1150,14 @@ msgid "unrecognized format: %%(%s)"
  msgstr "nicht erkanntes Format: %%(%s)"

  #: ref-filter.c:77
-#, fuzzy, c-format
+#, c-format
  msgid "%%(body) does not take arguments"
-msgstr "--worktrees akzeptiert keine weiteren Argumente"
+msgstr "%%(body) akzeptiert keine Argumente"

  #: ref-filter.c:84
-#, fuzzy, c-format
+#, c-format
  msgid "%%(subject) does not take arguments"
-msgstr "--worktrees akzeptiert keine weiteren Argumente"
+msgstr "%%(subject) akzeptiert keine Argumente"

  #: ref-filter.c:101
  #, c-format
@@ -1200,14 +1200,14 @@ msgid "positive width expected with the %%(align) atom"
  msgstr "Positive Breitenangabe für %%(align) erwartet"

  #: ref-filter.c:244
-#, fuzzy, c-format
+#, c-format
  msgid "malformed field name: %.*s"
-msgstr "Missgebildeter Objektname %s"
+msgstr "Fehlerhafter Feldname: %.*s"

  #: ref-filter.c:270
-#, fuzzy, c-format
+#, c-format
  msgid "unknown field name: %.*s"
-msgstr "unbekanntes Argument für Option --mirror: %s"
+msgstr "Unbekannter Feldname: %.*s"

  #: ref-filter.c:372
  #, c-format
@@ -1215,33 +1215,33 @@ msgid "format: %%(end) atom used without corresponding 
atom"
  msgstr "Format: %%(end) Atom ohne zugehöriges Atom verwendet"

  #: ref-filter.c:424
-#, fuzzy, c-format
+#, c-format
  msgid "malformed format string %s"
-msgstr "Fehlerhafter Ident-String: '%s'"
+msgstr "Fehlerhafter Formatierungsstring %s"

  #: ref-filter.c:878
  msgid ":strip= requires a positive integer argument"
-msgstr ""
+msgstr ":strip= erfordert eine positive Ganzzahl als Argument"

  #: ref-filter.c:883
-#, fuzzy, c-format
+#, c-format
  msgid "ref '%s' does not have %ld components to :strip"
-msgstr "Pfad '%s' hat nicht alle notwendigen Versionen."
+msgstr "Referenz '%s' hat keine %ld Komponenten für :strip"

  #: ref-filter.c:1046
-#, fuzzy, c-format
+#, c-format
  msgid "unknown %.*s format %s"
-msgstr "Unbekannter Commit %s"
+msgstr "Unbekanntes %.*s Format %s"

  #: ref-filter.c:1066 ref-filter.c:1097
-#, fuzzy, c-format
+#, c-format
  msgid "missing object %s for %s"
-msgstr "fehlende Objekte erlauben"
+msgstr "Objekt %s fehlt für %s"

  #: ref-filter.c:1069 ref-filter.c:1100
  #, c-format
  msgid "parse_object_buffer failed on %s for %s"
-msgstr ""
+msgstr "parse_object_buffer bei %s für %s fehlgeschlagen"

  #: ref-filter.c:1311
  #, c-format
@@ -1249,14 +1249,14 @@ msgid "malformed object at '%s'"
  msgstr "fehlerhaftes Objekt bei '%s'"

  #: ref-filter.c:1373
-#, fuzzy, c-format
+#, c-format
  msgid "ignoring ref with broken name %s"
-msgstr "ignoriere Vorlage %s"
+msgstr "Ignoriere Referenz mit fehlerhaftem Namen %s"

  #: ref-filter.c:1378
-#, fuzzy, c-format
+#, c-format
  msgid "ignoring broken ref %s"
-msgstr "ignoriere Vorlage %s"
+msgstr "Ignoriere fehlerhafte Referenz %s"

  #: ref-filter.c:1651
  #, c-format
@@ -1680,17 +1680,17 @@ msgstr "Fehler beim Lesen von %s"

  #: sha1_file.c:1080
  msgid "offset before end of packfile (broken .idx?)"
-msgstr ""
+msgstr "Offset vor Ende der Packdatei (fehlerhafte Indexdatei?)"

  #: sha1_file.c:2459
  #, c-format
  msgid "offset before start of pack index for %s (corrupt index?)"
-msgstr ""
+msgstr "Offset vor Beginn des Pack-Index für %s (beschädigter Index?)"

  #: sha1_file.c:2463
  #, c-format
  msgid "offset beyond end of pack index for %s (truncated index?)"
-msgstr ""
+msgstr "Offset hinter Ende des Pack-Index für %s (abgeschnittener Index?)"

  #: sha1_name.c:462
  msgid ""
@@ -1743,9 +1743,9 @@ msgid "staging updated .gitmodules failed"
  msgstr "Konnte aktualisierte .gitmodules-Datei nicht zum Commit vormerken"

  #: trailer.c:237
-#, fuzzy, c-format
+#, c-format
  msgid "running trailer command '%s' failed"
-msgstr "Zusammenführen der \"Tree\"-Objekte %s und %s fehlgeschlagen"
+msgstr "Ausführen des Anhang-Befehls '%s' fehlgeschlagen"

  #: trailer.c:492 trailer.c:496 trailer.c:500 trailer.c:554 trailer.c:558
  #: trailer.c:562
@@ -4324,9 +4324,8 @@ msgid "HEAD is now at"
  msgstr "HEAD ist jetzt bei"

  #: builtin/checkout.c:665 builtin/clone.c:659
-#, fuzzy
  msgid "unable to update HEAD"
-msgstr "Konnte HEAD nicht auflösen."
+msgstr "Konnte HEAD nicht aktualisieren."

  #: builtin/checkout.c:669
  #, c-format
@@ -4864,6 +4863,8 @@ msgid ""
  "No directory name could be guessed.\n"
  "Please specify a directory on the command line"
  msgstr ""
+"Konnte keinen Verzeichnisnamen erraten.\n"
+"Bitte geben Sie ein Verzeichnis auf der Befehlszeile an."

  #: builtin/clone.c:305
  #, 

Re: [PATCH v2 0/4] make t6302 usable even without GPG installed

[Johannes Schindelin]

Hi Eric,

On Sun, 6 Mar 2016, Eric Sunshine wrote:

> This is a re-roll of [1] which aims to allow t6302 to be run even
> without GPG installed.

What a beautiful story this patch series tells. Truly a pleasure to
review.

Thanks!
Dscho
--
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 1/4] lib-gpg: drop unnecessary "missing GPG" warning

[Johannes Schindelin]

Hi Eric,

On Sun, 6 Mar 2016, Eric Sunshine wrote:

> I also sneaked in a minor style cleanup.

Isn't this "snuck"?

The patch is fine.

Ciao,
Dscho
--
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] submodule-config: use hashmap_iter_first()

[Eric Sunshine]

On Tue, Mar 15, 2016 at 3:21 PM, Stefan Beller  wrote:
> On Tue, Mar 15, 2016 at 12:13 PM, Alexander Kuleshov
>  wrote:
>> from the  for simplification.
>
> I think what Eric wanted to point out, was to not have a continuous sentence
> from commit message header to body.

Yes, thanks for clarifying that.

> Either leave the body blank (as it is obvious) or write a whole sentence 
> there:
>
>   [PATCH v2] submodule-config: use hashmap_iter_first()
>
>   The hashmap API offers the `hashmap_iter_first` function as initializing and
>   getting the first entry is a common pattern. Use that instead of
> doing initialization
>   by hand and then get the first entry.
--
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] commit: add a commit.verbose config variable

[Eric Sunshine]

On Tue, Mar 15, 2016 at 3:00 PM, Pranit Bauva  wrote:
> On Tue, Mar 15, 2016 at 5:01 PM, SZEDER Gábor  wrote:
>> You made 'commit.verbose' a boolean, so either verbose or not, ...
>> ... but note these context lines telling us that --verbose can be
>> specified not just once but twice (and who knows what the future may
>> bring).  This raises some not entirely rhetorical questions:
>>
>>   - What does 'git config commit.verbose true && git commit --verbose'
>> do?
>
> This is a nice thought which didn't strike me!
>
> As Eric Sunshine mentioned ($gmane.org/288811), it would react
> according to the multiple verbosity level and since its not currently
> defined in `commit` it will react as it is reacting when verbosity
> level is 1.

I get the feeling that you missed SZEDER's point which was that
git-commit already behaves differently when --verbose is specified
multiple times. (I hadn't gotten around to reviewing that part of the
code yet, so I'm glad that SZEDER saved me the effort.)

The new config variable, which is boolean, doesn't mesh well with
multiple verbosity levels. For instance, with a combination of
commit.verbose=true and a single --verbose, the code will think that
--verbose was given twice and use verbosity level 2, which is not at
all intuitive and would be surprising for the user. So, SZEDER was
asking how this impedance mismatch can be rectified.

A possibly sane approach would be to make commit.verbose be a
verbosity level rather than boolean, and behave as follows:

1. if --verbose is used (one or more), completely ignore commit.verbose.
2. else, if commit.verbose is set, use it.
3. else, default behavior.

I'm not sure if this makes sense, but as a convenience, maybe also
recognize "true" and "false" as aliases for 1 and 0, respectively, for
values of commit.verbose.

And, of course you'd want to test these behaviors.
--
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: [GSOC] Microproject "Move ~/.git-credential-cache to ~/.config/git"

[Jeff King]

On Tue, Mar 15, 2016 at 05:48:18AM +, 惠轶群 wrote:

> On Tue, Mar 15, 2016, 11:13 AM Jeff King  wrote:
> > The socket is inherently ephemeral, and designed to go
> > away after a few minutes (and the program designed to run sanely when it
> > does not exist).
> 
> I agree.
> 
> > So yes, when you switch from older git to newer git, you might
> > technically have a cache-daemon running that you _could_ contact, but
> > don't find it. But I don't think it's a big deal in practice, and not
> > worth designing around
> 
> Yes, it's OK with git itself. What I worry about is that this change break
> some third-party tools. Does it matter?

I don't think so. I suppose one could have a script that tests for the
existence of the socket or something. But then, I don't think "use the
old directory if it exists" really solves that. Such a script would work
on people who had already run the old version of credential-cache, and
break on new ones.

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

Re: [PATCH v2] submodule-config: use hashmap_iter_first()

[Stefan Beller]

On Tue, Mar 15, 2016 at 12:13 PM, Alexander Kuleshov
 wrote:
> from the  for simplification.

I think what Eric wanted to point out, was to not have a continuous sentence
from commit message header to body.

Either leave the body blank (as it is obvious) or write a whole sentence there:

  [PATCH v2] submodule-config: use hashmap_iter_first()

  The hashmap API offers the `hashmap_iter_first` function as initializing and
  getting the first entry is a common pattern. Use that instead of
doing initialization
  by hand and then get the first entry.



>
> Signed-off-by: Alexander Kuleshov 
> Reviewed-by: Stefan Beller 
> ---
> Changelog: added missed Signof-off-by and function name fixed
> in the commit message.
>
>  submodule-config.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/submodule-config.c b/submodule-config.c
> index b82d1fb..8ac5031 100644
> --- a/submodule-config.c
> +++ b/submodule-config.c
> @@ -405,8 +405,7 @@ static const struct submodule *config_from(struct 
> submodule_cache *cache,
> struct hashmap_iter iter;
> struct submodule_entry *entry;
>
> -   hashmap_iter_init(&cache->for_name, &iter);
> -   entry = hashmap_iter_next(&iter);
> +   entry = hashmap_iter_first(&cache->for_name, &iter);
> if (!entry)
> return NULL;
> return entry->config;
> --
> 2.8.0.rc2.216.g1477fb2.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
--
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] submodule-config: use hashmap_iter_first()

[Alexander Kuleshov]

from the  for simplification.

Signed-off-by: Alexander Kuleshov 
Reviewed-by: Stefan Beller 
---
Changelog: added missed Signof-off-by and function name fixed
in the commit message.

 submodule-config.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/submodule-config.c b/submodule-config.c
index b82d1fb..8ac5031 100644
--- a/submodule-config.c
+++ b/submodule-config.c
@@ -405,8 +405,7 @@ static const struct submodule *config_from(struct 
submodule_cache *cache,
struct hashmap_iter iter;
struct submodule_entry *entry;
 
-   hashmap_iter_init(&cache->for_name, &iter);
-   entry = hashmap_iter_next(&iter);
+   entry = hashmap_iter_first(&cache->for_name, &iter);
if (!entry)
return NULL;
return entry->config;
-- 
2.8.0.rc2.216.g1477fb2.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: [PATCH] submodule-config: use hashmap_iter_init()

[Alexander Kuleshov]

On Wed, Mar 16, 2016 at 1:08 AM, Stefan Beller  wrote:
> The change looks correct to me. But as Eric said, the commit message
> needs work and a sign off. With that,
> Reviewed-by: Stefan Beller 

Ah, yes, forgot to pass `-s` to commit command. Sorry for noise guys,
will resend
the patch.
--
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] submodule-config: use hashmap_iter_init()

[Stefan Beller]

On Tue, Mar 15, 2016 at 11:58 AM, Eric Sunshine  wrote:
> On Tue, Mar 15, 2016 at 2:25 PM, Alexander Kuleshov
>  wrote:
>> submodule-config: use hashmap_iter_init()
>
> Did you mean s/init/first/ ?
>
>> from the  for simplification.
>
> Sentence fragment...
>
> Missing sign-off.
>
>> ---
>> diff --git a/submodule-config.c b/submodule-config.c
>> index b82d1fb..8ac5031 100644
>> --- a/submodule-config.c
>> +++ b/submodule-config.c
>> @@ -405,8 +405,7 @@ static const struct submodule *config_from(struct 
>> submodule_cache *cache,
>> struct hashmap_iter iter;
>> struct submodule_entry *entry;
>>
>> -   hashmap_iter_init(&cache->for_name, &iter);
>> -   entry = hashmap_iter_next(&iter);
>> +   entry = hashmap_iter_first(&cache->for_name, &iter);

The change looks correct to me. But as Eric said, the commit message
needs work and a sign off. With that,
Reviewed-by: Stefan Beller 

Thanks,
Stefan
--
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] commit: add a commit.verbose config variable

[Pranit Bauva]

On Tue, Mar 15, 2016 at 5:01 PM, SZEDER Gábor  wrote:

> You made 'commit.verbose' a boolean, so either verbose or not, ...
> ... but note these context lines telling us that --verbose can be
> specified not just once but twice (and who knows what the future may
> bring).  This raises some not entirely rhetorical questions:
>
>   - What does 'git config commit.verbose true && git commit --verbose'
> do?

This is a nice thought which didn't strike me!

As Eric Sunshine mentioned ($gmane.org/288811), it would react
according to the multiple verbosity level and since its not currently
defined in `commit` it will react as it is reacting when verbosity
level is 1.

If let's say we incorporate this behavior now, it can lead to
confusion for the user (not developer) as to whether `commit` supports
multiple verbosity.

>   - Should 'commit.verbose' only care about the convenience of those
> who always prever '--verbose', or about those who like '-v -v',
> too?
>
>   - If the latter, i.e. 'commit.verbose' should cater for '-v -v' as
> well, then what should 'git config commit.verbose " two>" && git commit --verbose' do?

If I was the user, I would use multiple levels of verbosity only where
I would feel that there is some problem happening with the commit that
is in progress. Having an "awkward" commit isn't usual and definitely
not every time. Though if in future it is required, We can add edit
the line namely :

 if(!strcmp(k, "commit.verbose")) {
- verbose = git_config_bool(k, v);
+verbose = git_config_int(k, v);
 return 0;
 }

Additionally we will have to define scenarios and mention them in the
documentation as to how `commit` will react as this cannot be known by
intuition. This would complicate things for the user who is reading
the man pages.

Regards,
Pranit Bauva
--
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] submodule-config: use hashmap_iter_init()

[Eric Sunshine]

On Tue, Mar 15, 2016 at 2:25 PM, Alexander Kuleshov
 wrote:
> submodule-config: use hashmap_iter_init()

Did you mean s/init/first/ ?

> from the  for simplification.

Sentence fragment...

Missing sign-off.

> ---
> diff --git a/submodule-config.c b/submodule-config.c
> index b82d1fb..8ac5031 100644
> --- a/submodule-config.c
> +++ b/submodule-config.c
> @@ -405,8 +405,7 @@ static const struct submodule *config_from(struct 
> submodule_cache *cache,
> struct hashmap_iter iter;
> struct submodule_entry *entry;
>
> -   hashmap_iter_init(&cache->for_name, &iter);
> -   entry = hashmap_iter_next(&iter);
> +   entry = hashmap_iter_first(&cache->for_name, &iter);
> if (!entry)
> return NULL;
> return entry->config;
> --
--
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] git-p4: map a P4 user to Git author name and email address

[Luke Diamand]

Yes please.


On 15 March 2016 at 16:52, Junio C Hamano  wrote:
> Luke Diamand  writes:
>
>>> Is the patch uninteresting for git-p4 as it handles only an occasional
>>> exception or did the patch get lost in the noise? :-)
>>
>> I thought it was useful; I hadn't realised that it was needed for deleted 
>> users.
>>
>> Luke
>
> So..., should I just pick it up and queue with your Reviewed-by:?
>
> Thanks.
--
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] submodule-config: use hashmap_iter_init()

[Alexander Kuleshov]

from the  for simplification.
---
 submodule-config.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/submodule-config.c b/submodule-config.c
index b82d1fb..8ac5031 100644
--- a/submodule-config.c
+++ b/submodule-config.c
@@ -405,8 +405,7 @@ static const struct submodule *config_from(struct 
submodule_cache *cache,
struct hashmap_iter iter;
struct submodule_entry *entry;
 
-   hashmap_iter_init(&cache->for_name, &iter);
-   entry = hashmap_iter_next(&iter);
+   entry = hashmap_iter_first(&cache->for_name, &iter);
if (!entry)
return NULL;
return entry->config;
-- 
2.8.0.rc2.216.g1477fb2.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: [Q] updates to gitk, git-gui and git-svn for 2.8?

[Junio C Hamano]

Eric Wong  writes:

> Anyways, we'll let that cook a while and the other two patches
> can be had at:
>
> The following changes since commit db6696f653b917509dac1ac13b922e12773a84ff:
>
>   Merge branch 'mg/wt-status-mismarked-i18n' (2016-03-14 10:46:17 -0700)
>
> are available in the git repository at:
>
>   git://bogomips.org/git-svn.git svn-glob
>
> for you to fetch changes up to 62335bbbc747c96636b5ce9917b156304c732eaf:
>
>   git-svn: shorten glob error message (2016-03-15 01:35:39 +)
>
> 
> Eric Wong (1):
>   git-svn: shorten glob error message
>
> Victor Leschuk (1):
>   git-svn: loosen config globs limitations
>
>  Documentation/git-svn.txt  |  12 ++
>  perl/Git/SVN/GlobSpec.pm   |  18 ++-
>  t/t9108-git-svn-glob.sh|   9 +-
>  t/t9109-git-svn-multi-glob.sh  |   9 +-
>  t/t9168-git-svn-partially-globbed-names.sh | 223 
> +
>  5 files changed, 258 insertions(+), 13 deletions(-)
>  create mode 100755 t/t9168-git-svn-partially-globbed-names.sh

Thanks.  Pulled.
--
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

git checkout --theirs fails

[Phil Susi]

I'm doing a rebase and got some conflicts.  I just want to take their
version of all files, but git checkout --theirs complains:

--ours/--theirs' cannot be used with switching branches

What gives?  I'm not *trying* to switch branches.  I just want to
resolve the conflict by taking their version.  If I try git checkout
--theirs ., then it complains that not every single file in the
directory has a "their" version.  So?  Take the ones that do.

--
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] l10n: de.po: translate 22 new messages

[Ralf Thielow]

Translate 22 new messages came from git.pot update in f1522b2
(l10n: git.pot: v2.8.0 round 2 (21 new, 1 removed)) and a5a4168
(l10n: git.pot: Add one new message for Git 2.8.0).

Signed-off-by: Ralf Thielow 
---
 po/de.po | 68 
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/po/de.po b/po/de.po
index edee6db..7093139 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1150,14 +1150,14 @@ msgid "unrecognized format: %%(%s)"
 msgstr "nicht erkanntes Format: %%(%s)"
 
 #: ref-filter.c:77
-#, fuzzy, c-format
+#, c-format
 msgid "%%(body) does not take arguments"
-msgstr "--worktrees akzeptiert keine weiteren Argumente"
+msgstr "%%(body) akzeptiert keine Argumente"
 
 #: ref-filter.c:84
-#, fuzzy, c-format
+#, c-format
 msgid "%%(subject) does not take arguments"
-msgstr "--worktrees akzeptiert keine weiteren Argumente"
+msgstr "%%(subject) akzeptiert keine Argumente"
 
 #: ref-filter.c:101
 #, c-format
@@ -1200,14 +1200,14 @@ msgid "positive width expected with the %%(align) atom"
 msgstr "Positive Breitenangabe für %%(align) erwartet"
 
 #: ref-filter.c:244
-#, fuzzy, c-format
+#, c-format
 msgid "malformed field name: %.*s"
-msgstr "Missgebildeter Objektname %s"
+msgstr "Fehlerhafter Feldname: %.*s"
 
 #: ref-filter.c:270
-#, fuzzy, c-format
+#, c-format
 msgid "unknown field name: %.*s"
-msgstr "unbekanntes Argument für Option --mirror: %s"
+msgstr "Unbekannter Feldname: %.*s"
 
 #: ref-filter.c:372
 #, c-format
@@ -1215,33 +1215,33 @@ msgid "format: %%(end) atom used without corresponding 
atom"
 msgstr "Format: %%(end) Atom ohne zugehöriges Atom verwendet"
 
 #: ref-filter.c:424
-#, fuzzy, c-format
+#, c-format
 msgid "malformed format string %s"
-msgstr "Fehlerhafter Ident-String: '%s'"
+msgstr "Fehlerhafter Formatierungsstring %s"
 
 #: ref-filter.c:878
 msgid ":strip= requires a positive integer argument"
-msgstr ""
+msgstr ":strip= erfordert eine positive Ganzzahl als Argument"
 
 #: ref-filter.c:883
-#, fuzzy, c-format
+#, c-format
 msgid "ref '%s' does not have %ld components to :strip"
-msgstr "Pfad '%s' hat nicht alle notwendigen Versionen."
+msgstr "Referenz '%s' hat keine %ld Komponenten für :strip"
 
 #: ref-filter.c:1046
-#, fuzzy, c-format
+#, c-format
 msgid "unknown %.*s format %s"
-msgstr "Unbekannter Commit %s"
+msgstr "Unbekanntes %.*s Format %s"
 
 #: ref-filter.c:1066 ref-filter.c:1097
-#, fuzzy, c-format
+#, c-format
 msgid "missing object %s for %s"
-msgstr "fehlende Objekte erlauben"
+msgstr "Objekt %s fehlt für %s"
 
 #: ref-filter.c:1069 ref-filter.c:1100
 #, c-format
 msgid "parse_object_buffer failed on %s for %s"
-msgstr ""
+msgstr "parse_object_buffer bei %s für %s fehlgeschlagen"
 
 #: ref-filter.c:1311
 #, c-format
@@ -1249,14 +1249,14 @@ msgid "malformed object at '%s'"
 msgstr "fehlerhaftes Objekt bei '%s'"
 
 #: ref-filter.c:1373
-#, fuzzy, c-format
+#, c-format
 msgid "ignoring ref with broken name %s"
-msgstr "ignoriere Vorlage %s"
+msgstr "Ignoriere Referenz mit fehlerhaftem Namen %s"
 
 #: ref-filter.c:1378
-#, fuzzy, c-format
+#, c-format
 msgid "ignoring broken ref %s"
-msgstr "ignoriere Vorlage %s"
+msgstr "Ignoriere fehlerhafte Referenz %s"
 
 #: ref-filter.c:1651
 #, c-format
@@ -1680,17 +1680,17 @@ msgstr "Fehler beim Lesen von %s"
 
 #: sha1_file.c:1080
 msgid "offset before end of packfile (broken .idx?)"
-msgstr ""
+msgstr "Offset vor Ende der Packdatei (fehlerhafte Indexdatei?)"
 
 #: sha1_file.c:2459
 #, c-format
 msgid "offset before start of pack index for %s (corrupt index?)"
-msgstr ""
+msgstr "Offset vor Beginn des Pack-Index für %s (beschädigter Index?)"
 
 #: sha1_file.c:2463
 #, c-format
 msgid "offset beyond end of pack index for %s (truncated index?)"
-msgstr ""
+msgstr "Offset hinter Ende des Pack-Index für %s (abgeschnittener Index?)"
 
 #: sha1_name.c:462
 msgid ""
@@ -1743,9 +1743,9 @@ msgid "staging updated .gitmodules failed"
 msgstr "Konnte aktualisierte .gitmodules-Datei nicht zum Commit vormerken"
 
 #: trailer.c:237
-#, fuzzy, c-format
+#, c-format
 msgid "running trailer command '%s' failed"
-msgstr "Zusammenführen der \"Tree\"-Objekte %s und %s fehlgeschlagen"
+msgstr "Ausführen des Anhang-Befehls '%s' fehlgeschlagen"
 
 #: trailer.c:492 trailer.c:496 trailer.c:500 trailer.c:554 trailer.c:558
 #: trailer.c:562
@@ -4324,9 +4324,8 @@ msgid "HEAD is now at"
 msgstr "HEAD ist jetzt bei"
 
 #: builtin/checkout.c:665 builtin/clone.c:659
-#, fuzzy
 msgid "unable to update HEAD"
-msgstr "Konnte HEAD nicht auflösen."
+msgstr "Konnte HEAD nicht aktualisieren."
 
 #: builtin/checkout.c:669
 #, c-format
@@ -4864,6 +4863,8 @@ msgid ""
 "No directory name could be guessed.\n"
 "Please specify a directory on the command line"
 msgstr ""
+"Konnte keinen Verzeichnisnamen erraten.\n"
+"Bitte geben Sie ein Verzeichnis auf der Befehlszeile an."
 
 #: builtin/clone.c:305
 #, c-format
@@ -4945,9 +4946,9 @@ msgid "remote did not send all necessary objects"
 msgstr "Remote-Repository hat ni

[PATCH 2/2] pull --rebase: add --[no-]autostash flag

[Mehul Jain]

If rebase.autoStash configuration variable is set, there is no way to
override it for "git pull --rebase" from the command line.

Teach "git pull --rebase" the --[no-]autostash command line flag which
overrides the current value of rebase.autoStash, if set. As "git rebase"
understands the --[no-]autostash option, it's just a matter of passing
the option to underlying "git rebase" when "git pull --rebase" is called.

Helped-by: Matthieu Moy 
Helped-by: Junio C Hamano 
Helped-by: Paul Tan 
Helped-by: Eric Sunshine 
Signed-off-by: Mehul Jain 
---
previous patches: http://thread.gmane.org/gmane.comp.version-control.git/287709

 Documentation/git-pull.txt |  9 +
 builtin/pull.c | 13 +++--
 t/t5520-pull.sh| 39 +++
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index a62a2a6..a070ec9 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -128,6 +128,15 @@ unless you have read linkgit:git-rebase[1] carefully.
 --no-rebase::
Override earlier --rebase.
 
+--autostash::
+--no-autostash::
+   Before starting rebase, stash local modifications away (see
+   linkgit:git-stash.txt[1]) if needed, and apply the stash when
+   done (this option is only valid when "--rebase" is used).
++
+`--no-autostash` is useful to override the `rebase.autoStash`
+configuration variable (see linkgit:git-config[1]).
+
 Options related to fetching
 ~~~
 
diff --git a/builtin/pull.c b/builtin/pull.c
index 43353f9..c48e28a 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -86,6 +86,7 @@ static char *opt_commit;
 static char *opt_edit;
 static char *opt_ff;
 static char *opt_verify_signatures;
+static int opt_autostash = -1;
 static int config_autostash;
 static struct argv_array opt_strategies = ARGV_ARRAY_INIT;
 static struct argv_array opt_strategy_opts = ARGV_ARRAY_INIT;
@@ -150,6 +151,8 @@ static struct option pull_options[] = {
OPT_PASSTHRU(0, "verify-signatures", &opt_verify_signatures, NULL,
N_("verify that the named commit has a valid GPG signature"),
PARSE_OPT_NOARG),
+   OPT_BOOL(0, "autostash", &opt_autostash,
+   N_("automatically stash/stash pop before and after rebase")),
OPT_PASSTHRU_ARGV('s', "strategy", &opt_strategies, N_("strategy"),
N_("merge strategy to use"),
0),
@@ -801,6 +804,7 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_pushv(&args, opt_strategy_opts.argv);
if (opt_gpg_sign)
argv_array_push(&args, opt_gpg_sign);
+   argv_array_push(&args, opt_autostash ? "--autostash" : 
"--no-autostash");
 
argv_array_push(&args, "--onto");
argv_array_push(&args, sha1_to_hex(merge_head));
@@ -851,12 +855,17 @@ int cmd_pull(int argc, const char **argv, const char 
*prefix)
if (is_null_sha1(orig_head) && !is_cache_unborn())
die(_("Updating an unborn branch with changes added to 
the index."));
 
-   if (config_autostash)
+   if (opt_autostash == -1)
+   opt_autostash = config_autostash;
+
+   if (!opt_autostash)
die_on_unclean_work_tree(prefix);
 
if (get_rebase_fork_point(rebase_fork_point, repo, *refspecs))
hashclr(rebase_fork_point);
-   }
+   } else
+   if (opt_autostash != -1)
+die(_("--[no-]autostash option is only valid with 
--rebase."));
 
if (run_fetch(repo, refspecs))
return 1;
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index c952d5e..85d9bea 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -255,6 +255,45 @@ test_expect_success 'pull --rebase succeeds with dirty 
working directory and reb
test "$(cat new_file)" = dirty &&
test "$(cat file)" = "modified again"
 '
+test_expect_success 'pull --rebase: --autostash overrides rebase.autostash' '
+   test_config rebase.autostash false &&
+   git reset --hard before-rebase &&
+   echo dirty >new_file &&
+   git add new_file &&
+   git pull --rebase --autostash . copy &&
+   test_cmp_rev HEAD^ copy &&
+   test "$(cat new_file)" = dirty &&
+   test "$(cat file)" = "modified again"
+'
+
+test_expect_success 'pull --rebase --autostash works with rebase.autostash set 
true' '
+   test_config rebase.autostash true &&
+   git reset --hard before-rebase &&
+   echo dirty >new_file &&
+   git add new_file &&
+   git pull --rebase --autostash . copy &&
+   test_cmp_rev HEAD^ copy &&
+   test "$(cat new_file)" = dirty &&
+   test "$(cat file)" = "modified again"
+'
+
+test_expect_success 'pull --rebase: --no-autostash overrides rebase.autostash' 
'
+   test_config rebase.autostash true &&
+   g

[PATCH 1/2] git-pull.c: introduce git_pull_config()

[Mehul Jain]

git-pull makes a seperate call to git_config_get_bool() to read the value
of "rebase.autostash", this can be reduced as a call to git_config() is
already there in the code.

Introduce a callback function git_pull_config() to read "rebase.autostash"
along with other variables.

Helped-by: Junio C Hamano 
Helped-by: Paul Tan 
Signed-off-by: Mehul Jain 
---
Previous patches: http://thread.gmane.org/gmane.comp.version-control.git/287709

Change: config_autostash initialized with 0 instead of -1

 builtin/pull.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index 10eff03..43353f9 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -86,6 +86,7 @@ static char *opt_commit;
 static char *opt_edit;
 static char *opt_ff;
 static char *opt_verify_signatures;
+static int config_autostash;
 static struct argv_array opt_strategies = ARGV_ARRAY_INIT;
 static struct argv_array opt_strategy_opts = ARGV_ARRAY_INIT;
 static char *opt_gpg_sign;
@@ -304,6 +305,17 @@ static enum rebase_type config_get_rebase(void)
 
return REBASE_FALSE;
 }
+/**
+ * Read config variables.
+ */
+static int git_pull_config(const char *var, const char *value, void *cb)
+{
+   if (!strcmp(var, "rebase.autostash")) {
+   config_autostash = git_config_bool(var, value);
+   return 0;
+   }
+   return git_default_config(var, value, cb);
+}
 
 /**
  * Returns 1 if there are unstaged changes, 0 otherwise.
@@ -823,7 +835,7 @@ int cmd_pull(int argc, const char **argv, const char 
*prefix)
if (opt_rebase < 0)
opt_rebase = config_get_rebase();
 
-   git_config(git_default_config, NULL);
+   git_config(git_pull_config, NULL);
 
if (read_cache_unmerged())
die_resolve_conflict("Pull");
@@ -835,13 +847,11 @@ int cmd_pull(int argc, const char **argv, const char 
*prefix)
hashclr(orig_head);
 
if (opt_rebase) {
-   int autostash = 0;
 
if (is_null_sha1(orig_head) && !is_cache_unborn())
die(_("Updating an unborn branch with changes added to 
the index."));
 
-   git_config_get_bool("rebase.autostash", &autostash);
-   if (!autostash)
+   if (config_autostash)
die_on_unclean_work_tree(prefix);
 
if (get_rebase_fork_point(rebase_fork_point, repo, *refspecs))
-- 
2.7.1.340.g69eb491.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

[L10N] Kickoff for Git v2.8.0 l10n round 3

[Jiang Xin]

Hi guys,

One tiny update triggered this round of l10n. Wait for your merge request.
Thank you.

-- Forwarded message --
From: Jiang Xin 
Date: 2016-03-16 0:51 GMT+08:00
Subject: [GIT PULL] l10n updates for 2.8.0 round 2
To: Junio C Hamano 


Hi Junio,

The following changes since commit db6696f653b917509dac1ac13b922e12773a84ff:

  Merge branch 'mg/wt-status-mismarked-i18n' (2016-03-14 10:46:17 -0700)

are available in the git repository at:

  git://github.com/git-l10n/git-po tags/l10n-2.8.0-rnd2

for you to fetch changes up to 5c0c220c53823e2a9ebe8e566e649ca30cd7e8e0:

  l10n: zh_CN: for git v2.8.0 l10n round 3 (2016-03-16 00:27:40 +0800)


l10n-2.8.0-rnd2


Audric Schiltknecht (1):
  l10n: fr.po: Correct case in sentence

Changwoo Ryu (2):
  l10n: ko.po: Update Korean translation
  l10n: ko: Update Korean translation

Christoph Hoopmann (1):
  l10n: de.po: fix typo

Dimitriy Ryazantcev (2):
  l10n: ru.po: update Russian translation
  l10n: ru.po: update Russian translation

Jean-Noel Avila (2):
  l10n: fr.po v2.8.0 round 1 2509t
  l10n: fr.po v2.8.0 round 2

Jiang Xin (12):
  l10n: git.pot: v2.8.0 round 1 (48 new, 16 removed)
  Merge branch 'master' of https://github.com/vnwildman/git
  Merge branch 'ko/merge-l10n' of https://github.com/changwoo/git-l10n-ko
  Merge branch 'master' of git://github.com/nafmo/git-l10n-sv
  l10n: zh_CN: for git v2.8.0 l10n round 1
  Merge branch 'master' of git://github.com/git-l10n/git-po
  l10n: git.pot: v2.8.0 round 2 (21 new, 1 removed)
  Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru
  l10n: zh_CN: for git v2.8.0 l10n round 2
  Merge branch 'master' of git://github.com/git-l10n/git-po
  l10n: git.pot: Add one new message for Git 2.8.0
  l10n: zh_CN: for git v2.8.0 l10n round 3

Peter Krefting (2):
  l10n: sv.po: Fix inconsistent translation of "progress meter"
  l10n: sv.po: Update Swedish translation (2509t0f0u)

Ralf Thielow (5):
  l10n: TEAMS: update Ralf Thielow's email address
  l10n: de.po: add space to abbreviation "z. B."
  l10n: de.po: fix interactive rebase message
  l10n: de.po: translate "command" as "Befehl"
  l10n: de.po: translate 48 new messages

Trần Ngọc Quân (1):
  l10n: vi.po (2509t): Updated Vietnamese translation

 po/TEAMS|2 +-
 po/de.po| 2993 +---
 po/fr.po| 3033 +++--
 po/git.pot  | 2881 +-
 po/ko.po| 3106 ---
 po/ru.po| 3018 ++---
 po/sv.po| 2895 +--
 po/vi.po| 2894 +--
 po/zh_CN.po | 3011 +++--
 9 files changed, 12830 insertions(+), 11003 deletions(-)

--
Jiang Xin
--
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] git-p4: map a P4 user to Git author name and email address

[Junio C Hamano]

Luke Diamand  writes:

>> Is the patch uninteresting for git-p4 as it handles only an occasional
>> exception or did the patch get lost in the noise? :-)
>
> I thought it was useful; I hadn't realised that it was needed for deleted 
> users.
>
> Luke

So..., should I just pick it up and queue with your Reviewed-by:?

Thanks.
--
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 13/16] ref-filter: allow porcelain to translate messages in the output

[Karthik Nayak]

Introduce setup_ref_filter_porcelain_msg() so that the messages used in
the atom %(upstream:track) can be translated if needed. This is needed
as we port branch.c to use ref-filter's printing API's.

Written-by: Matthieu Moy 
Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 28 
 ref-filter.h |  2 ++
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 73e0a7f..3435df1 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -15,6 +15,26 @@
 #include "version.h"
 #include "wt-status.h"
 
+static struct ref_msg {
+   const char *gone;
+   const char *ahead;
+   const char *behind;
+   const char *ahead_behind;
+} msgs = {
+   "gone",
+   "ahead %d",
+   "behind %d",
+   "ahead %d, behind %d"
+};
+
+void setup_ref_filter_porcelain_msg(void)
+{
+   msgs.gone = _("gone");
+   msgs.ahead = _("ahead %d");
+   msgs.behind = _("behind %d");
+   msgs.ahead_behind = _("ahead %d, behind %d");
+}
+
 typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
 
 struct align {
@@ -1097,15 +1117,15 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
else if (atom->u.remote_ref.option == RR_TRACK) {
if (stat_tracking_info(branch, &num_ours,
   &num_theirs, NULL)) {
-   *s = xstrdup("gone");
+   *s = xstrdup(msgs.gone);
} else if (!num_ours && !num_theirs)
*s = "";
else if (!num_ours)
-   *s = xstrfmt("behind %d", num_theirs);
+   *s = xstrfmt(msgs.behind, num_theirs);
else if (!num_theirs)
-   *s = xstrfmt("ahead %d", num_ours);
+   *s = xstrfmt(msgs.ahead, num_ours);
else
-   *s = xstrfmt("ahead %d, behind %d",
+   *s = xstrfmt(msgs.ahead_behind,
 num_ours, num_theirs);
if (!atom->u.remote_ref.nobracket && *s[0]) {
const char *to_free = *s;
diff --git a/ref-filter.h b/ref-filter.h
index 0014b92..da17145 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -111,5 +111,7 @@ struct ref_sorting *ref_default_sorting(void);
 int parse_opt_merge_filter(const struct option *opt, const char *arg, int 
unset);
 /*  Get the current HEAD's description */
 char *get_head_description(void);
+/*  Set up translated strings in the output. */
+void setup_ref_filter_porcelain_msg(void);
 
 #endif /*  REF_FILTER_H  */
-- 
2.7.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

[PATCH v2 09/16] ref-filter: make "%(symref)" atom work with the ':short' modifier

[Karthik Nayak]

The "%(symref)" atom doesn't work when used with the ':short' modifier
because we strictly match only 'symref' for setting the 'need_symref'
indicator. Fix this by using comparing with valid_atom rather than used_atom.

Add tests for %(symref) and %(symref:short) while we're here.

Helped-by: Junio C Hamano 
Signed-off-by: Karthik Nayak 
---
 ref-filter.c|  2 +-
 t/t6300-for-each-ref.sh | 24 
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/ref-filter.c b/ref-filter.c
index 8c97cdb..5c59b17 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -338,7 +338,7 @@ int parse_ref_filter_atom(const char *atom, const char *ep)
valid_atom[i].parser(&used_atom[at], arg);
if (*atom == '*')
need_tagged = 1;
-   if (!strcmp(used_atom[at].name, "symref"))
+   if (!strcmp(valid_atom[i].name, "symref"))
need_symref = 1;
return at;
 }
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 2c5f177..b06ea1c 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -38,6 +38,7 @@ test_atom() {
case "$1" in
head) ref=refs/heads/master ;;
 tag) ref=refs/tags/testtag ;;
+sym) ref=refs/heads/sym ;;
   *) ref=$1 ;;
esac
printf '%s\n' "$3" >expected
@@ -565,4 +566,27 @@ test_expect_success 'Verify sort with multiple keys' '
refs/tags/bogo refs/tags/master > actual &&
test_cmp expected actual
 '
+
+test_expect_success 'Add symbolic ref for the following tests' '
+   git symbolic-ref refs/heads/sym refs/heads/master
+'
+
+cat >expected < actual &&
+   test_cmp expected actual
+'
+
+cat >expected < actual &&
+   test_cmp expected actual
+'
+
 test_done
-- 
2.7.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

[PATCH v2 03/16] ref-filter: implement %(if:equals=) and %(if:notequals=)

[Karthik Nayak]

Implement %(if:equals=) wherein the if condition is only
satisfied if the value obtained between the %(if:...) and %(then) atom
is the same as the given ''.

Similarly, implement (if:notequals=) wherein the if condition
is only satisfied if the value obtained between the %(if:...) and
%(then) atom is differnt from the given ''.

This is done by introducing 'if_atom_parser()' which parses the given
%(if) atom and then stores the data in used_atom which is later passed
on to the used_atom of the %(then) atom, so that it can do the required
comparisons.

Add tests and Documentation for the same.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 Documentation/git-for-each-ref.txt |  3 +++
 ref-filter.c   | 43 +-
 t/t6302-for-each-ref-filter.sh | 18 
 3 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index d048561..e1b1a66 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -152,6 +152,9 @@ if::
evaluating the string before %(then), this is useful when we
use the %(HEAD) atom which prints either "*" or " " and we
want to apply the 'if' condition only on the 'HEAD' ref.
+   Append ":equals=" or ":notequals=" to compare
+   the value between the %(if:...) and %(then) atoms with the
+   given string.
 
 In addition to the above, for commit and tag objects, the header
 field names (`tree`, `parent`, `object`, `type`, and `tag`) can
diff --git a/ref-filter.c b/ref-filter.c
index 12e646c..857a8b5 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -22,6 +22,8 @@ struct align {
 };
 
 struct if_then_else {
+   const char *if_equals,
+   *not_equals;
unsigned int then_atom_seen : 1,
else_atom_seen : 1,
condition_satisfied : 1;
@@ -49,6 +51,10 @@ static struct used_atom {
enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, 
C_SUB } option;
unsigned int nlines;
} contents;
+   struct {
+   const char *if_equals,
+   *not_equals;
+   } if_then_else;
enum { O_FULL, O_SHORT } objectname;
} u;
 } *used_atom;
@@ -169,6 +175,19 @@ static void align_atom_parser(struct used_atom *atom, 
const char *arg)
string_list_clear(¶ms, 0);
 }
 
+static void if_atom_parser(struct used_atom *atom, const char *arg)
+{
+   if (!arg)
+   return;
+   else if (skip_prefix(arg, "equals=", &atom->u.if_then_else.if_equals))
+;
+   else if (skip_prefix(arg, "notequals=", 
&atom->u.if_then_else.not_equals))
+   ;
+   else
+   die(_("unrecognized %%(if) argument: %s"), arg);
+}
+
+
 static struct {
const char *name;
cmp_type cmp_type;
@@ -209,7 +228,7 @@ static struct {
{ "color", FIELD_STR, color_atom_parser },
{ "align", FIELD_STR, align_atom_parser },
{ "end" },
-   { "if" },
+   { "if", FIELD_STR, if_atom_parser },
{ "then" },
{ "else" },
 };
@@ -410,6 +429,9 @@ static void if_atom_handler(struct atom_value *atomv, 
struct ref_formatting_stat
struct ref_formatting_stack *new;
struct if_then_else *if_then_else = xcalloc(sizeof(struct 
if_then_else), 1);
 
+   if_then_else->if_equals = atomv->atom->u.if_then_else.if_equals;
+   if_then_else->not_equals = atomv->atom->u.if_then_else.not_equals;
+
push_stack_element(&state->stack);
new = state->stack;
new->at_end = if_then_else_handler;
@@ -441,10 +463,17 @@ static void then_atom_handler(struct atom_value *atomv, 
struct ref_formatting_st
die(_("format: %%(then) atom used after %%(else)"));
if_then_else->then_atom_seen = 1;
/*
-* If there exists non-empty string between the 'if' and
-* 'then' atom then the 'if' condition is satisfied.
+* If the 'equals' or 'notequals' attribute is used then
+* perform the required comparison. If not, only non-empty
+* strings satisfy the 'if' condition.
 */
-   if (cur->output.len && !is_empty(cur->output.buf))
+   if (if_then_else->if_equals) {
+   if (!strcmp(if_then_else->if_equals, cur->output.buf))
+   if_then_else->condition_satisfied = 1;
+   } else  if (if_then_else->not_equals) {
+   if (strcmp(if_then_else->not_equals, cur->output.buf))
+   if_then_else->condition_satisfied = 1;
+   } else if (cur->output.len && !is_empty(cur->output.buf))
if_then_else->condition_satisfied = 1;
strbuf_reset(&cur->output);
 }
@@ -1137,7 +1166,11 @@ static void populate_value(struct ref_array_item *ref)
} else i

[PATCH v2 04/16] ref-filter: modify "%(objectname:short)" to take length

[Karthik Nayak]

Add support for %(objectname:short=) which would print the
abbreviated unique objectname of given length. When no length is
specified 7 is used. The minimum length is 'MINIMUM_ABBREV'.

Add tests and documentation for the same.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 ref-filter.c| 25 +++--
 t/t6300-for-each-ref.sh | 10 ++
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 857a8b5..17f781d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -55,7 +55,10 @@ static struct used_atom {
const char *if_equals,
*not_equals;
} if_then_else;
-   enum { O_FULL, O_SHORT } objectname;
+   struct {
+   enum { O_FULL, O_LENGTH, O_SHORT } option;
+   unsigned int length;
+   } objectname;
} u;
 } *used_atom;
 static int used_atom_cnt, need_tagged, need_symref;
@@ -118,10 +121,17 @@ static void contents_atom_parser(struct used_atom *atom, 
const char *arg)
 static void objectname_atom_parser(struct used_atom *atom, const char *arg)
 {
if (!arg)
-   atom->u.objectname = O_FULL;
+   atom->u.objectname.option = O_FULL;
else if (!strcmp(arg, "short"))
-   atom->u.objectname = O_SHORT;
-   else
+   atom->u.objectname.option = O_SHORT;
+   else if (skip_prefix(arg, "short=", &arg)) {
+   atom->u.contents.option = O_LENGTH;
+   if (strtoul_ui(arg, 10, &atom->u.objectname.length) ||
+   atom->u.objectname.length == 0)
+   die(_("positive value expected objectname:short=%s"), 
arg);
+   if (atom->u.objectname.length < MINIMUM_ABBREV)
+   atom->u.objectname.length = MINIMUM_ABBREV;
+   } else
die(_("unrecognized %%(objectname) argument: %s"), arg);
 }
 
@@ -591,12 +601,15 @@ static int grab_objectname(const char *name, const 
unsigned char *sha1,
   struct atom_value *v, struct used_atom *atom)
 {
if (starts_with(name, "objectname")) {
-   if (atom->u.objectname == O_SHORT) {
+   if (atom->u.objectname.option == O_SHORT) {
v->s = xstrdup(find_unique_abbrev(sha1, 
DEFAULT_ABBREV));
return 1;
-   } else if (atom->u.objectname == O_FULL) {
+   } else if (atom->u.objectname.option == O_FULL) {
v->s = xstrdup(sha1_to_hex(sha1));
return 1;
+   } else if (atom->u.objectname.option == O_LENGTH) {
+   v->s = xstrdup(find_unique_abbrev(sha1, 
atom->u.objectname.length));
+   return 1;
} else
die("BUG: unknown %%(objectname) option");
}
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 19a2823..2be0a3f 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -60,6 +60,8 @@ test_atom head objecttype commit
 test_atom head objectsize 171
 test_atom head objectname $(git rev-parse refs/heads/master)
 test_atom head objectname:short $(git rev-parse --short refs/heads/master)
+test_atom head objectname:short=1 $(git rev-parse --short=1 refs/heads/master)
+test_atom head objectname:short=10 $(git rev-parse --short=10 
refs/heads/master)
 test_atom head tree $(git rev-parse refs/heads/master^{tree})
 test_atom head parent ''
 test_atom head numparent 0
@@ -99,6 +101,8 @@ test_atom tag objecttype tag
 test_atom tag objectsize 154
 test_atom tag objectname $(git rev-parse refs/tags/testtag)
 test_atom tag objectname:short $(git rev-parse --short refs/tags/testtag)
+test_atom head objectname:short=1 $(git rev-parse --short=1 refs/heads/master)
+test_atom head objectname:short=10 $(git rev-parse --short=10 
refs/heads/master)
 test_atom tag tree ''
 test_atom tag parent ''
 test_atom tag numparent ''
@@ -164,6 +168,12 @@ test_expect_success 'Check invalid format specifiers are 
errors' '
test_must_fail git for-each-ref --format="%(authordate:INVALID)" 
refs/heads
 '
 
+test_expect_success 'arguments to %(objectname:short=) must be positive 
integers' '
+   test_must_fail git for-each-ref --format="%(objectname:short=0)" &&
+   test_must_fail git for-each-ref --format="%(objectname:short=-1)" &&
+   test_must_fail git for-each-ref --format="%(objectname:short=foo)"
+'
+
 test_date () {
f=$1 &&
committer_date=$2 &&
-- 
2.7.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

[PATCH v2 16/16] branch: implement '--format' option

[Karthik Nayak]

Implement the '--format' option provided by 'ref-filter'. This lets the
user list branches as per desired format similar to the implementation
in 'git for-each-ref'.

Add tests and documentation for the same.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 Documentation/git-branch.txt |  7 ++-
 builtin/branch.c | 14 +-
 t/t3203-branch-output.sh | 12 
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4a7037f..8af132f 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -12,7 +12,7 @@ SYNOPSIS
[--list] [-v [--abbrev= | --no-abbrev]]
[--column[=] | --no-column]
[(--merged | --no-merged | --contains) []] [--sort=]
-   [--points-at ] [...]
+   [--points-at ] [--format=] [...]
 'git branch' [--set-upstream | --track | --no-track] [-l] [-f]  
[]
 'git branch' (--set-upstream-to= | -u ) []
 'git branch' --unset-upstream []
@@ -246,6 +246,11 @@ start-point is either a local or remote-tracking branch.
 --points-at ::
Only list branches of the given object.
 
+--format ::
+   A string that interpolates `%(fieldname)` from the object
+   pointed at by a ref being shown.  The format is the same as
+   that of linkgit:git-for-each-ref[1].
+
 Examples
 
 
diff --git a/builtin/branch.c b/builtin/branch.c
index 29cd206..fb05b39 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -27,6 +27,7 @@ static const char * const builtin_branch_usage[] = {
N_("git branch [] [-r] (-d | -D) ..."),
N_("git branch [] (-m | -M) [] "),
N_("git branch [] [-r | -a] [--points-at]"),
+   N_("git branch [] [-r | -a] [--format]"),
NULL
 };
 
@@ -331,14 +332,14 @@ static char *build_format(struct ref_filter *filter, int 
maxwidth, const char *r
return strbuf_detach(&fmt, NULL);
 }
 
-static void print_ref_list(struct ref_filter *filter, struct ref_sorting 
*sorting)
+static void print_ref_list(struct ref_filter *filter, struct ref_sorting 
*sorting, const char *format)
 {
int i;
struct ref_array array;
int maxwidth = 0;
const char *remote_prefix = "";
struct strbuf out = STRBUF_INIT;
-   char *format;
+   char *to_free = NULL;
 
/*
 * If we are listing more than just remote branches,
@@ -355,7 +356,8 @@ static void print_ref_list(struct ref_filter *filter, 
struct ref_sorting *sortin
if (filter->verbose)
maxwidth = calc_maxwidth(&array, strlen(remote_prefix));
 
-   format = build_format(filter, maxwidth, remote_prefix);
+   if (!format)
+   format = to_free = build_format(filter, maxwidth, 
remote_prefix);
verify_ref_format(format);
 
/*
@@ -383,7 +385,7 @@ static void print_ref_list(struct ref_filter *filter, 
struct ref_sorting *sortin
}
 
ref_array_clear(&array);
-   free(format);
+   free(to_free);
 }
 
 static void rename_branch(const char *oldname, const char *newname, int force)
@@ -483,6 +485,7 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
enum branch_track track;
struct ref_filter filter;
static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
+   const char *format = NULL;
 
struct option options[] = {
OPT_GROUP(N_("Generic options")),
@@ -523,6 +526,7 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
OPTION_CALLBACK, 0, "points-at", &filter.points_at, 
N_("object"),
N_("print only branches of the object"), 0, 
parse_opt_object_name
},
+   OPT_STRING(  0 , "format", &format, N_("format"), N_("format to 
use for the output")),
OPT_END(),
};
 
@@ -583,7 +587,7 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
if ((filter.kind & FILTER_REFS_BRANCHES) && filter.detached)
filter.kind |= FILTER_REFS_DETACHED_HEAD;
filter.name_patterns = argv;
-   print_ref_list(&filter, sorting);
+   print_ref_list(&filter, sorting, format);
print_columns(&output, colopts, NULL);
string_list_clear(&output, 0);
return 0;
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 4261403..c33a3f3 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -184,4 +184,16 @@ test_expect_success 'ambiguous branch/tag not marked' '
test_cmp expect actual
 '
 
+test_expect_success 'git branch --format option' '
+   cat >expect <<-\EOF &&
+   Refname is (HEAD detached from fromtag)
+   Refname is refs/heads/ambiguous
+   Refname is refs/heads/branch-one
+   Refname is refs/heads/branch-two
+   Refname is refs/heads/maste

[PATCH v2 14/16] branch, tag: use porcelain output

[Karthik Nayak]

Call ref-filter's setup_ref_filter_porcelain_msg() to enable
translated messages for the %(upstream:tack) atom. Although branch.c
doesn't currently use ref-filter's printing API's, this will ensure
that when it does in the future patches, we do not need to worry about
translation.

Written-by: Matthieu Moy 
Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 builtin/branch.c | 2 ++
 builtin/tag.c| 2 ++
 2 files changed, 4 insertions(+)

diff --git a/builtin/branch.c b/builtin/branch.c
index 460f32f..8747d82 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -622,6 +622,8 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
OPT_END(),
};
 
+   setup_ref_filter_porcelain_msg();
+
memset(&filter, 0, sizeof(filter));
filter.kind = FILTER_REFS_BRANCHES;
filter.abbrev = -1;
diff --git a/builtin/tag.c b/builtin/tag.c
index 1705c94..82a04ed 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -373,6 +373,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_END()
};
 
+   setup_ref_filter_porcelain_msg();
+
git_config(git_tag_config, sorting_tail);
 
memset(&opt, 0, sizeof(opt));
-- 
2.7.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/RFC/GSoC 17/17] rebase-interactive: introduce interactive backend for builtin rebase

[Paul Tan]

Hi Dscho,

On Tue, Mar 15, 2016 at 3:57 PM, Johannes Schindelin
 wrote:
> On Sat, 12 Mar 2016, Paul Tan wrote:
>
>> Since 1b1dce4 (Teach rebase an interactive mode, 2007-06-25), git-rebase
>> supports an interactive mode when passed the -i switch.
>>
>> In interactive mode, git-rebase allows users to edit the list of patches
>> (using the user's GIT_SEQUENCE_EDITOR), so that the user can reorder,
>> edit and delete patches.
>>
>> Re-implement a skeletal version of the above feature by introducing a
>> rebase-interactive backend for our builtin-rebase. This skeletal
>> implementation is only able to pick and re-order commits.
>>
>> Signed-off-by: Paul Tan 
>
> It is a pity that both of us worked on overlapping projects in stealth
> mode. Inevitably, some of the work is now wasted :-(

No worries, I did this series for my own interest, especially to get a
gauge of the speedup between rebase in shell and C. GSoC applications
have opened and will close in 10 days time, so I wanted to get some
data before the deadline at least :-).

> Not all is lost, though.
>
> Much of the code can be salvaged, although I really want to reiterate
> that an all-or-nothing conversion of the rebase command is not going to
> fly.

Sure. I admit that I concentrated more on how the "final code" would
look like, and not so much how the rewrite would be built upon in
pieces.

> For several reasons: it would be rather disruptive, huge and hard to
> review. It would not let anybody else work on that huge task. And you're
> prone to fall behind due to Git's source code being in constant flux
> (including the rebase bits).
>
> There is another, really important reason: if you package the conversion
> into small, neat bundles, it is much easier to avoid too narrow a focus
> that would tuck perfectly useful functions away in a location where it
> cannot be reused and where it is likely to be missed by other developers
> who need the same, or similar functionality (point in case:
> has_uncommitted_changes()). And we know that this happened in the past,
> and sometimes resulted in near-duplicated code, hence Karthik's Herculean,
> still ongoing work.
>
> Lastly, I need to point out that the conversion of rebase into a builtin
> is not the end game, it is the game's opening.
>
> [...]
>
> So you see, there was a much larger master plan behind my recommendation
> to go the rebase--helper route.

Ah I see, thanks for publishing your branch and sharing your plans.

Originally I was thinking smaller -- rewrite git-rebase first,
following its shell script closely, and then doing the libification
and optimization after that. However, I see now that you have grander
plans than that :-).

>
> As to my current state: Junio put me into quite a fix (without knowing it)
> by releasing 2.7.3 just after I took off for an extended offline weekend,
> and now I am scrambling because a change in MSYS2's runtime (actually,
> probably more like: an update of the GCC that is used to compile the
> runtime, that now causes a regression) is keeping me away from my work on
> the interactive rebase. Even so, I am pretty far along; There are only
> three major things left to do: 1) fix fixups/squashes with fast-forwarding
> picks, 2) implement 'reword', 3) display the progress.  And of course 4)
> clean up the fallout. ;-)
>
> At this point, I'd rather finish this myself than falling prey to Brooks'
> Law.

Okay, I won't touch interactive rebase then.

> I also have to admit that I would love to give you a project over the
> summer whose logical children are exciting enough to dabble with even
> during the winter. And somehow I do not see that excitement in the boring
> conversion from shell to C (even if its outcome is well-needed).

Well, that is subjective ;-).

Even with interactive rebase out-of-bounds, I don't think it's a dead
end though:

1. git-rebase--am.sh, git-rebase--merge.sh and git-rebase.sh can be
rewritten to C, and call git-rebase--interactive.sh externally, like
what Duy demonstrated in his patch series. The timings show that am
and merge rebase still benefit, and that way we will be closer to a
git-rebase in full C.

2. git-commit can be libified, so that we can access its functionality
directly. (sequencer.c runs it once per commit, rebase-interactive
uses it for squashes etc.)

Or would that be stepping on your toes?

> Ciao,
> Dscho
>
> Footnote *1*:
> https://github.com/git-for-windows/build-extra/blob/master/shears.sh

Regards,
Paul
--
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 10/16] ref-filter: introduce symref_atom_parser()

[Karthik Nayak]

Introduce symref_atom_parser() which will parse the '%(symref)' atom and
store information into the 'used_atom' structure based on the modifiers
used along with the atom.

Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 5c59b17..7b35e4f 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -62,6 +62,7 @@ static struct used_atom {
enum { O_FULL, O_LENGTH, O_SHORT } option;
unsigned int length;
} objectname;
+   enum { S_FULL, S_SHORT } symref;
} u;
 } *used_atom;
 static int used_atom_cnt, need_tagged, need_symref;
@@ -217,6 +218,15 @@ static void if_atom_parser(struct used_atom *atom, const 
char *arg)
die(_("unrecognized %%(if) argument: %s"), arg);
 }
 
+static void symref_atom_parser(struct used_atom *atom, const char *arg)
+{
+   if (!arg)
+   atom->u.symref = S_FULL;
+   else if (!strcmp(arg, "short"))
+   atom->u.symref = S_SHORT;
+   else
+   die(_("unrecognized %%(symref) argument: %s"), arg);
+}
 
 static struct {
const char *name;
@@ -252,7 +262,7 @@ static struct {
{ "contents", FIELD_STR, contents_atom_parser },
{ "upstream", FIELD_STR, remote_ref_atom_parser },
{ "push", FIELD_STR, remote_ref_atom_parser },
-   { "symref" },
+   { "symref", FIELD_STR, symref_atom_parser },
{ "flag" },
{ "HEAD" },
{ "color", FIELD_STR, color_atom_parser },
@@ -1132,6 +1142,17 @@ char *get_head_description(void)
return strbuf_detach(&desc, NULL);
 }
 
+static const char *get_symref(struct used_atom *atom, struct ref_array_item 
*ref)
+{
+   if (!ref->symref)
+   return "";
+   else if (atom->u.symref == S_SHORT)
+   return shorten_unambiguous_ref(ref->symref,
+  warn_ambiguous_refs);
+   else
+   return ref->symref;
+}
+
 /*
  * Parse the object referred by ref, and grab needed value.
  */
@@ -1176,7 +1197,7 @@ static void populate_value(struct ref_array_item *ref)
if (ref->kind & FILTER_REFS_DETACHED_HEAD)
refname = get_head_description();
} else if (starts_with(name, "symref"))
-   refname = ref->symref ? ref->symref : "";
+   refname = get_symref(atom, ref);
else if (starts_with(name, "upstream")) {
const char *branch_name;
/* only local branches may have an upstream */
-- 
2.7.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

[PATCH v2 08/16] ref-filter: add support for %(upstream:track,nobracket)

[Karthik Nayak]

Add support for %(upstream:track,nobracket) which will print the
tracking information without the brackets (i.e. "ahead N, behind M").
This is needed when we port branch.c to use ref-filter's printing APIs.

Add test and documentation for the same.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 Documentation/git-for-each-ref.txt |  5 ++-
 ref-filter.c   | 67 +-
 t/t6300-for-each-ref.sh|  2 ++
 3 files changed, 50 insertions(+), 24 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 6dbd7bd..4e41cee 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -116,7 +116,10 @@ upstream::
version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
or "=" (in sync).  Has no effect if the ref does not have
tracking information associated with it. `:track` also prints
-   "[gone]" whenever unknown upstream ref is encountered.
+   "[gone]" whenever unknown upstream ref is encountered. Append
+   `:track,nobracket` to show tracking information without
+   brackets (i.e "ahead N, behind M").  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 4d7e0c0..8c97cdb 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -46,8 +46,10 @@ static struct used_atom {
union {
char color[COLOR_MAXLEN];
struct align align;
-   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT }
-   remote_ref;
+   struct {
+   enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT } 
option;
+   unsigned int nobracket: 1;
+   } remote_ref;
struct {
enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, 
C_SUB } option;
unsigned int nlines;
@@ -75,16 +77,33 @@ static void color_atom_parser(struct used_atom *atom, const 
char *color_value)
 
 static void remote_ref_atom_parser(struct used_atom *atom, const char *arg)
 {
-   if (!arg)
-   atom->u.remote_ref = RR_NORMAL;
-   else if (!strcmp(arg, "short"))
-   atom->u.remote_ref = RR_SHORTEN;
-   else if (!strcmp(arg, "track"))
-   atom->u.remote_ref = RR_TRACK;
-   else if (!strcmp(arg, "trackshort"))
-   atom->u.remote_ref = RR_TRACKSHORT;
-   else
-   die(_("unrecognized format: %%(%s)"), atom->name);
+   struct string_list params = STRING_LIST_INIT_DUP;
+   int i;
+
+   if (!arg) {
+   atom->u.remote_ref.option = RR_NORMAL;
+   return;
+   }
+
+   atom->u.remote_ref.nobracket = 0;
+   string_list_split(¶ms, arg, ',', -1);
+
+   for (i = 0; i < params.nr; i++) {
+   const char *s = params.items[i].string;
+
+   if (!strcmp(s, "short"))
+   atom->u.remote_ref.option = RR_SHORTEN;
+   else if (!strcmp(s, "track"))
+   atom->u.remote_ref.option = RR_TRACK;
+   else if (!strcmp(s, "trackshort"))
+   atom->u.remote_ref.option = RR_TRACKSHORT;
+   else if (!strcmp(s, "nobracket"))
+   atom->u.remote_ref.nobracket = 1;
+   else
+   die(_("unrecognized format: %%(%s)"), atom->name);
+   }
+
+   string_list_clear(¶ms, 0);
 }
 
 static void body_atom_parser(struct used_atom *atom, const char *arg)
@@ -1045,25 +1064,27 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
struct branch *branch, const char **s)
 {
int num_ours, num_theirs;
-   if (atom->u.remote_ref == RR_SHORTEN)
+   if (atom->u.remote_ref.option == RR_SHORTEN)
*s = shorten_unambiguous_ref(refname, warn_ambiguous_refs);
-   else if (atom->u.remote_ref == RR_TRACK) {
+   else if (atom->u.remote_ref.option == RR_TRACK) {
if (stat_tracking_info(branch, &num_ours,
   &num_theirs, NULL)) {
-   *s = "[gone]";
-   return;
-   }
-
-   if (!num_ours && !num_theirs)
+   *s = xstrdup("gone");
+   } else if (!num_ours && !num_theirs)
*s = "";
else if (!num_ours)
-   *s = xstrfmt("[behind %d]", num_theirs);
+   *s = xstrfmt("behind %d", num_theirs);
else if (!num_theirs)
-   *s = xstrfmt("[ahead %d]", num_ours);
+   *s = xstrfmt("ahead %d", num_ours);
else
-

[PATCH v2 12/16] ref-filter: add support for %(refname:dir) and %(refname:base)

[Karthik Nayak]

Add the options `:dir` and `:base` to the %(refname) atom. The `:dir`
option gives the directory (the part after $GIT_DIR/) of the ref without
the refname. The `:base` option gives the base directory of the given
ref (i.e. the directory following $GIT_DIR/refs/).

Add tests and documentation for the same.

Signed-off-by: Karthik Nayak 
---
 Documentation/git-for-each-ref.txt |  4 +++-
 ref-filter.c   | 28 +---
 t/t6300-for-each-ref.sh|  2 ++
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 4e41cee..578bbd1 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -96,7 +96,9 @@ refname::
slash-separated path components from the front of the refname
(e.g., `%(refname:strip=2)` turns `refs/tags/foo` into `foo`.
`` must be a positive integer.  If a displayed ref has fewer
-   components than ``, the command aborts with an error.
+   components than ``, the command aborts with an error. For the base
+   directory of the ref (i.e. foo in refs/foo/bar/boz) append
+   `:base`. For the entire directory path append `:dir`.
 
 objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).
diff --git a/ref-filter.c b/ref-filter.c
index dc1e404..73e0a7f 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -64,7 +64,7 @@ static struct used_atom {
} objectname;
enum { S_FULL, S_SHORT } symref;
struct {
-   enum { R_NORMAL, R_SHORT, R_STRIP } option;
+   enum { R_BASE, R_DIR, R_NORMAL, R_SHORT, R_STRIP } 
option;
unsigned int strip;
} refname;
} u;
@@ -243,7 +243,11 @@ static void refname_atom_parser(struct used_atom *atom, 
const char *arg)
if (strtoul_ui(arg, 10, &atom->u.refname.strip) ||
atom->u.refname.strip <= 0)
die(_("positive value expected refname:strip=%s"), arg);
-   } else
+   } else if (!strcmp(arg, "dir"))
+   atom->u.contents.option = R_DIR;
+   else if (!strcmp(arg, "base"))
+   atom->u.contents.option = R_BASE;
+   else
die(_("unrecognized %%(refname) argument: %s"), arg);
 }
 
@@ -1175,7 +1179,25 @@ static const char *get_refname(struct used_atom *atom, 
struct ref_array_item *re
return shorten_unambiguous_ref(ref->refname, 
warn_ambiguous_refs);
else if (atom->u.refname.option == R_STRIP)
return strip_ref_components(ref->refname, 
atom->u.refname.strip);
-   else
+   else if (atom->u.refname.option == R_BASE) {
+   const char *sp, *ep;
+
+   if (skip_prefix(ref->refname, "refs/", &sp)) {
+   ep = strchr(sp, '/');
+   if (!ep)
+   return "";
+   return xstrndup(sp, ep - sp);
+   }
+   return "";
+   } else if (atom->u.refname.option == R_DIR) {
+   const char *sp, *ep;
+
+   sp = ref->refname;
+   ep = strrchr(sp, '/');
+   if (!ep)
+   return "";
+   return xstrndup(sp, ep - sp);
+   } else
return ref->refname;
 }
 
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index b06ea1c..36d32d7 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -53,6 +53,8 @@ test_atom head refname refs/heads/master
 test_atom head refname:short master
 test_atom head refname:strip=1 heads/master
 test_atom head refname:strip=2 master
+test_atom head refname:dir refs/heads
+test_atom head refname:base heads
 test_atom head upstream refs/remotes/origin/master
 test_atom head upstream:short origin/master
 test_atom head push refs/remotes/myfork/master
-- 
2.7.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: git smudge filter fails

[Junio C Hamano]

Stephen Morton  writes:

> It's perhaps beyond the scope of my original question, but for
> situations where I need a "last change date" embedded in a file (e.g.
> because a protocol standard requires it), is there any recommended way
> to do so? We've the hard way that hardcoding makes
> merging/cherry-picking a bit of a nightmare and should be avoided.

Does that "last change date" have to be embedded in a file with
other stuff in there, or can it be a standalone file by itself
(which may be used by other things via linking or inclusion)?

If it can be a standalone file, a custom ll-merge driver that knows
how yoru datestring looks like and takes the later of the versions
in the two branches being merged would not be too hard to write to
eliminate the "nightmare", I would think.

--
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 11/16] ref-filter: introduce refname_atom_parser()

[Karthik Nayak]

Introduce refname_atom_parser() which will parse the '%(refname)' atom
and store information into the 'used_atom' structure based on the
modifiers used along with the atom.

Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 70 +---
 1 file changed, 39 insertions(+), 31 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 7b35e4f..dc1e404 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -63,6 +63,10 @@ static struct used_atom {
unsigned int length;
} objectname;
enum { S_FULL, S_SHORT } symref;
+   struct {
+   enum { R_NORMAL, R_SHORT, R_STRIP } option;
+   unsigned int strip;
+   } refname;
} u;
 } *used_atom;
 static int used_atom_cnt, need_tagged, need_symref;
@@ -228,12 +232,27 @@ static void symref_atom_parser(struct used_atom *atom, 
const char *arg)
die(_("unrecognized %%(symref) argument: %s"), arg);
 }
 
+static void refname_atom_parser(struct used_atom *atom, const char *arg)
+{
+   if (!arg)
+   atom->u.refname.option = R_NORMAL;
+   else if (!strcmp(arg, "short"))
+   atom->u.refname.option = R_SHORT;
+   else if (skip_prefix(arg, "strip=", &arg)) {
+   atom->u.contents.option = R_STRIP;
+   if (strtoul_ui(arg, 10, &atom->u.refname.strip) ||
+   atom->u.refname.strip <= 0)
+   die(_("positive value expected refname:strip=%s"), arg);
+   } else
+   die(_("unrecognized %%(refname) argument: %s"), arg);
+}
+
 static struct {
const char *name;
cmp_type cmp_type;
void (*parser)(struct used_atom *atom, const char *arg);
 } valid_atom[] = {
-   { "refname" },
+   { "refname", FIELD_STR, refname_atom_parser },
{ "objecttype" },
{ "objectsize", FIELD_ULONG },
{ "objectname", FIELD_STR, objectname_atom_parser },
@@ -1047,21 +1066,16 @@ static inline char *copy_advance(char *dst, const char 
*src)
return dst;
 }
 
-static const char *strip_ref_components(const char *refname, const char 
*nr_arg)
+static const char *strip_ref_components(const char *refname, unsigned int len)
 {
-   char *end;
-   long nr = strtol(nr_arg, &end, 10);
-   long remaining = nr;
+   long remaining = len;
const char *start = refname;
 
-   if (nr < 1 || *end != '\0')
-   die(_(":strip= requires a positive integer argument"));
-
while (remaining) {
switch (*start++) {
case '\0':
-   die(_("ref '%s' does not have %ld components to 
:strip"),
-   refname, nr);
+   die("ref '%s' does not have %ud components to :strip",
+   refname, len);
case '/':
remaining--;
break;
@@ -1153,6 +1167,18 @@ static const char *get_symref(struct used_atom *atom, 
struct ref_array_item *ref
return ref->symref;
 }
 
+static const char *get_refname(struct used_atom *atom, struct ref_array_item 
*ref)
+{
+   if (ref->kind & FILTER_REFS_DETACHED_HEAD)
+   return get_head_description();
+   if (atom->u.refname.option == R_SHORT)
+   return shorten_unambiguous_ref(ref->refname, 
warn_ambiguous_refs);
+   else if (atom->u.refname.option == R_STRIP)
+   return strip_ref_components(ref->refname, 
atom->u.refname.strip);
+   else
+   return ref->refname;
+}
+
 /*
  * Parse the object referred by ref, and grab needed value.
  */
@@ -1181,7 +1207,6 @@ static void populate_value(struct ref_array_item *ref)
struct atom_value *v = &ref->value[i];
int deref = 0;
const char *refname;
-   const char *formatp;
struct branch *branch = NULL;
 
v->handler = append_atom;
@@ -1192,11 +1217,9 @@ static void populate_value(struct ref_array_item *ref)
name++;
}
 
-   if (starts_with(name, "refname")) {
-   refname = ref->refname;
-   if (ref->kind & FILTER_REFS_DETACHED_HEAD)
-   refname = get_head_description();
-   } else if (starts_with(name, "symref"))
+   if (starts_with(name, "refname"))
+   refname = get_refname(atom, ref);
+   else if (starts_with(name, "symref"))
refname = get_symref(atom, ref);
else if (starts_with(name, "upstream")) {
const char *branch_name;
@@ -1273,21 +1296,6 @@ static void populate_value(struct ref_array_item *ref)
} else
continue;
 
-   formatp = strchr(name, ':');
-   if (f

[PATCH v2 07/16] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams

[Karthik Nayak]

Borrowing from branch.c's implementation print "[gone]" whenever an
unknown upstream ref is encountered instead of just ignoring it.

This makes sure that when branch.c is ported over to using ref-filter
APIs for printing, this feature is not lost.

Make changes to t/t6300-for-each-ref.sh and
Documentation/git-for-each-ref.txt to reflect this change.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Helped-by : Jacob Keller 
Signed-off-by: Karthik Nayak 
---
 Documentation/git-for-each-ref.txt | 3 ++-
 ref-filter.c   | 4 +++-
 t/t6300-for-each-ref.sh| 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index e1b1a66..6dbd7bd 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -115,7 +115,8 @@ upstream::
"[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.
+   tracking information associated with it. `:track` also prints
+   "[gone]" whenever unknown upstream ref is encountered.
 
 push::
The name of a local ref which represents the `@{push}` location
diff --git a/ref-filter.c b/ref-filter.c
index 3bb474f..4d7e0c0 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1049,8 +1049,10 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
*s = shorten_unambiguous_ref(refname, warn_ambiguous_refs);
else if (atom->u.remote_ref == RR_TRACK) {
if (stat_tracking_info(branch, &num_ours,
-  &num_theirs, NULL))
+  &num_theirs, NULL)) {
+   *s = "[gone]";
return;
+   }
 
if (!num_ours && !num_theirs)
*s = "";
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 2be0a3f..a92b36f 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -382,7 +382,7 @@ test_expect_success 'Check that :track[short] cannot be 
used with other atoms' '
 
 test_expect_success 'Check that :track[short] works when upstream is invalid' '
cat >expected <<-\EOF &&
-
+   [gone]
 
EOF
test_when_finished "git config branch.master.merge refs/heads/master" &&
-- 
2.7.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

[PATCH v2 05/16] ref-filter: move get_head_description() from branch.c

[Karthik Nayak]

Move the implementation of get_head_description() from branch.c to
ref-filter.  This gives a description of the HEAD ref if called. This
is used as the refname for the HEAD ref whenever the
FILTER_REFS_DETACHED_HEAD option is used. Make it public because we
need it to calculate the length of the HEAD refs description in
branch.c:calc_maxwidth() when we port branch.c to use ref-filter
APIs.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 builtin/branch.c | 31 ---
 ref-filter.c | 38 --
 ref-filter.h |  2 ++
 3 files changed, 38 insertions(+), 33 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index 7b45b6b..460f32f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -355,37 +355,6 @@ static void add_verbose_info(struct strbuf *out, struct 
ref_array_item *item,
strbuf_release(&subject);
 }
 
-static char *get_head_description(void)
-{
-   struct strbuf desc = STRBUF_INIT;
-   struct wt_status_state state;
-   memset(&state, 0, sizeof(state));
-   wt_status_get_state(&state, 1);
-   if (state.rebase_in_progress ||
-   state.rebase_interactive_in_progress)
-   strbuf_addf(&desc, _("(no branch, rebasing %s)"),
-   state.branch);
-   else if (state.bisect_in_progress)
-   strbuf_addf(&desc, _("(no branch, bisect started on %s)"),
-   state.branch);
-   else if (state.detached_from) {
-   /* TRANSLATORS: make sure these match _("HEAD detached at ")
-  and _("HEAD detached from ") in wt-status.c */
-   if (state.detached_at)
-   strbuf_addf(&desc, _("(HEAD detached at %s)"),
-   state.detached_from);
-   else
-   strbuf_addf(&desc, _("(HEAD detached from %s)"),
-   state.detached_from);
-   }
-   else
-   strbuf_addstr(&desc, _("(no branch)"));
-   free(state.branch);
-   free(state.onto);
-   free(state.detached_from);
-   return strbuf_detach(&desc, NULL);
-}
-
 static void format_and_print_ref_item(struct ref_array_item *item, int 
maxwidth,
  struct ref_filter *filter, const char 
*remote_prefix)
 {
diff --git a/ref-filter.c b/ref-filter.c
index 17f781d..7004bf0 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -13,6 +13,7 @@
 #include "utf8.h"
 #include "git-compat-util.h"
 #include "version.h"
+#include "wt-status.h"
 
 typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
 
@@ -1077,6 +1078,37 @@ static void fill_remote_ref_details(struct used_atom 
*atom, const char *refname,
*s = refname;
 }
 
+char *get_head_description(void)
+{
+   struct strbuf desc = STRBUF_INIT;
+   struct wt_status_state state;
+   memset(&state, 0, sizeof(state));
+   wt_status_get_state(&state, 1);
+   if (state.rebase_in_progress ||
+   state.rebase_interactive_in_progress)
+   strbuf_addf(&desc, _("(no branch, rebasing %s)"),
+   state.branch);
+   else if (state.bisect_in_progress)
+   strbuf_addf(&desc, _("(no branch, bisect started on %s)"),
+   state.branch);
+   else if (state.detached_from) {
+   /* TRANSLATORS: make sure these match _("HEAD detached at ")
+  and _("HEAD detached from ") in wt-status.c */
+   if (state.detached_at)
+   strbuf_addf(&desc, _("(HEAD detached at %s)"),
+   state.detached_from);
+   else
+   strbuf_addf(&desc, _("(HEAD detached from %s)"),
+   state.detached_from);
+   }
+   else
+   strbuf_addstr(&desc, _("(no branch)"));
+   free(state.branch);
+   free(state.onto);
+   free(state.detached_from);
+   return strbuf_detach(&desc, NULL);
+}
+
 /*
  * Parse the object referred by ref, and grab needed value.
  */
@@ -1116,9 +1148,11 @@ static void populate_value(struct ref_array_item *ref)
name++;
}
 
-   if (starts_with(name, "refname"))
+   if (starts_with(name, "refname")) {
refname = ref->refname;
-   else if (starts_with(name, "symref"))
+   if (ref->kind & FILTER_REFS_DETACHED_HEAD)
+   refname = get_head_description();
+   } else if (starts_with(name, "symref"))
refname = ref->symref ? ref->symref : "";
else if (starts_with(name, "upstream")) {
const char *branch_name;
diff --git a/ref-filter.h b/ref-filter.h
index 14d435e..4aea594 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -106,5 +106,7 @@ int

[PATCH v2 02/16] ref-filter: include reference to 'used_atom' within 'atom_value'

[Karthik Nayak]

Ensure that each 'atom_value' has a reference to its corresponding
'used_atom'. This let's us use values within 'used_atom' in the
'handler' function.

Hence we can get the %(align) atom's parameters directly from the
'used_atom' therefore removing the necessity of passing %(align) atom's
parameters to 'atom_value'.

This also acts as a preparatory patch for the upcoming patch where we
introduce %(if:equals=) and %(if:notequals=).

Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 41e73f0..12e646c 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -230,11 +230,9 @@ struct ref_formatting_state {
 
 struct atom_value {
const char *s;
-   union {
-   struct align align;
-   } u;
void (*handler)(struct atom_value *atomv, struct ref_formatting_state 
*state);
unsigned long ul; /* used for sorting when not FIELD_STR */
+   struct used_atom *atom;
 };
 
 /*
@@ -370,7 +368,7 @@ static void align_atom_handler(struct atom_value *atomv, 
struct ref_formatting_s
push_stack_element(&state->stack);
new = state->stack;
new->at_end = end_align_handler;
-   new->at_end_data = &atomv->u.align;
+   new->at_end_data = &atomv->atom->u.align;
 }
 
 static void if_then_else_handler(struct ref_formatting_stack **stack)
@@ -1069,6 +1067,7 @@ static void populate_value(struct ref_array_item *ref)
struct branch *branch = NULL;
 
v->handler = append_atom;
+   v->atom = atom;
 
if (*name == '*') {
deref = 1;
@@ -1133,7 +1132,6 @@ static void populate_value(struct ref_array_item *ref)
v->s = " ";
continue;
} else if (starts_with(name, "align")) {
-   v->u.align = atom->u.align;
v->handler = align_atom_handler;
continue;
} else if (!strcmp(name, "end")) {
-- 
2.7.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

[PATCH v2 15/16] branch: use ref-filter printing APIs

[Karthik Nayak]

Port branch.c to use ref-filter APIs for printing. This clears out
most of the code used in branch.c for printing and replaces them with
calls made to the ref-filter library.

Introduce build_format() which gets the format required for printing
of refs. Make amendments to print_ref_list() to reflect these changes.

Change calc_maxwidth() to also account for the length of HEAD ref, by
calling ref-filter:get_head_discription().

Also change the test in t6040 to reflect the changes.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 builtin/branch.c | 226 ++-
 t/t6040-tracking-info.sh |   2 +-
 2 files changed, 66 insertions(+), 162 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index 8747d82..29cd206 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -35,12 +35,12 @@ static unsigned char head_sha1[20];
 
 static int branch_use_color = -1;
 static char branch_colors[][COLOR_MAXLEN] = {
-   GIT_COLOR_RESET,
-   GIT_COLOR_NORMAL,   /* PLAIN */
-   GIT_COLOR_RED,  /* REMOTE */
-   GIT_COLOR_NORMAL,   /* LOCAL */
-   GIT_COLOR_GREEN,/* CURRENT */
-   GIT_COLOR_BLUE, /* UPSTREAM */
+   "%(color:reset)",
+   "%(color:reset)",   /* PLAIN */
+   "%(color:red)", /* REMOTE */
+   "%(color:reset)",   /* LOCAL */
+   "%(color:green)",   /* CURRENT */
+   "%(color:blue)",/* UPSTREAM */
 };
 enum color_branch {
BRANCH_COLOR_RESET = 0,
@@ -271,157 +271,6 @@ static int delete_branches(int argc, const char **argv, 
int force, int kinds,
return(ret);
 }
 
-static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
-   int show_upstream_ref)
-{
-   int ours, theirs;
-   char *ref = NULL;
-   struct branch *branch = branch_get(branch_name);
-   const char *upstream;
-   struct strbuf fancy = STRBUF_INIT;
-   int upstream_is_gone = 0;
-   int added_decoration = 1;
-
-   if (stat_tracking_info(branch, &ours, &theirs, &upstream) < 0) {
-   if (!upstream)
-   return;
-   upstream_is_gone = 1;
-   }
-
-   if (show_upstream_ref) {
-   ref = shorten_unambiguous_ref(upstream, 0);
-   if (want_color(branch_use_color))
-   strbuf_addf(&fancy, "%s%s%s",
-   branch_get_color(BRANCH_COLOR_UPSTREAM),
-   ref, 
branch_get_color(BRANCH_COLOR_RESET));
-   else
-   strbuf_addstr(&fancy, ref);
-   }
-
-   if (upstream_is_gone) {
-   if (show_upstream_ref)
-   strbuf_addf(stat, _("[%s: gone]"), fancy.buf);
-   else
-   added_decoration = 0;
-   } else if (!ours && !theirs) {
-   if (show_upstream_ref)
-   strbuf_addf(stat, _("[%s]"), fancy.buf);
-   else
-   added_decoration = 0;
-   } else if (!ours) {
-   if (show_upstream_ref)
-   strbuf_addf(stat, _("[%s: behind %d]"), fancy.buf, 
theirs);
-   else
-   strbuf_addf(stat, _("[behind %d]"), theirs);
-
-   } else if (!theirs) {
-   if (show_upstream_ref)
-   strbuf_addf(stat, _("[%s: ahead %d]"), fancy.buf, ours);
-   else
-   strbuf_addf(stat, _("[ahead %d]"), ours);
-   } else {
-   if (show_upstream_ref)
-   strbuf_addf(stat, _("[%s: ahead %d, behind %d]"),
-   fancy.buf, ours, theirs);
-   else
-   strbuf_addf(stat, _("[ahead %d, behind %d]"),
-   ours, theirs);
-   }
-   strbuf_release(&fancy);
-   if (added_decoration)
-   strbuf_addch(stat, ' ');
-   free(ref);
-}
-
-static void add_verbose_info(struct strbuf *out, struct ref_array_item *item,
-struct ref_filter *filter, const char *refname)
-{
-   struct strbuf subject = STRBUF_INIT, stat = STRBUF_INIT;
-   const char *sub = _("  invalid ref ");
-   struct commit *commit = item->commit;
-
-   if (!parse_commit(commit)) {
-   pp_commit_easy(CMIT_FMT_ONELINE, commit, &subject);
-   sub = subject.buf;
-   }
-
-   if (item->kind == FILTER_REFS_BRANCHES)
-   fill_tracking_info(&stat, refname, filter->verbose > 1);
-
-   strbuf_addf(out, " %s %s%s",
-   find_unique_abbrev(item->commit->object.oid.hash, 
filter->abbrev),
-   stat.buf, sub);
-   strbuf_release(&stat);
-   strbuf_release(&subject);
-}
-
-static void format_and_print_ref_item(struct ref_array_item *item, int 
maxwidth,
-  

[PATCH v2 06/16] ref-filter: introduce format_ref_array_item()

[Karthik Nayak]

To allow column display, we will need to first render the output in a
string list to allow print_columns() to compute the proper size of
each column before starting the actual output. Introduce the function
format_ref_array_item() that does the formatting of a ref_array_item
to an strbuf.

show_ref_array_item() is kept as a convenience wrapper around it which
obtains the strbuf and prints it the standard output.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 16 
 ref-filter.h |  3 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 7004bf0..3bb474f 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1813,10 +1813,10 @@ static void append_literal(const char *cp, const char 
*ep, struct ref_formatting
}
 }
 
-void show_ref_array_item(struct ref_array_item *info, const char *format, int 
quote_style)
+void format_ref_array_item(struct ref_array_item *info, const char *format,
+  int quote_style, struct strbuf *final_buf)
 {
const char *cp, *sp, *ep;
-   struct strbuf *final_buf;
struct ref_formatting_state state = REF_FORMATTING_STATE_INIT;
 
state.quote_style = quote_style;
@@ -1846,9 +1846,17 @@ void show_ref_array_item(struct ref_array_item *info, 
const char *format, int qu
}
if (state.stack->prev)
die(_("format: %%(end) atom missing"));
-   final_buf = &state.stack->output;
-   fwrite(final_buf->buf, 1, final_buf->len, stdout);
+   strbuf_addbuf(final_buf, &state.stack->output);
pop_stack_element(&state.stack);
+}
+
+void show_ref_array_item(struct ref_array_item *info, const char *format, int 
quote_style)
+{
+   struct strbuf final_buf = STRBUF_INIT;
+
+   format_ref_array_item(info, format, quote_style, &final_buf);
+   fwrite(final_buf.buf, 1, final_buf.len, stdout);
+   strbuf_release(&final_buf);
putchar('\n');
 }
 
diff --git a/ref-filter.h b/ref-filter.h
index 4aea594..0014b92 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -98,6 +98,9 @@ int parse_ref_filter_atom(const char *atom, const char *ep);
 int verify_ref_format(const char *format);
 /*  Sort the given ref_array as per the ref_sorting provided */
 void ref_array_sort(struct ref_sorting *sort, struct ref_array *array);
+/*  Based on the given format and quote_style, fill the strbuf */
+void format_ref_array_item(struct ref_array_item *info, const char *format,
+  int quote_style, struct strbuf *final_buf);
 /*  Print the ref using the given format and quote_style */
 void show_ref_array_item(struct ref_array_item *info, const char *format, int 
quote_style);
 /*  Callback function for parsing the sort option */
-- 
2.7.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

[PATCH v2 01/16] ref-filter: implement %(if), %(then), and %(else) atoms

[Karthik Nayak]

Implement %(if), %(then) and %(else) atoms. Used as
%(if)...%(then)...%(end) or %(if)...%(then)...%(else)...%(end). If the
format string between %(if) and %(then) expands to an empty string, or
to only whitespaces, then the whole %(if)...%(end) expands to the string
following %(then). Otherwise, it expands to the string following
%(else), if any. Nesting of this construct is possible.

This is in preparation for porting over `git branch -l` to use
ref-filter APIs for printing.

Add Documentation and tests regarding the same.

Mentored-by: Christian Couder 
Mentored-by: Matthieu Moy 
Signed-off-by: Karthik Nayak 
---
 Documentation/git-for-each-ref.txt |  45 +++--
 ref-filter.c   | 133 +++--
 t/t6302-for-each-ref-filter.sh |  70 +++
 3 files changed, 237 insertions(+), 11 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 012e8f9..d048561 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -141,10 +141,17 @@ align::
"width=" and/or "position=" prefixes may be omitted, and bare
 and  used instead.  For instance,
`%(align:,)`. If the contents length is more
-   than the width then no alignment is performed. If used with
-   '--quote' everything in between %(align:...) and %(end) is
-   quoted, but if nested then only the topmost level performs
-   quoting.
+   than the width then no alignment is performed.
+
+if::
+   Used as %(if)...%(then)...(%end) or
+   %(if)...%(then)...%(else)...%(end).  If there is an atom with
+   value or string literal after the %(if) then everything after
+   the %(then) is printed, else if the %(else) atom is used, then
+   everything after %(else) is printed. We ignore space when
+   evaluating the string before %(then), this is useful when we
+   use the %(HEAD) atom which prints either "*" or " " and we
+   want to apply the 'if' condition only on the 'HEAD' ref.
 
 In addition to the above, for commit and tag objects, the header
 field names (`tree`, `parent`, `object`, `type`, and `tag`) can
@@ -181,6 +188,20 @@ As a special case for the date-type fields, you may 
specify a format for
 the date by adding `:` followed by date format name (see the
 values the `--date` option to linkgit::git-rev-list[1] takes).
 
+Some atoms like %(align) and %(if) always require a matching %(end).
+We call them "opening atoms" and sometimes denote them as %($open).
+
+When a scripting language specific quoting is in effect (i.e. one of
+`--shell`, `--perl`, `--python`, `--tcl` is used), except for opening
+atoms, replacement from every %(atom) is quoted when and only when it
+appears at the top-level (that is, when it appears outside
+%($open)...%(end)).
+
+When a scripting language specific quoting is in effect, everything
+between a top-level opening atom and its matching %(end) is evaluated
+according to the semantics of the opening atom and its result is
+quoted.
+
 
 EXAMPLES
 
@@ -268,6 +289,22 @@ eval=`git for-each-ref --shell --format="$fmt" \
 eval "$eval"
 
 
+
+An example to show the usage of %(if)...%(then)...%(else)...%(end).
+This prefixes the current branch with a star.
+
+
+git for-each-ref --format="%(if)%(HEAD)%(then)* %(else)  
%(end)%(refname:short)" refs/heads/
+
+
+
+An example to show the usage of %(if)...%(then)...%(end).
+This prints the authorname, if present.
+
+
+git for-each-ref --format="%(refname)%(if)%(authorname)%(then) 
%(color:red)Authored by: %(authorname)%(end)"
+
+
 SEE ALSO
 
 linkgit:git-show-ref[1]
diff --git a/ref-filter.c b/ref-filter.c
index bc551a7..41e73f0 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -21,6 +21,12 @@ struct align {
unsigned int width;
 };
 
+struct if_then_else {
+   unsigned int then_atom_seen : 1,
+   else_atom_seen : 1,
+   condition_satisfied : 1;
+};
+
 /*
  * An atom is a valid field atom listed below, possibly prefixed with
  * a "*" to denote deref_tag().
@@ -203,6 +209,9 @@ static struct {
{ "color", FIELD_STR, color_atom_parser },
{ "align", FIELD_STR, align_atom_parser },
{ "end" },
+   { "if" },
+   { "then" },
+   { "else" },
 };
 
 #define REF_FORMATTING_STATE_INIT  { 0, NULL }
@@ -210,7 +219,7 @@ static struct {
 struct ref_formatting_stack {
struct ref_formatting_stack *prev;
struct strbuf output;
-   void (*at_end)(struct ref_formatting_stack *stack);
+   void (*at_end)(struct ref_formatting_stack **stack);
void *at_end_data;
 };
 
@@ -343,13 +352,14 @@ static void pop_stack_element(struct ref_formatting_stack 
**stack)
*stack = prev;
 }
 
-static void end_align_handler(struct ref_formatting_stack *stack)
+static void end_align_handler(struct ref_formatting_stack **stack)
 {
-   

[PATCH v2 00/16] port branch.c to use ref-filter's printing options

[Karthik Nayak]

This is part of unification of the commands 'git tag -l, git branch -l
and git for-each-ref'. This ports over branch.c to use ref-filter's
printing options.

Initially posted here: $(gmane/279226). It was decided that this series
would follow up after refactoring ref-filter parsing mechanism, which
is now merged into master (9606218b32344c5c756f7c29349d3845ef60b80c).

v1 can be found here: $(gmane/288342)

Changes in this version:

1. Implement parser atoms for %(if:equals=...) and %(if:notequals=...)
2. Include a pointer to the corresponding used_atom within atom_value.
3. add missing documentation for %(upstream:track).
4. Fix commit message.

Thanks to Jacob and Junio for their suggestions on the first iteration.

Karthik Nayak (16):
  ref-filter: implement %(if), %(then), and %(else) atoms
  ref-filter: include reference to 'used_atom' within 'atom_value'
  ref-filter: implement %(if:equals=) and
%(if:notequals=)
  ref-filter: modify "%(objectname:short)" to take length
  ref-filter: move get_head_description() from branch.c
  ref-filter: introduce format_ref_array_item()
  ref-filter: make %(upstream:track) prints "[gone]" for invalid
upstreams
  ref-filter: add support for %(upstream:track,nobracket)
  ref-filter: make "%(symref)" atom work with the ':short' modifier
  ref-filter: introduce symref_atom_parser()
  ref-filter: introduce refname_atom_parser()
  ref-filter: add support for %(refname:dir) and %(refname:base)
  ref-filter: allow porcelain to translate messages in the output
  branch, tag: use porcelain output
  branch: use ref-filter printing APIs
  branch: implement '--format' option

 Documentation/git-branch.txt   |   7 +-
 Documentation/git-for-each-ref.txt |  58 -
 builtin/branch.c   | 267 ++
 builtin/tag.c  |   2 +
 ref-filter.c   | 447 +++--
 ref-filter.h   |   7 +
 t/t3203-branch-output.sh   |  12 +
 t/t6040-tracking-info.sh   |   2 +-
 t/t6300-for-each-ref.sh|  40 +++-
 t/t6302-for-each-ref-filter.sh |  88 
 10 files changed, 653 insertions(+), 277 deletions(-)

Interdiff:

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 193e99e..578bbd1 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -116,10 +116,12 @@ 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).  Append `:track,nobracket` to show tracking
-   information without brackets (i.e "ahead N, behind M").  Has
-   no effect if the ref does not have tracking information
-   associated with it.
+   or "=" (in sync).  Has no effect if the ref does not have
+   tracking information associated with it. `:track` also prints
+   "[gone]" whenever unknown upstream ref is encountered. Append
+   `:track,nobracket` to show tracking information without
+   brackets (i.e "ahead N, behind M").  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 76ea7c3..3435df1 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -75,6 +75,10 @@ static struct used_atom {
unsigned int nlines;
} contents;
struct {
+   const char *if_equals,
+   *not_equals;
+   } if_then_else;
+   struct {
enum { O_FULL, O_LENGTH, O_SHORT } option;
unsigned int length;
} objectname;
@@ -226,6 +230,18 @@ static void align_atom_parser(struct used_atom *atom, 
const char *arg)
string_list_clear(¶ms, 0);
 }
 
+static void if_atom_parser(struct used_atom *atom, const char *arg)
+{
+   if (!arg)
+   return;
+   else if (skip_prefix(arg, "equals=", &atom->u.if_then_else.if_equals))
+;
+   else if (skip_prefix(arg, "notequals=", 
&atom->u.if_then_else.not_equals))
+   ;
+   else
+   die(_("unrecognized %%(if) argument: %s"), arg);
+}
+
 static void symref_atom_parser(struct used_atom *atom, const char *arg)
 {
if (!arg)
@@ -295,7 +311,7 @@ static struct {
{ "color", FIELD_STR, color_atom_parser },
{ "align", FIELD_STR, align_atom_parser },
{ "end" },
-   { "if" },
+   { "if", FIELD_STR, if_atom_parser },
{ "then" },
{ "else" },
 };
@@ -316,11 +332,9 @@ struct ref_formatting_state {
 
 struct atom_value {
const char *s;
-   union {
-   struct align align;
-   } u;
void (*handler)(struct atom_valu

Re: [ANNOUNCE] Git v2.8.0-rc2

[Jiang Xin]

2016-03-14 23:29 GMT+08:00 Michael J Gruber :
> Hi Junio,
>
> Have you pulled git.pot for 2.8.0 already? [1]
>
> Maybe I'm not up-to-date on the release cycle timing regarding l10n, but
> I was trying to fix a mixed translation/non-translation issue, and it
> turned out the reason is probably that it is not in "git.pot":
>
> "behind " is in git.pot
> "ahead " is not in git.pot

Yes, I find your commit has just been merged in the master branch, and
it brings one extra message to be translated in Git v2.8.0 l10n.

So let's start round #3 of l10n for Git 2.8.0 to make it perfect.

> Now, I can recreate git.pot locally, of course, but localisations such
> as de.po seem to have those translation commented out because they're
> missing from git.pot.
>
> Basically, translations don't get proper testing at this point in the
> release cycle.

I will send a pull request to Junio right now, and you can test it on
a updated git.pot.


-- 
Jiang Xin
--
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 15/15] branch: implement '--format' option

[Karthik Nayak]

On Tue, Mar 8, 2016 at 7:28 AM, Jacob Keller  wrote:
> On Sun, Mar 6, 2016 at 4:05 AM, Karthik Nayak  wrote:
>> Implement the '--format' option provided by 'ref-filter'.
>> This lets the user list tags as per desired format similar
>> to the implementation in 'git for-each-ref'.
>>
>
> s/tags/branches/ maybe?
>
> Thanks,
> Jake

Copy-Paste error, will fix. Thank you.

-- 
Regards,
Karthik Nayak
--
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

SVN clone on Cygwin drops a / and reports "not a complete URL"

[Adam Dinwoodie]

Hi all,

Currently, attempting to clone a Subversion repository using an svn://
or https:// URI specified with -T fails on Cygwin:

$ git svn init -T svn://svn.code.sf.net/p/squirrelmail/code/trunk
Initialized empty Git repository in /home/add/tmp/.git/
E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete URL  
and a separate URL is not specified

I don't think this is a problem in Git itself -- I see the same
behaviour on clean builds of both v2.7.0 and v2.2.0, and I'm pretty sure
this used to work, so that would imply there's something in the Cygwin
environment that's changed.  Nonetheless I'm reporting here in the hope
that somebody else will have seen a similar problem or have an idea what
might be going wrong.

Interestingly, the below _does_ work:

$ git svn init svn://svn.code.sf.net/p/squirrelmail/code
Initialized empty Git repository in /home/add/tmp/.git/

$ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk

$ git svn fetch
r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
A   squirrelmail/ATHORS
A   squirrelmail/login.php3
A   squirrelmail/signout.php3
...

There are no obvious test case failures, either.

Does anyone have any ideas about what might be going wrong?
--
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 smudge filter fails

[Stephen Morton]

On Thu, Mar 10, 2016 at 5:04 PM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>> On Thu, Mar 10, 2016 at 09:45:19AM -0500, Stephen Morton wrote:
>>
>>> I am a bit confused because this is basically the example used in
>>> ProGit [1] and it is fundamentally broken. In fact, if I understand
>>> correctly, this means that smudge filters cannot be relied upon to
>>> provide any 'keyword expansion' type tasks because they will all by
>>> nature have to query the file with 'git log'.
>>
>> Interesting. Perhaps I am missing something (I am far from an expert in
>> clean/smudge filters, which I do not generally use myself), but the
>> example in ProGit looks kind of bogus to me. I don't think it ever would
>> have worked reliably, under any version of git.
>>
>>> (Note that although in my example I used 'git checkout', with an only
>>> slightly more complicated example I can make it fail on 'git pull'
>>> which is perhaps a much more realistic use case. That was probably
>>> implied in your answer, I just wanted to mention it.)
>>
>> Yeah, I think the issue is basically the same for several commands which
>> update the worktree and the HEAD. Most of them are going to do the
>> worktree first.
>
> You can have a pair of branches A and B that have forked long time
> ago, and have a path F that has been changed identically since they
> forked, perhaps by cherry-picking the same change.  This happens all
> the time.
>
> If there were some mechanism that modifies the checked out version
> of F with information that depends on the history that leads to A
> (e.g. "which commit that is an ancestor of A last modified F?")
> when you check out branch A, it will become invalid when you do "git
> checkout B", because the path F will not change because they are the
> same between the branches.  In short, CVS $Id$-style substitutions
> that depend on the history fundamentally does not work, unless you
> are willing to always rewrite the whole working tree every time you
> switch branches.
>
> The smudge and clean filters are given _only_ the blob contents and
> nothing else, not "which commit (or tree) the blob is taken from",
> not "which path this blob sits in that tree-ish", not "what branch
> am I on" and this is a very much deliberate design decision made in
> order to avoid leading people to a misguided attempt to mimick CVS
> $Id$-style substitutions.
>


I will raise an Issue with ProGit.

It's perhaps beyond the scope of my original question, but for
situations where I need a "last change date" embedded in a file (e.g.
because a protocol standard requires it), is there any recommended way
to do so? We've the hard way that hardcoding makes
merging/cherry-picking a bit of a nightmare and should be avoided. Is
a post-checkout hook the way to go? I've actually found the smudge
filter to be very slow for this application as each file is processed
in series; a post-commit hook that could operate on files in parallel
would likely be substantially faster.

Stephen

(Sorry about the earlier top-posting. I didn't realize what gmail was
doing until after it had happened.)
--
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 04/19] index-helper: new daemon for caching index and related stuff

[Junio C Hamano]

Duy Nguyen  writes:

> Another aspect that's not mentioned is, we keep this daemon's logic as
> thin as possible. The "brain" stays in git. So the daemon can read and
> validate stuff, but that's about all it's allowed to do. It's not
> supposed to add/create new contents. It's not even allowed to accept
> direct updates from git.

That explanation does make the intent clear. It is a kind of design
decision that needs to be made early and that is hard to change
later (I am not saying I see the need of changing, though), so it is
worth stating explicitly to guide future readers and updaters of the
code.

Thanks.
--
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 18/19] index-helper: autorun

[Johannes Schindelin]

Hi Duy,

On Tue, 15 Mar 2016, Duy Nguyen wrote:

> On Thu, Mar 10, 2016 at 1:36 AM, David Turner  
> wrote:
> > Introduce a new config option, indexhelper.autorun, to automatically
> > run git index-helper before starting up a builtin git command.  This
> > enables users to keep index-helper running without manual
> > intervention.
> 
> This could be a problem on Windows because "index-helper --detach"
> does not work there. I have no idea how "daemons" are managed on
> Windows and not sure if our design is still good when such a "daemon"
> is added on Windows. So I'm pulling Johannes in for his opinions.
> 
> Background for Johannes. We're adding "git index-helper" daemon (one
> per repo) to cache the index in memory to speed up index load time
> (and in future probably name-hash too, I think it's also more often
> used on Windows because of case-insensitive fs). It also enables
> watchman (on Windows) for faster refresh. This patch allows to start
> the daemon automatically if it's not running. But I don't know it will
> work ok on Windows.
> 
> Assuming that "index-helper" service has to be installed and started
> from system, there can only be one service running right? This clashes
> with the per-repo daemon design... I think it can stilf work, if the
> main service just spawns new process, one for each repo. But again I'm
> not sure.

If we want to run the process as a Windows service, you are correct, there
really can only be one. Worse: it runs with admin privileges.

But why not just keep it running as a detached process? We can run those
on Windows, and if we're opening a named pipe whose name reveals the
one-to-one mapping with the index in question, I think we are fine (read:
we can detect whether the process is running already).

We can even tell those processes to have a timeout, or to react to other
system events.

Please note that I am *very* interested in this feature (speeding up index
operations).

Ciao,
Dscho
--
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/RFC/GSoC 09/17] rebase-common: implement cache_has_unstaged_changes()

[Johannes Schindelin]

Hi Duy,

On Tue, 15 Mar 2016, Duy Nguyen wrote:

> On Tue, Mar 15, 2016 at 3:54 AM, Johannes Schindelin
>  wrote:
> > In my 'interactive-rebase' branch...
> 
> 64 commits! Maybe next time we should announce wip branches like this
> when we start doing stuff so people don't overlap. Of course these
> branches do not have to be perfect (and can be force pushed from time
> to time, even).

Much of this is cleanup in the beginning. And I tried to split out a patch
I thought was uncontentious, and promptly ran into a philosophical
discussion I did not seek ;-)

Ciao,
Dscho
--
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 0/1] Introduce a way to create a branch and worktree at the same time

[Duy Nguyen]

On Tue, Mar 15, 2016 at 8:56 PM, Johannes Schindelin
 wrote:
> Sure. And with the repository being put elsewhere, you also buy the tedium
> to no longer be able to simply "less .git/rebase-apply/patch". Which I
> have to type *a lot*. You win some, you lose some. If you ask me, you lose
> some more, but in some cases that is worth it.

If you start to use git-worktree, you'll need to type even longer. I
notice I do and am seriously considering an alias of `git rev-parse
--git-path rebase-apply/patch` to type less temporarily. But this is
the lack of proper UI. "git rebase" should provide a way to look at
this file (and maybe some others too). I just don't know what the
option would be and how we align it with git-am, which shares this
same problem.
-- 
Duy
--
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 0/1] Introduce a way to create a branch and worktree at the same time

[Johannes Schindelin]

Hi Duy,

On Tue, 15 Mar 2016, Duy Nguyen wrote:

> On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin
>  wrote:
> >> That approach to implement the UI that directly faces the end users
> >> via scripting would let your users choose layouts more flexibly.
> >> Some people may want a repository and its worktrees next to each
> >> other, some others may want the worktrees embedded inside the main
> >> repository, yet some others may want layouts other than those two.
> >
> > Having the worktree in a totally different location than the associated
> > repository is *very* confusing.
> 
> I disagree (unless I misunderstood you).

How is it not confusing having all of your worktrees, no matter whether
they connect to git.git, to git-for-windows/build-extra.git, to
Alexpux/MSYS2-packages.git, to cygwin.git, to curl/curl.git, to
whatever.git inside $HOME/worktrees/?

I tell you how it is not confusing. It is not confusing by artificially
re-creating the hierarchy inside the $HOME/worktrees/ directory.

And you only need to re-create the hierarchy because, you guessed it, you
tried to disconnect the worktrees from their repositories.

So it is nothing but a bad old workaround, is what it is.

> One of the use cases I have for multi worktree is move all repos to a
> central place. Remember the .git directory security bug?

I remember.

> It would not happen if the repo is put away.

Sure. And with the repository being put elsewhere, you also buy the tedium
to no longer be able to simply "less .git/rebase-apply/patch". Which I
have to type *a lot*. You win some, you lose some. If you ask me, you lose
some more, but in some cases that is worth it.

> And it would be easier to backup repo data too. Also, "git worktree
> list" is there to locate any worktree. I don't see why it's confusing.

Yeah, it is clear to me now that you do not find it confusing. Even if I
find that fact in and of itself confusing, because it is very, very
confusing to me to have the repository so far away from my worktree as to
forget where it actually is, opening the door real wide for trouble e.g.
by archiving my repository behind my worktree's back.

You win some, you lose some. I am simply not prepared to lose *that* much.
My worktrees will stay inside my originally checked out working directory,
thankyouverymuch.

Ciao,
Dscho
--
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 19/19] hack: watchman/untracked cache mashup

[Duy Nguyen]

On Thu, Mar 10, 2016 at 1:36 AM, David Turner  wrote:
>  static struct watchman_query *make_query(const char *last_update)
> @@ -60,8 +61,24 @@ static void update_index(struct index_state *istate,
> continue;
>
> pos = index_name_pos(istate, wm->name, strlen(wm->name));
> -   if (pos < 0)
> +   if (pos < 0) {
> +   if (istate->untracked) {
> +   char *name = xstrdup(wm->name);
> +   char *dname = dirname(name);
> +
> +   /*
> +* dirname() returns '.' for the root,
> +* but we call it ''.
> +*/
> +   if (dname[0] == '.' && dname[1] == 0)
> +   
> string_list_append(&istate->untracked->invalid_untracked, "");
> +   else
> +   
> string_list_append(&istate->untracked->invalid_untracked,
> +  dname);
> +   free(name);
> +   }
> continue;
> +   }

So if we detect an updated file that's not in the index, we are
prepared to invalidate that path, correct? We may invalidate more than
necessary if that's true. Imagine a.o is already ignored. If it's
rebuilt, we should not need to update untracked cache.

What I had in mind (and argued with watchman devs a bit [1]) was
maintain the file list of each clock and compare the file list of
different clocks to figure out what files are added or deleted. Then
we can generate invalidation list more accurately. We need to keep at
least one file list corresponds to  the clock saved in the index. When
we get the refresh request, we get a new file list (with new clock),
do a diff then save the invalidation list as an extension. Once we
notice that new clock is written back in index, we can discard older
file lists. In theory we should not need to keep too many file lists,
so even if one list is big, it should not be a big problem.

I have a note with me about race conditions with this approach, but I
haven't remembered exactly why or how yet.. My recent thoughts about
it though, are race conditions when you do "git status" is probably
tolerable. After all if you're doing some I/O when you do git-status,
you're guaranteed to miss some updates.

[1] https://github.com/facebook/watchman/issues/65
-- 
Duy
--
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 18/19] index-helper: autorun

[Duy Nguyen]

On Thu, Mar 10, 2016 at 1:36 AM, David Turner  wrote:
> Introduce a new config option, indexhelper.autorun, to automatically
> run git index-helper before starting up a builtin git command.  This
> enables users to keep index-helper running without manual
> intervention.

This could be a problem on Windows because "index-helper --detach"
does not work there. I have no idea how "daemons" are managed on
Windows and not sure if our design is still good when such a "daemon"
is added on Windows. So I'm pulling Johannes in for his opinions.

Background for Johannes. We're adding "git index-helper" daemon (one
per repo) to cache the index in memory to speed up index load time
(and in future probably name-hash too, I think it's also more often
used on Windows because of case-insensitive fs). It also enables
watchman (on Windows) for faster refresh. This patch allows to start
the daemon automatically if it's not running. But I don't know it will
work ok on Windows.

Assuming that "index-helper" service has to be installed and started
from system, there can only be one service running right? This clashes
with the per-repo daemon design... I think it can stilf work, if the
main service just spawns new process, one for each repo. But again I'm
not sure.

> Signed-off-by: David Turner 
> ---
>  git.c   | 38 +-
>  index-helper.c  | 11 ++-
>  t/t7900-index-helper.sh | 10 ++
>  3 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/git.c b/git.c
> index a4f6f71..ccf04ab 100644
> --- a/git.c
> +++ b/git.c
> @@ -521,6 +521,40 @@ static void strip_extension(const char **argv)
>  #define strip_extension(cmd)
>  #endif
>
> +static int want_auto_index_helper(void)
> +{
> +   int want = -1;
> +   const char *value = NULL;
> +   const char *key = "indexhelper.autorun";
> +
> +   if (git_config_key_is_valid(key) &&
> +   !git_config_get_value(key, &value)) {
> +   int b = git_config_maybe_bool(key, value);
> +   want = b >= 0 ? b : 0;
> +   }
> +   return want;
> +}
> +
> +static void maybe_run_index_helper(struct cmd_struct *cmd)
> +{
> +   const char *argv[] = {"git-index-helper", "--detach", "--auto", NULL};
> +   int status;
> +
> +   if (!(cmd->option & NEED_WORK_TREE))
> +   return;
> +
> +   if (want_auto_index_helper() <= 0)
> +   return;
> +
> +   trace_argv_printf(argv, "trace: auto index-helper:");
> +
> +   status = run_command_v_opt(argv, RUN_SILENT_EXEC_FAILURE | 
> RUN_CLEAN_ON_EXIT);
> +
> +   if (status) {
> +   warning("You specified indexhelper.autorun, but running 
> git-index-helper failed");
> +   }
> +}
> +
>  static void handle_builtin(int argc, const char **argv)
>  {
> const char *cmd;
> @@ -536,8 +570,10 @@ static void handle_builtin(int argc, const char **argv)
> }
>
> builtin = get_builtin(cmd);
> -   if (builtin)
> +   if (builtin) {
> +   maybe_run_index_helper(builtin);
> exit(run_builtin(builtin, argc, argv));
> +   }
>  }
>
>  static void execv_dashed_external(const char **argv)
> diff --git a/index-helper.c b/index-helper.c
> index a75da60..bc5c328 100644
> --- a/index-helper.c
> +++ b/index-helper.c
> @@ -379,6 +379,7 @@ int main(int argc, char **argv)
> int idle_in_minutes = 10, detach = 0;
> int ignore_existing = 0;
> int kill_existing = 0;
> +   int nongit = 0, autorun = 0;
> const char *pid_file;
> struct option options[] = {
> OPT_INTEGER(0, "exit-after", &idle_in_minutes,
> @@ -388,6 +389,7 @@ int main(int argc, char **argv)
> OPT_BOOL(0, "detach", &detach, "detach the process"),
> OPT_BOOL(0, "ignore-existing", &ignore_existing, "run even if 
> another index-helper seems to be running for this repo"),
> OPT_BOOL(0, "kill", &kill_existing, "kill any running 
> index-helper for this repo"),
> +   OPT_BOOL(0, "auto", &autorun, "this is an automatic run of 
> git index-helper, so certain errors can be solved by silently exiting"),
> OPT_END()
> };
>
> @@ -397,11 +399,18 @@ int main(int argc, char **argv)
> if (argc == 2 && !strcmp(argv[1], "-h"))
> usage_with_options(usage_text, options);
>
> -   prefix = setup_git_directory();
> +   prefix = setup_git_directory_gently(&nongit);
> if (parse_options(argc, (const char **)argv, prefix,
>   options, usage_text, 0))
> die(_("too many arguments"));
>
> +   if (nongit) {
> +   if (autorun)
> +   exit(0);
> +   else
> +   die("Not a git repository");
> +   }
> +
> if (ignore_existing && kill_existing)
> die(_("--ignore-existing and --kill don't make sense 
> togethe

Re: [PATCH 04/19] index-helper: new daemon for caching index and related stuff

[Duy Nguyen]

On Thu, Mar 10, 2016 at 6:09 AM, Junio C Hamano  wrote:
> David Turner  writes:
>
>> From: Nguyễn Thái Ngọc Duy 
>>
>> Instead of reading the index from disk and worrying about disk
>> corruption, the index is cached in memory (memory bit-flips happen
>> too, but hopefully less often). The result is faster read. Read time
>> is reduced by 70%.
>>
>> The biggest gain is not having to verify the trailing SHA-1, which
>> takes lots of time especially on large index files. But this also
>> opens doors for further optimiztions:
>>
>>  - we could create an in-memory format that's essentially the memory
>>dump of the index to eliminate most of parsing/allocation
>>overhead. The mmap'd memory can be used straight away. Experiment
>>[1] shows we could reduce read time by 88%.
>>
>>  - we could cache non-index info such as name hash
>>
>> The shared memory's name folows the template "git--"
>> where  is the trailing SHA-1 of the index file.  is
>> "index" for cached index files (and may be "name-hash" for name-hash
>> cache). If such shared memory exists, it contains the same index
>> content as on disk. The content is already validated by the daemon and
>> git won't validate it again (except comparing the trailing SHA-1s).
>
> This indeed is an interesting approach; what is not explained but
> must be is when the on-disk index is updated to reflect the reality
> (if I am reading the explanation and the code right, while the
> daemon is running, its in-core cache becomes the source of truth by
> forcing everybody's read-index-from() to go to the daemon).  The
> explanation could be "this is only for read side, and updating the
> index happens via the traditional 'write a new file and rename it to
> the final place' codepath, at which time the daemon must be told to
> re-read it."

Another aspect that's not mentioned is, we keep this daemon's logic as
thin as possible. The "brain" stays in git. So the daemon can read and
validate stuff, but that's about all it's allowed to do. It's not
supposed to add/create new contents. It's not even allowed to accept
direct updates from git.
-- 
Duy
--
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 04/19] index-helper: new daemon for caching index and related stuff

[Duy Nguyen]

On Thu, Mar 10, 2016 at 1:36 AM, David Turner  wrote:
> Git can poke the daemon to tell it to refresh the index cache, or to
> keep it alive some more minutes via UNIX signals.

The reason I went with UNIX signals was because it made it possible to
make a simple GetMessage loop, the only thing I can remember from my
Windows time, on Windows later. It sounded clever, but because this is
more like UDP (vs TCP) it's harder for communication. For example, we
can't get a confirmation after a request... UNIX sockets would be more
natural.

Since this patch was written, watchman has gained Windows support. I
just looked at the code, it uses named pipe on Windows. So maybe we
can just go with that too (if only because it has been proven working
in practice) and we can go back to UNIX sockets on the *nix side. Too
bad we can't just copy some functions from watchman because of license
incompatibility. But we can leave Windows support to gfw team now, I
think.
-- 
Duy
--
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