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

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 o

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

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 C

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

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

Re: [PATCH] ref-filter: fallback on alphabetical comparison

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 c

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

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 design

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

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 a

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

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"

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

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 re

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

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 ":/

Re: ancestor and descendant ~ clarification needed

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

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

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 = [] >> >>

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

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 |

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

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

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

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

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

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 no

[PATCH] ref-filter: fallback on alphabetical comparison

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/

Re: t3203: --sort=objectsize failure on Windows

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 eq

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

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

[PATCH 2/2] daemon: plug memory leak

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

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

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

t3203: --sort=objectsize failure on Windows

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

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

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 =