On Sat, Sep 12, 2015 at 10:39 PM, Eric Sunshine wrote:
> On Fri, Sep 4, 2015 at 5:39 PM, Michael Rappazzo wrote:
>> + }
>> + } else if (strbuf_read_file(ref, path_to_ref, 0) >= 0) {
>> + if (starts_with(ref->buf, "ref:")) {
>> + strbuf_remov
On Sat, Sep 12, 2015 at 2:44 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Thu, Sep 10, 2015 at 10:27 PM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
This is part of the series of unifying the code used by
"git tag -l, git branch -l, git for-each-ref".
The
Do you need a Business or Personal Loan without too many complications? REPLY
for details.
--
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
On Fri, Sep 4, 2015 at 5:39 PM, Michael Rappazzo wrote:
> 'git worktree list' iterates through the worktree list, and outputs
> the worktree dir. By default, only the worktree path is output.
Comments below in addition to Junio's...
> Supported options include:
> --skip-bare: do not out
On Fri, Sep 4, 2015 at 5:39 PM, Michael Rappazzo wrote:
> The code formerly in branch.c was largely the basis of the
> get_worktree_list implementation is now moved to worktree.c,
> and the find_shared_symref implementation has been refactored
> to use get_worktree_list
Some comments below in add
On Fri, Sep 4, 2015 at 5:39 PM, Michael Rappazzo wrote:
> Including functions to get the list of all worktrees, and to get
> a specific worktree (primary or linked).
Some comments below in addition to those by Junio...
> Signed-off-by: Michael Rappazzo
> ---
> diff --git a/worktree.c b/worktree
While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.
The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This
If there is a pattern "!foo/bar", this patch makes it not exclude "foo"
right away. This gives us a chance to examine "foo" and re-include
"foo/bar".
In order for it to detect that the directory under examination should
not be excluded right away, in other words it is a parent directory of a
negat
No code change. Explain why 1/2 is needed in the commit message.
Nguyễn Thái Ngọc Duy (2):
dir.c: make last_exclude_matching_from_list() run til the end
dir.c: don't exclude whole dir prematurely if neg pattern may match
Documentation/gitignore.txt| 21 ++---
dir.c
The next patch adds some post processing to the result value before it's
returned to the caller. Make all branches reach the end of the function,
so we can do it all in one place.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
Duy Nguyen writes:
> On Mon, Sep 7, 2015 at 11:33 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
>>
>> The cover letter talks about "local clone", and in this entire
>> series, I saw new tests only for the local case, but doesn't t
Signed-off-by: Nguyễn Thái Ngọc Duy
---
path.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/path.c b/path.c
index 95acbaf..a536ee3 100644
--- a/path.c
+++ b/path.c
@@ -431,7 +431,7 @@ const char *enter_repo(const char *path, int strict)
}
if
Signed-off-by: Nguyễn Thái Ngọc Duy
---
path.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/path.c b/path.c
index a536ee3..7340e11 100644
--- a/path.c
+++ b/path.c
@@ -441,8 +441,7 @@ const char *enter_repo(const char *path, int strict)
else if (chdir(path))
Fixes strbuf_addf in 4/5. Makes a note about the relation of
enter_repo to this local clone in 3/5. Changes since v1
-- 8< --
diff --git a/builtin/clone.c b/builtin/clone.c
index 7a010bb..3e14491 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -432,7 +432,7 @@ static void clone_local(const c
Strict mode is about not guessing where .git is. If the user points to a
.git file, we know exactly where the target .git dir will be.
This is needed even in local clone case because transport.c code uses
upload-pack for fetching remote refs.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
path.c | 9 +
Noticed-by: Bjørnar Snoksrud
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/clone.c | 6 --
t/t2025-worktree-add.sh | 5 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 578da85..39d4adf 100644
--- a/builtin/clone.c
+++ b/b
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/clone.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 39d4adf..3e14491 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -294,9 +294,14 @@ static int add_one_reference(struct st
On Mon, Sep 7, 2015 at 11:33 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> The cover letter talks about "local clone", and in this entire
> series, I saw new tests only for the local case, but doesn't this
> and the next change also
Hi,
On Sat, Sep 12, 2015 at 3:51 PM, Philip Oakley wrote:
> The branch description will be included in 'git format-patch
> --cover-letter' and in 'git pull-request' emails. Tell the reader.
>
> While here, clarify that the description may be a multi-line
> explanation of the purpose of the branch
Hi Marko,
On 2015-09-12 20:46, Marko Palola wrote:
> I have some problems with 2.5.2 and 2.5.1 and bitdefender scanner.
> but I can use v2.5.0
We have had plenty of reports since the start of the Git for Windows project in
2007. None of them have turned out to be true viruses, all of them were
Dear Git users,
you probably noticed that there was a really obvious bug in the "Git GUI" entry
in the Start Menu (because it has been reported several times).
I just released a new version that squashes this bug and three more. Please
find it here:
https://github.com/git-for-windows/git/r
The branch description will be included in 'git format-patch
--cover-letter' and in 'git pull-request' emails. Tell the reader.
While here, clarify that the description may be a multi-line
explanation of the purpose of the branch's patch series.
Signed-off-by: Philip Oakley
---
This is a short
From: "Junio C Hamano"
Sent: Saturday, September 12, 2015 9:29 AM
Jeff King writes:
Yeah, I think what is happening in this first hunk:
...
is doing the right thing. It did feel a little weird to me to be
munging
the global commit objects themselves, but I guess it is fairly normal
for git
Chris Cowan streak.com> writes:
>
> I've recently had an issue where running "gitk --all" has stopped
> working on a large repository of mine. Gitk's main window appears with
> all of the sections empty, and a modal tells me 'Error executing git
> log: couldn't execute "git": argument list too l
Good day!
I am Russian and Ukrainian native speaker. I have a little free time
and I want to help in translating.
What I may do for 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.
On Sat, Sep 12, 2015 at 12:01 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> The worst case is due to a bug in the negotiation. With nothing
>> common, the client just goes on forever until it reaches roots
>> (something is wrong with MAX_IN_VAIN). We saw 56,318 have lines ... a
>> 2.6 MiB
Stefan Beller writes:
> diff --git a/run-command.c b/run-command.c
> index 28e1d55..b8ff67b 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -852,3 +852,147 @@ int capture_command(struct child_process *cmd, struct
> strbuf *buf, size_t hint)
> close(cmd->out);
> return finish_
Shawn Pearce writes:
> The worst case is due to a bug in the negotiation. With nothing
> common, the client just goes on forever until it reaches roots
> (something is wrong with MAX_IN_VAIN). We saw 56,318 have lines ... a
> 2.6 MiB section. But smart HTTP gzips, so this may be only 1.3 MiB on
>
From: Edward Thomson
Ensure that when passing a pipe, the gnulib poll replacement will not
return 0 before the timeout has passed.
Not obeying the timeout (and merely returning 0) causes pathological
behavior when preparing a packfile for a repository and taking a
long time to do so. If poll we
Is apparently a known issue.
Here is a temp fix : https://github.com/git-for-windows/git/issues/376
--
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
2015-09-12 0:47 GMT+08:00 Junio C Hamano :
> Ralf Thielow writes:
>
>> The description of option "create-reflog" is "create_reflog", which
>> is neither a good description, nor a sensible string to translate.
>> Change it to a more meaningful message.
>>
>> Signed-off-by: Ralf Thielow
>> ---
>
>
2015-09-11 23:53 GMT+08:00 Ralf Thielow :
> "false|true|preserve" are actual values for option "rebase"
> of the "git-pull" command and should therefore not be marked
> for translation.
Agree, I see those who have already finished this round of l10n
(including vi, fr, and zh_CN) not translate it a
Hi Johannes,
Johannes Schindelin gmx.de> writes:
>
> Hi Long,
>
> On 2015-09-12 13:43, Long Yang wrote:
>
> > Thanks for the email to confirm the bug.
>
> Of course! Thank you for taking the time to report it.
>
> > To answer your question first, I found only the Community page at
> > http:
Don't format the second paragraph as a literal block.
Signed-off-by: Andreas Schwab
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0c351b9..e0bd703 100644
--- a/Documentation/config.tx
Hi Long,
On 2015-09-12 13:43, Long Yang wrote:
> Thanks for the email to confirm the bug.
Of course! Thank you for taking the time to report it.
> To answer your question first, I found only the Community page at
> http://www.git-scm.com/, as I was looking for a forum-kind of page to
> see if s
Hi,
On 2015-09-12 08:31, Sukhwinder Singh wrote:
> We already have 3-4 environments setup on our Windows servers without Git
> and each environment already has code which is different from each
> other.
>
> There are three environments
> Live
> UAT
> Test (has the latest code)
>
>
> And then d
On Sat, Sep 12, 2015 at 12:37:33PM +0200, Julian Andres Klode wrote:
> Introduce an option to deny unsigned tags from entering
> a repository. This is useful in teams where members forget
> to sign their release tags.
>
> It does not actually check whether the signature is actually
> complete or v
Introduce an option to deny unsigned tags from entering
a repository. This is useful in teams where members forget
to sign their release tags.
It does not actually check whether the signature is actually
complete or valid, it just checks for the beginning of a
signature, as further checks would be
Dear Diaoul,
it is considered rude on this mailing list to top-post, and likewise to cull
the Cc: list. Please do not do that.
On 2015-09-12 11:34, Diaoul wrote:
> I can confirm this on the same setup (W10 64bit git 2.5.2)
Please see the corresponding ticket:
https://github.com/git-for-windows
Hi Long,
On 2015-09-11 18:13, Long wrote:
> Installation of 64bit could complete, but running Git GUI always prompt the
> error below:
>
> Couldn’t read file “C:\Program
> Files\Git\cmd\mingw64\libexec\git-core\git-gui”: no such file or
> directory
Please see the corresponding ticket:
https://
Hi Adrian,
please note that Renato never got your mail (you should always use
reply-to-all). I re-Cc:ed him, please do not forget to reply-to-all next time.
On 2015-09-11 23:33, Adrian Ang wrote:
> Renato Akaboci gmail.com> writes:
>>
>> I´m in trouble just after installation of my Git for Wind
I can confirm this on the same setup (W10 64bit git 2.5.2)
Long gmail.com> writes:
>
> Installation of 64bit could complete, but running Git GUI always prompt the
> error below:
>
> Couldn’t read file “C:\Program
> Files\Git\cmd\mingw64\libexec\git-core\git-gui”: no such file or directory
Karthik Nayak writes:
> On Thu, Sep 10, 2015 at 10:27 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> This is part of the series of unifying the code used by
>>> "git tag -l, git branch -l, git for-each-ref".
>>>
>>> The previous version can be found here (version 16):
>>> article.gma
Jeff King writes:
> Yeah, I think what is happening in this first hunk:
> ...
> is doing the right thing. It did feel a little weird to me to be munging
> the global commit objects themselves, but I guess it is fairly normal
> for git code.
Yeah, the above may be brilliant, but ...
>> diff --gi
44 matches
Mail list logo
