Re: git --literal-pathspecs add -u says "fatal: pathspec ':/' did not match any files"

2015-10-24 Thread Victor Leschuk 

Hello Noam,

The problem is that in the absence of explicit argument we set the list 
of files to special path ":/" which means repo root:


if ((0 < addremove_explicit || take_worktree_changes) && !argc) {
static const char *whole[2] = { ":/", NULL };
argc = 1;
argv = whole;
}

And after that we treat it as regular file


if (!seen[i] && path[0] &&
((pathspec.items[i].magic &
  (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
 !file_exists(path))) {  /* < 
file_exists() here just checks lstat() result */
Maybe it'll make sense to modify file_exists() to treat ":/" specially. 
Something like that:


diff --git a/dir.c b/dir.c
index 109ceea..6cae3b9 100644
--- a/dir.c
+++ b/dir.c
@@ -2103,6 +2103,10 @@ int read_directory(struct dir_struct *dir, const 
char *path, int len, const stru

 int file_exists(const char *f)
 {
struct stat sb;
+   if (!strcmp(f, ":/")) {
+   /* ":/" - root dir, always exists */
+   return 1;
+   }
return lstat(f, &sb) == 0;
 }

--
Victor

On 10/24/2015 02:39 AM, Noam Postavsky wrote:

~/tmp/tmprepo$ git init
Initialized empty Git repository in /home/npostavs/tmp/tmprepo/.git/
~/tmp/tmprepo$ git --literal-pathspecs add -u
fatal: pathspec ':/' did not match any files
~/tmp/tmprepo$ git --version
git version 2.6.1

It was reported[1] that 2.0.2 and several following versions also fail
with the same error; I found that version 1.9.5 succeeds.

Adding a "." argument:

git --literal-pathspecs add -u .

succeeds in all versions.

[1]: https://github.com/magit/magit/issues/2354#issuecomment-150665961
--
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

t3203: --sort=objectsize failure on Windows

2015-10-24 Thread Johannes Sixt 
On Windows, I observe a failure of the test case 'git branch `--sort` 
option' introduced by aedcb7dc (branch.c: use 'ref-filter' APIs). The 
reason is that the resulting order generated by qsort is unspecified for 
entries that compare equal. In fact, the test case sorts 4 entries where 
there are only 2 different values.


To achieve a deterministic order, perhaps cmp_ref_sorting() should fall 
back to alphabetic comparison if the other criterion (when used) 
compares equal?


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

[PATCH 1/2] run-command: factor out child_process_clear()

2015-10-24 Thread René Scharfe 
Avoid duplication by moving the code to release allocated memory for
arguments and environment to its own function, child_process_clear().
Export it to provide a counterpart to child_process_init().

Signed-off-by: Rene Scharfe 
---
 Documentation/technical/api-run-command.txt |  7 +++
 run-command.c   | 15 +--
 run-command.h   |  1 +
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/Documentation/technical/api-run-command.txt 
b/Documentation/technical/api-run-command.txt
index a9fdb45..8bf3e37 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -46,6 +46,13 @@ Functions
The argument dir corresponds the member .dir. The argument env
corresponds to the member .env.
 
+`child_process_clear`::
+
+   Release the memory associated with the struct child_process.
+   Most users of the run-command API don't need to call this
+   function explicitly because `start_command` invokes it on
+   failure and `finish_command` calls it automatically already.
+
 The functions above do the following:
 
 . If a system call failed, errno is set and -1 is returned. A diagnostic
diff --git a/run-command.c b/run-command.c
index e17e456..13fa452 100644
--- a/run-command.c
+++ b/run-command.c
@@ -11,6 +11,12 @@ void child_process_init(struct child_process *child)
argv_array_init(&child->env_array);
 }
 
+void child_process_clear(struct child_process *child)
+{
+   argv_array_clear(&child->args);
+   argv_array_clear(&child->env_array);
+}
+
 struct child_to_clean {
pid_t pid;
struct child_to_clean *next;
@@ -327,8 +333,7 @@ int start_command(struct child_process *cmd)
 fail_pipe:
error("cannot create %s pipe for %s: %s",
str, cmd->argv[0], strerror(failed_errno));
-   argv_array_clear(&cmd->args);
-   argv_array_clear(&cmd->env_array);
+   child_process_clear(cmd);
errno = failed_errno;
return -1;
}
@@ -513,8 +518,7 @@ fail_pipe:
close_pair(fderr);
else if (cmd->err)
close(cmd->err);
-   argv_array_clear(&cmd->args);
-   argv_array_clear(&cmd->env_array);
+   child_process_clear(cmd);
errno = failed_errno;
return -1;
}
@@ -540,8 +544,7 @@ fail_pipe:
 int finish_command(struct child_process *cmd)
 {
int ret = wait_or_whine(cmd->pid, cmd->argv[0], 0);
-   argv_array_clear(&cmd->args);
-   argv_array_clear(&cmd->env_array);
+   child_process_clear(cmd);
return ret;
 }
 
diff --git a/run-command.h b/run-command.h
index 5428b04..12bb26c 100644
--- a/run-command.h
+++ b/run-command.h
@@ -47,6 +47,7 @@ struct child_process {
 
 #define CHILD_PROCESS_INIT { NULL, ARGV_ARRAY_INIT, ARGV_ARRAY_INIT }
 void child_process_init(struct child_process *);
+void child_process_clear(struct child_process *);
 
 int start_command(struct child_process *);
 int finish_command(struct child_process *);
-- 
2.6.2

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

[PATCH 2/2] daemon: plug memory leak

2015-10-24 Thread René Scharfe 
Call child_process_clear() when a child ends to release the memory
allocated for its environment.  This is necessary because unlike all
other users of start_command() we don't call finish_command(), which
would have taken care of that for us.

This leak was introduced by f063d38b (daemon: use cld->env_array
when re-spawning).

Signed-off-by: Rene Scharfe 
---
 daemon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/daemon.c b/daemon.c
index 56679a1..be70cd4 100644
--- a/daemon.c
+++ b/daemon.c
@@ -802,6 +802,7 @@ static void check_dead_children(void)
/* remove the child */
*cradle = blanket->next;
live_children--;
+   child_process_clear(&blanket->cld);
free(blanket);
} else
cradle = &blanket->next;
-- 
2.6.2

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

[RFC] t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" flaky?

2015-10-24 Thread Lars Schneider 
Hi,

while working on the Git CI integration I noticed that t5516 "75 - deny fetch 
unreachable SHA1, allowtipsha1inwant=true" (introduced in 68ee628) seems to be 
flaky on TravisCI. I get the following output in verbose mode:

>>>
expecting success: 
mk_empty testrepo &&
(
cd testrepo &&
git config uploadpack.allowtipsha1inwant $configallowtipsha1inwant 
&&
git commit --allow-empty -m foo &&
git commit --allow-empty -m bar &&
git commit --allow-empty -m xyz
) &&
SHA1_1=$(git --git-dir=testrepo/.git rev-parse HEAD^^) &&
SHA1_2=$(git --git-dir=testrepo/.git rev-parse HEAD^) &&
SHA1_3=$(git --git-dir=testrepo/.git rev-parse HEAD) &&
(
cd testrepo &&
git reset --hard $SHA1_2 &&
git cat-file commit $SHA1_1 &&
git cat-file commit $SHA1_3
) &&
mk_empty shallow &&
(
cd shallow &&
test_must_fail git fetch ../testrepo/.git $SHA1_3 &&
test_must_fail git fetch ../testrepo/.git $SHA1_1 &&
git --git-dir=../testrepo/.git config 
uploadpack.allowreachablesha1inwant true &&
git fetch ../testrepo/.git $SHA1_1 &&
git cat-file commit $SHA1_1 &&
test_must_fail git cat-file commit $SHA1_2 &&
git fetch ../testrepo/.git $SHA1_2 &&
git cat-file commit $SHA1_2 &&
test_must_fail git fetch ../testrepo/.git $SHA1_3
)

Initialized empty Git repository in 
/home/travis/build/larsxschneider/git/t/trash 
directory.t5516-fetch-push/testrepo/.git/
[master (root-commit) a6b22ca] foo
 Author: A U Thor 
[master 5e26403] bar
 Author: A U Thor 
[master 64ea4c1] xyz
 Author: A U Thor 
HEAD is now at 5e26403 bar
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author A U Thor  1112912053 -0700
committer C O Mitter  1112912053 -0700
foo
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent 5e26403b4485d7a44fd8b65dc3f71e21c0dd6fad
author A U Thor  1112912053 -0700
committer C O Mitter  1112912053 -0700
xyz
Initialized empty Git repository in 
/home/travis/build/larsxschneider/git/t/trash 
directory.t5516-fetch-push/shallow/.git/
fatal: git upload-pack: not our ref 64ea4c133d59fa98e86a771eda009872d6ab2886
test_must_fail: died by signal: git fetch ../testrepo/.git 
64ea4c133d59fa98e86a771eda009872d6ab2886
not ok 75 - deny fetch unreachable SHA1, allowtipsha1inwant=true 
<<<

"git fetch ../testrepo/.git $SHA1_3" seems to die as follows:
1. fetch-pack.c:408 goto done;
2. fetch-pack.c:447 done:
3. fetch-pack.c:229 static void send_request... (send "0009done\n" --> 9 bytes)
4. write_or_die.c:74 write_or_die
5. wrapper.c:331 write_in_full
6. wrapper.c:281 xwrite
7. wrapper.c:287 write --> just dies with exit code 141?!
(use 4688abf to match the line numbers)

You can find the full logs about the CI run here:
https://travis-ci.org/larsxschneider/git/jobs/86984110

I repeatedly executed this test to demonstrate the flakiness:
failed after 100 attempts: 
https://travis-ci.org/larsxschneider/git/jobs/87181753
failed after 1876 attempts: 
https://travis-ci.org/larsxschneider/git/jobs/87181754
(all executed on bbd2929 from https://github.com/larsxschneider/git)

Unfortunately I was not able to make it fail on my local machine (OS X 10.9) 
nor on my VM (Ubuntu 14.10). Travis CI uses Ubuntu 12.04 LTS Server Edition 64 
bit with a AUFS file system.

Has anyone an idea what might causes these failures or can give me pointers how
to investigate it?

Thank you,
Lars--
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: t3203: --sort=objectsize failure on Windows

2015-10-24 Thread Karthik Nayak 
On Sat, Oct 24, 2015 at 1:19 PM, Johannes Sixt  wrote:
> On Windows, I observe a failure of the test case 'git branch `--sort`
> option' introduced by aedcb7dc (branch.c: use 'ref-filter' APIs). The reason
> is that the resulting order generated by qsort is unspecified for entries
> that compare equal. In fact, the test case sorts 4 entries where there are
> only 2 different values.

Thanks for reporting the error. Although I couldn't reproduce this on
a Linux environment.
I get what the problem is.

>
> To achieve a deterministic order, perhaps cmp_ref_sorting() should fall back
> to alphabetic comparison if the other criterion (when used) compares equal?
>

Seems like a simple and good way to go around this. will reply with a patch.

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

[PATCH] ref-filter: fallback on alphabetical comparison

2015-10-24 Thread Karthik Nayak 
In ref-filter.c the comparison of refs while sorting is handled by
cmp_ref_sorting() function. When sorting as per numerical values
(e.g. --sort=objectsize) there is no fallback comparison when both refs
hold the same value. This can cause unexpected results as pointed out
by Johannes Sixt ($gmane/280117).

Hence, fallback to alphabetical comparison based on the refname whenever
the other criterion is equal. Fix the test in t3203 in this regard.

Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 2 +-
 t/t3203-branch-output.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 046e73b..7b33cb8 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1698,7 +1698,7 @@ static int cmp_ref_sorting(struct ref_sorting *s, struct 
ref_array_item *a, stru
if (va->ul < vb->ul)
cmp = -1;
else if (va->ul == vb->ul)
-   cmp = 0;
+   cmp = strcmp(a->refname, b->refname);
else
cmp = 1;
}
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index f77971c..9f2d482 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -158,8 +158,8 @@ EOF
 
 test_expect_success 'git branch `--sort` option' '
cat >expect <<-\EOF &&
- branch-two
* (HEAD detached from fromtag)
+ branch-two
  branch-one
  master
EOF
-- 
2.6.2

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

[PATCH 0/2] checkout: added two options to control progress output

2015-10-24 Thread Edmundo Carmona 
From: Edmundo Carmona Antoranz 

checkout will refuse to print progress information if it's not connected
to a TTY. These patches will add two options:

--progress-no-tty: enable printing progress info even if not using a TTY
--progress-lf: print progress information using LFs instead of CRs

If none of these options is used, default behavior would be used to avoid
breaking current use cases

Edmundo Carmona Antoranz (2):
  checkout: progress on non-tty. progress with lf
  checkout: adjust documentation to the two new options

 Documentation/git-checkout.txt | 10 ++
 builtin/checkout.c | 12 ++--
 progress.c |  8 +++-
 progress.h |  1 +
 unpack-trees.c |  3 +++
 unpack-trees.h |  2 ++
 6 files changed, 33 insertions(+), 3 deletions(-)

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

[PATCH 1/2] checkout: progress on non-tty. progress with lf

2015-10-24 Thread Edmundo Carmona 
From: Edmundo Carmona Antoranz 

--progress-no-tty: option to write progress even if not working on a TTY
--progress-lf: option to print progress using LF instead of CR
Signed-off-by: Edmundo Carmona Antoranz 
---
 builtin/checkout.c | 12 ++--
 progress.c |  8 +++-
 progress.h |  1 +
 unpack-trees.c |  3 +++
 unpack-trees.h |  2 ++
 5 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index bc703c0..2c86a9a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -37,6 +37,8 @@ struct checkout_opts {
int overwrite_ignore;
int ignore_skipworktree;
int ignore_other_worktrees;
+   int progress_lf;
+   int progress_notty;
 
const char *new_branch;
const char *new_branch_force;
@@ -417,7 +419,8 @@ static int reset_tree(struct tree *tree, const struct 
checkout_opts *o,
opts.reset = 1;
opts.merge = 1;
opts.fn = oneway_merge;
-   opts.verbose_update = !o->quiet && isatty(2);
+   opts.verbose_update = !o->quiet && (o->progress_notty || isatty(2));
+   opts.eol = o->progress_lf ? _("\n") : NULL;
opts.src_index = &the_index;
opts.dst_index = &the_index;
parse_tree(tree);
@@ -501,7 +504,8 @@ static int merge_working_tree(const struct checkout_opts 
*opts,
topts.update = 1;
topts.merge = 1;
topts.gently = opts->merge && old->commit;
-   topts.verbose_update = !opts->quiet && isatty(2);
+   topts.verbose_update = !opts->quiet && (opts->progress_notty || 
isatty(2));
+   topts.eol = opts->progress_lf ? _("\n") : NULL;
topts.fn = twoway_merge;
if (opts->overwrite_ignore) {
topts.dir = xcalloc(1, sizeof(*topts.dir));
@@ -1156,6 +1160,10 @@ int cmd_checkout(int argc, const char **argv, const char 
*prefix)
N_("second guess 'git checkout 
'")),
OPT_BOOL(0, "ignore-other-worktrees", 
&opts.ignore_other_worktrees,
 N_("do not check if another worktree is holding the 
given ref")),
+   OPT_BOOL(0, "progress-lf", &opts.progress_lf,
+N_("write progress using lf instead of cr")),
+   OPT_BOOL(0, "progress-no-tty", &opts.progress_notty,
+N_("write progress info even if not using a TTY")),
OPT_END(),
};
 
diff --git a/progress.c b/progress.c
index 353bd37..3af0594 100644
--- a/progress.c
+++ b/progress.c
@@ -36,6 +36,7 @@ struct progress {
unsigned delay;
unsigned delayed_percent_treshold;
struct throughput *throughput;
+   const char *eol;
 };
 
 static volatile sig_atomic_t progress_update;
@@ -99,7 +100,7 @@ static int display(struct progress *progress, unsigned n, 
const char *done)
 
progress->last_value = n;
tp = (progress->throughput) ? progress->throughput->display.buf : "";
-   eol = done ? done : "   \r";
+   eol = done ? done : (progress->eol ? progress->eol : "   \r");
if (progress->total) {
unsigned percent = n * 100 / progress->total;
if (percent != progress->last_percent || progress_update) {
@@ -221,6 +222,7 @@ struct progress *start_progress_delay(const char *title, 
unsigned total,
progress->delayed_percent_treshold = percent_treshold;
progress->delay = delay;
progress->throughput = NULL;
+   progress->eol = NULL;
set_progress_signal();
return progress;
 }
@@ -230,6 +232,10 @@ struct progress *start_progress(const char *title, 
unsigned total)
return start_progress_delay(title, total, 0, 0);
 }
 
+void set_progress_eol(struct progress *p_progress, const char *eol) {
+   p_progress->eol = eol;
+}
+
 void stop_progress(struct progress **p_progress)
 {
stop_progress_msg(p_progress, _("done"));
diff --git a/progress.h b/progress.h
index 611e4c4..dbde34e 100644
--- a/progress.h
+++ b/progress.h
@@ -8,6 +8,7 @@ int display_progress(struct progress *progress, unsigned n);
 struct progress *start_progress(const char *title, unsigned total);
 struct progress *start_progress_delay(const char *title, unsigned total,
   unsigned percent_treshold, unsigned 
delay);
+void set_progress_eol(struct progress *p_progress, const char *eol);
 void stop_progress(struct progress **progress);
 void stop_progress_msg(struct progress **progress, const char *msg);
 
diff --git a/unpack-trees.c b/unpack-trees.c
index 8e2032f..250482b 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -202,6 +202,9 @@ static int check_updates(struct unpack_trees_options *o)
 
progress = start_progress_delay(_("Checking out files"),
total, 50, 1);
+   if (o->eol) {
+   set_progres

[PATCH 2/2] checkout: adjust documentation to the two new options

2015-10-24 Thread Edmundo Carmona 
From: Edmundo Carmona Antoranz 

Signed-off-by: Edmundo Carmona Antoranz 
---
 Documentation/git-checkout.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index e269fb1..4ff270c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -250,6 +250,16 @@ section of linkgit:git-add[1] to learn how to operate the 
`--patch` mode.
out anyway. In other words, the ref can be held by more than one
worktree.
 
+--progress-no-tty
+   By default, git will refuse to write progress information if it
+   detects it's not connected to a tty. In order to avoid this check,
+   this option can be used.
+
+--progress-lf
+   By default, git will write progress information using "carriage
+   return" (ascii 0x0d) so that it stays on a single line. This
+   option will make git print progress information on separate lines.
+
 ::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
-- 
2.6.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

[PATCH] use pop_commit() for consuming the first entry of a struct commit_list

2015-10-24 Thread René Scharfe 
Instead of open-coding the function pop_commit() just call it.  This
makes the intent clearer and reduces code size.

Signed-off-by: Rene Scharfe 
---
 builtin/fmt-merge-msg.c |  9 +++--
 builtin/merge.c | 12 +---
 builtin/reflog.c|  6 +-
 builtin/rev-parse.c |  7 ++-
 builtin/show-branch.c   | 17 +++--
 commit.c| 27 +++
 remote.c|  6 ++
 revision.c  | 27 +--
 shallow.c   |  6 +-
 upload-pack.c   |  6 ++
 10 files changed, 31 insertions(+), 92 deletions(-)

diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 4ba7f28..846004b 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -537,7 +537,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)
 static void find_merge_parents(struct merge_parents *result,
   struct strbuf *in, unsigned char *head)
 {
-   struct commit_list *parents, *next;
+   struct commit_list *parents;
struct commit *head_commit;
int pos = 0, i, j;
 
@@ -576,13 +576,10 @@ static void find_merge_parents(struct merge_parents 
*result,
parents = reduce_heads(parents);
 
while (parents) {
+   struct commit *cmit = pop_commit(&parents);
for (i = 0; i < result->nr; i++)
-   if (!hashcmp(result->item[i].commit,
-parents->item->object.sha1))
+   if (!hashcmp(result->item[i].commit, cmit->object.sha1))
result->item[i].used = 1;
-   next = parents->next;
-   free(parents);
-   parents = next;
}
 
for (i = j = 0; i < result->nr; i++) {
diff --git a/builtin/merge.c b/builtin/merge.c
index a0a9328..31241b8 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1019,7 +1019,7 @@ static struct commit_list *reduce_parents(struct commit 
*head_commit,
  int *head_subsumed,
  struct commit_list *remoteheads)
 {
-   struct commit_list *parents, *next, **remotes = &remoteheads;
+   struct commit_list *parents, **remotes;
 
/*
 * Is the current HEAD reachable from another commit being
@@ -1033,16 +1033,14 @@ static struct commit_list *reduce_parents(struct commit 
*head_commit,
/* Find what parents to record by checking independent ones. */
parents = reduce_heads(remoteheads);
 
-   for (remoteheads = NULL, remotes = &remoteheads;
-parents;
-parents = next) {
-   struct commit *commit = parents->item;
-   next = parents->next;
+   remoteheads = NULL;
+   remotes = &remoteheads;
+   while (parents) {
+   struct commit *commit = pop_commit(&parents);
if (commit == head_commit)
*head_subsumed = 0;
else
remotes = &commit_list_insert(commit, remotes)->next;
-   free(parents);
}
return remoteheads;
 }
diff --git a/builtin/reflog.c b/builtin/reflog.c
index f96ca2a..cf1145e 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -218,7 +218,6 @@ static int keep_entry(struct commit **it, unsigned char 
*sha1)
  */
 static void mark_reachable(struct expire_reflog_policy_cb *cb)
 {
-   struct commit *commit;
struct commit_list *pending;
unsigned long expire_limit = cb->mark_limit;
struct commit_list *leftover = NULL;
@@ -228,11 +227,8 @@ static void mark_reachable(struct expire_reflog_policy_cb 
*cb)
 
pending = cb->mark_list;
while (pending) {
-   struct commit_list *entry = pending;
struct commit_list *parent;
-   pending = entry->next;
-   commit = entry->item;
-   free(entry);
+   struct commit *commit = pop_commit(&pending);
if (commit->object.flags & REACHABLE)
continue;
if (parse_commit(commit))
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 02d747d..e92a782 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -281,11 +281,8 @@ static int try_difference(const char *arg)
b = lookup_commit_reference(end);
exclude = get_merge_bases(a, b);
while (exclude) {
-   struct commit_list *n = exclude->next;
-   show_rev(REVERSED,
-exclude->item->object.sha1,NULL);
-   free(exclude);
-   exclude = n;
+   struct commit *commit = pop_commit(&exclude);
+   show_rev(REVERSED, commit->object.sha1, NULL);

Re: [PATCH v1] git-p4: Add option to ignore empty commits

2015-10-24 Thread Lars Schneider 

On 20 Oct 2015, at 19:27, Junio C Hamano  wrote:

> larsxschnei...@gmail.com writes:
> 
>> diff --git a/git-p4.py b/git-p4.py
>> index 0093fa3..6c50c74 100755
>> --- a/git-p4.py
>> +++ b/git-p4.py
>> @@ -2288,12 +2288,6 @@ class P4Sync(Command, P4UserMap):
>> filesToDelete = []
>> 
>> for f in files:
>> -# if using a client spec, only add the files that have
>> -# a path in the client
>> -if self.clientSpecDirs:
>> -if self.clientSpecDirs.map_in_client(f['path']) == "":
>> -continue
>> -
>> filesForCommit.append(f)
>> if f['action'] in self.delete_actions:
>> filesToDelete.append(f)
> 
> Earlier, the paths outside the clientspec were not in filesToDelete
> (or filesToRead that is below the context here).  Now they all go to
> these arrays, and will hit this loop beyond the context:
> 
># deleted files...
>for f in filesToDelete:
>self.streamOneP4Deletion(f)
> 
> after leaving the above for loop.  I cannot quite see where this
> "stream one deletion" is turned into a no-op for paths outside after
> this patch gets applied.

Earlier the client spec filtering happened in "def streamP4Files(self, files)". 
I moved the code up to the caller of this function into "def commit(...)" which 
now calls "streamP4Files" with an already filtered file list. Therefore the 
logic should be exactly the same.


> Also I have this suspicion that those who do want to use client spec
> to get a narrowed view into the history would almost always want
> this "ignore empty" behaviour (I'd even say the current behaviour to
> leave empty commits by default is a bug).  What are the advantages
> of keeping empty commits?  If there aren't many, perhaps git-p4
> should by the default skip empties and require p4.keepEmpty
> configuration to keep them?

I agree. 
@Luke: What option do you prefer? "git-p4.keepEmptyCommits" or 
"git-p4.ignoreEmptyCommits" ?

Thanks,
Lars--
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: ancestor and descendant ~ clarification needed

2015-10-24 Thread Junio C Hamano 
Xue Fuqiao  writes:

> On Sat, Oct 24, 2015 at 12:56 AM, Junio C Hamano  wrote:
>>> I see.  Thank you.  What do you think about the following minor patch
>>> for user-manual.txt?
>>
>> While the updated text is more correct than the original, I do not
>> know if that is sufficient, or we would also want to mention the
>> "Already up-to-date!" case here while at it.
>
> I thought about that, and IMHO it's not needed.  The section name is
> "Fast-forward merges" and intends to introduce the "fast-forward"
> concept, which is irrelevant to "Already up-to-date!".

Okay.
--
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 --literal-pathspecs add -u says "fatal: pathspec ':/' did not match any files"

2015-10-24 Thread Noam Postavsky 
On Sat, Oct 24, 2015 at 3:13 AM, Victor Leschuk  wrote:
> The problem is that in the absence of explicit argument we set the list of
> files to special path ":/" which means repo root:

> And after that we treat it as regular file

Aha.

> Maybe it'll make sense to modify file_exists() to treat ":/" specially.

I'm not sure how this would translate into code, but it would make
more sense to me if we undo the effect of --literal-pathspecs when
setting arguments to ":/". After all, it's obviously not meant to be a
literal file so it shouldn't treated as one (also this way still
allows a user to pass --literal-pathspecs with ":/" to add an actual
directory named ":" (not that anyone should ever want that)).
--
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 --literal-pathspecs add -u says "fatal: pathspec ':/' did not match any files"

2015-10-24 Thread Junio C Hamano 
Victor Leschuk  writes:

> Maybe it'll make sense to modify file_exists() to treat ":/"
> specially.

The real problem is that the code assumes that it can internally use
":/" to mean "everything from the top", and with global 'literal
pathspec' magic, that is not the case.  "did not match" is a red
herring.  Even if you disable that typo-catcher, the resulting
pathspec will match only paths inside a directory whose name is ':',
so you would break 'add -u' in a more grave way.

Disabling the typo-catcher has another problem.  When an end user
says "git --literal-pathspecs add -u :/", the user means "I happen
to have this funnily named directory ':' and want to update
everything under it, but because :/ is normally taken as special, I
am passing --literal-pathspecs".  And if that ':' does not exist,
the user must get the "well you may have misspelt it" error.

But a code you are changing cannot tell if ":/" came from the end
user, or if it the one added by our code upon seeing "-u" or "-A"
without any pathspecs, to make that distinction so that you disable
it only for our internal ":/".

I think the right approach is something along the line of this patch
instead.

-- >8 --
Subject: add: simplify -u/-A without pathspec

Since Git 2.0, "add -u" and "add -A" run from a subdirectory without
any pathspec mean "everything in the working tree" (before 2.0, they
were limited to the current directory).  The limiting to the current
directory was implemented by inserting "." to the command line when
the end user did not give us any pathspec.  At 2.0, we updated the
code to insert ":/" (instead of '.') to consider everything from the
top-level, by using a pathspec magic "top".

The call to parse_pathspec() using the command line arguments is,
however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add:
convert to use parse_pathspec, 2013-07-14), which predates Git 2.0.
In retrospect, there was no need to turn "adding . to limit to the
directory" into "adding :/ to unlimit to everywhere" in Git 2.0;
instead we could just have done "if there is no pathspec on the
command line, just let it be".  The parse_pathspec() then would give
us a pathspec that matches everything and all is well.

Incidentally such a simplifcation also fixes a corner case bug that
stems from the fact that ":/" does not necessarily mean any magic.
A user would say "git --literal-pathspecs add -u :/" from the
command line when she has a directory ':' and wants to add
everything in it (and she knows that her :/ will be taken as
'everything under the sun' magic pathspec unless she disables the
magic with --literal-pathspecs).  The internal use of ':/' would
behave the same way as such an explicitly given ":/" when run with
"--literal-pathspecs", and will not add everything under the sun as
the code originally intended.

Signed-off-by: Junio C Hamano 
---

 builtin/add.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index b2a5c57..145f06e 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -336,14 +336,8 @@ int cmd_add(int argc, const char **argv, const char 
*prefix)
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with 
--dry-run"));
 
-   if ((0 < addremove_explicit || take_worktree_changes) && !argc) {
-   static const char *whole[2] = { ":/", NULL };
-   argc = 1;
-   argv = whole;
-   }
-
add_new_files = !take_worktree_changes && !refresh_only;
-   require_pathspec = !take_worktree_changes;
+   require_pathspec = !(take_worktree_changes || (0 < addremove_explicit));
 
hold_locked_index(&lock_file, 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 v1] git-p4: Add option to ignore empty commits

2015-10-24 Thread Lars Schneider 

On 21 Oct 2015, at 08:32, Luke Diamand  wrote:

> On 19/10/15 19:43, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider 
>> 
>> A changelist that contains only excluded files (e.g. via client spec or
>> branch prefix) will be imported as empty commit. Add option
>> "git-p4.ignoreEmptyCommits" to ignore these commits.
>> 
>> Signed-off-by: Lars Schneider 
>> ---
>>  Documentation/git-p4.txt   |   5 ++
>>  git-p4.py  |  41 -
>>  t/t9826-git-p4-ignore-empty-commits.sh | 103 
>> +
>>  3 files changed, 133 insertions(+), 16 deletions(-)
>>  create mode 100755 t/t9826-git-p4-ignore-empty-commits.sh
>> 
>> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
>> index 82aa5d6..f096a6a 100644
>> --- a/Documentation/git-p4.txt
>> +++ b/Documentation/git-p4.txt
>> @@ -510,6 +510,11 @@ git-p4.useClientSpec::
>>  option '--use-client-spec'.  See the "CLIENT SPEC" section above.
>>  This variable is a boolean, not the name of a p4 client.
>> 
>> +git-p4.ignoreEmptyCommits::
>> +A changelist that contains only excluded files will be imported
>> +as empty commit. To ignore these commits set this boolean option
>> +to 'true'.
> 
> s/as empty/as an empty/
> 
> Possibly putting 'true' in quotes could be confusing.
OK. Will fix.

> 
>> +
>>  Submit variables
>>  
>>  git-p4.detectRenames::
>> diff --git a/git-p4.py b/git-p4.py
>> index 0093fa3..6c50c74 100755
>> --- a/git-p4.py
>> +++ b/git-p4.py
>> @@ -2288,12 +2288,6 @@ class P4Sync(Command, P4UserMap):
>>  filesToDelete = []
>> 
>>  for f in files:
>> -# if using a client spec, only add the files that have
>> -# a path in the client
>> -if self.clientSpecDirs:
>> -if self.clientSpecDirs.map_in_client(f['path']) == "":
>> -continue
>> -
>>  filesForCommit.append(f)
>>  if f['action'] in self.delete_actions:
>>  filesToDelete.append(f)
>> @@ -2368,18 +2362,33 @@ class P4Sync(Command, P4UserMap):
>>  if self.verbose:
>>  print "commit into %s" % branch
>> 
>> -# start with reading files; if that fails, we should not
>> -# create a commit.
>> -new_files = []
>> -for f in files:
>> -if [p for p in self.branchPrefixes if 
>> p4PathStartsWith(f['path'], p)]:
>> -new_files.append (f)
>> -else:
>> -sys.stderr.write("Ignoring file outside of prefix: %s\n" % 
>> f['path'])
>> -
>>  if self.clientSpecDirs:
>>  self.clientSpecDirs.update_client_spec_path_cache(files)
>> 
>> +def inClientSpec(path):
> 
> This seems to be adding a new function in the middle of an existing function. 
> Is that right?
That is true. I could move these functions into the P4Sync class if you don't 
like them here. I added them right there because it is the only place where 
they are used/useful.


> 
>> +if not self.clientSpecDirs:
>> +return True
>> +inClientSpec = self.clientSpecDirs.map_in_client(path)
>> +if not inClientSpec and self.verbose:
>> +print '\n  Ignoring file outside of client spec' % path
>> +return inClientSpec
> 
> Any particular reason for putting a \n at the start of the message?
I did this because "sys.stdout.write("\rImporting revision ..." (line 2724) 
does not add a newline. However, I agree that this looks stupid. I will remove 
the "\n" and fix the "Import revision" print. Speaking of that one: this is 
only printed if "not self.silent". Is there a particular reason to have 
"self.silent" and "self.verbose"? Should we merge the two? 


> 
> Also, could you use python3 style print stmnts, print("whatever") ?
Sure. How do you prefer the formatting? Using "format" would be true Python 3 
style I think:
print('Ignoring file outside of client spec: {}'.format(path))
OK?

> 
>> +
>> +def hasBranchPrefix(path):
>> +if not self.branchPrefixes:
>> +return True
>> +hasPrefix = [p for p in self.branchPrefixes
>> +if p4PathStartsWith(path, p)]
>> +if hasPrefix and self.verbose:
>> +print '\n  Ignoring file outside of prefix: %s' % path
>> +return hasPrefix
>> +
>> +files = [f for f in files
>> +if inClientSpec(f['path']) and hasBranchPrefix(f['path'])]
>> +
>> +if not files and gitConfigBool('git-p4.ignoreEmptyCommits'):
>> +print '\n  Ignoring change %s as it would produce an empty 
>> commit.'
>> +return
> 
> As with Junio's comment elsewhere, I worry about deletion here.
I believe this is right. See my answer to Junio.


>> +
>>  self.gitStream.write("commit %s\n" % branch)
>>  #gitStream.write("mark :%s\n" % details["change"])
>>

Re: [PATCH v1] git-p4: Add option to ignore empty commits

2015-10-24 Thread Luke Diamand 

On 24/10/15 17:28, Lars Schneider wrote:





Also I have this suspicion that those who do want to use client spec
to get a narrowed view into the history would almost always want
this "ignore empty" behaviour (I'd even say the current behaviour to
leave empty commits by default is a bug).  What are the advantages
of keeping empty commits?  If there aren't many, perhaps git-p4
should by the default skip empties and require p4.keepEmpty
configuration to keep them?


I agree.
@Luke: What option do you prefer? "git-p4.keepEmptyCommits" or 
"git-p4.ignoreEmptyCommits" ?


keepEmptyCommits.


--
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-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

2015-10-24 Thread Noam Postavsky 
On Tue, Oct 20, 2015 at 10:35 PM, Noam Postavsky
 wrote:
> On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano  wrote:
>> I cannot speak for the person who was primarily responsible for
>> designing this behaviour, but I happen to agree with the current
>> behaviour in the situation where it was designed to be used.  Upon
>> the first use in your session, the "daemon" is auto-spawned, you can
>> keep talking with that same instance during your session, and you do
>> not have to do anything special to shut it down when you log out.
>> Isn't that what happens here?
>
> After looking at this some more, I've discovered this is NOT what
> actually happens here. If I "git push" from a shell and then log out
> and log in again, another "git push" does NOT ask me for a password.
> In other words, the daemon is NOT shut down automatically when I log
> out. Given that, does it make sense to change the daemon to ignore
> SIGHUP, or is there some way to change it so that it does exit on
> logout?

ping?
--
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] ref-filter: fallback on alphabetical comparison

2015-10-24 Thread Eric Sunshine 
On Sat, Oct 24, 2015 at 10:42 AM, Karthik Nayak  wrote:
> In ref-filter.c the comparison of refs while sorting is handled by
> cmp_ref_sorting() function. When sorting as per numerical values
> (e.g. --sort=objectsize) there is no fallback comparison when both refs
> hold the same value. This can cause unexpected results as pointed out
> by Johannes Sixt ($gmane/280117).

Please make the commit message self-contained by describing the
"unexpected results" here rather than directing readers to chase down
the information elsewhere themselves.

> Hence, fallback to alphabetical comparison based on the refname whenever
> the other criterion is equal. Fix the test in t3203 in this regard.
>
> Signed-off-by: Karthik Nayak 

It would not be amiss to add a Reported-by: to credit j6t.

> ---
> diff --git a/ref-filter.c b/ref-filter.c
> index 046e73b..7b33cb8 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1698,7 +1698,7 @@ static int cmp_ref_sorting(struct ref_sorting *s, 
> struct ref_array_item *a, stru
> if (va->ul < vb->ul)
> cmp = -1;
> else if (va->ul == vb->ul)
> -   cmp = 0;
> +   cmp = strcmp(a->refname, b->refname);
> else
> cmp = 1;
> }
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index f77971c..9f2d482 100755
> --- a/t/t3203-branch-output.sh
> +++ b/t/t3203-branch-output.sh
> @@ -158,8 +158,8 @@ EOF
>
>  test_expect_success 'git branch `--sort` option' '
> cat >expect <<-\EOF &&
> - branch-two
> * (HEAD detached from fromtag)
> + branch-two
>   branch-one
>   master
> EOF
> --
> 2.6.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] user-manual: fix the description of fast-forward

2015-10-24 Thread Xue Fuqiao 
Currently, the "Fast-forward merges" section of user-manual.txt says if the
current branch is a descendant of the other, Git will perform a fast-forward
merge, but it should the other way around.  Correct this issue and improve
wording.

Signed-off-by: Xue Fuqiao 
Thanks-to: Junio C Hamano 
---

Discussed in $gmane/280042.

 Documentation/user-manual.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1b7987e..d68df13 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1431,11 +1431,11 @@ differently.  Normally, a merge results in a merge 
commit, with two
 parents, one pointing at each of the two lines of development that
 were merged.
 
-However, if the current branch is a descendant of the other--so every
-commit present in the one is already contained in the other--then Git
-just performs a "fast-forward"; the head of the current branch is moved
-forward to point at the head of the merged-in branch, without any new
-commits being created.
+However, if the current branch is an ancestor of the other--so every commit
+present in the current branch is already contained in the other branch--then 
Git
+just performs a "fast-forward"; the head of the current branch is moved forward
+to point at the head of the merged-in branch, without any new commits being
+created.
 
 [[fixing-mistakes]]
 Fixing mistakes
-- 
2.6.2

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

Re: [PATCH 1/2] checkout: progress on non-tty. progress with lf

2015-10-24 Thread Edmundo Carmona Antoranz 
Hello, everybody!

So, this is my first patch ever for git. What would be the expected
workflow for this patch from a newcomer like me? Maybe getting some
fire starting monday?

On the technical side, I was wondering if it made more sense to use a
"boolean" value to control if progress should use CR or LF, instead of
allowing to set whatever we wanted in struct progress.eol.

Something like

diff --git a/progress.c b/progress.c
index 3af0594..8584e48 100644
--- a/progress.c
+++ b/progress.c
@@ -36,7 +36,7 @@ struct progress {
   unsigned delay;
   unsigned delayed_percent_treshold;
   struct throughput *throughput;
-   const char *eol;
+   int eol_lf;
};

static volatile sig_atomic_t progress_update;
@@ -100,7 +100,7 @@ static int display(struct progress *progress,
unsigned n, const char *done)

   progress->last_value = n;
   tp = (progress->throughput) ? progress->throughput->display.buf : "";
-   eol = done ? done : (progress->eol ? progress->eol : "   \r");
+   eol = done ? done : (progress->eol_lf ? "\n" : "   \r");
   if (progress->total) {
   unsigned percent = n * 100 / progress->total;
   if (percent != progress->last_percent || progress_update) {


Thanks!

On Sat, Oct 24, 2015 at 8:59 AM, Edmundo Carmona  wrote:
> From: Edmundo Carmona Antoranz 
>
> --progress-no-tty: option to write progress even if not working on a TTY
> --progress-lf: option to print progress using LF instead of CR
> Signed-off-by: Edmundo Carmona Antoranz 
> ---
>  builtin/checkout.c | 12 ++--
>  progress.c |  8 +++-
>  progress.h |  1 +
>  unpack-trees.c |  3 +++
>  unpack-trees.h |  2 ++
>  5 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index bc703c0..2c86a9a 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -37,6 +37,8 @@ struct checkout_opts {
> int overwrite_ignore;
> int ignore_skipworktree;
> int ignore_other_worktrees;
> +   int progress_lf;
> +   int progress_notty;
>
> const char *new_branch;
> const char *new_branch_force;
> @@ -417,7 +419,8 @@ static int reset_tree(struct tree *tree, const struct 
> checkout_opts *o,
> opts.reset = 1;
> opts.merge = 1;
> opts.fn = oneway_merge;
> -   opts.verbose_update = !o->quiet && isatty(2);
> +   opts.verbose_update = !o->quiet && (o->progress_notty || isatty(2));
> +   opts.eol = o->progress_lf ? _("\n") : NULL;
> opts.src_index = &the_index;
> opts.dst_index = &the_index;
> parse_tree(tree);
> @@ -501,7 +504,8 @@ static int merge_working_tree(const struct checkout_opts 
> *opts,
> topts.update = 1;
> topts.merge = 1;
> topts.gently = opts->merge && old->commit;
> -   topts.verbose_update = !opts->quiet && isatty(2);
> +   topts.verbose_update = !opts->quiet && (opts->progress_notty 
> || isatty(2));
> +   topts.eol = opts->progress_lf ? _("\n") : NULL;
> topts.fn = twoway_merge;
> if (opts->overwrite_ignore) {
> topts.dir = xcalloc(1, sizeof(*topts.dir));
> @@ -1156,6 +1160,10 @@ int cmd_checkout(int argc, const char **argv, const 
> char *prefix)
> N_("second guess 'git checkout 
> '")),
> OPT_BOOL(0, "ignore-other-worktrees", 
> &opts.ignore_other_worktrees,
>  N_("do not check if another worktree is holding the 
> given ref")),
> +   OPT_BOOL(0, "progress-lf", &opts.progress_lf,
> +N_("write progress using lf instead of cr")),
> +   OPT_BOOL(0, "progress-no-tty", &opts.progress_notty,
> +N_("write progress info even if not using a TTY")),
> OPT_END(),
> };
>
> diff --git a/progress.c b/progress.c
> index 353bd37..3af0594 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -36,6 +36,7 @@ struct progress {
> unsigned delay;
> unsigned delayed_percent_treshold;
> struct throughput *throughput;
> +   const char *eol;
>  };
>
>  static volatile sig_atomic_t progress_update;
> @@ -99,7 +100,7 @@ static int display(struct progress *progress, unsigned n, 
> const char *done)
>
> progress->last_value = n;
> tp = (progress->throughput) ? progress->throughput->display.buf : "";
> -   eol = done ? done : "   \r";
> +   eol = done ? done : (progress->eol ? progress->eol : "   \r");
> if (progress->total) {
> unsigned percent = n * 100 / progress->total;
> if (percent != progress->last_percent || progress_update) {
> @@ -221,6 +222,7 @@ struct progress *start_progress_delay(const char *title, 
> unsigned total,
> progress->delayed_percent_treshold = percent_treshold;
> progress->delay = delay;
>

[PATCH] fetch: only show "Fetching remote" when verbose mode is enabled

2015-10-24 Thread Paul Wise 
By default when fetching one remote nothing is printed unless there
are changes that need fetching. This makes fetching multiple remotes
be just as verbose as fetching a single remote.

This is needed when fetching multiple repositories using the myrepos
tool in minimal output mode, where myrepos only prints the repository
names when git fetch prints some output. For example in the output below
the cgit and git-remote-* lines would be hidden if git fetch were
silent by default when fetching multiple remotes, since the default
for myrepos is to fetch all remotes for git repositories.

pabs@chianamo ~ $ mr -m fetch
mr fetch: /home/pabs/cgit
Fetching origin

mr fetch: /home/pabs/git
Fetching origin
>From https://github.com/git/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub
Fetching hg
>From https://github.com/SRabbelier/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub

mr fetch: /home/pabs/git-remote-bzr
Fetching origin

mr fetch: /home/pabs/git-remote-hg
Fetching origin

Signed-off-by: Paul Wise 
---
 builtin/fetch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a3869f..fc33667 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1067,7 +1067,7 @@ static int fetch_multiple(struct string_list *list)
for (i = 0; i < list->nr; i++) {
const char *name = list->items[i].string;
argv_array_push(&argv, name);
-   if (verbosity >= 0)
+   if (verbosity >= 1)
printf(_("Fetching %s\n"), name);
if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) {
error(_("Could not fetch %s"), name);
-- 
2.6.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