On Mon, Apr 18, 2016 at 11:47:52PM -0700, Stefan Beller wrote:
> I am convinced the better way to do it is like this:
>
> Calculate the entropy for each line and take the last line with the
> lowest entropy as the last line of the hunk.
I'll be curious to see the results, but I think som
On Tue, Apr 19, 2016 at 12:00 AM, Jeff King wrote:
> On Mon, Apr 18, 2016 at 11:47:52PM -0700, Stefan Beller wrote:
>
>> I am convinced the better way to do it is like this:
>>
>> Calculate the entropy for each line and take the last line with the
>> lowest entropy as the last line of the
On Mon, Apr 18, 2016 at 4:41 PM, Stefan Beller wrote:
> When directories are moved using `git mv` all files in the directory
> have been just moved, but no further action was taken on them. This
> was done by assigning the mode = WORKING_DIRECTORY to the files
> inside a moved directory.
>
> submo
On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Add parameters for a list of refspecs to transport_get_remote_refs and
> > get_refs_list. These parameters are presently unused -- soon, we will
> > use them to implement fetches which only learn about
On 16 Apr 2016, at 21:58, Jan Durovec wrote:
> When migrating from Perforce to git the information about P4 jobs
> associated with P4 changelists is lost.
>
> Having these jobs listed on messages of related git commits enables smooth
> migration for projects that take advantage of e.g. JIRA int
On 19 April 2016 at 02:15, Junio C Hamano wrote:
> Jan Durovec writes:
>
>> When migrating from Perforce to git the information about P4 jobs
>> associated with P4 changelists is lost.
>>
>> Having these jobs listed on messages of related git commits enables smooth
>> migration for projects that
On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:
> On 18/04/16 16:21, Adam Dinwoodie wrote:
> > t7008.12 is marked as an expected failure, but building Git on Cygwin
> > including a `make configure && ./configure` step has the test
> > unexpectedly passing. Building without the config
When generating build options for Cygwin, enable
OBJECT_CREATION_USES_RENAMES. This is necessary to use Git on Windows
shared directories, and is already enabled for the MinGW and plain
Windows builds.
Reported-by: Peter Rosin
Signed-off-by: Adam Dinwoodie
---
This patch has previously been di
Change Makefile to include git-parse-remote.sh in LOCALIZED_SH.
TODO: remove 3rd argument of error_on_missing_default_upstream function
that is no longer required.
Signed-off-by: Vasco Almeida
---
Makefile| 2 +-
git-parse-remote.sh | 46 +---
Git could output "completed with 1 local objects", but in this case
using "object" instead of "objects" is the correct form.
Use Q_() instead of _().
Signed-off-by: Vasco Almeida
---
builtin/index-pack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/index-pack.c
Mark description and parameter for option "set-upstream-to" for translation.
Signed-off-by: Vasco Almeida
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0adba62..b7d906d 100644
--- a/builtin/branch.c
+++ b/builti
Split string "If you wish to set tracking information
for this branch you can do so with:\n" to match occurring string in
git-parse-remote.sh. In this case, the translator handles it only once.
On the other hand, the translations of the string that were already made
are mark as fuzzy and the trans
Some translations might also translate "" and "".
Signed-off-by: Vasco Almeida
---
I opted to mark also the brackets of placeholders, which I think is a good
compromise between consistency and letting the translators know what
they're translating.
builtin/pull.c | 6 +++---
1 file changed, 3 in
Mark strings seen by the user inside setup_unpack_trees_porcelain() and
display_error_msgs() functions for translation.
Signed-off-by: Vasco Almeida
---
unpack-trees.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
i
Remove a comma from string marked for translation. Make the string match the
one in builtin/mv.c. Now translators have do handle this string only once.
Signed-off-by: Vasco Almeida
---
builtin/rm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rm.c b/builtin/rm.c
in
From: Torsten Bögershausen
Make the commit_chk_wrnNNO test in t0027 more reliable:
When the attributes of a commited file are changed and the file is otherwise
unchanged, Git may not detect that the next commit may need to treat the
file as changed.
This happens when lstat() doesn't detect a chan
From: Torsten Bögershausen
Add more test cases for the not normalized files ("NNO"). The
"text" attribute is most important, use it as the first parameter.
"ident", if set, is the second paramater followed by the eol
attribute. The eol attribute overrides core.autocrlf, which
overrides core.eol
From: Torsten Bögershausen
Even though the configuration parser errors out when core.autocrlf
is set to 'input' when core.eol is set to 'crlf', there is no need
to do so, because the core.autocrlf setting trumps core.eol.
Allow all combinations of core.crlf and core.eol and document
that core.au
From: Torsten Bögershausen
When the ident attributes is set, get_stream_filter() did not obey
core.autocrlf=true, and the file was checked out with LF.
Change the rule when a streaming filter can be used:
- if an external filter is specified, don't use a stream filter.
- if the worktree eol is C
Hi Lukáš,
On Mon, 18 Apr 2016, Lukáš Rumpala wrote:
> I have question regarding Git for Windows Portable in version 2.8.1
> 32bit that can be downloaded from https://git-scm.com/download/win .
> What is the minimum version of .NET and OS that is necessary to
> successfully run it?
.NET is not ne
We simply need to read the config, is all.
This fixes https://github.com/git-for-windows/git/issues/733
Signed-off-by: Johannes Schindelin
---
builtin/replace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/replace.c b/builtin/replace.c
index 748c6ca..02b13f6 100644
--- a/builtin/
Dearest one
I wish you and your family happy moments of life
now and forever more amen.Please, I do not have formal relationship
with you but because of my present predicament and circumstances I am
made to contact you.I have been suffering from cancer of the Lungs and
has a short life to leave.I h
Implements the GIT_TRACE_CURL environment variable to allow a
greater degree of detail of GIT_CURL_VERBOSE, in particular
the complete transport header and all the data payload exchanged.
It might be useful if a particular situation could require a more
thorough debugging analysis
Helped-by: Tors
Permit the use of the GIT_TRACE_CURL environment variable calling
the curl_trace and curl_dump http.c helper routine
Helped-by: Torsten Bögershausen
Helped-by: Ramsay Jones
Helped-by: Junio C Hamano
Helped-by: Eric Sunshine
Helped-by: Jeff King
Signed-off-by: Elia Pinto
---
imap-send.c |
On Mon, Apr 18, 2016 at 10:03 PM, Jeff King wrote:
> I guess this will invalidate old patch-ids, but there's not much to be
> done about that.
What do you mean by that? (What consequences do you imagine?)
I think diffs with any kind of heuristic can still be applied, no?
Thanks,
Stefan
>
> -Pe
Add the debug callback and helper routine prototype used by
curl_easy_setopt CURLOPT_DEBUGFUNCTION in http.c
for implementing the GIT_TRACE_CURL environment variable
Helped-by: Torsten Bögershausen
Helped-by: Ramsay Jones
Helped-by: Junio C Hamano
Helped-by: Eric Sunshine
Helped-by: Jeff Kin
Describe the purpose of the GIT_TRACE_CURL environment variable
Helped-by: Torsten Bögershausen
Helped-by: Ramsay Jones
Helped-by: Junio C Hamano
Helped-by: Eric Sunshine
Helped-by: Jeff King
Signed-off-by: Elia Pinto
---
Documentation/git.txt | 8
1 file changed, 8 insertions(+)
Thanks Jeff for pointing out issues in the comment!
Thanks,
Stefan
diff to origin/jk/diff-compact-heuristic:
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 5a02b15..b3c6848 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -515,12 +515,12 @@ int xdl_change_compact(xdfile_t *xdf, xdfile_t *x
In order to produce the smallest possible diff and combine several diff
hunks together, we implement a heuristic from GNU Diff which moves diff
hunks forward as far as possible when we find common context above and
below a diff hunk. This sometimes produces less readable diffs when
writing C, Shell
From: Jacob Keller
It is a common pattern in xdl_change_compact to check that hashes and
strings match. The resulting code to perform this change causes very
long lines and makes it hard to follow the intention. Introduce a helper
function recs_match which performs both checks to increase
code re
This is the second version but in reality is the complete rewriting of the
patches discussed here
$gmane/290520
$gmane/290521
Changes from V1
- introduced GIT_TRACE_CURL variable with its documentation
- changed the name of the temporary variable "i" in "w" in the helper routine
- used the c es
"git blame -L475,6 builtin/replace.c" points at b892bb45 (replace:
add --edit option, 2014-04-26) and the commit log message names two
people who can review this change, so that is what I am doing here.
Johannes Schindelin writes:
> We simply need to read the config, is all.
>
> This fixes https
Stefan Beller writes:
> Thanks Jeff for pointing out issues in the comment!
>
> Thanks,
> Stefan
>
> diff to origin/jk/diff-compact-heuristic:
> diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
> index 5a02b15..b3c6848 100644
> --- a/xdiff/xdiffi.c
> +++ b/xdiff/xdiffi.c
> @@ -515,12 +515,12 @@ int x
Luke Diamand writes:
>> I am not familiar with "Perforce jobs", but I assume that they are
>> always named as "job" + small non-negative integer in a dense way
>> and it is OK for this loop to always begin at 0 and immediately stop
>> when job + num does not exist (i.e. if job7 is missing, it is
On Mon, Apr 18, 2016 at 5:01 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> A single patch evolves into a series.
>
> Power of code inspection to see bugs that are not reported, perhaps
> ;-)?
>
> I wonder if we can come up with test cases to cover these potential
> issues that are addres
Hi,
given the fact that the rest of the code just follows existing
source code style, i.e.
* using %s not %d to add number to string (see git-p4.py:2301)
* no space between function name and parentheses (see all functions
in t/lib-git-p4.sh)
* no tab when specifying in-line expected output (see
Jeff King writes:
> I guess this will invalidate old patch-ids, but there's not much to be
> done about that.
If we really cared, we could disable this (and any future) change to
the compaction logic to "patch-id --[un]stable" option.
I am not sure if it is worth the effort, though ;-)
--
To un
On Tue, Apr 19, 2016 at 08:17:38AM -0700, Stefan Beller wrote:
> On Mon, Apr 18, 2016 at 10:03 PM, Jeff King wrote:
>
> > I guess this will invalidate old patch-ids, but there's not much to be
> > done about that.
>
> What do you mean by that? (What consequences do you imagine?)
> I think diffs
From: Santiago Torres
This is a follow up of [1], [2], [3], [4], [5], [6]. patches 1/6, 2/6, are the
same as the corresponding commits in pu.
v7:
Mostly style/clarity changes mostly. Thanks Peff, Eric and Junio for the
feedback! In summary:
* Eric pointed out issues with 3/6's commit message
From: Santiago Torres
The verify-tag command supports multiple tag names to verify, but
existing tests only test for invocation with a single tag.
Add a test invoking it with multiple tags.
Helped-by: Jeff King
Signed-off-by: Santiago Torres
Reviewed-by: Eric Sunshine
Signed-off-by: Junio C
From: Santiago Torres
The verify_signed_buffer() function may trigger a SIGPIPE when the
GPG child process terminates early (due to a bad keyid, for example)
and Git tries to write to it afterwards. Previously, ignoring
SIGPIPE was done in builtin/verify-tag.c to avoid this issue.
However, any
From: Santiago Torres
The current interface of verify_tag() resolves reference names to SHA1,
however, the plan is to make this functionality public and the current
interface is cumbersome for callers: they are expected to supply the
textual representation of a sha1/refname. In many cases, this r
From: Santiago Torres
The PGP verification routine for tags could be accessed by other modules
that require to do so.
Publish the verify_tag function in tag.c and rename it to gpg_verify_tag
so it does not conflict with builtin/mktag's static function.
Helped-by: Junio C Hamano
Signed-off-by:
From: Santiago Torres
Instead of having tag -v fork to run verify-tag, use the
gpg_verify_tag() function directly.
Helped-by: Eric Sunshine
Signed-off-by: Santiago Torres
---
builtin/tag.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
From: Santiago Torres
The run_gpg_verify() function has two variables, size and len.
This may come off as confusing when reading the code. Clarify which one
pertains to the length of the tag headers by renaming len to
payload_size. Additionally, change the type of payload_size to size_t to
match
Jan Durovec writes:
> given the fact that the rest of the code just follows existing
> source code style, i.e.
>
> * using %s not %d to add number to string (see git-p4.py:2301)
This one I do not care too deeply about, as formatting anything that
can be formatted via '%s' could just be more Pyth
Junio C Hamano writes:
> Not a new problem in this script, but we'd prefer to spell this as
>
> p4_add_job () {
>
> i.e. a space on both sides of ().
>
>> +name=$1 &&
>> +p4 job -f -i <<-EOF
>> +Job: $name
>> +Status: open
>> +User: dummy
>> +Description:
>> +EOF
>
Elia Pinto writes:
> Add the debug callback and helper routine prototype used by
> curl_easy_setopt CURLOPT_DEBUGFUNCTION in http.c
> for implementing the GIT_TRACE_CURL environment variable
>
>
> Helped-by: Torsten Bögershausen
> Helped-by: Ramsay Jones
> Helped-by: Junio C Hamano
> Helped-by
Elia Pinto writes:
> Implements the GIT_TRACE_CURL environment variable to allow a
> greater degree of detail of GIT_CURL_VERBOSE, in particular
> the complete transport header and all the data payload exchanged.
> It might be useful if a particular situation could require a more
> thorough debug
Would it be acceptable the other way around? I.e. this patch followed
by the one that fixes code style (once this gets merged)?
Reason being that I don't know how to use submitGit to generate a patch
against a state that is not already in git repo (ie. based on another
patch).
In the following pa
On Tue, Apr 19, 2016 at 12:14 AM, Jeff King wrote:
> On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote:
>
>> David Turner writes:
>>
>> > Add parameters for a list of refspecs to transport_get_remote_refs and
>> > get_refs_list. These parameters are presently unused -- soon, we will
Elia Pinto writes:
> Permit the use of the GIT_TRACE_CURL environment variable calling
> the curl_trace and curl_dump http.c helper routine
s/$/./; the patch itself is very concise and the "dump" thing in 3/4
looked sensible.
>
> Helped-by: Torsten Bögershausen
> Helped-by: Ramsay Jones
> Hel
Stefan Beller writes:
> ..., but I am unsure
> if patch 1 is a good idea.
Then let's postpone it for now. I too would like to hear opinion
from other submodule folks, especially Jens, for what 1/2 does
before committing us to the course.
Can you do only the 2/2 on top of maint (or maint-2.6) f
When directories are moved using `git mv` all files in the directory
have been just moved, but no further action was taken on them. This
was done by assigning the mode = WORKING_DIRECTORY to the files
inside a moved directory.
submodules however need to update their link to the git directory as
we
Dear Beloved
I am Mrs. Lily KIm from Syria who is dying for a gaseous poisoning exposition
in Syria who has decided to donate her funds to you for charity project, For
More details contact me.
Via e-mail: mrslilyki...@gmail.com
Thank you and God bless you.
Mrs. Lily Kim
--
To unsubscribe from thi
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 7:47 PM, Junio C Hamano wrote:
>>
>> If you really want to know the preference, we prefer a preliminary
>> clean-up patch to correct existing style issues, followed by a new
>> feature patch that builds on the cleaned up codebase.
>
> Would it be acc
> Any submitGit users? I think it lets you throw multiple-patch
> series just fine. In this case, you'd prepare a two patch series on
> a branch, 1/2 being the clean-up and 2/2 being the new feature, and
> if you give that branch to submitGit as a whole it should do the
> right thing, I'd imagine
On Fri, 2016-04-15 at 17:07 -0700, Stefan Beller wrote:
> > +static void refresh_by_watchman(struct index_state *istate)
> > +{
> > + void *shm = NULL;
> > + int length;
> > + int i;
> > + struct stat st;
> > + int fd = -1;
> > + const char *path = index_helper_p
On Sat, 2016-04-16 at 21:51 -0400, Eric Sunshine wrote:
> On Fri, Apr 15, 2016 at 3:19 PM, David Turner <
> dtur...@twopensource.com> wrote:
> > + if (refspec) {
> > + struct strbuf interesting_refs =
> > STRBUF_INIT;
> > + strbuf_addstr(&in
On 19/04/16 09:42, Adam Dinwoodie wrote:
> On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:
>> On 18/04/16 16:21, Adam Dinwoodie wrote:
>>> t7008.12 is marked as an expected failure, but building Git on Cygwin
>>> including a `make configure && ./configure` step has the test
>>> unex
On Tue, Apr 19, 2016 at 1:47 PM, wrote:
> tag -v: verfy directly rather than exec-ing verify-tag
s/verfy/verify:
> Instead of having tag -v fork to run verify-tag, use the
> gpg_verify_tag() function directly.
This description is easy enough to understand. Thanks.
> Signed-off-by: Santiago To
Hmph, two patches in the previous series seem to be missing. On
purpose, or by mistake? Their net-effect is shown at the end of
this message, and I thought they made sense.
Puzzled...
diff --git a/builtin/branch.c b/builtin/branch.c
index 5ab106b..32be954 100644
--- a/builtin/branch.c
+++ b/bui
On Tue, Apr 19, 2016 at 1:47 PM, wrote:
> This is a follow up of [1], [2], [3], [4], [5], [6]. patches 1/6, 2/6, are the
> same as the corresponding commits in pu.
>
> v7:
> Mostly style/clarity changes mostly. Thanks Peff, Eric and Junio for the
> feedback! In summary:
>
> * Eric pointed out is
On Mon, 2016-04-18 at 11:34 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Signed-off-by: David Turner
> > ---
>
> OK (it might be easier to read if you used the pushl form for the
> "fixed initial segment" like these calls, though).
Good idea.
--
To unsubscribe from this list: send
On Tue, Apr 19, 2016 at 1:47 PM, wrote:
> The current interface of verify_tag() resolves reference names to SHA1,
> however, the plan is to make this functionality public and the current
> interface is cumbersome for callers: they are expected to supply the
> textual representation of a sha1/refn
On Mon, 2016-04-18 at 11:35 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > The local variable 'options' was shadowing a global of the same
> > name.
> >
> > Signed-off-by: David Turner
> > ---
>
> OK. In general, giving a longer and more descriptive name to the
> global would be a
On Mon, 2016-04-18 at 11:45 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Add parameters for a list of refspecs to transport_get_remote_refs
> > and
> > get_refs_list. These parameters are presently unused -- soon, we
> > will
> > use them to implement fetches which only learn about
Eric Sunshine writes:
> I'd have probably called this "display_name", but then I suppose it
> suffers the same issue Junio mentioned previously about it sounding
> like a boolean. Anyhow, as long as Junio is happy with it, that's what
> matters.
No ;-) I am just trying to help people come up wit
Junio C Hamano writes:
> Hmph, two patches in the previous series seem to be missing. On
> purpose, or by mistake? Their net-effect is shown at the end of
> this message, and I thought they made sense.
>
> Puzzled...
Ah, I see. These two were sent outside the series, but because they
are on t
When migrating from Perforce to git the information about P4 jobs
associated with P4 changelists is lost.
Having these jobs listed on messages of related git commits enables smooth
migration for projects that take advantage of e.g. JIRA integration
(which uses jobs on Perforce side and parses comm
Preliminary clean-up of testing libraries for git-p4.
* spaces added to both sides of () in function definitions in lib-git-p4
* tab indentation added to git-p4 tests when <<- redirection is used
Signed-off-by: Jan Durovec
---
t/lib-git-p4.sh | 24 +++
t/t9826-g
From: Lars Schneider
Travis-CI uses 'brew' to always install the latest available version of
Git LFS on the OS X build machines (on Linux the version is sticky).
A change in Git LFS 1.2.0 [1] breaks the git-p4 LFS integration [2].
This mini series updates Travis-CI to the latest Git-LFS and Perf
From: Lars Schneider
Signed-off-by: Lars Schneider
---
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 78e433b..4acf617 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -22,8 +22,8 @@ addons:
env:
global:
- DEVELOPER=1
-
From: Lars Schneider
Git LFS 1.2.0 removed a line from the output of the 'git lfs pointer'
command [1] which broke the parsing of this output. Adjust the parser
to the new output and add minimum Git LFS version to the docs.
[1] https://github.com/github/git-lfs/pull/1105
Signed-off-by: Lars Sch
Elia Pinto writes:
> Implements the GIT_TRACE_CURL environment variable to allow a
> greater degree of detail of GIT_CURL_VERBOSE, in particular
> the complete transport header and all the data payload exchanged.
> It might be useful if a particular situation could require a more
> thorough debug
Huh... seems that it works :)
v3 sent in 2 parts
On Tue, Apr 19, 2016 at 8:50 PM, Jan Durovec wrote:
>> Any submitGit users? I think it lets you throw multiple-patch
>> series just fine. In this case, you'd prepare a two patch series on
>> a branch, 1/2 being the clean-up and 2/2 being the new
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Git LFS 1.2.0 removed a line from the output of the 'git lfs pointer'
> command [1] which broke the parsing of this output. Adjust the parser
> to the new output and add minimum Git LFS version to the docs.
Hmph, adjust to operate with
Duy Nguyen writes:
> On Tue, Apr 19, 2016 at 12:42 AM, Junio C Hamano wrote:
>>> Another option is leave wt_status_get_state() alone, factor out the
>>> rebase-detection code and use that for worktree/checkout. We save a
>>> few syscalls this way too.
>>>
>>> Comments?
>>>
>>> [01/07] path.c:
> On 19 Apr 2016, at 22:30, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Git LFS 1.2.0 removed a line from the output of the 'git lfs pointer'
>> command [1] which broke the parsing of this output. Adjust the parser
>> to the new output and add mi
Jeff King writes:
>> What the code tries to do I am more than halfway happy. It is
>> unfortunate that we cannot do this natively without upgrading the
>> protocol in a fundamental way, but this is a nice way to work it
>> around only for Git-over-HTTP transport without having to break the
>> pr
Lars Schneider writes:
>> On 19 Apr 2016, at 22:30, Junio C Hamano wrote:
>>
>> larsxschnei...@gmail.com writes:
>>
>>> From: Lars Schneider
>>>
>>> Git LFS 1.2.0 removed a line from the output of the 'git lfs pointer'
>>> command [1] which broke the parsing of this output. Adjust the parser
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 8:50 PM, Jan Durovec wrote:
>>> Any submitGit users? I think it lets you throw multiple-patch
>>> series just fine. In this case, you'd prepare a two patch series on
>>> a branch, 1/2 being the clean-up and 2/2 being the new feature, and
>>> if you
On Sat, 2016-04-16 at 22:36 -0400, Eric Sunshine wrote:
> On Fri, Apr 15, 2016 at 3:19 PM, David Turner <
> dtur...@twopensource.com> wrote:
> > For single-branch clones (when we know in advance what the remote
> > branch name will be), send a refspec so that the server doesn't
> > tell us about an
There's a comment on PR itself (in addition to individual commits) so
theoretically it could.
It seems that for [PATCH ... n/m] e-mails the commit messages are used,
so there's no reason why the PR comment couldn't be used for a cover
letter.
In this case the PR comment was the same as for one of
On Sat, 2016-04-16 at 22:33 -0400, Eric Sunshine wrote:
> On Fri, Apr 15, 2016 at 3:19 PM, David Turner <
> dtur...@twopensource.com> wrote:
> > When fetching over http, send the requested refspec to the server.
> > The server will then only send refs matching that refspec. It is
> > permitted for
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> Add more test cases for the not normalized files ("NNO"). The
> "text" attribute is most important, use it as the first parameter.
> "ident", if set, is the second paramater followed by the eol
> attribute. The eol attribute overrides core.
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 11:09 PM, Junio C Hamano wrote:
>
>> For a series this small it does not matter, but anything longer it
>> would be easier to review with a cover letter (i.e. [PATCH 0/N]). I
>> do not know if submitGit lets us do that, though.
>
> There's a comment
On Tue, 2016-04-19 at 03:14 -0400, Jeff King wrote:
> On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote:
>
> > David Turner writes:
> >
> > > Add parameters for a list of refspecs to
> > > transport_get_remote_refs and
> > > get_refs_list. These parameters are presently unused -- s
> By the way, you may or may not have noticed that I've been
> reordering the lines of your message quoted in my responses; around
> here, top-posting is frowned upon.
I haven't noticed. Thanks for pointing out.
As for the submitGit cover letter I wanted to raise at least an issue
(if not create
On Fri, 2016-04-15 at 17:04 -0700, Stefan Beller wrote:
> > +static int try_shm(struct index_state *istate)
> > +{
> > + void *new_mmap = NULL;
> > + size_t old_size = istate->mmap_size;
> > + ssize_t new_size;
> > + const unsigned char *sha1;
> > + struct stat st;
> >
On Fri, 2016-04-15 at 17:04 -0700, Stefan Beller wrote:
> > +static int try_shm(struct index_state *istate)
> > +{
> > + void *new_mmap = NULL;
> > + size_t old_size = istate->mmap_size;
> > + ssize_t new_size;
> > + const unsigned char *sha1;
> > + struct stat st;
> >
On 19/04/16 16:10, Elia Pinto wrote:
> Add the debug callback and helper routine prototype used by
> curl_easy_setopt CURLOPT_DEBUGFUNCTION in http.c
> for implementing the GIT_TRACE_CURL environment variable
>
>
> Helped-by: Torsten Bögershausen
> Helped-by: Ramsay Jones
> Helped-by: Junio C
On Sat, 2016-04-16 at 18:08 +0200, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 13, 2016 at 2:33 AM, David Turner <
> dtur...@twopensource.com> wrote:
> > Add a new command (and command-line arg) to allow index-helpers to
> > exit cleanly.
> >
> > This is mainly useful for tests.
>
> Both --kill
On 19/04/16 22:48, Ramsay Jones wrote:
>
[snip]
> I think the minimal fixup (including Junio's comment on patch #2, which also
> triggered for me) is given in the patch below.
BTW, if you want to have a single static instance of the 'struct trace_key',
then the following patch on top should wo
On Sun, 2016-04-17 at 12:19 +0700, Duy Nguyen wrote:
> On Wed, Apr 13, 2016 at 7:33 AM, David Turner <
> dtur...@twopensource.com> wrote:
> > @@ -536,8 +567,10 @@ static void handle_builtin(int argc, const
> > char **argv)
> > }
> >
> > builtin = get_builtin(cmd);
> > - if (b
I ran across a deadlock today while pushing from a corrupted repository
where pack-objects fails. Obviously I don't expect this to succeed, but
it should not hang indefinitely.
The first patch below fixes the deadlock. Unfortunately, it turns it
into a likely SIGPIPE death. Which is an improvement
This fixes a deadlock on the client side when pushing a
large number of refs from a corrupted repo. There's a
reproduction script below, but let's start with a
human-readable explanation.
The client side of a push goes something like this:
1. Start an async process to demux sideband coming fro
Async processes can be implemented as separate forked
processes, or as threads (depending on the NO_PTHREADS
setting). In the latter case, if an async thread gets
SIGPIPE, it takes down the whole process. This is obviously
bad if the main process was not otherwise going to die, but
even if we were
If we get an error from pack-objects, we may exit
send_pack() early, before reading the server's status
response. In such a case, we may racily see SIGPIPE from our
async demuxer (which is trying to write that status back to
us), and we'd prefer to continue pushing the error up the
call stack, rath
In commit 9ff18fa (fetch-pack: ignore SIGPIPE in sideband
demuxer, 2016-02-24), we started using sigchain_push() to
ignore SIGPIPE in the async demuxer thread. However, this is
rather clumsy, as it ignores SIGPIPE for the entire process,
including the main thread. At the time we didn't have any
per
1 - 100 of 142 matches
Mail list logo
