* [PATCH 6/5] diff -i
From: Junio C Hamano @ 2012-02-20 7:36 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
The previous patch to teach "--ignore-case" option to our "diff" machinery
deliberately omitted a short-and-sweet "-i" that GNU diff uses to ask for
"--ignore-case". This is because our diff machinery are often used by and
shares the command line options with the commands in the "git log" family,
where the short option already means something entirely different. Namely,
it instructs to use case-insensitive match when looking for commits that
match information that appear in the commit object itself, e.g. --author
and --grep.
Tweak the option parser so that "-i" means both, so that
$ git log --grep=frotz -i -p
first picks commits that have string "frotz" in any combination of cases,
and then shows patches that ignore case-only changes for the chosen
commits, while "--ignore-case" and "--regexp-ignore-case" can be used to
mean only one, i.e.
$ git log --grep=frotz --regexp-ignore-case -p
would pick the same set of commits, but the patches shown by it does not
ignore case-only changes while
$ git log --grep=frotz --ignore-case -p
would pick commits that has "frotz" in all lowercase, but shows patches
that ignore case-only changes for the chosen commits.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-options.txt | 1 +
diff.c | 2 +-
revision.c | 6 +++++-
t/lib-diff-alternative.sh | 3 ++-
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 791e07f..9ed78c9 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -404,6 +404,7 @@ endif::git-format-patch[]
differences even if one line has whitespace where the other
line has none.
+-i::
--ignore-case::
Ignore changes in case only; only ASCII alphabet is supported for
now.
diff --git a/diff.c b/diff.c
index d7604b7..9d1584e 100644
--- a/diff.c
+++ b/diff.c
@@ -3399,7 +3399,7 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE);
else if (!strcmp(arg, "--ignore-space-at-eol"))
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
- else if (!strcmp(arg, "--ignore-case"))
+ else if (!strcmp(arg, "--ignore-case") || !strcmp(arg, "-i"))
DIFF_XDL_SET(options, IGNORE_CASE);
else if (!strcmp(arg, "--patience"))
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
diff --git a/revision.c b/revision.c
index 8764dde..f1a1354 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "xdiff-interface.h"
volatile show_early_output_fn_t show_early_output;
@@ -1557,7 +1558,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
return argcount;
} else if (!strcmp(arg, "--extended-regexp") || !strcmp(arg, "-E")) {
revs->grep_filter.regflags |= REG_EXTENDED;
- } else if (!strcmp(arg, "--regexp-ignore-case") || !strcmp(arg, "-i")) {
+ } else if (!strcmp(arg, "-i")) {
+ DIFF_XDL_SET(&revs->diffopt, IGNORE_CASE);
+ revs->grep_filter.regflags |= REG_ICASE;
+ } else if (!strcmp(arg, "--regexp-ignore-case")) {
revs->grep_filter.regflags |= REG_ICASE;
} else if (!strcmp(arg, "--fixed-strings") || !strcmp(arg, "-F")) {
revs->grep_filter.fixed = 1;
diff --git a/t/lib-diff-alternative.sh b/t/lib-diff-alternative.sh
index 45c665e..81609f8 100644
--- a/t/lib-diff-alternative.sh
+++ b/t/lib-diff-alternative.sh
@@ -175,9 +175,10 @@ test_diff_ignore () {
echo " A quick brownfox" >test-w
echo "A quick brown fox " >test--ignore-space-at-eol
echo "A Quick Brown Fox" >test--ignore-case
+ echo "A Quick Brown FoX" >test-i
echo "A Quick Brown Fox" >test--ignore-case-b
echo "A quick brown fox jumps" >test
- cases="-b -w --ignore-space-at-eol --ignore-case"
+ cases="-b -w --ignore-space-at-eol --ignore-case -i"
if test -z "$STRATEGY"
then
^ permalink raw reply related
* Re: [PATCH] completion: remote set-* <name> and <branch>
From: Junio C Hamano @ 2012-02-20 7:58 UTC (permalink / raw)
To: Philip Jägenstedt
Cc: git, SZEDER Gábor, Felipe Contreras, Teemu Likonen
In-Reply-To: <1329571973-20796-1-git-send-email-philip@foolip.org>
Philip Jägenstedt <philip@foolip.org> writes:
> Complete <name> only for set-url. For set-branches and
> set-head, complete <name> and <branch> over the network,
> like e.g. git pull already does.
>
> Signed-off-by: Philip Jägenstedt <philip@foolip.org>
You addressed your patch to Shawn, who originally wrote this, but
"git shortlog -n -s --no-merges --since=9.months pu contrib/completion"
indicates that he no longer is involved in enhancing this script, and it
has seen actions primarily from three people I Cc'ed this message to.
> contrib/completion/git-completion.bash | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 1505cff..8e7abb6 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -738,6 +738,9 @@ __git_complete_remote_or_refspec ()
> {
> local cur_="$cur" cmd="${words[1]}"
> local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
> + if [ "$cmd" = "remote" ]; then
> + c=$((++c))
> + fi
I don't know about others, but auto-incrementing a variable and assigning
the result to the same variable, while not wrong at all, hurts my brain.
c=$(($c + 1))
is far more readable and does not suggest there is any funky magic
involved. Also it is a good habit to get into not to omit $ from
variables inside arithmetic substitution, even though bash allows it and
this script is meant to be consumed only by shells that understand this
bash-ism.
I do not know offhand if zsh groks it, but the point is that you do not
have to worry about it if you write "$(($c+1))" instead of "$((c+1))".
I'll let the area experts to comment on the remainder of the patch.
Thanks.
> @@ -788,7 +791,7 @@ __git_complete_remote_or_refspec ()
> __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
> fi
> ;;
> - pull)
> + pull|remote)
> if [ $lhs = 1 ]; then
> __gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
> else
> @@ -2289,7 +2292,7 @@ _git_config ()
>
> _git_remote ()
> {
> - local subcommands="add rename rm show prune update set-head"
> + local subcommands="add rename rm set-head set-branches set-url show prune update"
> local subcommand="$(__git_find_on_cmdline "$subcommands")"
> if [ -z "$subcommand" ]; then
> __gitcomp "$subcommands"
> @@ -2297,9 +2300,12 @@ _git_remote ()
> fi
>
> case "$subcommand" in
> - rename|rm|show|prune)
> + rename|rm|set-url|show|prune)
> __gitcomp_nl "$(__git_remotes)"
> ;;
> + set-head|set-branches)
> + __git_complete_remote_or_refspec
> + ;;
> update)
> local i c='' IFS=$'\n'
> for i in $(git --git-dir="$(__gitdir)" config --get-regexp "remotes\..*" 2>/dev/null); do
^ permalink raw reply
* Re: Manually decoding a git object
From: Philip Oakley @ 2012-02-20 8:19 UTC (permalink / raw)
To: ??; +Cc: Git List
In-Reply-To: <CAMocUqRNNXpGOJ2ZG8bWpkieKkVfoo0=Lkevjw+E3Tssw68Hwg@mail.gmail.com>
From: "??" <xudifsd@gmail.com> Sent: Monday, February 20, 2012 4:45 AM
> 2012/2/20 Philip Oakley <philipoakley@iee.org>:
>> If I have a renamed file which is a git object, such a "Git_Object", was
>> 8c-something-or-other, what is the easiest way of examining / decoding /
>> recreating the original file (either as its sha1, or a cat-file).
>>
> I don't think I fully understood what you mean, I assume you just move
> an object file from $GIT_DIR/objects/ to somewhere and rename it,
> let's call it "obj", so if you want to exam its content you can just
> simply call "git cat-file -p obj". And you can also use "git cat-file
> -t obj" to exam its object type. If it's a blob you can use "git
> cat-file -p obj > original" to recreate it, else it's meaningless to
> recreate it.
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
Because its sha1 isn't yet known I can't put it into the correct
.git/objects/xx/ subdirectory of an fresh 'git init', and I have located an
unzip programme that will take the plain git object and decode it - they all
expect archives.
I've described the background use-case at
http://stackoverflow.com/questions/9341278/how-to-track-the-git-directory-in-git-in-its-own-store -
the edit links to a typical corporate scenario.
Even just locating a zlib implementation that simply confirms the file
stream is compressesd and deflates it would be a start.
Philip
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-20 8:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Git Mailing List,
Nguyen Thai Ngoc Duy
In-Reply-To: <20120217222912.GC31830@sigill.intra.peff.net>
On Fri, Feb 17, 2012 at 11:29 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Feb 17, 2012 at 02:25:25PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > That being said, we do have an index extension to store the tree sha1 of
>> > whole directories (i.e., we populate it when we write a whole tree or
>> > subtree into the index from the object db, and it becomes invalidated
>> > when a file becomes modified). This optimization is used by things like
>> > "git commit" to avoid having to recreate the same sub-trees over and
>> > over when creating tree objects from the index. But we could also use it
>> > here to avoid having to even read the sub-tree objects from the object
>> > db.
>>
>> Like b65982b (Optimize "diff-index --cached" using cache-tree, 2009-05-20)
>> perhaps?
>
> That's what I get for speaking before running "git log".
>
> So yeah, we may be about as reasonably fast as we can go. Or maybe that
> optimization isn't kicking in for some reason. I think going further
> would require Piotr to do more profiling.
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
git version 1.7.9.188.g12766
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Manually decoding a git object
From: Thomas Rast @ 2012-02-20 8:29 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
In-Reply-To: <A716A27D407F401DAAC373027D5CFF2A@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> If I have a renamed file which is a git object, such a "Git_Object", was
> 8c-something-or-other, what is the easiest way of examining / decoding /
> recreating the original file (either as its sha1, or a cat-file).
>
> I don't appear to be able to unzip the file in its raw format... I'm using
> Msysgit on windows XP.
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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCHv2 3/8] gitweb: Faster project search
From: Junio C Hamano @ 2012-02-20 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1329338332-30358-4-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Before searching by some field the information we search for must be
> filled in. For this fill_project_list_info() was enhanced in previous
> commit to take additional parameters which part of projects info to
"must be filled in." is correct, but that happens without the previous
patch. The first sentence must also say:
In order to search by some field, the information we look for must
be filled in, but we do not have to fill other fields that are not
involved in the search.
to justify the previous "fill_project_list_info can be asked to return
without getting unused fields" patch. The rest of the log message then
makes good sense.
> fill. This way we can limit doing expensive calculations (like
> running git-for-each-ref to get 'age' / "Last changed" info) only to
> projects which we will show as search results.
>
> With this commit the number of git commands used to generate search
> results is 2*<matched projects> + 1, and depends on number of matched
> projects rather than number of all projects (all repositories).
>
> Note: this is 'git for-each-ref' to find last activity, and 'git config'
> for each project, and 'git --version' once.
^ permalink raw reply
* Re: [PATCH 0/1] Make libintl in libc detection more robust
From: Junio C Hamano @ 2012-02-20 8:34 UTC (permalink / raw)
To: John Szakmeister; +Cc: git
In-Reply-To: <1329593884-9999-1-git-send-email-john@szakmeister.net>
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
I'll tweak the log message and queue.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/5] diff --ignore-case
From: Johannes Sixt @ 2012-02-20 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
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? And how useful is it that it
does not obey the current locale, as in your implementation?
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-latexdiff: new command in contrib, to use latexdiff and Git
From: Matthieu Moy @ 2012-02-20 8:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Tim Haga, git
In-Reply-To: <m34nups3q2.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Aren't there LaTeX tools archives that would be a much better home for
>> this tool?
>
> There is CTAN: Comprehensive TeX Archive Network (http://ctan.org),
> which hosts tools such like latexmk (cousin of the general make
> utility), autolatex (generates Makefile), chktex, ite (interactive TeX
> editor),... latexdiff itself is also there.
It's not really the same thing: AFAIK, ctan is a good place to
distribute things, but not to develop them (i.e. I don't see revision
control or developpers mailing-lists there, which were the two
motivations for pushing git-latexdiff in git.git).
Anyway, since no one spoke up to defend my position, I'll have to find
another place to host it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 0/5] diff --ignore-case
From: Junio C Hamano @ 2012-02-20 8:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4F420749.9010206@kdbg.org>
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.
You can update the hash and recmatch to be locale-aware, which would be an
internal update to xdiff/ directory that is independent of the rest of the
series, and/or the change to plug the machinery to -G.
^ permalink raw reply
* Re: [PATCH] git-latexdiff: new command in contrib, to use latexdiff and Git
From: Junio C Hamano @ 2012-02-20 9:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jakub Narebski, Tim Haga, git
In-Reply-To: <vpqy5rxsxb3.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> There is CTAN: Comprehensive TeX Archive Network (http://ctan.org),
>> which hosts tools such like latexmk (cousin of the general make
>> utility), autolatex (generates Makefile), chktex, ite (interactive TeX
>> editor),... latexdiff itself is also there.
>
> It's not really the same thing: AFAIK, ctan is a good place to
> distribute things, but not to develop them (i.e. I don't see revision
> control or developpers mailing-lists there, which were the two
> motivations for pushing git-latexdiff in git.git).
Oh, don't get me wrong.
It's just that I agree with Jakub that a better final destination for it
is CTAN next to latexdiff, not in git.git/contrib/, and when we last did
something similar for emacs vc mode support, the copy I carried ended up
becoming way stale than its final destination, and we had to remove our
copy in order to reduce confusion. I just do not want to make the same
mistake here.
I didn't intend to discourage discusson of your application here.
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.
I just do not think my tree is a good place to use as a "while we are
developing" staging area.
^ permalink raw reply
* Re: Manually decoding a git object
From: Philip Oakley @ 2012-02-20 10:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List, 徐迪
In-Reply-To: <87mx8dj4at.fsf@thomas.inf.ethz.ch>
From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20, 2012 8:29
AM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> If I have a renamed file which is a git object, such a "Git_Object", was
>> 8c-something-or-other, what is the easiest way of examining / decoding /
>> recreating the original file (either as its sha1, or a cat-file).
>>
>> I don't appear to be able to unzip the file in its raw format... I'm
>> using
>> Msysgit on windows XP.
Correction to reply to xu's message: and I have /NOT/ located an
unzip programme that will take the plain git object and decode it.
>
> 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?
Philip
^ permalink raw reply
* 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
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