* What's cooking in git.git (Feb 2012, #07; Mon, 20)
From: Junio C Hamano @ 2012-02-20 10:24 UTC (permalink / raw)
To: git; +Cc: Luke Diamand, Pete Wyckoff
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 first maintenance release v1.7.9.1 ironed out usability kinks in the
new features added in v1.7.9 release. Topics that add new features and
fixes that have been cooking in 'next' start to graduate to 'master'
again.
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
--------------------------------------------------
[Graduated to "master"]
* cb/maint-rev-list-verify-object (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at a407b9a)
+ git rev-list: fix invalid typecast
Fixes an obscure bug in "rev-list --verify" that skipped verification
depending on the phase of the moon, which dates back to 1.7.8.x series.
* cb/maint-t5541-make-server-port-portable (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at 762eefb)
+ t5541: check error message against the real port number used
Test fix.
* cb/receive-pack-keep-errors (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at 9ff846e)
+ do not override receive-pack errors
Sometimes error status detected by a check in an earlier phase of
receive-pack (the other end of 'git push') was lost by later checks,
resulting in false indication of success.
* cb/transfer-no-progress (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at ff17092)
+ push/fetch/clone --no-progress suppresses progress output
The transport programs ignored --no-progress and showed progress when
sending their output to a terminal.
* jc/diff-stat-scaler (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at 404d336)
+ diff --stat: show bars of same length for paths with same amount of changes
The output from "git diff --stat" for two paths that have the same amount
of changes showed graph bars of different length due to the way we handled
rounding errors.
* tg/tag-points-at (2012-02-13) 2 commits
(merged to 'next' on 2012-02-13 at a8f4046)
+ builtin/tag.c: Fix a sparse warning
(merged to 'next' on 2012-02-10 at 4bff88f)
+ tag: add --points-at list option
* zj/decimal-width (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at 72805c4)
+ make lineno_width() from blame reusable for others
(this branch is used by zj/diff-stat-dyncol.)
Refactoring.
* zj/term-columns (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at fe70c88)
+ pager: find out the terminal width before spawning the pager
(this branch is used by zj/diff-stat-dyncol.)
Fixes "git -p cmd" for any subcommand that cares about the true terminal
width.
--------------------------------------------------
[New Topics]
* fc/push-prune (2012-02-17) 2 commits
- remote: reorganize check_pattern_match()
- remote: use a local variable in match_push_refs()
The first two of the three-patch RFC series. The second one and the third
one (not queued) both need better explanation, and the third one also had
a handful of minor yuck factors all of which should be straightforward to
improve.
Expecting a reroll.
* jc/add-refresh-unmerged (2012-02-17) 1 commit
- refresh_index: do not show unmerged path that is outside pathspec
"git add --refresh <pathspec>" warned about unmerged paths outside the
given pathspec.
* jc/diff-ignore-case (2012-02-19) 6 commits
- diff -i
- diff: --ignore-case
- xdiff: introduce XDF_IGNORE_CASE
- xdiff: introduce XDF_INEXACT_MATCH
- xdiff: PATIENCE/HISTOGRAM are not independent option bits
- xdiff: remove XDL_PATCH_* macros
"git diff" learned "--ignore-case" option.
* jn/gitweb-hilite-regions (2012-02-19) 5 commits
- gitweb: Use esc_html_match_hl() in 'grep' search
- gitweb: Highlight matched part of shortened project description
- gitweb: Highlight matched part of project description when searching projects
- gitweb: Highlight matched part of project name when searching projects
- gitweb: Introduce esc_html_hl_regions
(this branch uses jn/gitweb-search-optim.)
Not reviewed and do not know what this is about yet ;-).
* jn/gitweb-search-optim (2012-02-19) 3 commits
- gitweb: Faster project search
- gitweb: Option for filling only specified info in fill_project_list_info
- gitweb: Refactor checking if part of project info need filling
(this branch is used by jn/gitweb-hilite-regions.)
The API introduced in the second step still has yucky design, but at least
it is more clear than the previous rounds what this is trying to do.
* js/configure-libintl (2012-02-20) 1 commit
- configure: don't use -lintl when there is no gettext support
Build fix for autoconf, meant for 'maint' track.
* pj/remote-set-branches-usage-fix (2012-02-19) 1 commit
- remote: fix set-branches usage and documentation
Documentation fix.
--------------------------------------------------
[Stalled]
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
The second one looked iffy.
* hv/submodule-recurse-push (2012-02-13) 3 commits
- push: teach --recurse-submodules the on-demand option
- Refactor submodule push check to use string list instead of integer
- Teach revision walking machinery to walk multiple times sequencially
The bottom one was not clearly explained and needs a reroll.
* zj/diff-stat-dyncol (2012-02-15) 6 commits
. diff --stat: use less columns for change counts
- (squash to the previous -- replace the last line of the log with the following)
- diff --stat: use the full terminal width
- (squash to the previous -- replace the log message with this)
- diff --stat: tests for long filenames and big change counts
- Merge branches zj/decimal-width and zj/term-columns
I am beginning to think that the last one should wait until the dust from
the earlier part settles.
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 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
- varint-in-pack: refactor varint encoding/decoding
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
dissapointed that the original patch series that was sent almost two
months 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" fanboys, 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 :-(.
* nd/columns (2012-02-08) 15 commits
. column: Fix some compiler and sparse warnings
. column: add a corner-case test to t3200
. columns: minimum coding style fixes
. tag: add --column
. column: support piping stdout to external git-column process
. status: add --column
. branch: add --column
. help: reuse print_columns() for help -a
. column: add column.ui for default column output settings
. column: support columns with different widths
. column: add columnar layout
. Stop starting pager recursively
. Add git-column and column mode parsing
. column: add API to print items in columns
. Save terminal width before setting up pager
Expecting a reroll on top of zj/term-columns topic.
--------------------------------------------------
[Cooking]
* jk/diff-highlight (2012-02-13) 5 commits
(merged to 'next' on 2012-02-20 at ba040ae)
+ diff-highlight: document some non-optimal cases
+ diff-highlight: match multi-line hunks
+ diff-highlight: refactor to prepare for multi-line hunks
+ diff-highlight: don't highlight whole lines
+ diff-highlight: make perl strict and warnings fatal
Updates diff-highlight (in contrib/).
* jn/gitweb-unborn-head (2012-02-17) 1 commit
(merged to 'next' on 2012-02-20 at 80e3ff2)
+ gitweb: Fix "heads" view when there is no current branch
"gitweb" compared non-existent value of HEAD with the names of commit
objects at tips of branches, triggering runtime warnings.
* tr/perftest (2012-02-17) 3 commits
(merged to 'next' on 2012-02-20 at 4c75ba9)
+ Add a performance test for git-grep
+ Introduce a performance testing framework
+ Move the user-facing test library to test-lib-functions.sh
* jb/required-filter (2012-02-17) 1 commit
. Add a setting to require a filter to be successful
A content filter used to be a way to make the recorded contents "more
useful", but this defines a way to optionally mark a filter "required".
A few test in t0021 use 'false' as the filter, which can exit without
reading any byte from us, before we start writing and causes us to die
with SIGPIPE, leading to intermittent test failure. I think treating this
as a failure of running the filter (the end user's filter should read what
is fed in full, produce its output and write the result back to us) is the
right thing to do, so this patch needs update the surrounding code to
handle such a situation better, probably by using sigchain_push(SIGPIPE)
or something.
* jk/config-include (2012-02-17) 10 commits
(merged to 'next' on 2012-02-20 at 7b150b7)
+ config: add include directive
+ config: eliminate config_exclusive_filename
+ config: stop using config_exclusive_filename
+ config: provide a version of git_config with more options
+ config: teach git_config_rename_section a file argument
+ config: teach git_config_set_multivar_in_file a default path
+ config: copy the return value of prefix_filename
+ t1300: add missing &&-chaining
+ docs/api-config: minor clarifications
+ docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
Reverted the earlier round from 'next' and then fixed up further.
* ld/git-p4-expanded-keywords (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at a9004c5)
+ git-p4: add initial support for RCS keywords
Teach git-p4 to unexpand $RCS$-like keywords that are embedded in
tracked contents in order to reduce unnecessary merge conflicts.
Is this ready for 'master'?
^ permalink raw reply
* Re: Manually decoding a git object
From: Thomas Rast @ 2012-02-20 10:56 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List, 徐迪
In-Reply-To: <5D290031F60941368FB1A36464201DCF@PhilipOakley>
Philip Oakley <philipoakley@iee.org> writes:
> From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20,
> 2012 8:29 AM
>>
>> The SHA1 is over the decompressed object contents. The file simply
>> holds a zlib-compressed stream of those contents. (It's pretty much
>> like gzip without the file header.)
>>
>> You can use any bindings to zlib and something that does sha1, e.g. in
>> python:
>>
>> $ cd g/.git/objects/aa/ # my git.git
>> $ ls
>> 592bda986a8380b64acd8cbb3d5bdfcbc0834d
>> 6322a757bee31919f54edcc127608a3d724c99
>> $ python
>> Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import hashlib
>> >>>
>> hashlib.sha1(open('592bda986a8380b64acd8cbb3d5bdfcbc0834d').read().decode('zlib')).digest().encode('hex')
>> 'aa592bda986a8380b64acd8cbb3d5bdfcbc0834d'
>>
>> Notice that the first byte of the hash goes into the directory name.
>>
>
> At the moment I'm in a Catch 22 situation where I can't make the first
> step of examining the deflated contents, so I can't do all those next
> steps to get the sha1 etc.. Have I misunderstood your suggestions?
Huh? The method I showed does not rely on knowing the SHA1. The fact
that I used it on a properly filed away (by its SHA1) object file is
immaterial, if perhaps confusing.
I can untangle that python expression for you:
hashlib.sha1(foo).digest() gives the SHA1 digest of the string foo, as a (binary) string
foo.encode('hex') turns foo from (binary) string into its hex representation
open('filename').read() opens the file called filename, and returns its whole contents
foo.decode('zlib') applies the zlib decompressor to foo, and returns the resulting data
So that trick works for any file[*], and you can then use its results to
file it back where it needs to go.
[*] that is sufficiently small for Python to hold it in memory, but git
shares the same problems in that department.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Manually decoding a git object
From: 徐迪 @ 2012-02-20 11:39 UTC (permalink / raw)
To: Thomas Rast; +Cc: Philip Oakley, Git List
In-Reply-To: <871uppbwnu.fsf@thomas.inf.ethz.ch>
2012/2/20 Thomas Rast <trast@inf.ethz.ch>:
> Philip Oakley <philipoakley@iee.org> writes:
>
>> From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20,
>> 2012 8:29 AM
>>>
>>> The SHA1 is over the decompressed object contents. The file simply
>>> holds a zlib-compressed stream of those contents. (It's pretty much
>>> like gzip without the file header.)
>>>
>>> You can use any bindings to zlib and something that does sha1, e.g. in
>>> python:
>>>
>>> $ cd g/.git/objects/aa/ # my git.git
>>> $ ls
>>> 592bda986a8380b64acd8cbb3d5bdfcbc0834d
>>> 6322a757bee31919f54edcc127608a3d724c99
>>> $ python
>>> Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import hashlib
>>> >>>
>>> hashlib.sha1(open('592bda986a8380b64acd8cbb3d5bdfcbc0834d').read().decode('zlib')).digest().encode('hex')
>>> 'aa592bda986a8380b64acd8cbb3d5bdfcbc0834d'
>>>
>>> Notice that the first byte of the hash goes into the directory name.
>>>
I think Thomas got the point.
> When I tried it from my home directory (not in a git directory):
> $ git cat-file -p Git-Object
> fatal: Not a git repository (or any of the parent directories): .git
this is because git will first do a git-dir-search, if you're current
work dir is not within git repo, it will die.
I really do not know how you get thing that mess. From the link[1] you
give, i think you just want to clone a repo across computer not by
network, if so this[2] will be helpful.
[1]:http://stackoverflow.com/questions/9343260/what-after-git-unpack-objects-to-get-the-actual-file
[2]:http://progit.org/2010/03/10/bundles.html
^ permalink raw reply
* Re: [PATCH] git-latexdiff: new command in contrib, to use latexdiff and Git
From: Matthieu Moy @ 2012-02-20 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Tim Haga, git
In-Reply-To: <7v4nulnac8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Carry on the discussion in a forum where you think the most people with
> appropriate skills and interests hang out, and if that forum is this list,
> that is perfectly fine. Host a development repository at GitHub, Gitorious
> or somesuch, if it would help people stay in sync with the current status
> to have a public repository.
The script is now available here:
https://gitorious.org/git-latexdiff/git-latexdiff/trees/master
In the meantime, I discovered another script doing essentially the
same : latexdiff-git
https://github.com/cawka/latexdiff/blob/master/latexdiff-git
My feeling is that the development of latexdiff is stalled (the
author's email included in the script bounces ...), and there are a few
unofficial forks, more or less stalled too.
When I have time, I may try to add the features of my script to
latexdiff-git (written in perl, while latexdiff is already in perl, so
the choice of language is probably better). But that's most likely not
going to happen soon.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2] tag: refuse tag messages that contain NULs
From: Nguyễn Thái Ngọc Duy @ 2012-02-20 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <7v39a6pkmb.fsf@alter.siamese.dyndns.org>
This follows the paranoid spirit in 37576c1 (commit_tree(): refuse
commit messages that contain NULs - 2011-12-15) and stops users from
creating tags that contain NULs. If these tags are merged into a commit
as a mergetag line, it may break the commit header processing badly.
While at it, check for NULs in mergetag and gpgsig commit headers, and
check again at write_sha1_file() as the last resort, mostly to catch
programming errors.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
2012/2/20 Junio C Hamano <gitster@pobox.com>:
>> if (verify_tag(buf.buf, buf.len) < 0)
>> die("invalid tag signature file");
>>
>> + if (memchr(buf.buf, '\0', buf.len))
>> + die("a NUL byte in tag message not allowed.");
>> +
>
> Is there a good reason why you check _after_ calling verify_tag(), instead
> of before?
[...]
>> if (sign && do_sign(buf) < 0)
>> return error(_("unable to sign the tag"));
>> + if (memchr(buf->buf, '\0', buf->len))
>> + return error("a NUL byte in tag message not allowed.");
>
> Is there a good reason why you check _after_ calling do_sign(), instead of
> before?
It's not about after those. It's about right before write_sha1_file().
I wanted to catch all NULs no matter how they come. But yes the check
should happen early to avoid wasting user's time (e.g. doing signing)
So how about this?
builtin/mktag.c | 2 ++
builtin/tag.c | 2 ++
commit.c | 2 ++
sha1_file.c | 6 ++++++
t/t7004-tag.sh | 4 ++++
t/t7510-signed-commit.sh | 2 +-
6 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/builtin/mktag.c b/builtin/mktag.c
index 640ab64..e579471 100644
--- a/builtin/mktag.c
+++ b/builtin/mktag.c
@@ -160,6 +160,8 @@ int cmd_mktag(int argc, const char **argv, const char *prefix)
die_errno("could not read from stdin");
}
+ if (memchr(buf.buf, '\0', buf.len))
+ return error("a NUL byte in tag message not allowed.");
/* Verify it for some basic sanity: it needs to start with
"object <sha1>\ntype\ntagger " */
if (verify_tag(buf.buf, buf.len) < 0)
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..3e284f7 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -257,6 +257,8 @@ static void write_tag_body(int fd, const unsigned char *sha1)
static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
{
+ if (memchr(buf->buf, '\0', buf->len))
+ return error("a NUL byte in tag message not allowed.");
if (sign && do_sign(buf) < 0)
return error(_("unable to sign the tag"));
if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
diff --git a/commit.c b/commit.c
index 4b39c19..545325f 100644
--- a/commit.c
+++ b/commit.c
@@ -1144,6 +1144,8 @@ int commit_tree_extended(const struct strbuf *msg, unsigned char *tree,
strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
while (extra) {
+ if (memchr(extra->value, '\0', extra->len))
+ return error("a NUL byte in commit header %s not allowed.", extra->key);
add_extra_header(&buffer, extra);
extra = extra->next;
}
diff --git a/sha1_file.c b/sha1_file.c
index 88f2151..2fc8623 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2519,6 +2519,12 @@ int write_sha1_file(const void *buf, unsigned long len, const char *type, unsign
char hdr[32];
int hdrlen;
+ /* GIT_HASH_NUL is for the test suite to hash abitrary content */
+ if (!getenv("GIT_HASH_NUL") &&
+ (!strcmp(type, commit_type) || !strcmp(type, tag_type)) &&
+ memchr(buf, '\0', len))
+ return error("BUG: %s message contains NUL.", type);
+
/* Normally if we have it in the pack then we do not bother writing
* it out into .git/objects/??/?{38} file.
*/
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index e93ac73..8cb13e5 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1269,4 +1269,8 @@ test_expect_success 'mixing incompatibles modes and options is forbidden' '
test_must_fail git tag -v -s
'
+test_expect_success 'tag content contains NUL' '
+ test_must_fail git tag -F "$TEST_DIRECTORY"/t3900/UTF-16.txt utf16
+'
+
test_done
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 1d3c56f..d75a349 100755
--- a/t/t7510-signed-commit.sh
+++ b/t/t7510-signed-commit.sh
@@ -63,7 +63,7 @@ test_expect_success GPG 'detect fudged signature with NUL' '
git cat-file commit master >raw &&
cat raw >forged2 &&
echo Qwik | tr "Q" "\000" >>forged2 &&
- git hash-object -w -t commit forged2 >forged2.commit &&
+ GIT_HASH_NUL=1 git hash-object -w -t commit forged2 >forged2.commit &&
git show --pretty=short --show-signature $(cat forged2.commit) >actual2 &&
grep "BAD signature from" actual2 &&
! grep "Good signature from" actual2
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH] completion: Allow dash as the first character for __git_ps1
From: Christian Hammerl @ 2012-02-20 12:17 UTC (permalink / raw)
To: git, gitster; +Cc: Christian Hammerl
If the argument for `__git_ps1` begins with a dash, `printf` tries to
interpret it as an option which results in an error message.
The problem is solved by adding '--' before the argument to tell
`printf` to not interpret the following argument as an option.
Adding '--' directly to the argument does not help because the argument
is enclosed by double quotes.
Signed-off-by: Christian Hammerl <info@christian-hammerl.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 91c7acb..61ff152 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -313,7 +313,7 @@ __git_ps1 ()
fi
local f="$w$i$s$u"
- printf "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
+ printf -- "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
fi
}
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 0/1] Make libintl in libc detection more robust
From: John Szakmeister @ 2012-02-20 13:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd399nbt2.fsf@alter.siamese.dyndns.org>
On Mon, Feb 20, 2012 at 3:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> John Szakmeister <john@szakmeister.net> writes:
>
>> This is my first time submitting a patch to git. I hope I've done
>> things correctly!
>
> Looks good, except for the subject line that would have been better to say
> something like:
>
> configure: don't use -lintl when there is no gettext support
You're right, that's much better. I'll keep your feedback in mind for
next time.
> I'll tweak the log message and queue.
Thanks Junio!
-John
^ permalink raw reply
* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Nguyen Thai Ngoc Duy @ 2012-02-20 13:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Niedier, Shawn O. Pearce, Scott Chacon
In-Reply-To: <7vlinzp67m.fsf@alter.siamese.dyndns.org>
2012/2/19 Junio C Hamano <gitster@pobox.com>:
>> - Do we assume tag/commit header in utf-8 or ascii?
>
> Author-ident is typically utf-8 already, so you cannot assume "ASCII".
I wonder if anyone puts non utf-8 strings in there, or could we
enforce utf-8 (i.e. validate and reject non utf-8 strings) and accept
encoded word syntax (rfc 2047) with the help of the new
$GIT_IDENT_ENCODING variable. The "accept ..." part can wait until
someone is hit by "utf-8 only" check and steps up.
By the same reasoning, maybe we should declare tag content is utf-8
only, until someone needs and adds "encoding" support for it.
>> +The filename may be an arbitrary nonempty string of bytes, as long as
>> +it contains no '/' or NUL character.
>
> s/, as long as it contains no/; it cannot contain any/
Pathname also cannot be "." nor "..", I suppose.
Since we also support Windows, should '\\' be banned too? ... probably
not worth it.
>> +The header must not contain NUL.
>
> I vaguely recall that you made sure neither the header nor the body
> contains NUL.
One of the purposes of this document is to note all constraints and
limitations (another one is a reference for users who want to dig deep
in git data structure without looking at the code). The problem with
handling NUL probably only exists in C Git (and maybe libgit2). I'll
turn that to "should not contain NUL".
--
Duy
^ permalink raw reply
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Jeff King @ 2012-02-20 13:56 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: git
In-Reply-To: <9cd657a3c4960a8c496515a03bbf623e.squirrel@arekh.dyndns.org>
On Mon, Feb 20, 2012 at 06:38:54AM +0100, Nicolas Mailhot wrote:
> > As a non-browser client, what should git do? We can't make sense of the
> > content at http://login.corporatenetwork, which is most likely an HTML
> > form asking for credentials (or even money, if the captive portal is
> > something like a public wireless provider). The best we can probably do
> > is die and say "apparently you need to go http://login.corporatenetwork
> > in a browser before making your request".
>
> Actually, the best would be to launch something capable of interpreting html
> forms on the url given by the error.
Doing that portably is near impossible (keep in mind that git runs on
things like antique versions of Solaris). Not to mention that git is
often running without a user present, or on a remote system connected
to the user only by ssh. So our best bet would probably be a
configuration option to tell git how to run a browser. Distributions
which ship binary packages could ship a sane default for their system.
> But short of that, that depends on how good git is at resuming work
> later. Error 511 can occur at any time, not just on initial connection
> (because credentials can expire at any time). So pausing may be better
> than dying.
It can, but I doubt it is a big problem with smart-http. We will make a
handful of quick negotiation requests at the beginning, and then the
bulk of the data will come over a single http request.
> However without going there: the portal page will usually be pretty simple, a
> standard basic auth form, can't git handle this? If simple web clients such as
> git have specific constrains on what can appear or not on this page, can you
> not define them and send them ietf-side so they can document them in a later
> rfc revision?
Git handles http basic auth. But my experience has been that captive
portals almost _never_ do basic auth. Instead, they give you an html
page with a bunch of form fields. And possibly some javascript required
to submit it. Git does not understand either of those things, and nor
should it; spawning a browser is the right thing to do there.
I don't think the IETF can or should mandate what goes on such a page.
Some portals will want login/password. Some will want billing
information. Some will even want other things (at some airports, I have
seen captive portals offer the option to take a short survey in return
for net access for a day). So it is not a matter of what git wants, but
what the captive portals want.
> The main impetus from my point of view is that captive portal/proxy auth is a
> mess, because they try to trick web clients into displaying something they are
> not prepared to and don't want to do, and this spec is replacing trick with
> explicit request, which is nice.
Yeah, and I think it is an improvement over the current state. Right now
git will properly fail with a 511 (which is what the designers
intended). I'd rather hold off on something more advanced until somebody
comes forward with a concrete case and says "hey, my network gives a 511
in this instance, and here's what would be the best thing for git to
do". Preferably with patches, of course. :)
-Peff
^ permalink raw reply
* Re: [PATCH 0/5] diff --ignore-case
From: Thomas Rast @ 2012-02-20 14:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Chris Leong
In-Reply-To: <7v8vjxnayn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Am 20.02.2012 03:16, schrieb Junio C Hamano:
>>> This teaches our "diff" machinery to optionally consider lines that are
>>> different only in upper/lower-cases to be equivalent.
>>
>> When would I want to use --ignore-case?
>
> I wouldn't myself; it was just I saw somebody asked if -G can be used to
> do case insensitive and then I realized we do not even support such in the
> diff machinery to begin with, but now this opens a way to do so by copying
> the xdl options when the pickaxe-grep codepath runs a subdiff.
I wonder which one of us misunderstood the original request ;-)
It was
} Is there any way to run diff -G with a case insensitivity flag?
and I took that to mean "I want to find addition/removal of a string
like -G does, but I don't know how it was capitalized". OTOH you
interpreted it as "I want to run -G but ignore changes in case while
diffing".
So maybe Chris can comment on what was intended?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Jeff King @ 2012-02-20 14:06 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Thomas Rast, Git Mailing List,
Nguyen Thai Ngoc Duy
In-Reply-To: <CAA01CsozANwtox06iihKBL8iii175FHAhChmNhG1B0ofGKWcEA@mail.gmail.com>
On Mon, Feb 20, 2012 at 09:25:00AM +0100, Piotr Krukowiecki wrote:
> Is the cache set? Not sure how to check it. t0090-cache-tree.sh uses
> test-dump-cache-tree and executes "read-tree HEAD" to establish the
> cache, but in my case read-tree does not make the cache dumpable (but
> it improves status performance).
>
> $ test-dump-cache-tree | wc -l
> 0
> $ git read-tree HEAD
> $ test-dump-cache-tree | wc -l
> 0
> $ echo 3 | sudo tee /proc/sys/vm/drop_caches && time git status -- .
> [...]
> real 0m1.085s
Hmm. I would think test-dump-cache-tree would do it. I don't know why
read-tree wouldn't fill it in, though.
Interestingly, on my git.git repo, I had an empty cache. Running "git
read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
that running "git checkout" empties the cache. So perhaps git could do
better about keeping the cache valid over time.
-Peff
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Thomas Rast @ 2012-02-20 14:09 UTC (permalink / raw)
To: Jeff King
Cc: Piotr Krukowiecki, Junio C Hamano, Git Mailing List,
Nguyen Thai Ngoc Duy
In-Reply-To: <20120220140653.GC5131@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Feb 20, 2012 at 09:25:00AM +0100, Piotr Krukowiecki wrote:
>
>> Is the cache set? Not sure how to check it. t0090-cache-tree.sh uses
>> test-dump-cache-tree and executes "read-tree HEAD" to establish the
>> cache, but in my case read-tree does not make the cache dumpable (but
>> it improves status performance).
>>
>> $ test-dump-cache-tree | wc -l
>> 0
>> $ git read-tree HEAD
>> $ test-dump-cache-tree | wc -l
>> 0
>> $ echo 3 | sudo tee /proc/sys/vm/drop_caches && time git status -- .
>> [...]
>> real 0m1.085s
>
> Hmm. I would think test-dump-cache-tree would do it. I don't know why
> read-tree wouldn't fill it in, though.
>
> Interestingly, on my git.git repo, I had an empty cache. Running "git
> read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
> that running "git checkout" empties the cache. So perhaps git could do
> better about keeping the cache valid over time.
test_expect_failure 'checkout gives cache-tree' '
git checkout HEAD^ &&
test_shallow_cache_tree
'
;-)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Nguyen Thai Ngoc Duy @ 2012-02-20 14:16 UTC (permalink / raw)
To: Jeff King
Cc: Piotr Krukowiecki, Junio C Hamano, Thomas Rast, Git Mailing List
In-Reply-To: <20120220140653.GC5131@sigill.intra.peff.net>
On Mon, Feb 20, 2012 at 9:06 PM, Jeff King <peff@peff.net> wrote:
> Interestingly, on my git.git repo, I had an empty cache. Running "git
> read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
> that running "git checkout" empties the cache. So perhaps git could do
> better about keeping the cache valid over time.
For fast forward case when result index matches 100% destination tree,
yeah we should repopulate cache-tree. "git reset" does that. Not sure
about other cases though. I don't think we can keep track what
subtrees are unchanged after unpack_trees() in order to keep them.
--
Duy
^ permalink raw reply
* [PATCH] git-svn.perl: fix a false-positive in the "already exists" test
From: Steven Walter @ 2012-02-20 14:17 UTC (permalink / raw)
To: normalperson, gitster, git; +Cc: Steven Walter
In-Reply-To: <20120219105442.GA11889@dcvr.yhbt.net>
open_or_add_dir checks to see if the directory already exists or not.
If it already exists and is not a directory, then we fail. However,
open_or_add_dir did not previously account for the possibility that the
path did exist as a file, but is deleted in the current commit.
In order to prevent this legitimate case from failing, open_or_add_dir
needs to know what files are deleted in the current commit.
Unfortunately that information has to be plumbed through a couple of
layers.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 43 ++++++++++++++++++++++++++-----------------
t/t9100-git-svn-basic.sh | 33 ++++++++++++++++++---------------
2 files changed, 44 insertions(+), 32 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 06c9322..c7a961d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5130,7 +5130,7 @@ sub rmdirs {
}
sub open_or_add_dir {
- my ($self, $full_path, $baton) = @_;
+ my ($self, $full_path, $baton, $deletions) = @_;
my $t = $self->{types}->{$full_path};
if (!defined $t) {
die "$full_path not known in r$self->{r} or we have a bug!\n";
@@ -5139,7 +5139,7 @@ sub open_or_add_dir {
no warnings 'once';
# SVN::Node::none and SVN::Node::file are used only once,
# so we're shutting up Perl's warnings about them.
- if ($t == $SVN::Node::none) {
+ if ($t == $SVN::Node::none || defined($deletions->{$full_path})) {
return $self->add_directory($full_path, $baton,
undef, -1, $self->{pool});
} elsif ($t == $SVN::Node::dir) {
@@ -5154,17 +5154,18 @@ sub open_or_add_dir {
}
sub ensure_path {
- my ($self, $path) = @_;
+ my ($self, $path, $deletions) = @_;
my $bat = $self->{bat};
my $repo_path = $self->repo_path($path);
return $bat->{''} unless (length $repo_path);
+
my @p = split m#/+#, $repo_path;
my $c = shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''}, $deletions);
while (@p) {
my $c0 = $c;
$c .= '/' . shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0}, $deletions);
}
return $bat->{$c};
}
@@ -5221,9 +5222,9 @@ sub apply_autoprops {
}
sub A {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
@@ -5233,9 +5234,9 @@ sub A {
}
sub C {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5252,9 +5253,9 @@ sub delete_entry {
}
sub R {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5263,14 +5264,14 @@ sub R {
$self->close_file($fbat,undef,$self->{pool});
($dir, $file) = split_path($m->{file_a});
- $pbat = $self->ensure_path($dir);
+ $pbat = $self->ensure_path($dir, $deletions);
$self->delete_entry($m->{file_a}, $pbat);
}
sub M {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
@@ -5340,9 +5341,9 @@ sub chg_file {
}
sub D {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
print "\tD\t$m->{file_b}\n" unless $::_q;
$self->delete_entry($m->{file_b}, $pbat);
}
@@ -5375,10 +5376,18 @@ sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
my %o = ( D => 0, C => 1, R => 2, A => 3, M => 4, T => 5 );
+ my %deletions;
+
+ foreach my $m (@$mods) {
+ if ($m->{chg} eq "D") {
+ $deletions{$m->{file_b}} = 1;
+ }
+ }
+
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
- $self->$f($m);
+ $self->$f($m, \%deletions);
} else {
fatal("Invalid change type: $f");
}
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index b041516..4029f84 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -92,9 +92,11 @@ test_expect_success "$name" '
echo yyy > bar/zzz/yyy &&
git update-index --add bar/zzz/yyy &&
git commit -m "$name" &&
- test_must_fail git svn set-tree --find-copies-harder --rmdir \
- ${remotes_git_svn}..mybranch3' || true
-
+ git svn set-tree --find-copies-harder --rmdir \
+ ${remotes_git_svn}..mybranch3 &&
+ svn_cmd up "$SVN_TREE" &&
+ test -d "$SVN_TREE"/bar/zzz &&
+ test -e "$SVN_TREE"/bar/zzz/yyy ' || true
name='detect node change from directory to file #2'
test_expect_success "$name" '
@@ -134,10 +136,10 @@ test_expect_success "$name" '
test -x "$SVN_TREE"/exec.sh'
-name='executable file becomes a symlink to bar/zzz (file)'
+name='executable file becomes a symlink to file'
test_expect_success "$name" '
rm exec.sh &&
- ln -s bar/zzz exec.sh &&
+ ln -s file exec.sh &&
git update-index exec.sh &&
git commit -m "$name" &&
git svn set-tree --find-copies-harder --rmdir \
@@ -148,14 +150,14 @@ test_expect_success "$name" '
name='new symlink is added to a file that was also just made executable'
test_expect_success "$name" '
- chmod +x bar/zzz &&
- ln -s bar/zzz exec-2.sh &&
- git update-index --add bar/zzz exec-2.sh &&
+ chmod +x file &&
+ ln -s file exec-2.sh &&
+ git update-index --add file exec-2.sh &&
git commit -m "$name" &&
git svn set-tree --find-copies-harder --rmdir \
${remotes_git_svn}..mybranch5 &&
svn_cmd up "$SVN_TREE" &&
- test -x "$SVN_TREE"/bar/zzz &&
+ test -x "$SVN_TREE"/file &&
test -h "$SVN_TREE"/exec-2.sh'
name='modify a symlink to become a file'
@@ -195,14 +197,15 @@ name='check imported tree checksums expected tree checksums'
rm -f expected
if test_have_prereq UTF8
then
- echo tree bf522353586b1b883488f2bc73dab0d9f774b9a9 > expected
+ echo tree dc68b14b733e4ec85b04ab6f712340edc5dc936e > expected
fi
cat >> expected <<\EOF
-tree 83654bb36f019ae4fe77a0171f81075972087624
-tree 031b8d557afc6fea52894eaebb45bec52f1ba6d1
-tree 0b094cbff17168f24c302e297f55bfac65eb8bd3
-tree d667270a1f7b109f5eb3aaea21ede14b56bfdd6e
-tree 56a30b966619b863674f5978696f4a3594f2fca9
+tree c3322890dcf74901f32d216f05c5044f670ce632
+tree d3ccd5035feafd17b030c5732e7808cc49122853
+tree d03e1630363d4881e68929d532746b20b0986b83
+tree 149d63cd5878155c846e8c55d7d8487de283f89e
+tree 312b76e4f64ce14893aeac8591eb3960b065e247
+tree 149d63cd5878155c846e8c55d7d8487de283f89e
tree d667270a1f7b109f5eb3aaea21ede14b56bfdd6e
tree 8f51f74cf0163afc9ad68a4b1537288c4558b5a4
EOF
--
1.7.3.4
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Jeff King @ 2012-02-20 14:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Piotr Krukowiecki, Junio C Hamano, Thomas Rast, Git Mailing List
In-Reply-To: <CACsJy8AHEHDAa2v4DvNgwd1YsBQuRCL9bHaxF70L8O4yWc4gZg@mail.gmail.com>
On Mon, Feb 20, 2012 at 09:16:43PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Mon, Feb 20, 2012 at 9:06 PM, Jeff King <peff@peff.net> wrote:
> > Interestingly, on my git.git repo, I had an empty cache. Running "git
> > read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
> > that running "git checkout" empties the cache. So perhaps git could do
> > better about keeping the cache valid over time.
>
> For fast forward case when result index matches 100% destination tree,
> yeah we should repopulate cache-tree. "git reset" does that. Not sure
> about other cases though. I don't think we can keep track what
> subtrees are unchanged after unpack_trees() in order to keep them.
Yeah, doing it after unpack_trees seems crazy. But I really feel like
unpack_trees should be able to handle cache updates as it unpacks. It
knows what is being updated and what is being merged. But maybe it is
more complicated than that; I haven't looked at the code yet.
-Peff
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Nguyen Thai Ngoc Duy @ 2012-02-20 14:36 UTC (permalink / raw)
To: Thomas Rast
Cc: Jeff King, Piotr Krukowiecki, Junio C Hamano, Git Mailing List
In-Reply-To: <87ty2l38ay.fsf@thomas.inf.ethz.ch>
On Mon, Feb 20, 2012 at 03:09:57PM +0100, Thomas Rast wrote:
> > Interestingly, on my git.git repo, I had an empty cache. Running "git
> > read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
> > that running "git checkout" empties the cache. So perhaps git could do
> > better about keeping the cache valid over time.
>
> test_expect_failure 'checkout gives cache-tree' '
> git checkout HEAD^ &&
> test_shallow_cache_tree
> '
>
> ;-)
Quick and dirty that passes that test. I think we could do better if
we analyse two way merge rules carefully and avoid this diff, but
that's too much for me right now.
-- 8< --
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5bf96ba..c06287a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -319,6 +319,10 @@ static void show_local_changes(struct object *head, struct diff_options *opts)
die(_("diff_setup_done failed"));
add_pending_object(&rev, head, NULL);
run_diff_index(&rev, 0);
+ if (!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES)) {
+ struct tree *tree = parse_tree_indirect(head->sha1);
+ prime_cache_tree(&active_cache_tree, tree);
+ }
}
static void describe_detached_head(const char *msg, struct commit *commit)
@@ -493,13 +497,13 @@ static int merge_working_tree(struct checkout_opts *opts,
}
}
+ if (!opts->force && !opts->quiet)
+ show_local_changes(&new->commit->object, &opts->diff_options);
+
if (write_cache(newfd, active_cache, active_nr) ||
commit_locked_index(lock_file))
die(_("unable to write new index file"));
- if (!opts->force && !opts->quiet)
- show_local_changes(&new->commit->object, &opts->diff_options);
-
return 0;
}
-- 8< --
--
Duy
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Jeff King @ 2012-02-20 14:39 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Thomas Rast, Piotr Krukowiecki, Junio C Hamano, Git Mailing List
In-Reply-To: <20120220143644.GA13938@do>
On Mon, Feb 20, 2012 at 09:36:44PM +0700, Nguyen Thai Ngoc Duy wrote:
> > test_expect_failure 'checkout gives cache-tree' '
> > git checkout HEAD^ &&
> > test_shallow_cache_tree
> > '
> >
> > ;-)
>
> Quick and dirty that passes that test. I think we could do better if
> we analyse two way merge rules carefully and avoid this diff, but
> that's too much for me right now.
Unpack trees is already sprinkled with cache_tree_invalidate_path. But
something seems to throw away the cache tree entirely (I think it may be
that the extension simply isn't copied over to the destination index).
I'm walking through it right now.
-Peff
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Jeff King @ 2012-02-20 15:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Thomas Rast, Piotr Krukowiecki, Junio C Hamano, Git Mailing List
In-Reply-To: <20120220143952.GA8387@sigill.intra.peff.net>
On Mon, Feb 20, 2012 at 09:39:52AM -0500, Jeff King wrote:
> On Mon, Feb 20, 2012 at 09:36:44PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > > test_expect_failure 'checkout gives cache-tree' '
> > > git checkout HEAD^ &&
> > > test_shallow_cache_tree
> > > '
> > >
> > > ;-)
> >
> > Quick and dirty that passes that test. I think we could do better if
> > we analyse two way merge rules carefully and avoid this diff, but
> > that's too much for me right now.
>
> Unpack trees is already sprinkled with cache_tree_invalidate_path. But
> something seems to throw away the cache tree entirely (I think it may be
> that the extension simply isn't copied over to the destination index).
> I'm walking through it right now.
Hmm. OK, this doesn't pass the test, but I think it is better than the
current behavior.
Basically, what happens now with "git checkout" is this:
1. read_cache pulls the cache_tree from disk into the_index
2. we call unpack_trees with o->src_index == o->dst_index ==
&the_index.
3. during tree traversal, unpack_trees callbacks properly calls
cache_tree_invalidate_path whenever it updates a path. We write the
results into o->result.
4. At the end of unpack_trees, we forget about src_index, and copy
o->result into *o->dst_index byte for byte. I.e., we overwrite
the_index.cache_tree, which has been properly updated the whole
time, with NULL, dropping it entirely (in fact, I believe it even
creates a memory leak of the old cache_tree).
This one-liner improves that a bit:
diff --git a/unpack-trees.c b/unpack-trees.c
index 8be3f6c..e8aedea 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1135,6 +1135,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
}
}
+ o->result.cache_tree = o->src_index->cache_tree;
o->src_index = NULL;
ret = check_updates(o) ? (-2) : 0;
if (o->dst_index)
by copying the cache_tree (which has been updated all along) from
src_index into the result (which will then make it into the
destination index, which of course in this case is the same as the
source index, anyway).
It makes "git checkout" with no changes just work (since we preserve the
cache tree, and it doesn't need updated). It makes something like "git
checkout HEAD^" work, keeping most of the cache-tree intact, but
invalidating trees containing paths that were modified.
But it does not actually insert the _destination_ tree into the cache
tree. Which we can do in certain situations, but only if there were no
paths in the tree that were left unchanged (e.g., you modify "foo", then
"git checkout HEAD^", which updates "bar". Your tree does not match
HEAD^, and must be invalidated). While it would be cool to be able to
handle those complex cases, making this one simple change covers most of
the cases people care about (i.e., leaving the cache-tree intact for all
of the directories that weren't touched at all).
I think this implementation matches the intent of the original calls to
cache_tree_invalidate_path sprinkled throughout unpack-trees.c. But I
have to say that it seems a little odd for us to be modifying the
o->src_index throughout the whole thing. I would think the right thing
would be to make a deep copy of o->src_index->cache_tree into
o->result.cache_tree as the very first thing, and then update
o->result.cache_tree throughout the tree traversal. There is no point in
invalidating src_index's cache_tree, since it is not receiving the
updates.
In practice, this doesn't tend to matter because everybody just sets src
and dst to &the_index anyway. The one exception seems to be diff_cache,
which sets dst_index to NULL. But it doesn't matter there, because we
are only using oneway_diff as our callback, which does not actually
write or invalidate anything in the cache.
-Peff
^ permalink raw reply related
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Nicolas Mailhot @ 2012-02-20 15:34 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Mailhot, git
In-Reply-To: <20120220135639.GA5131@sigill.intra.peff.net>
Le Lun 20 février 2012 14:56, Jeff King a écrit :
> On Mon, Feb 20, 2012 at 06:38:54AM +0100, Nicolas Mailhot wrote:
>
>> > As a non-browser client, what should git do? We can't make sense of the
>> > content at http://login.corporatenetwork, which is most likely an HTML
>> > form asking for credentials (or even money, if the captive portal is
>> > something like a public wireless provider). The best we can probably do
>> > is die and say "apparently you need to go http://login.corporatenetwork
>> > in a browser before making your request".
>>
>> Actually, the best would be to launch something capable of interpreting html
>> forms on the url given by the error.
>
> Doing that portably is near impossible (keep in mind that git runs on
> things like antique versions of Solaris).
Can't the you let the user specify a browser command (firefox, elinks w3m) to
auto-feed the portal page to when needed ?
The main problem with captive portals is when they shut down the connection
and the user has no idea how to restore it (and error 511 is intended to fix
this, but that won't do a lot of good if the user does is not shown the
captive portal url transmitted with the error)
Regards,
--
Nicolas Mailhot
^ permalink raw reply
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Jeff King @ 2012-02-20 15:44 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: git
In-Reply-To: <e1d3ddd965eb32717163aaa87fa71e17.squirrel@arekh.dyndns.org>
On Mon, Feb 20, 2012 at 04:34:19PM +0100, Nicolas Mailhot wrote:
> >> Actually, the best would be to launch something capable of interpreting html
> >> forms on the url given by the error.
> >
> > Doing that portably is near impossible (keep in mind that git runs on
> > things like antique versions of Solaris).
>
> Can't the you let the user specify a browser command (firefox, elinks w3m) to
> auto-feed the portal page to when needed ?
Yes, that's why I said "we could add a configuration option" in the part
that you snipped. But doing it out of the box is not going to be
portable.
> The main problem with captive portals is when they shut down the connection
> and the user has no idea how to restore it (and error 511 is intended to fix
> this, but that won't do a lot of good if the user does is not shown the
> captive portal url transmitted with the error)
In my experience, the captive portal process usually goes like this:
1. Connect to network.
2. Try some non-browser command. Wonder why in the world it isn't
working.
3. Open a browser and say "Ah, I see. A captive portal".
The 511 proposal makes step 2 a lot better if the protocol is http[1].
But it pretty much makes it better even without non-browser client
support, because at least you will get a 511 error instead of having git
complain that the remote repository is corrupted (which happens if the
captive portal returns a redirect to an html page).
We should already be doing that. Adding more support could make step 3 a
little nicer, but like I said, I'd be more interested in seeing a real
case first. It may even be a feature that would be more appropriate to
curl (which git builds on for http access).
-Peff
[1] Of course it doesn't help at all for git:// or ssh:// (which are
usually even worse off in the first place, as many captive portals
will simply drop the packets, making it look like the remote server
is down).
^ permalink raw reply
* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Jeff King @ 2012-02-20 16:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, git, Jonathan Niedier, Shawn O. Pearce,
Scott Chacon
In-Reply-To: <CACsJy8CEeZPf55idLB9NE-rf--ySmZh_9gkMc_zo0VmiVftMUg@mail.gmail.com>
On Mon, Feb 20, 2012 at 08:55:28PM +0700, Nguyen Thai Ngoc Duy wrote:
> > Author-ident is typically utf-8 already, so you cannot assume "ASCII".
>
> I wonder if anyone puts non utf-8 strings in there, or could we
> enforce utf-8 (i.e. validate and reject non utf-8 strings) and accept
> encoded word syntax (rfc 2047) with the help of the new
> $GIT_IDENT_ENCODING variable. The "accept ..." part can wait until
> someone is hit by "utf-8 only" check and steps up.
I was just having a similar discussion with libgit2 folks, who were
wondering if there would ever be non-utf8 in there. When we call
"reencode_commit_message", it looks like we do the whole object. In
other words, your author name _must_ match any encoding you specify in
the "encoding" header.
I.e., if you do:
# latin1 é
e=`printf '\xe9'`
export GIT_AUTHOR_NAME="P${e}ff King"
git init
git config i18n.commitencoding iso8859-1
touch foo && git add foo &&
git commit --allow-empty -m "more latin1 ${e}ncoding"
both the name and the message should show fine on your utf8 terminal if
you do this:
git config i18n.logoutputencoding utf8
git show
And similarly, we do the right thing in format-patch, both with and
without logoutputencoding set:
$ git format-patch --root --stdout | grep -Ei "^(from|subject):"
From: =?iso8859-1?q?P=E9ff=20King?= <peff@peff.net>
Subject: [PATCH] =?iso8859-1?q?more=20latin1=20=E9ncoding?=
$ git config i18n.logoutputencoding utf8
$ git format-patch --root --stdout | grep -Ei "^(from|subject):"
From: =?utf8?q?P=C3=A9ff=20King?= <peff@peff.net>
Subject: [PATCH] =?utf8?q?more=20latin1=20=C3=A9ncoding?=
(where 0xc3a9 is the utf8 equivalent of latin1 0xe9).
So I have no idea if people are using it or not, but it is actually
usable.
-Peff
^ permalink raw reply
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Nicolas Mailhot @ 2012-02-20 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Mailhot, git
In-Reply-To: <20120220154452.GA27456@sigill.intra.peff.net>
Le Lun 20 février 2012 16:44, Jeff King a écrit :
> In my experience, the captive portal process usually goes like this:
>
> 1. Connect to network.
>
> 2. Try some non-browser command. Wonder why in the world it isn't
> working.
>
> 3. Open a browser and say "Ah, I see. A captive portal".
>
> The 511 proposal makes step 2 a lot better if the protocol is http[1].
> But it pretty much makes it better even without non-browser client
> support, because at least you will get a 511 error instead of having git
> complain that the remote repository is corrupted (which happens if the
> captive portal returns a redirect to an html page).
>
> We should already be doing that. Adding more support could make step 3 a
> little nicer, but like I said, I'd be more interested in seeing a real
> case first. It may even be a feature that would be more appropriate to
> curl (which git builds on for http access).
Step 3 is a quite less obvious on a corporate network, where Internet access
is gated by a filtering proxy, that will let some sites pass transparently but
require credentials to let you access others. Worst case, there are several
load-balanced gateways on different physical sites (to avoid spofs in case of
planes falling on the wrong place), that do not share authentication (because
propagating auth across physical sites is hard). So no, just launching a
browser is not sufficient to find the captive portal, you need to actually
access the URL returned by error 511 in meta information. Git should at
minimum report this URL.
(and no this is not an hypothetical scenario and yes there are git users
trying to pass the gateways there)
--
Nicolas Mailhot
^ permalink raw reply
* Re: Manually decoding a git object
From: Philip Oakley @ 2012-02-20 18:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List, 徐迪
In-Reply-To: <871uppbwnu.fsf@thomas.inf.ethz.ch>
From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20, 2012
10:56 AM
> Philip Oakley <philipoakley@iee.org> writes:
>
>> From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20,
>> 2012 8:29 AM
>>>
>>> The SHA1 is over the decompressed object contents. The file simply
>>> holds a zlib-compressed stream of those contents. (It's pretty much
>>> like gzip without the file header.)
>>>
>>> You can use any bindings to zlib and something that does sha1, e.g. in
>>> python:
>>>
>>> $ cd g/.git/objects/aa/ # my git.git
>>> $ ls
>>> 592bda986a8380b64acd8cbb3d5bdfcbc0834d
>>> 6322a757bee31919f54edcc127608a3d724c99
>>> $ python
>>> Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import hashlib
>>> >>>
>>> hashlib.sha1(open('592bda986a8380b64acd8cbb3d5bdfcbc0834d').read().decode('zlib')).digest().encode('hex')
>>> 'aa592bda986a8380b64acd8cbb3d5bdfcbc0834d'
>>>
>>> Notice that the first byte of the hash goes into the directory name.
>>>
>>
>> At the moment I'm in a Catch 22 situation where I can't make the first
>> step of examining the deflated contents, so I can't do all those next
>> steps to get the sha1 etc.. Have I misunderstood your suggestions?
>
> Huh? The method I showed does not rely on knowing the SHA1. The fact
> that I used it on a properly filed away (by its SHA1) object file is
> immaterial, if perhaps confusing.
>
> I can untangle that python expression for you:
>
> hashlib.sha1(foo).digest() gives the SHA1 digest of the string foo,
> as a (binary) string
> foo.encode('hex') turns foo from (binary) string into its
> hex representation
> open('filename').read() opens the file called filename, and
> returns its whole contents
> foo.decode('zlib') applies the zlib decompressor to foo, and
> returns the resulting data
>
> So that trick works for any file[*], and you can then use its results to
> file it back where it needs to go.
>
>
> [*] that is sufficiently small for Python to hold it in memory, but git
> shares the same problems in that department.
>
I see what you mean now. I'll need to work out how to get Python in
msysgit - the 'minimal' part of msys keeps on biting... That is, I didn't
see it (Python) in the 1.7.8 full install bash - I didn't see it anyway.
I was hopeful that unzip/gunzip would have an option to simply deflate a
(file)stream, rather than it expecting the normal file archive.
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Thomas Rast @ 2012-02-20 18:45 UTC (permalink / raw)
To: Jeff King
Cc: Nguyen Thai Ngoc Duy, Piotr Krukowiecki, Junio C Hamano,
Git Mailing List
In-Reply-To: <20120220151134.GA13135@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 8be3f6c..e8aedea 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1135,6 +1135,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
> }
> }
>
> + o->result.cache_tree = o->src_index->cache_tree;
> o->src_index = NULL;
> ret = check_updates(o) ? (-2) : 0;
> if (o->dst_index)
Brilliant. I know I'm stealing Junio's punchline, but please make it so
:-)
Browsing around in history, it seems that this was silently broken by
34110cd (Make 'unpack_trees()' have a separate source and destination
index, 2008-03-06), which introduced the distinction between source and
destination index. Before that they were the same, so the cache tree
would have been updated correctly.
> It makes "git checkout" with no changes just work (since we preserve the
> cache tree, and it doesn't need updated). It makes something like "git
> checkout HEAD^" work, keeping most of the cache-tree intact, but
> invalidating trees containing paths that were modified.
Great. Here's a test you could use. It's a bit noisy because the
shallow in test_shallow_cache_tree no longer made any sense, but I think
it tests what we want to see.
diff --git i/t/t0090-cache-tree.sh w/t/t0090-cache-tree.sh
index 6c33e28..5706305 100755
--- i/t/t0090-cache-tree.sh
+++ w/t/t0090-cache-tree.sh
@@ -16,14 +16,16 @@ cmp_cache_tree () {
# We don't bother with actually checking the SHA1:
# test-dump-cache-tree already verifies that all existing data is
# correct.
-test_shallow_cache_tree () {
- printf "SHA (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >expect &&
+test_cache_tree () {
+ printf "SHA (%d entries, 1 subtrees)\n" $(git ls-files|wc -l) >expect &&
+ printf "SHA sub/ (%d entries, 0 subtrees)\n" $(git ls-files sub|wc -l) >>expect &&
cmp_cache_tree expect
}
test_invalid_cache_tree () {
- echo "invalid (0 subtrees)" >expect &&
- printf "SHA #(ref) (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >>expect &&
+ echo "invalid (1 subtrees)" >expect &&
+ printf "SHA #(ref) (%d entries, 1 subtrees)\n" $(git ls-files|wc -l) >>expect &&
+ printf "SHA sub/ (%d entries, 0 subtrees)\n" $(git ls-files sub|wc -l) >>expect &&
cmp_cache_tree expect
}
@@ -33,13 +35,16 @@ test_no_cache_tree () {
}
test_expect_failure 'initial commit has cache-tree' '
+ mkdir sub &&
+ echo bar > sub/bar &&
+ git add sub/bar &&
test_commit foo &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_expect_success 'read-tree HEAD establishes cache-tree' '
git read-tree HEAD &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_expect_success 'git-add invalidates cache-tree' '
@@ -59,7 +64,7 @@ test_expect_success 'update-index invalidates cache-tree' '
test_expect_success 'write-tree establishes cache-tree' '
test-scrap-cache-tree &&
git write-tree &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_expect_success 'test-scrap-cache-tree works' '
@@ -70,24 +75,39 @@ test_expect_success 'test-scrap-cache-tree works' '
test_expect_success 'second commit has cache-tree' '
test_commit bar &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_expect_success 'reset --hard gives cache-tree' '
test-scrap-cache-tree &&
git reset --hard &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_expect_success 'reset --hard without index gives cache-tree' '
rm -f .git/index &&
git reset --hard &&
- test_shallow_cache_tree
+ test_cache_tree
'
-test_expect_failure 'checkout gives cache-tree' '
+test_expect_success 'checkout HEAD leaves cache-tree intact' '
+ git read-tree HEAD &&
+ git checkout HEAD &&
+ test_cache_tree
+'
+
+# NEEDSWORK: only one of these two can succeed. The second is there
+# because it would be the better result.
+test_expect_success 'checkout HEAD^ correctly invalidates cache-tree' '
+ git checkout HEAD^ &&
+ test_invalid_cache_tree
+'
+
+test_expect_failure 'checkout HEAD^ gives full cache-tree' '
+ git checkout master &&
+ git read-tree HEAD &&
git checkout HEAD^ &&
- test_shallow_cache_tree
+ test_cache_tree
'
test_done
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Jeff King @ 2012-02-20 19:09 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Nicolas Mailhot, git
In-Reply-To: <alpine.DEB.2.00.1202202002330.28090@tvnag.unkk.fr>
On Mon, Feb 20, 2012 at 08:06:46PM +0100, Daniel Stenberg wrote:
> > 3. Open a browser and say "Ah, I see. A captive portal".
> >
> >We should already be doing that. Adding more support could make
> >step 3 a little nicer, but like I said, I'd be more interested in
> >seeing a real case first. It may even be a feature that would be
> >more appropriate to curl (which git builds on for http access).
>
> We're already discussing the 511 in the curl camp as well, but with
> even more sighs and hands in the air. 511 is clearly intended for
> HTML-understanding user agents and curl is not one of those. IMHO,
> curl will remain to simply help users to figure out that it is 511
> and leave it at that.
Thanks for the input. It sounds like our best bet is to just report the
URL from a 511 better, then. Do you have any idea yet how that
information will be available to curl library users?
> As a git user, I would probably be very surprised if using 'git'
> suddenly caused by browser to pop up a captive portal login. I would
> prefer git to instead properly explain to me that is being the victim
> of a 511 and what I should do to fix it.
I agree. Even if the "step 3" in my list is "then the user starts a
browser given the URL from git's error message", that is a huge
improvement over the current state. And it retains the principle of
least surprise.
-Peff
^ 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