* question about interactive.singlekey
From: Valentin Haenel @ 2011-09-06 20:50 UTC (permalink / raw)
To: Git-List
Hi,
i have recently installed debian on my laptop. I discovered that the
'interactive.singlekey' setting does not seem to work. On my desktop,
which has been debian for a while it does work. These are both debian
stable and have the exact same version of git v1.7.2.5, but
perhaps slightly different packages of other software installed. Does
the 'interactive.singlekey' setting perhaps need additional libraries
which were forgotten in the debian package dependencies?
Any ideas on where to look are greatly appreciated.
V-
^ permalink raw reply
* [PATCH] State what commit to expect in request-pull
From: Junio C Hamano @ 2011-09-06 21:24 UTC (permalink / raw)
To: git
Interestingly, we did say what commit the requesters based their changes
on, but did not give the person who performs a fetch & merge to make sure
he fetched the right branch.
This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 1 +
t/t5150-request-pull.sh | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index fc080cc..9b06a87 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -71,6 +71,7 @@ git show -s --format='The following changes since commit %H:
are available in the git repository at:' $baserev &&
echo " $url $branch" &&
+echo "for you to fetch changes up to $headrev"
echo &&
git shortlog ^$baserev $headrev &&
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 9cc0a42..9d27c43 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -194,6 +194,7 @@ test_expect_success 'pull request format' '
are available in the git repository at:
URL BRANCH
+ for you to fetch changes up to OBJECT_NAME
SHORTLOG
^ permalink raw reply related
* Re: question about interactive.singlekey
From: Junio C Hamano @ 2011-09-06 21:28 UTC (permalink / raw)
To: Valentin Haenel; +Cc: Git-List
In-Reply-To: <20110906205011.GC1747@kudu.in-berlin.de>
Valentin Haenel <valentin@fsfe.org> writes:
> i have recently installed debian on my laptop. I discovered that the
> 'interactive.singlekey' setting does not seem to work. On my desktop,
> which has been debian for a while it does work. These are both debian
> stable and have the exact same version of git v1.7.2.5, but
> perhaps slightly different packages of other software installed. Does
> the 'interactive.singlekey' setting perhaps need additional libraries
> which were forgotten in the debian package dependencies?
I see this:
eval {
require Term::ReadKey;
Term::ReadKey->import;
$use_readkey = 1;
so perhaps...
$ apt-cache search term.*readkey
libterm-readkey-perl - A perl module for simple terminal control
^ permalink raw reply
* Re: question about interactive.singlekey
From: Valentin Haenel @ 2011-09-06 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git-List
In-Reply-To: <7vsjo9743o.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [110906]:
> Valentin Haenel <valentin@fsfe.org> writes:
>
> > i have recently installed debian on my laptop. I discovered that the
> > 'interactive.singlekey' setting does not seem to work. On my desktop,
> > which has been debian for a while it does work. These are both debian
> > stable and have the exact same version of git v1.7.2.5, but
> > perhaps slightly different packages of other software installed. Does
> > the 'interactive.singlekey' setting perhaps need additional libraries
> > which were forgotten in the debian package dependencies?
>
> I see this:
>
> eval {
> require Term::ReadKey;
> Term::ReadKey->import;
> $use_readkey = 1;
>
> so perhaps...
>
> $ apt-cache search term.*readkey
> libterm-readkey-perl - A perl module for simple terminal control
Bingo! Thanks! Should i send this downstream somewhere?
V-
^ permalink raw reply
* Re: question about interactive.singlekey
From: Junio C Hamano @ 2011-09-06 21:42 UTC (permalink / raw)
To: Valentin Haenel; +Cc: Gerrit Pape, Git-List
In-Reply-To: <20110906213326.GD1747@kudu.in-berlin.de>
Valentin Haenel <valentin@fsfe.org> writes:
>> > ... Does
>> > the 'interactive.singlekey' setting perhaps need additional libraries
>> > which were forgotten in the debian package dependencies?
>>
>> ...
>> so perhaps...
>>
>> $ apt-cache search term.*readkey
>> libterm-readkey-perl - A perl module for simple terminal control
>
> Bingo! Thanks! Should i send this downstream somewhere?
It may make sense to add libterm-readkey-perl to Suggests, perhaps, but I
am not a debian maintainer and I am not familiar with the policies to
handle a minor dependencies like this.
$ apt-cache show git | grep Maintainer
Maintainer: Gerrit Pape <pape@smarden.org>
^ permalink raw reply
* Tracking database changes.
From: Rodrigo Cortés @ 2011-09-06 21:55 UTC (permalink / raw)
To: git
Is there a way to use git to track database changes?
--
Rodrigo Cortés Carvajal
Ingeniería Eléctrica
Universidad Tecnológica de Chile
^ permalink raw reply
* Re: [PATCH] State what commit to expect in request-pull
From: Shawn Pearce @ 2011-09-06 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrdl749z.fsf@alter.siamese.dyndns.org>
On Tue, Sep 6, 2011 at 14:24, Junio C Hamano <gitster@pobox.com> wrote:
> Interestingly, we did say what commit the requesters based their changes
> on, but did not give the person who performs a fetch & merge to make sure
> he fetched the right branch.
...
> diff --git a/git-request-pull.sh b/git-request-pull.sh
> @@ -71,6 +71,7 @@ git show -s --format='The following changes since commit %H:
>
> are available in the git repository at:' $baserev &&
> echo " $url $branch" &&
> +echo "for you to fetch changes up to $headrev"
> echo &&
Better than what we had before. I was sort of hoping for changing the
pull line slightly to include the SHA-1. E.g. suppose instead the line
was:
echo " $url $headrev"
and git pull passed the $headrev down to git fetch, which then found
any reference that points exactly at $headrev and fetches that. The
branch name is now lost for the merge summary, but could be guessed
from the advertisement similar to how HEAD is guessed. Git pull could
also then validate that the commit its merging in FETCH_HEAD is what
was passed on the command line.
Then verification of the SHA-1 is automatic by Git, and doesn't
require a human. If the pull request was sent by GPG signed email, and
the MUA checked the signature, the puller has pretty reasonable
assurance over the content they are bringing into their repository.
--
Shawn.
^ permalink raw reply
* Re: Tracking database changes.
From: Carlos Martín Nieto @ 2011-09-06 22:18 UTC (permalink / raw)
To: Rodrigo Cortés; +Cc: git
In-Reply-To: <CAFSYZ5RjJYHByTMPu6LiM6awGitt3WqnVrLU34mA9t7O1MVHDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
On Tue, 2011-09-06 at 18:55 -0300, Rodrigo Cortés wrote:
> Is there a way to use git to track database changes?
That question is too generic to receive a useful answer. You could do a
nightly dump of the database contents and commit that file. Whether that
will give you anything useful is a different matter.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Junio C Hamano @ 2011-09-06 22:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tay Ray Chuan
In-Reply-To: <20110905222202.GA32071@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> When asked to fetch over SSL without a valid
> /etc/ssl/certs/ca-certificates.crt file, "git fetch" writes
>
> error: while accessing https://github.com/torvalds/linux.git/info/refs
>
> which is a little disconcerting. Better to fall back to
> curl_easy_strerror(result) when the error string is empty, like the
> curl utility does:
>
> error: Problem with the SSL CA cert (path? access rights?) while
> accessing https://github.com/torvalds/linux.git/info/refs
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Hi,
>
> I ran into this error today because this machine has no certs enabled.
> I'm not thrilled with the following patch because the error string
> buffer is not cleared very often so it seems possible for it to be
> not empty but stale at the relevant moment. I would be happier if we
> could rely on libcurl always filling the error buffer on errors.
Will queue both patches; thanks.
^ permalink raw reply
* Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Junio C Hamano @ 2011-09-06 22:58 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Jeff King
In-Reply-To: <1314924634-12235-1-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> @@ -659,15 +660,18 @@ static int mv(int argc, const char **argv)
> strbuf_addf(&buf, "remote.%s.fetch", rename.new);
> if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
> return error("Could not remove config section '%s'", buf.buf);
> + strbuf_addf(&old_remote_context, ":refs/remotes/%s/", rename.old);
> for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
> char *ptr;
>
> strbuf_reset(&buf2);
> strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
> - ptr = strstr(buf2.buf, rename.old);
> + ptr = strstr(buf2.buf, old_remote_context.buf);
> if (ptr)
> - strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
> - rename.new, strlen(rename.new));
> + strbuf_splice(&buf2,
> + ptr-buf2.buf + strlen(":refs/remotes/"),
> + strlen(rename.old), rename.new,
> + strlen(rename.new));
> if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
> return error("Could not append '%s'", buf.buf);
> }
It is somewhat bothering that we do not say "we didn't do any magic" here
when we did not move the tracking branch specifications, but that is not a
new problem, so I am OK with this change.
I however suspect that you would want to keep the record of what you
changed here, so that the renaming of actual refs done in [PATCH 2/2] is
limited to those that you updated the specifications for, no?
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #02; Tue, 6)
From: Junio C Hamano @ 2011-09-06 23:43 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Some of the recent patches are fixes to new feature topics already merged
to "master" and are being fast tracked for 1.7.7-rc1, but otherwise
patches for new features and fixes to longstanding issues will stay in
'pu' or 'next' until the 1.7.7 final.
--------------------------------------------------
[Graduated to "master"]
* cb/maint-ls-files-error-report (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at b606e19)
+ t3005: do not assume a particular order of stdout and stderr of git-ls-files
* mh/check-ref-format-print-normalize (2011-08-27) 2 commits
(merged to 'next' on 2011-08-30 at e827410)
+ Forbid DEL characters in reference names
+ check-ref-format --print: Normalize refnames that start with slashes
* rc/histogram-diff (2011-08-31) 1 commit
(merged to 'next' on 2011-09-02 at be4d245)
+ xdiff/xprepare: initialise xdlclassifier_t cf in xdl_prepare_env()
--------------------------------------------------
[New Topics]
* cb/common-prefix-unification (2011-09-06) 3 commits
- rename pathspec_prefix() to common_prefix() and move to dir.[ch]
- consolidate pathspec_prefix and common_prefix
- remove prefix argument from pathspec_prefix
* cb/maint-quiet-push (2011-09-05) 4 commits
. t5541: avoid TAP test miscounting
. push: old receive-pack does not understand --quiet
. fix push --quiet via http
. tests for push --quiet
Dropped for rerolling after 1.7.7 cycle.
* cb/send-email-help (2011-09-05) 1 commit
- send-email: add option -h
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
- test: fetch/receive with fsckobjects
- transfer.fsckobjects: unify fetch/receive.fsckobjects
- fetch.fsckobjects: verify downloaded objects
* jc/receive-verify (2011-09-02) 3 commits
- receive-pack: check connectivity before concluding "git push"
- check_everything_connected(): libify
- check_everything_connected(): refactor to use an iterator
(this branch uses jc/fetch-verify, jc/fetch-verify and jc/traverse-commit-list.)
* tr/doc-note-rewrite (2011-09-05) 1 commit
- Documentation: "on for all" configuration of notes.rewriteRef
* jc/request-pull-show-head (2011-09-06) 1 commit
- State what commit to expect in request-pull
* jn/maint-http-error-message (2011-09-06) 2 commits
- http: avoid empty error messages for some curl errors
- http: remove extra newline in error message
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates, tests, and integration with the higher level
callers, e.g. "git add -p".
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* bk/ancestry-path (2011-08-25) 3 commits
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
The topic came up a bit too late in the cycle.
Will cook for a while.
* mg/branch-list (2011-08-28) 5 commits
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
Not urgent; the topic came up a bit too late in the cycle.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
Not urgent; the topic came up a bit too late in the cycle.
* jk/default-attr (2011-08-26) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Not urgent; I fixed up the test breakage just for fun.
* hv/submodule-merge-search (2011-08-26) 4 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(this branch uses fg/submodule-auto-push.)
Not urgent; the topic came up a bit too late in the cycle.
The bottom one needs to be replaced with a properly written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
- git-remote-mediawiki: allow push to set MediaWiki metadata
- Add a remote helper to interact with mediawiki (fetch & push)
Fun.
Not urgent; the topic came up a bit too late in the cycle.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
Not urgent; will not be in 1.7.7.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
Not urgent; the topic came up a bit too late in the cycle.
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
Not urgent; the topic came up a bit too late in the cycle.
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
Will cook for a while.
* jn/remote-helpers-doc (2011-09-01) 3 commits
- (short) documentation for the testgit remote helper
- Documentation/git-remote-helpers: explain how import works with multiple refs
- Documentation/remote-helpers: explain capabilities first
Not urgent.
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
Not urgent; the topic came up a bit too late in the cycle.
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
Not urgent; the topic came up a bit too late in the cycle.
* fg/submodule-auto-push (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is used by hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/fetch-verify (2011-09-01) 3 commits
- fetch: verify we have everything we need before updating our ref
- rev-list --verify-object
- list-objects: pass callback data to show_objects()
(this branch is used by jc/receive-verify and jc/receive-verify; uses jc/traverse-commit-list.)
Make "git fetch" verify what it received a bit more carefully before
updating the refs in the receiving end.
Not urgent; the topic came up a bit too late in the cycle.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
Not urgent; will not be in 1.7.7.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
--------------------------------------------------
[Discarded]
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
^ permalink raw reply
* [ANNOUNCE] Git 1.7.6.2
From: Junio C Hamano @ 2011-09-06 23:46 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
I've tagged the latest maintenance release Git 1.7.6.2 but unfortunately
the tarballs are not available at the usual places. The release can be
fetched from any of the following repositories, at the tip of 'maint'
branch.
git://repo.or.cz/alt-git.git
https://github.com/gitster/git
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
This is primarily to fix "git push --quiet" breakage in 1.7.6.1.
----------------------------------------------------------------
Changes since v1.7.6.1 are as follows:
Junio C Hamano (3):
whitespace: have SP on both sides of an assignment "="
Revert "Merge branch 'cb/maint-quiet-push' into maint"
Git 1.7.6.2
Pang Yan Han (1):
update-ref: whitespace fix
Thomas Rast (1):
Documentation: clarify effects of -- <path> arguments
^ permalink raw reply
* Re: Linux 3.1-rc5
From: Henrique de Moraes Holschuh @ 2011-09-07 1:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, Linux Kernel Mailing List, git
In-Reply-To: <4E65307F.5020103@redhat.com>
On Mon, 05 Sep 2011, Mauro Carvalho Chehab wrote:
> It would be great if "git remote update" could also verify the tag
> signature (if present), as most of us just do a "git remote update".
That helps, and it really should be all that matter for a power-end-user
that just wants to build his kernel from a git tree.
However, one can still try to trick someone to base the tree he's going to
use for a future pull request on a tree with a rogue commit, in order to
try to get the rogue commit into mainline through an indirect path, for
example.
Yeah, it is very obvious, and not a real major point of concern around
LKML: we all check the diff, log or shortlog between the tree we're
offering upstream to pull from) and the current upstream tree for any
stray commits after all (if only to avoid embarassing mistakes). And
upstream does his/her own checks before keeping the merged tree, and so
forth.
It's just that the security of the kernel source trees are not a simple
consequence of how git works: the workflow matters. I feel that point
deserves to be stressed every once in a while, however obvious it might
be.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] date.c: Parse timezone with colon as separator
From: Haitao Li @ 2011-09-07 3:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20110906202440.GD14554@sigill.intra.peff.net>
> That seems like a sensible list to support, given that it is part of
> iso8601 (though I was a little surprised after reading your subject
> line, which would probably be better as "support iso8601 timezone
> formats").
I agree this is a better one! ;)
> We should probably have new tests, too. I was going to suggest squashing
> in the ones below, but your patch doesn't seem to work with the first
> one:
>
> diff --git a/t/t0006-date.sh b/t/t0006-date.sh
> index f87abb5..9b326cd 100755
> --- a/t/t0006-date.sh
> +++ b/t/t0006-date.sh
> @@ -40,6 +40,8 @@ check_parse 2008-02 bad
> check_parse 2008-02-14 bad
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
>
> check_approxidate() {
>
> If I am reading your commit message correctly, that should work, right?
>
Yes, you are right. I will send an updated version to get this right.
Thank you for reviewing and giving suggestions!
/Haitao
^ permalink raw reply
* Re: [BUG] git-svn: --no-metadata related bug
From: Eric Wong @ 2011-09-07 3:39 UTC (permalink / raw)
To: DaveAbrahams; +Cc: git
In-Reply-To: <1315033269582-6756044.post@n2.nabble.com>
DaveAbrahams <dave@boostpro.com> wrote:
> I am reproducing the problem here. Unfortunately I can't share the
> repository with you but I'm willing to try debugging it a bit.
Which version of git/git-svn are you using? (run: "git svn --version")
Can you reproduce it with newer versions? (I can't)
--
Eric Wong
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Christian Couder @ 2011-09-07 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Joel Kaasinen, git
In-Reply-To: <7vehztaan4.fsf@alter.siamese.dyndns.org>
On Tuesday 06 September 2011 18:38:55 Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
> >> How to reproduce:
> >> $ echo foo > .git/BISECT_START
> >> $ git bisect start HEAD HEAD^
> >>
> >> Fails with "fatal: invalid reference:" on git 1.7.6.
> >
> > Yeah, it looks like a very old behavior.
> > I'd suggest a simple improvement in the error message like this:
> >
> > diff --git a/git-bisect.sh b/git-bisect.sh
> > index c21e33c..bd7155b 100755
> > --- a/git-bisect.sh
> > +++ b/git-bisect.sh
> > @@ -67,7 +67,8 @@ bisect_start() {
> >
> > then
> >
> > # Reset to the rev from where we started.
> > start_head=$(cat "$GIT_DIR/BISECT_START")
> >
> > - git checkout "$start_head" -- || exit
> > + git checkout "$start_head" -- ||
> > + die "Could not checkout previous start point
> > '$start_head'. Try 'git bisect reset <branch>' first."
>
> I do not necessarily think this is a bug to begin with --- the user had a
> bad state, and bisect stopped without doing further damage.
Yeah, in fact commit f3a186ffade15f793ea17713a10e10ec4f26ff11 (bisect: improve
error message when branch checkout fails, Sat Apr 4, 2009) already improved
the error message, but probably didn't go far enough.
> The real question is what the sensible suggestion/advice the new message
> should give. It would have to involve bisect reset in the end to get rid
> of the stale bisect state, but wouldn't the user potentially lose some
> other state if s/he blindly followed the die message's suggestion and ran
> "bisect reset"?
When using "git bisect start" with an existing $GIT_DIR/BISECT_START file, the
next thing we do after checking out the previous head from the BISECT_START
file is a call to "bisect_clean_state". So all the previous bisect state is
discarded except the previous head that is in $start_head.
If checking out the previous head fails, that probably means that the previous
head is bad because it has been deleted.
In this case running "git bisect reset <branch>" and then "git bisect start
..." is ok because there is no valuable state lost compared to the situation
where "git bisect start ..." succeeded in the first place.
Of course if checking out the previous head failed because the
$GIT_DIR/BISECT_START file has been corrupted, then it might be better to fix
the content of this file. But anyway if we are able to fix the content of the
file, for example by putting "foobar" in it instead of the truncated "foo" that
made the checkout fail, then running "git bisect reset foobar" and then "git
bisect start ..." would probably do the trick too.
It wouldn't do the trick if the $GIT_DIR/BISECT_START file also needed a
permission change or more free space on the disc or something like that. But
in this case we will get an hopefully meaningful error message when running
"git bisect reset foobar" or "git bisect start ..." and we would not lose
information.
Thanks,
Christian.
^ permalink raw reply
* The imporantance of including http credential caching in 1.7.7
From: Kyle Neath @ 2011-09-07 5:33 UTC (permalink / raw)
To: git
Earlier today, Scott Chacon alerted me to this email thread:
http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I
am not sure how to properly reference this email or reply to it since I have
not been subscribed until today).
> * jk/http-auth-keyring (2011-08-03) 13 commits
> (merged to 'next' on 2011-08-03 at b06e80e)
> + credentials: add "getpass" helper
> + credentials: add "store" helper
> + credentials: add "cache" helper
> + docs: end-user documentation for the credential subsystem
> + http: use hostname in credential description
> + allow the user to configure credential helpers
> + look for credentials in config before prompting
> + http: use credential API to get passwords
> + introduce credentials API
> + http: retry authentication failures for all http requests
> + remote-curl: don't retry auth failures with dumb protocol
> + improve httpd auth tests
> + url: decode buffers that are not NUL-terminated
>
> Looked mostly reasonable except for the limitation that it is not clear
> how to deal with a site at which a user needs to use different passwords
> for different repositories. Will keep it in "next" at least for one cycle,
> until we start hearing real-world success reports on the list.
>
> Not urgent; will not be in 1.7.7.
This is very disheartening to hear. Of all the minor changes, bugs, and
potential features, I believe that http credential caching is the absolute
most important thing that git core can do to promote adoption. I've believed
this for more than a year now and I'm incredibly disappointed that it's being
shelved for yet another release.
Over the past two years as a designer for GitHub, I've answered ~thousands of
support requests and talked face to face with ~thousands of developers of
varying git skill levels. Once a month our company does online git training
for newbies - https://github.com/training/online and I've had many discussions
about newcomer's struggles with Matthew McCullough and Scott Chacon.
Previously, I worked at ENTP where I helped polish the very popular "Git for
Designers" guide http://hoth.entp.com/output/git_for_designers.html based on
feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at
people less familiar with the command line.
I bring all of this up because I'd like to think I have a good handle on
common problems that git newcomers or people resisting git adoption run into.
I've been deeply involved in spreading git adoption full time for nearly 3
years - it's something that's incredibly important to me professionally and
personally. And the number one problem that *always* comes up is SSH key
complexity.
A lot of these problems surface themselves in people saying it's hard to setup
git on Windows. When I push these people to explain further, it turns out that
the problem is always setting up SSH key authentication on Windows, not
necessarily git.
It's incredibly frustrating that git's biggest roadblock has nothing to do
with version control at all, but rather network authentication. Just as I
believe only *you* can own your availability, I believe git should do it's
best to own authentication.
HTTP credential caching combined with Smart HTTP make git one hell of an
amazing tool for newcomers and experts alike. I like to envision a world in
which git with both these features shipped with the latest OSX install.
Developers, designers, or anyone with an inkling for code would have exactly
two steps to get started with any given git host:
1. Set your git config email / username
2. git clone https://example.com/repository
Contrast this to our current help page for OSX:
http://help.github.com/mac-set-up-git/ or worse yet, our Windows setup page
with all of it's yelling about what kind of SSH keys to setup:
http://help.github.com/win-set-up-git/
Please note that I am not arguing against the merits of SSH keys - for those
developers who understand them, they're fantastic. But the reality is the
great majority of people who interact with version control do not understand
them at all. This results in passwordless SSH keys, confusion, and
frustration.
If another git version comes and goes without http credential caching, I fear
we as a community have purposefully ignored the largest potential for git
adoption currently available. This is important enough for me that I believe
it would be in git's best interest to delay the release of 1.7.7 until this
feature has been patched to the core team's standards.
I'll summarize with a graph of my opinion of where git's potential for
adoption lies:
------------------------------------------------------------------------------
OPPORTUNITY FOR GIT ADOPTION ACCORDING TO KYLE NEATH
Caching of http credentials
|
[=====================================================================||=====]
|
Everything else in the universe
------------------------------------------------------------------------------
With hopes and butterflies,
Kyle Neath
Director of Design at GitHub
^ permalink raw reply
* [PATCH v2] date.c: Support iso8601 timezone formats
From: Haitao Li @ 2011-09-07 5:46 UTC (permalink / raw)
To: git, Jeff King; +Cc: Haitao Li
In-Reply-To: <1315320996-1997-1-git-send-email-lihaitao@gmail.com>
Timezone designators including additional separator (`:`) are ignored.
Actually zone designators in below formats are all valid according to
ISO8601:2004, section 4.3.2:
[+-]hh, [+-]hhmm, [+-]hh:mm
Steps to reproduce the issue this patch fixes:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
$ echo 'timezone' > file.txt
$ git add .
$ git update-index
$ git write-tree
3e168d57e1c32a4598af134430384f0587581503
# Commit the tree returned above. Give a date with colon separated
# timezone
$ echo "Test commit" | \
TZ=UTC GIT_AUTHOR_DATE='2011-09-03T12:34:56+08:00' \
git commit-tree 3e168d57e1c32a4598af134430384f0587581503 | \
xargs git show | grep Date
Date: Sat Sep 3 12:34:56 2011 +0000
while the expected result is:
Date: Sat Sep 3 12:34:56 2011 +0800
^---
This patch teaches git recognizing zone designators with hours and
minutes separated by colon, or minutes are empty.
Signed-off-by: Haitao Li <lihaitao@gmail.com>
---
date.c | 32 ++++++++++++++++++++++++++------
t/t0006-date.sh | 5 +++++
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/date.c b/date.c
index 896fbb4..f970ea8 100644
--- a/date.c
+++ b/date.c
@@ -556,15 +556,35 @@ static int match_tz(const char *date, int *offp)
int min, hour;
int n = end - date - 1;
- min = offset % 100;
- hour = offset / 100;
+ /*
+ * ISO8601:2004(E) allows time zone designator been separated
+ * by a clone in the extended format
+ */
+ if (*end == ':') {
+ if (isdigit(end[1])) {
+ hour = offset;
+ min = strtoul(end+1, &end, 10);
+ } else {
+ /* Mark as invalid */
+ n = -1;
+ }
+ } else {
+ /* Only hours specified */
+ if (n == 1 || n == 2) {
+ hour = offset;
+ min = 0;
+ } else {
+ hour = offset / 100;
+ min = offset % 100;
+ }
+ }
/*
- * Don't accept any random crap.. At least 3 digits, and
- * a valid minute. We might want to check that the minutes
- * are divisible by 30 or something too.
+ * Don't accept any random crap.. We might want to check that
+ * the minutes are divisible by 15 or something too. (Offset of
+ * Kathmandu, Nepal is UTC+5:45)
*/
- if (min < 60 && n > 2) {
+ if (n > 0 && min < 60 && hour < 25) {
offset = hour*60+min;
if (*date == '-')
offset = -offset;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index f87abb5..5235b7a 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -40,6 +40,11 @@ check_parse 2008-02 bad
check_parse 2008-02-14 bad
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
+check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
+check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
check_approxidate() {
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v17 1/7] bisect: move argument parsing before state modification.
From: Christian Couder @ 2011-09-07 6:16 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, j6t, jnareb, jrnieder
In-Reply-To: <1312459263-16911-2-git-send-email-jon.seymour@gmail.com>
Hi,
On Thursday 04 August 2011 14:00:57 Jon Seymour wrote:
> Currently 'git bisect start' modifies some state prior to checking
> that its arguments are valid.
>
> This change moves argument validation before state modification
> with the effect that state modification does not occur
> unless argument validations succeeds.
This thread:
http://thread.gmane.org/gmane.comp.version-control.git/180733/
made me wonder if we introduced a bug with this patch.
If we start bisecting like this:
$ git bisect start HEAD HEAD~20
and then we decide that it was not optimum and we want to start again like
this:
$ git bisect start HEAD HEAD~6
then issuing the latter command might not work as it did before this patch.
Before this patch the latter command would do a "git checkout $start_head"
before the repeated rev=$(git rev-parse -q --verify "$arg^{commit}") to
convert arguments into sha1. And after this patch the order is reversed.
This means that before this patch "HEAD" in the arguments to "git bisect
start" would refer to $start_head because the "git checkout $start_head"
changes HEAD. After this patch "HEAD" in the arguments to "git bisect start"
would refer to the current HEAD.
For example before this patch, if I issue "git bisect start HEAD HEAD~8" twice
I get:
$ git bisect start HEAD HEAD~8
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
$ git bisect start HEAD HEAD~8
Previous HEAD position was 67c116b... Merge branch 'jk/pager-with-external-
command'
Switched to branch 'master'
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
so the same commit to test is checked out.
After this patch I get:
$ git bisect start HEAD HEAD~8
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
$ git bisect start HEAD HEAD~8
Previous HEAD position was 67c116b... Merge branch 'jk/pager-with-external-
command'
Switched to branch 'master'
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[e5cfcb04e0acc5f3b51e6d69487028315b33e4c9] Merge branch 'mh/attr'
so a different commit is checked out after the second "git bisect start HEAD
HEAD~8".
Best regards,
Christian.
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Joel Kaasinen @ 2011-09-07 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vehztaan4.fsf@alter.siamese.dyndns.org>
On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@pobox.com> wrote:
> I do not necessarily think this is a bug to begin with --- the user had a
> bad state, and bisect stopped without doing further damage.
Oh, actually my git-bisect man page says:
"""
Bisect reset
After a bisect session, to clean up the bisection state and return to
the original HEAD, issue the following command:
$ git bisect reset
By default, this will return your tree to the commit that was checked
out before git bisect start. (A new git bisect start will also do that,
as it cleans up the old bisection state.)
"""
The parenthetical sentence seems to imply that a bisect start cleans
out the old state. The problem is that the cleaning fails when the
state is bad. (Try e.g. "git bisect start; git bisect start a b" where
a and b are valid refs.)
It's pretty much the same to me how this gets resolved. I'm fine with
a more verbose error message from bisect start.
–J
^ permalink raw reply
* Re: [PATCH v17 1/7] bisect: move argument parsing before state modification.
From: Junio C Hamano @ 2011-09-07 11:29 UTC (permalink / raw)
To: Christian Couder; +Cc: Jon Seymour, git, j6t, jnareb, jrnieder
In-Reply-To: <201109070816.16655.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> If we start bisecting like this:
>
> $ git bisect start HEAD HEAD~20
>
> and then we decide that it was not optimum and we want to start again like
> this:
>
> $ git bisect start HEAD HEAD~6
>
> then issuing the latter command might not work as it did before this patch.
I didn't even know the above was supposed to work. It may have worked, but
I think it was not by design but merely by accident. Besides, wouldn't it
be the same to say "git bisect good" to further limit the suspect range,
instead of giving the second, seemingly nested, "bisect start" that is not
really nesting, which only confuses the users?
Having said that, if you can resurrect the old behaviour without too much
code churn, I wouldn't mind to look at the patch, but I am not sure if it
is worth it.
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Junio C Hamano @ 2011-09-07 10:51 UTC (permalink / raw)
To: Joel Kaasinen; +Cc: Christian Couder, git
In-Reply-To: <CAC6WLetO-KKkHmPHJ64rt6+BMbhUHUtNfxF3GK4obMUAuE9XXQ@mail.gmail.com>
Joel Kaasinen <joel@zenrobotics.com> writes:
> On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@pobox.com> wrote:
>> I do not necessarily think this is a bug to begin with --- the user had a
>> bad state, and bisect stopped without doing further damage.
>
> Oh, actually my git-bisect man page says:
>
> """
> Bisect reset
> After a bisect session, to clean up the bisection state and return to
> the original HEAD, issue the following command:
>
> $ git bisect reset
>
> By default, this will return your tree to the commit that was checked
> out before git bisect start. (A new git bisect start will also do that,
> as it cleans up the old bisection state.)
> """
>
> The parenthetical sentence seems to imply that a bisect start cleans
> out the old state. The problem is that the cleaning fails when the
> state is bad. (Try e.g. "git bisect start; git bisect start a b" where
> a and b are valid refs.)
>
> It's pretty much the same to me how this gets resolved. I'm fine with
> a more verbose error message from bisect start.
I do not think anybody minds "a more verbose" message. I do mind if the
suggestion the message makes were "wrong". That is what I was questioning.
^ permalink raw reply
* Git without morning coffee
From: Michael J Gruber @ 2011-09-07 7:48 UTC (permalink / raw)
To: Git Mailing List
Is this my lack of morning coffee, or git's:
git rev-parse origin/next origin/pu
7931f38a2fd882b0f75a4d6f0eb60c3b1b094178
edf014b39ded8ee8a67f2a0cd8d7926b33f3d578
# OK
git checkout origin/next
HEAD is now at 7931f38... Merge branch 'master' into next
# OK
git log --oneline --no-walk ":/Merge branch 'jk/generation-numbers' into pu"
0ac76f9 Merge branch 'jk/generation-numbers' into pu
# Sure it is.
git merge ":/Merge branch 'jk/generation-numbers' into pu"
fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
to a commit
# Huh?
git rev-parse ":/Merge branch 'jk/generation-numbers' into pu"
0ac76f96a94a46bce7ec9dcc6c67abcf9d36adac
# It does point to a commit!
git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
error: addinfo_cache failed for path 't/t7810-grep.sh'
Performing inexact rename detection: 100% (91476/91476), done.
error: addinfo_cache failed for path 't/t7810-grep.sh'
error: addinfo_cache failed for path 'gitweb/static/gitweb.js'
error: addinfo_cache failed for path 'gitweb/static/gitweb.css'
## hundreds more
error: addinfo_cache failed for path 't/t7810-grep.sh'
error: addinfo_cache failed for path 'gitweb/static/js/blame_incremental.js'
Auto-merging cache.h
Merge made by the 'recursive' strategy.
Double Huh? Finally, the merge succeeds, despite thy myriad of errors.
I mean, I'm merging a commit from origin/pu to origin/next when the
latter is basically contained in the former (except for some merge
commits). And what are these addinfo_cache errors?
git --version
git version 1.7.7.rc0.328.g9d6c7
which is last week's next with a few additions which I've been carrying
along for weeks. Stumped.
Michael
^ permalink raw reply
* [RFC/PATCH] core.clientTimeout config for git:// fetches
From: Eric Wong @ 2011-09-07 10:15 UTC (permalink / raw)
To: git
This allows "git fetch" to exit after a preconfigured socket
timeout. This is needed in case an undetected server or network
failure occurs.
The default timeout is 60 seconds.
http:// and rsync:// transports should be supported in future
changes, too.
So far, I've only tested (by hand) with a dummy server setup
using "nc -l $some_port".
---
I run "git fetch" from cron to keep mirrors up-to-date. I've
noticed some cron processes running for hours/days at a time after
network failures. When I straced thoses processes, I saw they were
stuck on read() syscalls to remote machines.
I'm not familiar with this code and hope there's a better way to do
this. Changing wrapper.c like this in this way doesn't feel right,
but neither does sprinkling alarm() calls in various places.
Using a custom GIT_PROXY_COMMAND which implements timeouts on its own
would also work, but I'd like to eventually have a consistent parameter
unified across all remote transports for consistency and ease-of-use.
The default 60s timeout could be too low on some slow servers
with big repos, maybe the default should remain zero (no timeout).
connect.c | 27 +++++++++++++++++++++++++++
wrapper.c | 47 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index ee1d4b4..c1fa1ab 100644
--- a/connect.c
+++ b/connect.c
@@ -320,10 +320,37 @@ static int git_tcp_connect_sock(char *host, int flags)
#endif /* NO_IPV6 */
+static int timeout_setup(const char *var, const char *value, void *cb)
+{
+ int *timeout = cb;
+
+ if (strcmp(var, "core.clienttimeout") == 0)
+ *timeout = git_config_int(var, value);
+
+ return 0;
+}
static void git_tcp_connect(int fd[2], char *host, int flags)
{
int sockfd = git_tcp_connect_sock(host, flags);
+ struct timeval tv;
+ int timeout = 60;
+
+ git_config(timeout_setup, &timeout);
+
+ if (timeout > 0) {
+ socklen_t len = sizeof(struct timeval);
+
+ tv.tv_sec = timeout;
+ tv.tv_usec = 0;
+ if (setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, len) < 0)
+ die_errno("could not set socket receive timeout");
+
+ tv.tv_sec = timeout;
+ tv.tv_usec = 0;
+ if (setsockopt(sockfd, SOL_SOCKET, SO_SNDTIMEO, &tv, len) < 0)
+ die_errno("could not set socket send timeout");
+ }
fd[0] = sockfd;
fd[1] = dup(sockfd);
diff --git a/wrapper.c b/wrapper.c
index 85f09df..09a31c6 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -109,6 +109,49 @@ void *xcalloc(size_t nmemb, size_t size)
return ret;
}
+static int io_continuable(int fd, int optname)
+{
+ if (errno == EINTR)
+ return 1;
+
+ /*
+ * If fd is a socket, a socket-level timeout could've been
+ * set in git_tcp_connect(). Unfortunately EAGAIN alone
+ * isn't enough to tell us if the timeout is user-specified
+ * or not, so we have to try to figure it out.
+ */
+ if (errno == EAGAIN) {
+ socklen_t len = sizeof(struct timeval);
+ struct timeval tv;
+ int flags;
+
+ /*
+ * Let any non-blocking I/O users through. Currently
+ * git does not explicitly use non-blocking I/O anywhere,
+ * but it could inherit a non-blocking descriptor. We
+ * rely on the fact that (currently) no sockets git itself
+ * creates (and thus may set timeout on) also sets O_NONBLOCK.
+ */
+ flags = fcntl(fd, F_GETFL);
+ if (flags < 0)
+ die_errno("fcntl failed to get file status flags");
+ if (flags & O_NONBLOCK)
+ return 1;
+
+ if (getsockopt(fd, SOL_SOCKET, optname, &tv, &len) < 0) {
+ if (errno == ENOTSOCK)
+ return 1;
+ die_errno("getsockopt failed to get socket option");
+ }
+ if (tv.tv_sec > 0 || tv.tv_usec > 0)
+ die("socket timed out");
+
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* xread() is the same a read(), but it automatically restarts read()
* operations with a recoverable error (EAGAIN and EINTR). xread()
@@ -119,7 +162,7 @@ ssize_t xread(int fd, void *buf, size_t len)
ssize_t nr;
while (1) {
nr = read(fd, buf, len);
- if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
+ if (nr < 0 && io_continuable(fd, SO_RCVTIMEO))
continue;
return nr;
}
@@ -135,7 +178,7 @@ ssize_t xwrite(int fd, const void *buf, size_t len)
ssize_t nr;
while (1) {
nr = write(fd, buf, len);
- if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
+ if (nr < 0 && io_continuable(fd, SO_SNDTIMEO))
continue;
return nr;
}
--
Eric Wong
^ permalink raw reply related
* Issue fetching tags error: unable to find eb03b... ; git fsck shows no problem...
From: James Blackburn @ 2011-09-07 16:14 UTC (permalink / raw)
To: git
Hi All,
I've got an error I can't seem to resolve. Fsck reports both my
repositories are OK, but git fetch --tags tells me it can't find an
object.
bash:jamesb:xl-cbga-20:32867> git --version
git version 1.7.6
bash:jamesb:xl-cbga-20:32864> git remote add old_tags ../old_tags/
bash:jamesb:xl-cbga-20:32865> git fetch old_tags
From ../old_tags
* [new branch] master -> old_tags/master
...
bash:jamesb:xl-cbga-20:32866> git fetch --tags old_tags
remote: Counting objects: 33613, done.
remote: Compressing objects: 100% (11778/11778), done.
remote: Total 33529 (delta 18473), reused 30013 (delta 15779)
Receiving objects: 100% (33529/33529), 28.59 MiB | 8.06 MiB/s, done.
Resolving deltas: 100% (18473/18473), completed with 17 local objects.
error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
git fsck --full shows no errors in old_tags.
git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f in old_tags seems to work:
commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
Date: Tue Oct 10 09:44:47 2006 +0000
This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
git-svn-id: svn://eng-cbga-2/tools/eclipse/tags/releases/3_2_0-5@39
e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff
diff --git a/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/allclasses-frame.html
b/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/
allclasses-frame.html
...
Any ideas how to resolve this?
Cheers,
James
^ 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