* Re: [PATCH] Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 21:49 UTC (permalink / raw)
To: szager; +Cc: git, daniel, sop, peff
In-Reply-To: <5081c896.cMdU6VySSwFm0uOa%szager@google.com>
Thanks.
^ permalink raw reply
* [PATCH] Fix potential hang in https handshake.
From: szager @ 2012-10-19 21:39 UTC (permalink / raw)
To: git; +Cc: daniel, sop, gitster, peff
It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading. The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped. The observed behavior is that
the git command will hang at the terminal and never transfer any
data.
This patch is a workaround for a probable bug in libcurl. The bug
only seems to manifest around a very specific set of circumstances:
- curl version (from curl/curlver.h):
#define LIBCURL_VERSION_NUM 0x071307
- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.
Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine). That would seem to suggest that this issue
is timing-sensitive.
This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Signed-off-by: Stefan Zager <szager@google.com>
---
http.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..b7e7ab4 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,18 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /*
+ * It can happen that curl_multi_timeout returns a pathologically
+ * long timeout when curl_multi_fdset returns no file descriptors
+ * to read. See commit message for more details.
+ */
+ if (max_fd < 0 &&
+ (select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000)) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.7.3
^ permalink raw reply related
* Re: Fix potential hang in https handshake (v3)
From: Junio C Hamano @ 2012-10-19 21:21 UTC (permalink / raw)
To: Jeff King; +Cc: szager, git, sop, daniel
In-Reply-To: <20121019210851.GD24184@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> + if (max_fd < 0 &&
>> + select_timeout.tv_sec > 0 ||
>> + select_timeout.tv_usec > 50000) {
>> + select_timeout.tv_sec = 0;
>> + select_timeout.tv_usec = 50000;
>> + }
>
> Should there be parentheses separating the || bit from the &&?
Yeah, I think there should be. Thanks for sharp eyes.
^ permalink raw reply
* Re: Fix potential hang in https handshake (v3)
From: Jeff King @ 2012-10-19 21:08 UTC (permalink / raw)
To: szager; +Cc: git, gitster, sop, daniel
In-Reply-To: <5081c054.eD2hEWR8K8zW5vdM%szager@google.com>
On Fri, Oct 19, 2012 at 02:04:20PM -0700, szager@google.com wrote:
> From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
> From: Stefan Zager <szager@google.com>
> Date: Thu, 18 Oct 2012 16:23:53 -0700
Drop these lines.
> Subject: [PATCH] Fix potential hang in https handshake.
And make this one your actual email subject.
> It has been observed that curl_multi_timeout may return a very long
> timeout value (e.g., 294 seconds and some usec) just before
> curl_multi_fdset returns no file descriptors for reading. The
> upshot is that select() will hang for a long time -- long enough for
> an https handshake to be dropped. The observed behavior is that
> the git command will hang at the terminal and never transfer any
> data.
>
> This patch is a workaround for a probable bug in libcurl. The bug
> only seems to manifest around a very specific set of circumstances:
>
> - curl version (from curl/curlver.h):
>
> #define LIBCURL_VERSION_NUM 0x071307
>
> - git-remote-https running on an ubuntu-lucid VM.
> - Connecting through squid proxy running on another VM.
>
> Interestingly, the problem doesn't manifest if a host connects
> through squid proxy running on localhost; only if the proxy is on
> a separate VM (not sure if the squid host needs to be on a separate
> physical machine). That would seem to suggest that this issue
> is timing-sensitive.
Thanks, that explanation makes much more sense.
> diff --git a/http.c b/http.c
> index df9bb71..51eef02 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /* It can happen that curl_multi_timeout returns a pathologically
> + * long timeout when curl_multi_fdset returns no file descriptors
> + * to read. See commit message for more details.
> + */
Minor nit, but our multi-line comment style is:
/*
* blah blah blah
*/
> + if (max_fd < 0 &&
> + select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
Should there be parentheses separating the || bit from the &&?
-Peff
^ permalink raw reply
* Fix potential hang in https handshake (v3)
From: szager @ 2012-10-19 21:04 UTC (permalink / raw)
To: git; +Cc: peff, gitster, sop, daniel
>From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
From: Stefan Zager <szager@google.com>
Date: Thu, 18 Oct 2012 16:23:53 -0700
Subject: [PATCH] Fix potential hang in https handshake.
It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading. The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped. The observed behavior is that
the git command will hang at the terminal and never transfer any
data.
This patch is a workaround for a probable bug in libcurl. The bug
only seems to manifest around a very specific set of circumstances:
- curl version (from curl/curlver.h):
#define LIBCURL_VERSION_NUM 0x071307
- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.
Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine). That would seem to suggest that this issue
is timing-sensitive.
This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Signed-off-by: Stefan Zager <szager@google.com>
---
http.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..51eef02 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /* It can happen that curl_multi_timeout returns a pathologically
+ * long timeout when curl_multi_fdset returns no file descriptors
+ * to read. See commit message for more details.
+ */
+ if (max_fd < 0 &&
+ select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.7.3
^ permalink raw reply related
* What's cooking in git.git (Oct 2012, #06; Fri, 19)
From: Junio C Hamano @ 2012-10-19 21:03 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The 1.8.0 release is expected to be tagged this weekend, after which
I'd disappear for a few weeks, and Git will be in steady and good
hands of Jeff King (thanks) in the meantime.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* js/mingw-fflush-errno (2012-10-17) 1 commit
(merged to 'next' on 2012-10-18 at 43d6ebb)
+ maybe_flush_or_die: move a too-loose Windows specific error
Will merge to 'master' in the first batch after 1.8.0 ships.
* mo/cvs-server-cleanup (2012-10-16) 10 commits
(merged to 'next' on 2012-10-18 at 5a60da1)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is used by mo/cvs-server-updates.)
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
(this branch uses mo/cvs-server-cleanup.)
* ta/doc-cleanup (2012-10-18) 5 commits
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* jc/prettier-pretty-note (2012-10-19) 7 commits
- Documentation: decribe format-patch --notes
- format-patch --notes: show notes after three-dashes
- format-patch: append --signature after notes
- pretty_print_commit(): do not append notes message
- pretty: prepare notes message at a centralized place
- format_note(): simplify API
- pretty: remove reencode_commit_message()
Needs updates to the placeholder documentation.
* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
(merged to 'next' on 2012-10-18 at 3864adc)
+ filter-branch: use git-sh-setup's ident parsing functions
+ git-sh-setup: refactor ident-parsing functions
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 54561c7)
+ strbuf: always return a non-NULL value from strbuf_detach
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/status-long (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 53940a1)
+ status: add --long output format option
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
Will merge to 'master' in the second batch after 1.8.0 ships.
* rs/branch-del-symref (2012-10-18) 5 commits
(merged to 'next' on 2012-10-18 at 68ee254)
+ branch: show targets of deleted symrefs, not sha1s
+ branch: skip commit checks when deleting symref branches
+ branch: delete symref branch, not its target
+ branch: factor out delete_branch_config()
+ branch: factor out check_branch_commit()
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
Will merge to 'master' in the second batch after 1.8.0 ships.
* sz/maint-curl-multi-timeout (2012-10-18) 1 commit
- Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
* jc/same-encoding (2012-10-18) 1 commit
- reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
--------------------------------------------------
[Stalled]
* mh/ceiling (2012-09-29) 9 commits
- t1504: stop resolving symlinks in GIT_CEILING_DIRECTORIES
- longest_ancestor_length(): resolve symlinks before comparing paths
- longest_ancestor_length(): use string_list_longest_prefix()
- longest_ancestor_length(): always add a slash to the end of prefixes
- longest_ancestor_length(): explicitly filter list before loop
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
The solution felt a bit unnecessarily convoluted to me.
Expecting a reroll.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-09-25 at 116e58f)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* fa/vcs-svn (2012-10-07) 4 commits
- vcs-svn: remove repo_tree
- vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
- vcs-svn/svndump: restructure node_ctx, rev_ctx handling
- svndump: move struct definitions to .h
(this branch uses fa/remote-svn.)
A follow-up to a GSoC project, but seems not quite ready.
Will discard.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* ph/credential-refactor (2012-09-02) 5 commits
- wincred: port to generic credential helper
- Merge branch 'ef/win32-cred-helper' into ph/credential-refactor
- osxkeychain: port to generic credential helper implementation
- gnome-keyring: port to generic helper implementation
- contrib: add generic credential helper
Attempts to refactor to share code among OSX keychain, Gnome keyring
and Win32 credential helpers.
* ms/contrib-thunderbird-updates (2012-08-31) 2 commits
- [SQUASH] minimum fixup
- Thunderbird: fix appp.sh format problems
Update helper to send out format-patch output using Thunderbird.
Seems to have design regression for silent users.
* jx/test-real-path (2012-08-27) 1 commit
- test: set the realpath of CWD as TRASH_DIRECTORY
Running tests with the "trash" directory elsewhere with the "--root"
option did not work well if the directory was specified by a symbolic
link pointing at it.
Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.
Will discard.
* jc/maint-push-refs-all (2012-08-27) 2 commits
- get_fetch_map(): tighten checks on dest refs
- [BROKEN] fetch/push: allow refs/*:refs/*
Allows pushing and fetching everything including refs/stash.
This is broken (see the log message there).
Not ready.
* jc/add-delete-default (2012-08-13) 1 commit
(merged to 'next' on 2012-10-11 at bd9e5cb)
+ git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* tx/relative-in-the-future (2012-08-16) 2 commits
- date: show relative dates in the future
- date: refactor the relative date logic from presentation
Not my itch; rewritten an earlier submission by Tom Xue into
somewhat more maintainable form, though it breaks existing i18n.
Waiting for a voluteer to fix it up.
Otherwise may discard.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
"The first remote becomes the default" bit is better done as a
separate step.
* jc/split-blob (2012-04-03) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- packfile: use varint functions
Not ready.
I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat disappointed that the original patch series
that was sent long time ago still remains here without much comments
and updates from the developer community. I even made the interface
to the logic that decides where to split chunks easily replaceable,
and I deliberately made the logic in the original patch extremely
stupid to entice others, especially the "bup" fanbois, to come up
with a better logic, thinking that giving people an easy target to
shoot for, they may be encouraged to help out. The plan is not
working :-<.
--------------------------------------------------
[Cooking]
* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
(merged to 'next' on 2012-10-16 at cc88829)
+ http: do not set up curl auth after a 401
+ remote-curl: do not call run_slot repeatedly
Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/grep-true-path (2012-10-12) 1 commit
(merged to 'next' on 2012-10-16 at 8a75ac8)
+ grep: stop looking at random places for .gitattributes
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
Will merge to 'master' in the second batch after 1.8.0 ships.
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
* fc/zsh-completion (2012-10-15) 3 commits
- completion: add new zsh completion
- tests: use __gitcompadd to simplify completion tests
- completion: add new __gitcompadd helper
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-16 at 850b5b2)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
* as/check-ignore (2012-10-19) 13 commits
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
(this branch uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with nd/wildmatch.)
Duy helped to reroll this.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-18 at 5b9a629)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
* km/send-email-compose-encoding (2012-10-10) 1 commit
(merged to 'next' on 2012-10-11 at d94bd05)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Will merge to 'master' in the second batch after 1.8.0 ships.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-17 at 0843a8b)
+ coloured git-prompt: paint detached HEAD marker in red
(merged to 'next' on 2012-10-16 at adf81be)
+ Fix up colored git-prompt
(merged to 'next' on 2012-10-11 at 1a14825)
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
* jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit
(merged to 'next' on 2012-10-11 at 639036d)
+ test-lib: Fix say_color () not to interpret \a\b\c in the message
Recent nd/wildmatch series was the first to reveal this ancient bug
in the test scaffolding.
Will merge to 'master' in the first batch after 1.8.0 ships.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* da/mergetools-p4 (2012-10-11) 1 commit
(merged to 'next' on 2012-10-12 at 16f5c06)
+ mergetools/p4merge: Handle "/dev/null"
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-16 at 5eaf3a4)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with as/check-ignore.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* nd/attr-match-optim (2012-10-05) 2 commits
(merged to 'next' on 2012-10-08 at bfbdd8a)
+ attr: avoid searching for basename on every match
+ attr: avoid strlen() on every match
(this branch is used by as/check-ignore, nd/attr-match-optim-more and nd/wildmatch.)
Trivial and obvious optimization for finding attributes that match
a given path.
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-16 at 9baac99)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch; uses nd/attr-match-optim.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
(merged to 'next' on 2012-10-11 at fec8530)
+ log: honor grep.* configuration
+ log --grep: accept --basic-regexp and --perl-regexp
+ log --grep: use the same helper to set -E/-F options as "git grep"
+ revisions: initialize revs->grep_filter using grep_init()
+ grep: move pattern-type bits support to top-level grep.[ch]
+ grep: move the configuration parsing logic to grep.[ch]
+ builtin/grep.c: make configuration callback more reusable
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/peel-ref (2012-10-04) 4 commits
(merged to 'next' on 2012-10-08 at 4adfa2f)
+ upload-pack: use peel_ref for ref advertisements
+ peel_ref: check object type before loading
+ peel_ref: do not return a null sha1
+ peel_ref: use faster deref_tag_noverify
Speeds up "git upload-pack" (what is invoked by "git fetch" on the
other side of the connection) by reducing the cost to advertise the
branches and tags that are available in the repository.
Will merge to 'master' in the first batch after 1.8.0 ships.
* fa/remote-svn (2012-10-07) 16 commits
(merged to 'next' on 2012-10-07 at 7b90cf4)
+ Add a test script for remote-svn
+ remote-svn: add marks-file regeneration
+ Add a svnrdump-simulator replaying a dump file for testing
+ remote-svn: add incremental import
+ remote-svn: Activate import/export-marks for fast-import
+ Create a note for every imported commit containing svn metadata
+ vcs-svn: add fast_export_note to create notes
+ Allow reading svn dumps from files via file:// urls
+ remote-svn, vcs-svn: Enable fetching to private refs
+ When debug==1, start fast-import with "--stats" instead of "--quiet"
+ Add documentation for the 'bidi-import' capability of remote-helpers
+ Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
+ Add argv_array_detach and argv_array_free_detached
+ Add svndump_init_fd to allow reading dumps from arbitrary FDs
+ Add git-remote-testsvn to Makefile
+ Implement a remote helper for svn in C
(this branch is used by fa/vcs-svn.)
A GSoC project.
Will merge to 'master' in the first batch after 1.8.0 ships.
* bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit
(merged to 'next' on 2012-10-08 at 69f54f4)
+ Remove the hard coded length limit on variable names in config files
The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently. Lift the limit.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jm/diff-context-config (2012-10-02) 2 commits
(merged to 'next' on 2012-10-02 at e57700a)
+ t4055: avoid use of sed 'a' command
(merged to 'next' on 2012-10-01 at 509a558)
+ diff: diff.context configuration gives default to -U
Teaches a new configuration variable to "git diff" Porcelain and
its friends.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jl/submodule-add-by-name (2012-09-30) 2 commits
(merged to 'next' on 2012-10-08 at 9408d8d)
+ submodule add: Fail when .git/modules/<name> already exists unless forced
+ Teach "git submodule add" the --name option
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-rm (2012-09-29) 1 commit
(merged to 'next' on 2012-10-01 at 4e5c4fc)
+ submodule: teach rm to remove submodules unless they contain a git directory
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
- pretty: support %>> that steal trailing spaces
- pretty: support truncating in %>, %< and %><
- pretty: support padding placeholders, %< %> and %><
- pretty: two phase conversion for non utf-8 commits
- utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
- utf8.c: move display_mode_esc_sequence_len() for use by other functions
- pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
- pretty: split parsing %C into a separate function
- pretty: share code between format_decoration and show_decorations
* jk/no-more-pre-exec-callback (2012-06-05) 1 commit
(merged to 'next' on 2012-10-12 at 69fed45)
+ pager: drop "wait for output to run less" hack
(Originally merged to 'next' on 2012-07-23)
Removes a workaround for buggy version of less older than version
406.
Will merge to 'master' in the first batch after 1.8.0 ships.
^ permalink raw reply
* Re: Re: Git for Windows and line endings
From: Jeff King @ 2012-10-19 20:59 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:
> I would like to point out:
> - Git on Linux does not mess around with line endings. I can create
> and edit a file in either line ending on Linux and commit and still
> have it untouched.
> - Git on Windows via Cygwin also does not mess around.
> - If those flavors of Git don't mess around, why should msysgit do it?
Most platforms (i.e., the userspace of most unix-y distributions) do not
mess around with line endings, either, so it is easy to have a sane
default there. I think the Cygwin build just followed that existing
defaults.
But msysgit's behavior was directly responding to user complaints. And
there were a lot of them. I do not use Windows myself, so I have only
the perspective of reading the list discussions. And that only what
bleeds onto the git@vger list, not the msysgit list.
Searching for "crlf" on the list yields over 2300 messages, many of
which discuss specific problems people are having without CRLF support.
I do not think any decision in the open source world is final, and
correcting a wrong decision from the past should always be an option.
But I do not think it is constructive to say "your decision is wrong"
without responding to the arguments that led to that decision. All I see
in your email is "your default is not my preference" without responding
to the discussion and perspectives of others through the years.
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
Again, I do not use Windows, so my anecdotes are purely culled from the
list. But people have mentioned that Visual Studio is bad for writing
our CRLFs for files which already have LFs. This makes diffs unreadable,
and gives merges, rebases and cherry-picks lots of spurious conflicts.
> - If there was SO MUCH thought into this, then it was too much; it was
> the wrong thought. There should not have been much at all, and just
> allow Git to do what it does: store things *exactly* as you put it in.
> Allow the clients to worry about things like line endings should they
> have the need to worry about it. I'm not seeing how the revision
> system has any business making alterations to things one commits into
> it.
One of the problems is that people do not realize the issue until they
have built a lot of history with CRLFs or mixed line endings (which they
might not even realize until the project starts being used by somebody
with a different editor or platform), and then they have a very painful
flag day turning on these options and normalizing the repository.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH] diff: diff.context configuration gives default to -U
From: Jeff Muizelaar @ 2012-10-19 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3923p0tb.fsf@alter.siamese.dyndns.org>
Introduce a configuration variable diff.context that tells
Porcelain commands to use a non-default number of context
lines instead of 3 (the default). With this variable, users
do not have to keep repeating "git log -U8" from the command
line; instead, it becomes sufficient to say "git config
diff.context 8" just once.
Signed-off-by: Jeff Muizelaar <jmuizelaar@mozilla.com>
---
On 2012-09-27, at 6:18 PM, Junio C Hamano wrote:
> Jeff Muizelaar <jmuizelaar@mozilla.com> writes:
>
>> + if (!strcmp(var, "diff.context")) {
>> + diff_context_default = git_config_int(var, value);
>> + if (diff_context_default < 0)
>> + return -1;
>> + return 0;
>
> I am somewhat torn on this part. This fails the entire command when
> diff.context is set to non integer or negative integer, which means
> trouble for a user of a future version of git that accepts such a
> value to do something intelligent we do not anticipate today. The
> useful configuration value cannot be given unless the user is
> certain that .gitconfig file will never be read by older version of
> git.
>
> Perhaps it is OK, at least for now. We'd have the same worry for
> what is given to -U<n> anyway.
I left this as is.
>> +test_expect_success 'diff.context affects log' '
>> + git log -1 -p >output &&
>> + ! grep firstline output &&
>> + git config diff.context 8 &&
>> + git log -1 -p >output &&
>> + grep firstline output
>> +'
>
> Is there a reason to favor "log -1 -p" over something a lot simpler
> like "show"? Not requesting to change anything, but just being
> curious.
No. I changed it to "show" to avoid the surprise.
Other than that I included the test changes you suggested. I did however
adjust the sed 'a' command. It seems that GNU sed and BSD sed have incompatible behaviour
here. Unfortunately this also seems to screw up the indentation.
---
Documentation/diff-config.txt | 4 ++
diff.c | 9 ++++-
t/t4055-diff-context.sh | 94 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 106 insertions(+), 1 deletions(-)
create mode 100755 t/t4055-diff-context.sh
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 67a90a8..75ab8a5 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -56,6 +56,10 @@ diff.statGraphWidth::
Limit the width of the graph part in --stat output. If set, applies
to all commands generating --stat output except format-patch.
+diff.context::
+ Generate diffs with <n> lines of context instead of the default of
+ 3. This value is overridden by the -U option.
+
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/diff.c b/diff.c
index 35d3f07..86e5f2a 100644
--- a/diff.c
+++ b/diff.c
@@ -26,6 +26,7 @@ static int diff_detect_rename_default;
static int diff_rename_limit_default = 400;
static int diff_suppress_blank_empty;
static int diff_use_color_default = -1;
+static int diff_context_default = 3;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
@@ -141,6 +142,12 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
diff_use_color_default = git_config_colorbool(var, value);
return 0;
}
+ if (!strcmp(var, "diff.context")) {
+ diff_context_default = git_config_int(var, value);
+ if (diff_context_default < 0)
+ return -1;
+ return 0;
+ }
if (!strcmp(var, "diff.renames")) {
diff_detect_rename_default = git_config_rename(var, value);
return 0;
@@ -3170,7 +3177,7 @@ void diff_setup(struct diff_options *options)
options->break_opt = -1;
options->rename_limit = -1;
options->dirstat_permille = diff_dirstat_permille_default;
- options->context = 3;
+ options->context = diff_context_default;
DIFF_OPT_SET(options, RENAME_EMPTY);
options->change = diff_change;
diff --git a/t/t4055-diff-context.sh b/t/t4055-diff-context.sh
new file mode 100755
index 0000000..60348b7
--- /dev/null
+++ b/t/t4055-diff-context.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Mozilla Foundation
+#
+
+test_description='diff.context configuration'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ cat >x <<-\EOF &&
+ firstline
+ b
+ c
+ d
+ e
+ f
+ preline
+ postline
+ i
+ j
+ k
+ l
+ m
+ n
+ EOF
+ git update-index --add x &&
+ git commit -m initial &&
+
+ git cat-file blob HEAD:x |
+ sed "s/preline/preline\\
+ADDED/" >x &&
+ git update-index --add x &&
+ git commit -m next &&
+
+ git cat-file blob HEAD:x |
+ sed s/ADDED/MODIFIED/ >x
+'
+
+test_expect_success 'the default number of context lines is 3' '
+ git diff >output &&
+ ! grep "^ d" output &&
+ grep "^ e" output &&
+ grep "^ j" output &&
+ ! grep "^ k" output
+'
+
+test_expect_success 'diff.context honored by "show"' '
+ git show >output &&
+ ! grep firstline output &&
+ git config diff.context 8 &&
+ git show >output &&
+ grep "^ firstline" output
+'
+
+test_expect_success 'The -U option overrides diff.context' '
+ git config diff.context 8 &&
+ git log -U4 -1 >output &&
+ ! grep "^ firstline" output
+'
+
+test_expect_success 'diff.context honored by "diff"' '
+ git config diff.context 8 &&
+ git diff >output &&
+ grep "^ firstline" output
+'
+
+test_expect_success 'plumbing not affected' '
+ git config diff.context 8 &&
+ git diff-files -p >output &&
+ ! grep "^ firstline" output
+'
+
+test_expect_success 'non-integer config parsing' '
+ git config diff.context no &&
+ test_must_fail git diff 2>output &&
+ test_i18ngrep "bad config value" output
+'
+
+test_expect_success 'negative integer config parsing' '
+ git config diff.context -1 &&
+ test_must_fail git diff 2>output &&
+ test_i18ngrep "bad config file" output
+'
+
+test_expect_success '-U0 is valid, so is diff.context=0' '
+ git config diff.context 0 &&
+ git diff >output &&
+ grep "^-ADDED" output &&
+ grep "^+MODIFIED" output &&
+ ! grep "^ postline" output
+'
+
+test_done
--
1.7.4.4
^ permalink raw reply related
* Re: Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 20:40 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, szager, git, sop
In-Reply-To: <20121019202723.GA24184@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
>> > IOW, it seems like we are _already_ following the advice referenced in
>> > curl's manpage. Is there some case I am missing? Confused...
>>
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:
Yeah, that sounds like a more targetted workaround (read: better).
>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /*
> + * Sometimes curl will give a really long timeout for a
> + * CONNECT when there are no fds to read, but we can
> + * get better results by running curl_multi_perform
> + * more frequently.
> + */
> + if (maxfd < 0 &&
> + (select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000)) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
> +
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
> }
>
> -Peff
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Jeff King @ 2012-10-19 20:40 UTC (permalink / raw)
To: Stefan Zager; +Cc: Shawn Pearce, Junio C Hamano, git, Shawn Pearce
In-Reply-To: <CAHOQ7J8D-8++vgMh=c0rcTtAKrhWUCQx2nSd_spBzFe=QdXwBw@mail.gmail.com>
On Fri, Oct 19, 2012 at 01:37:06PM -0700, Stefan Zager wrote:
> > diff --git a/http.c b/http.c
> > index df9bb71..cd07cdf 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> > FD_ZERO(&excfds);
> > curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
> >
> > + /*
> > + * Sometimes curl will give a really long timeout for a
> > + * CONNECT when there are no fds to read, but we can
> > + * get better results by running curl_multi_perform
> > + * more frequently.
> > + */
> > + if (maxfd < 0 &&
> > + (select_timeout.tv_sec > 0 ||
> > + select_timeout.tv_usec > 50000)) {
> > + select_timeout.tv_sec = 0;
> > + select_timeout.tv_usec = 50000;
> > + }
> > +
> > select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> > }
> > }
> >
> I have no objection to this; any one else?
If you wouldn't mind, I was hoping you could flesh out the comment a bit
more with real details of when this happens (and/or put them in the
commit message). If this is indeed a bug to be worked around, it will be
a huge help to somebody reading this code in a year who can confirm that
modern curl does not need it anymore.
-Peff
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Stefan Zager @ 2012-10-19 20:37 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Junio C Hamano, git, Shawn Pearce
In-Reply-To: <20121019202723.GA24184@sigill.intra.peff.net>
On Fri, Oct 19, 2012 at 1:27 PM, Jeff King <peff@peff.net> wrote:
>
> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
> > > IOW, it seems like we are _already_ following the advice referenced in
> > > curl's manpage. Is there some case I am missing? Confused...
> >
> > The issue with the current code is sometimes when libcurl is opening a
> > CONNECT style connection through an HTTP proxy it returns a crazy high
> > timeout (>240 seconds) and no fds. In this case Git waits forever.
> > Stefan observed that using a timeout of 50 ms in this situation to
> > poll libcurl is better, as it figures out a lot more quickly that it
> > is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:
>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /*
> + * Sometimes curl will give a really long timeout for a
> + * CONNECT when there are no fds to read, but we can
> + * get better results by running curl_multi_perform
> + * more frequently.
> + */
> + if (maxfd < 0 &&
> + (select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000)) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
> +
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
> }
>
> -Peff
I have no objection to this; any one else?
Stefan
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Jeff King @ 2012-10-19 20:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, szager, git, sop
In-Reply-To: <CAJo=hJvWV0WPN5rCYK-JxfaEPWp7syUM1H0w4=Eb27=50+pXjg@mail.gmail.com>
On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
> > IOW, it seems like we are _already_ following the advice referenced in
> > curl's manpage. Is there some case I am missing? Confused...
>
> The issue with the current code is sometimes when libcurl is opening a
> CONNECT style connection through an HTTP proxy it returns a crazy high
> timeout (>240 seconds) and no fds. In this case Git waits forever.
> Stefan observed that using a timeout of 50 ms in this situation to
> poll libcurl is better, as it figures out a lot more quickly that it
> is connected to the proxy and can issue the request.
Ah. That sounds like a bug in curl to me. But either way, if we want to
work around it, wouldn't the right thing be to override curl's timeout
in that instance? Like:
diff --git a/http.c b/http.c
index df9bb71..cd07cdf 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /*
+ * Sometimes curl will give a really long timeout for a
+ * CONNECT when there are no fds to read, but we can
+ * get better results by running curl_multi_perform
+ * more frequently.
+ */
+ if (maxfd < 0 &&
+ (select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000)) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
-Peff
^ permalink raw reply related
* Re: libgit2 status
From: Junio C Hamano @ 2012-10-19 20:13 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thiago Farina, git, dag, Nicolas Sebrecht, Andreas Ericsson,
greened
In-Reply-To: <CALkWK0=P7THaJduYFS1Sr6mxtNqAWQsDgwQyr_KEX4NA4kmVSA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Thiago Farina wrote:
>> [...]
>> With some structure like:
>>
>> include/git.h
>> src/git.c
>>
>> ...
>>
>> whatever.
>> [...]
>
> Junio- is it reasonable to expect the directory-restructuring by 2.0?
I actually hate "include/git.h vs src/git.c"; you have distinction
between .c and .h already.
^ permalink raw reply
* Re: A design for distributed submodules
From: Jens Lehmann @ 2012-10-19 20:09 UTC (permalink / raw)
To: Lauri Alanko; +Cc: git
In-Reply-To: <20121019033158.93403x1gcanyjo8u.lealanko@webmail.helsinki.fi>
Am 19.10.2012 02:31, schrieb Lauri Alanko:
> I think I finally agree that it's best to develop submodules further
> rather than introduce a new tool for the functionality I require. Here
> are some explicit proposals for submodules so we can at least establish
> agreement on what should be done. These are in order of decreasing
> importance (to me).
Good to hear that!
> * Upstreamless submodules
>
> If there is no 'url' key defined for a submodule in .gitconfig, there is
> no "authoritative upstream" for it. When a recursive
> fetch/pull/clone/push is performed on a remote superproject, its
> upstreamless submodules are also fetched/pulled/cloned/pushed directly
> from/to the submodule repositories under the superproject .git/modules.
> If this is the first time that remote's submodules are accessed, that
> remote is initialized for the local submodules: the submodule of the
> remote superproject becomes a remote of the local submodule, and is
> given the same name as the remote of the superproject.
>
> So, suppose we have a superproject with .gitmodules:
>
> [submodule "sub"]
> path = sub
>
> which is hosted at repositories at URL1 and URL2. Then we do:
>
> git clone --recursive URL1 super
> cd super
> git remote add other URL2
> git fetch --recursive URL2
>
> Now .git/modules/sub/config has:
>
> [remote "origin"]
> url = URL1/.git/modules/sub
> [remote "other"]
> url = URL2/.git/modules/sub
So you want to automatically propagate the new superproject remote
"other" into the submodules?
> So the effect is similar to just setting the submodule's url as
> ".git/modules/sub", except that:
>
> - it hides the implementation detail of the exact location of the
> submodule repository from the publicly visible configuration file
>
> - it also works with bare remotes (where the actual remote submodule
> location would be URL/modules/sub)
>
> - it allows multiple simultaneous superproject remotes (where
> git-submodule currently always resolves relative urls against
> branch.$branch.remote with no option to fetch from a different
> remote).
Maybe it's too late on a Friday evening in my timezone, but currently
I can't wrap my mind around what you have in mind here ... will try
again later.
> * Submodule discovery across all refs
>
> This is what Jens already mentioned. If we fetch multiple refs of a
> remote superproject, we also need to fetch _all_ of the submodules
> referenced by _any_ of the refs, not just the ones in the currently
> active branch.
That is how things already work now (and it is done in an optimized
way because we only do a fetch in a submodule when the referenced
commit isn't already present locally). But the current limitation
is that only populated submodules are updated (we do a "git fetch"
inside the submodules work tree), so e.g. currently we can't follow
renames. We should also do a fetch for submodules which aren't
checked out but whose repo is found in .git/modules/<name>.
> Finding the complete list of submodules probably has to
> be implemented by reading .gitmodules in all of the (updated) refs,
> which is a bit ugly, but not too bad.
Yes, this will be necessary to get the correct path -> name mapping
for submodules which aren't found in the work tree (e.g. because
they are renamed). (I will also need to peek into another commit's
.gitmodules file to make the recursive checkout work for appearing
submodules for the same reason)
> * Recording the active branch of a submodule
>
> When a submodule is added, its active branch should be stored in
> .gitmodules as submodule.$sub.branch. Then, when the submodule is
> checked out, and the head of that branch is the same as the commit in
> the gitlink (i.e. the superproject tree is "current"), then that branch
> is set as the active branch in the checked-out submodule working tree.
> Otherwise, a detached head is used.
We had some discussions about a "floating" submodule model where the
submodules follow the tip of a branch configured in .gitmodules. That
looked similar to what you have in mind, except that the tip of that
branch is always used.
> * Multiple working trees for a submodule
>
> A superproject may have multiple paths for the same submodule,
> presumably for different commits. This is for cases where the
> superproject is a snapshot of a developer's directory hierarchy, and the
> developer is simultaneously working on multiple branches of a submodule
> and it is convenient to have separate working trees for each of them.
>
> This is a bit hard to express with the current .gitconfig format, since
> paths are attributes of repository ids instead of vice versa. I'd
> introduce an alternative section format where you can say:
>
> [mount "path1"]
> module = sub
> branch = master
>
> [mount "path2"]
> module = sub
> branch = topic
>
> Implementing this is a bit intricate, since we need to use the
> git-new-workdir method to create multiple working directories that share
> the same refs, config, and object store, but have separate HEAD and
> index. I think this is a problem with the repository layout: the
> non-workdir-specific bits should all be in a single directory so that a
> single symlink would be enough.
I'm not sure how good that'll work. E.g. what happens if the user
configures the URL of "path1" to something else? It looks to me like
having the same repo copied under different .git/modules/<name> would
be a more robust approach, even though it wastes some disk space.
> Obviously, I'm willing to implement the above functionalities since I
> need them. However, I think I'm going to work in Dulwich (which doesn't
> currently have any submodule support): a Python API is currently more
> important to me than a command-line tool, and the git.git codebase
> doesn't look like a very attractive place to contribute anyway. No
> offense, it's just not to my tastes.
>
> So the main reason I'd like to reach some tentative agreement about the
> details of the proposal is to ensure that _once_ someone finally
> implements this kind of functionality in git.git, it will use the same
> configuration format and same conventions, so that it will be compatible
> with my code. The compatibility between different tools is after all the
> main reason for doing this stuff as an extension to submodules instead
> of something completely different.
Fair enough. But I fear unless we code the same functionality in both
worlds at about the same time the assumption that it will be done in
the future in the git core in the same way you expect may fail.
Having said that: I expect to implement peeking into another commit's
.gitmodules to read the config next after I finished the rm and mv for
submodules (and intend to use it for doing a fetch first), so maybe we
can start with that?
^ permalink raw reply
* Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes
From: Junio C Hamano @ 2012-10-19 20:06 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <7vlif3l9fw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As long as what it does is explained in format-patch, that is fine.
>
> I do not think this deserves to be in the SubmittingPatches. We do
> tell people to hide "here is the context of the change" additional
> explanation after three dashes, but how the submitters prepare that
> text is entirely up to them (and I personally do not think notes is
> not necessarily the right tool to do so).
Just in case, here is what I'll queue as a placeholder on 'pu'.
-- >8 --
Subject: [PATCH] Documentation: decribe format-patch --notes
Even though I coded this, I am not sure what use scenarios would benefit
from this option, so the description is unnecessarily negative at this
moment. People who do want to use this feature need to come up with a
more plausible use case and replace it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-format-patch.txt | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 6d43f56..066dc8b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -20,7 +20,7 @@ SYNOPSIS
[--ignore-if-in-upstream]
[--subject-prefix=Subject-Prefix]
[--to=<email>] [--cc=<email>]
- [--cover-letter] [--quiet]
+ [--cover-letter] [--quiet] [--notes[=<ref>]]
[<common diff options>]
[ <since> | <revision range> ]
@@ -191,6 +191,19 @@ will want to ensure that threading is disabled for `git send-email`.
containing the shortlog and the overall diffstat. You can
fill in a description in the file before sending it out.
+--notes[=<ref>]::
+ Append the notes (see linkgit:git-notes[1]) for the commit
+ after the three-dash line.
++
+The expected use case of this is to write supporting explanation for
+the commit that does not belong to the commit log message proper
+when (or after) you create the commit, and include it in your patch
+submission. But if you can plan ahead and write it down, there may
+not be a good reason not to write it in your commit message, and if
+you can't, you can always edit the output of format-patch before
+sending it out, so the practical value of this option is somewhat
+dubious, unless your workflow is broken.
+
--[no]-signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
is separated from the body by a line with '-- ' on it. If the
--
1.8.0.rc3.162.g1f53438
^ permalink raw reply related
* Re: [PATCH] Cache stat_tracking_info() for faster status and branch -v
From: Junio C Hamano @ 2012-10-19 19:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1350408967-13919-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> stat_tracking_info() is used to calculated how many commits ahead or
> behind for a branch. Rev walking can be slow especially when the
> branch is way behind its remote end. By caching the results, we won't
> have to rev walk every time we need these information.
> stat_tracking_info() cost can be greatly reduced this way.
>
> This makes sure "git status" instant no matter how far behind HEAD
> is, except the first time after HEAD changes. This also makes
> "branch -v" usable (for me) as it's now also instant versus 3.5
> seconds in non-cache case on my machine.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I wanted guaranteed-fast status for another reason, but it turns out
> "branch -v" benefits even more. Recent commit walking is not
> efficiently optimized even with Shawn's pack bitmaps. This may be
> useful some people, I guess.
Not particularly interested in the cause, but not so strongly
against it to veto it.
The design looks questionable.
You can fork one or more branches off of a single branch. You may
fork your 'frotz' branch off of remotes/origin/master but also
another 'xyzzy' branch may be forked from the same.
I understand that you are trying to optimize, given two commit
object names X and Y, the cost to learn the symmetric distances
between them.
Doesn't it make more sense to use a notes-cache that is keyed off of
the commit object name X of the remote? You will have a single note
that stores a blob for the commit object remotes/origin/master, and
the blob tells you how far the commit at the tip of 'frotz' is from
it, and the same for 'xyzzy'.
You would obviouly need to run "gc" on such a notes-cache tree from
time to time, removing notes for commits that are not tip of any
branch that could be a fork point, and from the remaining notes
blobs, entries that describe commits that are not tip of any branch,
if you go that route.
>
> remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index 04fd9ea..db825b8 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1549,6 +1549,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> struct rev_info revs;
> const char *rev_argv[10], *base;
> int rev_argc;
> + int fd;
>
> /*
> * Nothing to report unless we are marked to build on top of
> @@ -1579,6 +1580,33 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> if (theirs == ours)
> return 0;
>
> + if (!access(git_path("stat_tracking_cache/%s",
> + branch->refname), R_OK)) {
> + struct strbuf sb = STRBUF_INIT;
> + unsigned char sha1_ours[20], sha1_theirs[20];
> + int n1, n2;
> + if ((fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_RDONLY)) != -1 &&
> + strbuf_read(&sb, fd, 0) != -1 &&
> + sb.len > (40 + 1) * 2 &&
> + !get_sha1_hex(sb.buf, sha1_ours) &&
> + sb.buf[40] == '\n' &&
> + !get_sha1_hex(sb.buf + 41, sha1_theirs) &&
> + sb.buf[81] == '\n' &&
> + !hashcmp(sha1_ours, ours->object.sha1) &&
> + !hashcmp(sha1_theirs, theirs->object.sha1) &&
> + sscanf(sb.buf + 82, "%d\n%d\n", &n1, &n2) == 2) {
> + *num_ours = n1;
> + *num_theirs = n2;
> + close(fd);
> + strbuf_release(&sb);
> + return 1;
> + }
> + close(fd);
> + strbuf_release(&sb);
> + }
> +
> /* Run "rev-list --left-right ours...theirs" internally... */
> rev_argc = 0;
> rev_argv[rev_argc++] = NULL;
> @@ -1608,6 +1636,20 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> (*num_theirs)++;
> }
>
> + if (!safe_create_leading_directories(git_path("stat_tracking_cache/%s",
> + branch->refname)) &&
> + (fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_CREAT | O_TRUNC | O_RDWR, 0644)) != -1) {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(ours->object.sha1));
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(theirs->object.sha1));
> + strbuf_addf(&sb, "%d\n%d\n", *num_ours, *num_theirs);
> + write(fd, sb.buf, sb.len);
> + strbuf_release(&sb);
> + close(fd);
> + }
> +
> /* clear object flags smudged by the above traversal */
> clear_commit_marks(ours, ALL_REV_FLAGS);
> clear_commit_marks(theirs, ALL_REV_FLAGS);
^ permalink raw reply
* Re: Re: Git for Windows and line endings
From: Junio C Hamano @ 2012-10-19 17:22 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
Chris B <chris.blaszczynski@gmail.com> writes:
> - If there was SO MUCH thought into this, then it was too much...
I do not have much to add to what area experts already said on bits
specific to Git for Windows, but on just this part:
> - Our builds were not breaking, it was production due to deployment
> model utilizing Git. What if there was a process to extract from Git
> and then distribute?
Do you mean something like "git archive"? Or do you have something
else in mind?
> - Developers are not expecting revision control system to make changes
> to files they commit.
But isn't there a distinction between the logical content and its
physical representation? In source code (that is what developers
use a source code management system for), especially those of
cross-platform projects, the logical lines end with LF and physical
lines end with whatever is convenient on the platform of each
participant of the project. There needs a way to convert between
the two.
It does not sound fair to call it a crime if the port to a platform,
whose users (at least the majority of them) expect the latter to be
CRLF, chose to default to that to help the majority, as long as
there are ways for the minority power users to choose to use LF in
the physical representation on their working trees.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Daniel Stenberg @ 2012-10-19 17:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jeff King, Junio C Hamano, szager, git, sop
In-Reply-To: <CAJo=hJvWV0WPN5rCYK-JxfaEPWp7syUM1H0w4=Eb27=50+pXjg@mail.gmail.com>
On Fri, 19 Oct 2012, Shawn Pearce wrote:
> The issue with the current code is sometimes when libcurl is opening a
> CONNECT style connection through an HTTP proxy it returns a crazy high
> timeout (>240 seconds) and no fds. In this case Git waits forever.
Is this repeatable with a recent libcurl? It certainly sounds like a bug to
me, and I might be interested in giving a try at tracking it down...
--
/ daniel.haxx.se
^ permalink raw reply
* [PATCH] tree-walk: use enum interesting instead of integer
From: Nguyễn Thái Ngọc Duy @ 2012-10-19 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Commit d688cf0 (tree_entry_interesting(): give meaningful names to
return values - 2011-10-24) converts most of the tree_entry_interesting
values to the new enum, except "never_interesting". This completes the
conversion.
---
tree-walk.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 0e49299..42fe610 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -490,11 +490,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
static int match_entry(const struct name_entry *entry, int pathlen,
const char *match, int matchlen,
- int *never_interesting)
+ enum interesting *never_interesting)
{
int m = -1; /* signals that we haven't called strncmp() */
- if (*never_interesting) {
+ if (*never_interesting != entry_not_interesting) {
/*
* We have not seen any match that sorts later
* than the current path.
@@ -522,7 +522,7 @@ static int match_entry(const struct name_entry *entry, int pathlen,
* the variable to -1 and that is what will be
* returned, allowing the caller to terminate early.
*/
- *never_interesting = 0;
+ *never_interesting = entry_not_interesting;
}
if (pathlen > matchlen)
@@ -584,7 +584,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
{
int i;
int pathlen, baselen = base->len - base_offset;
- int never_interesting = ps->has_wildcard ?
+ enum interesting never_interesting = ps->has_wildcard ?
entry_not_interesting : all_entries_not_interesting;
if (!ps->nr) {
--
1.8.0.rc2.22.gad9383a
^ permalink raw reply related
* Re: Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 17:02 UTC (permalink / raw)
To: Stefan Zager; +Cc: Shawn Pearce, git, Jeff King, sop
In-Reply-To: <CAHOQ7J9W8FdKqzqbuDqj4bcFyN02kUigWtbL_xCen-PYWF9LUg@mail.gmail.com>
Stefan Zager <szager@google.com> writes:
> On Oct 19, 2012 7:11 AM, "Shawn Pearce" <spearce@spearce.org> wrote:
>>
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Correct. Anecdotally, the zero-file-descriptor situation happens only once
> per process invocation, so the risk of passing a too-long timeout to
> select() is small.
Thanks.
^ permalink raw reply
* Re: Unexpected directories from read-tree
From: Uri Moszkowicz @ 2012-10-19 16:10 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8BeMPwRtU9LQ9aS=0NY7vo_hXQs5Vxo9krXb+epqf=Fdw@mail.gmail.com>
I am using 1.8.0-rc2 but also tried 1.7.8.4. Thanks for the suggestion
to use "ls-files -t" - that's exactly what I was looking for. With
that I was easily able to tell what the problem is: missing "/" from
the sparse-checkout file.
On Thu, Oct 18, 2012 at 10:34 PM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz <uri@4refs.com> wrote:
>> I'm testing out the sparse checkout feature of Git on my large (14GB)
>> repository and am running into a problem. When I add "dir1/" to
>> sparse-checkout and then run "git read-tree -mu HEAD" I see dir1 as
>> expected. But when I add "dir2/" to sparse-checkout and read-tree
>> again I see dir2 and dir3 appear and they're not nested. If I replace
>> "dir2/" with "dir3/" in the sparse-checkout file, then I see dir1 and
>> dir3 but not dir2 as expected again. How can I debug this problem?
>
> Posting here is step 1. What version are you using? You can look at
> unpack-trees.c The function that does the check is excluded_from_list.
> You should check "ls-files -t", see if CE_SKIP_WORKTREE is set
> correctly for all dir1/*, dir2/* and dir3/*. Can you recreate a
> minimal test case for the problem?
> --
> Duy
^ permalink raw reply
* Re: [msysGit] Re: Git for Windows and line endings
From: Chris B @ 2012-10-19 14:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1210190801490.2695@bonsai2>
Hi. I'm sorry about the tone of the email; I was writing it after
spending a lot of energy fixing things up and I should have taken some
time to breathe. I recognize this is likely not going to change and
even if I could jump in to contribute it wouldn't matter. I also
recognize that changing it now might cause more problems. I am hopeful
though.
I would like to point out:
- Git on Linux does not mess around with line endings. I can create
and edit a file in either line ending on Linux and commit and still
have it untouched.
- Git on Windows via Cygwin also does not mess around.
- If those flavors of Git don't mess around, why should msysgit do it?
- Windows has been able to cope with UNIX line endings a long time; no
developer is using a default Notepad to open files with high
expectations. Any Windows development tool and editor worth anything
I've used is able to handle both just fine.
- VIM also handles Windows line endings just fine as well. I just
tested it on a Linux machine. Maybe old version? (pure VI is not even
on this machine but hard to press these days it can't handle it.)
- The files in .git folder are in UNIX format anyway, so why are those
not also included in line ending changes? Isn't is because there is a
Windows app (msysgit) running on Windows that expects the UNIX line
ending? So in the same manor, someone might have a Windows system
using some Cygwin components perhaps, or a Windows C program possibly
poorly written or just old, that demand some text files to be left
alone in the format we saved it.
- If there was SO MUCH thought into this, then it was too much; it was
the wrong thought. There should not have been much at all, and just
allow Git to do what it does: store things *exactly* as you put it in.
Allow the clients to worry about things like line endings should they
have the need to worry about it. I'm not seeing how the revision
system has any business making alterations to things one commits into
it.
- Our builds were not breaking, it was production due to deployment
model utilizing Git. What if there was a process to extract from Git
and then distribute? Sounds like it's simple and should work and there
are good advantages to this process to overcome speed of deployment
issues. That process is free to be either Linux or Windows, and to
distribute to either a Linux or Windows server. This process you may
consider a mistake, but the point is that Git is just storing things,
not worried about the process in which it is used.
- While there might be options to make the other flavors of Git mess
around with line endings, the default is to not touch it which is
critical. Because as you bring on developers you never know what they
selected during the installation, and you have to go back and have
them change it if they did something different.
- Developers are not expecting revision control system to make changes
to files they commit.
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Shawn Pearce @ 2012-10-19 14:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, szager, git, sop
In-Reply-To: <20121019103627.GA29366@sigill.intra.peff.net>
On Fri, Oct 19, 2012 at 3:36 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 18, 2012 at 03:59:41PM -0700, Junio C Hamano wrote:
>
>> > It will sometimes happen that curl_multi_fdset() doesn't
>> > return any file descriptors. In that case, it's recommended
>> > that the application sleep for a short time before running
>> > curl_multi_perform() again.
>> >
>> > http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
>> >
>> > Signed-off-by: Stefan Zager <szager@google.com>
>> > ---
>>
>> Thanks. Would it be a better idea to "patch up" in problematic
>> case, instead of making this logic too deeply nested, like this
>> instead, I have to wonder...
>>
>>
>> ... all the existing code above unchanged ...
>> curl_multi_fdset(..., &max_fd);
>> + if (max_fd < 0) {
>> + /* nothing actionable??? */
>> + select_timeout.tv_sec = 0;
>> + select_timeout.tv_usec = 50000;
>> + }
>>
>> select(max_fd+1, ..., &select_timeout);
>
> But wouldn't that override a potentially shorter timeout that curl gave
> us via curl_multi_timeout, making us unnecessarily slow to hand control
> back to curl?
>
> The current logic is:
>
> - if curl says there is something to do now (timeout == 0), do it
> immediately
>
> - if curl gives us a timeout, use it with select
>
> - otherwise, feed 50ms to selection
>
> It should not matter what we get from curl_multi_fdset. If there are
> fds, great, we will feed them to select with the timeout, and we may
> break out early if there is work to do. If not, then we are already
> doing this wait.
>
> IOW, it seems like we are _already_ following the advice referenced in
> curl's manpage. Is there some case I am missing? Confused...
The issue with the current code is sometimes when libcurl is opening a
CONNECT style connection through an HTTP proxy it returns a crazy high
timeout (>240 seconds) and no fds. In this case Git waits forever.
Stefan observed that using a timeout of 50 ms in this situation to
poll libcurl is better, as it figures out a lot more quickly that it
is connected to the proxy and can issue the request.
^ permalink raw reply
* Re: [PATCH 0/2] gitk: fix --full-diff handling
From: Felipe Contreras @ 2012-10-19 13:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Paul Mackerras
In-Reply-To: <508151A0.3050505@viscovery.net>
On Fri, Oct 19, 2012 at 3:12 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 10/19/2012 12:56, schrieb Felipe Contreras:
>> I find usel to do 'git log --full-duff -- file' to find out all the commits
>> that touched the file, and show the full diff (not just the one of the file).
>>
>> Unfortunately gitk doesn't honour this option; the diff is limited in the UI.
>
> There is Edit->Preferences->General->Limit diff to listed paths. Doesn't
> it do what you want if you switch it off?
Hmm, I guess so, but it's not triggered from the command line. Maybe
the --full-diff option should enable that flag.
--
Felipe Contreras
^ permalink raw reply
* [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2012-10-19 13:21 UTC (permalink / raw)
To: git list
As the examples in git-subtree.txt show, the synopsis in the same file should
surely get a patch along the lines of:
-'git subtree' add -P <prefix> <commit>
+'git subtree' add -P <prefix> <repository> <commit>
Failure to specify the repository (by just specifying a local commit) fails with
the cryptic:
warning: read-tree: emptying the index with no arguments is deprecated; use --empty
fatal: just how do you expect me to merge 0 trees?
Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
mentions a <refspec> which the synopsis does not show either.
As a sidenote it someone wants to do some maintainance, using "." as repository when
the branch to subtree-add is already locally available does not work well either
(fails with "could not find ref myremote/myhead").
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox