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 +-
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
>
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 ++--
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
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):
>>
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
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
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
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
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
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:
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.
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:
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
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
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
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
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
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 =
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
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
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
22 matches
Mail list logo