* Re: tip tree clone fail
From: Wang Chen @ 2008-10-13 9:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, H. Peter Anvin, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar said the following on 2008-10-13 0:59:
> * Petr Baudis <pasky@suse.cz> wrote:
>
>> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
>>> hm, -tip's .git/hooks/post-update already contained this, for the last 2
>>> months:
>>>
>>> exec git update-server-info
>>>
>>> so ... _despite_ us having this in the git repo, the HTTP protocol still
>>> does not work. Why?
>> I think your problem is that HTTP does not know where to look for
>> objects coming from alternates; IIRC this would work if you used
>> relative paths in objects/info/alternates, or you can create
>> objects/info/http-alternates like
>>
>> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
>> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> ok, i've now set it up like this:
>
> $ pwd
> /pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>
> $ cat objects/info/alternates
> /home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> $ cat objects/info/http-alternates
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> and i've added "git update-server-info" to hooks/post-receive and made
> it chmod +x.
>
> that should be golden, right? I'm wondering why this isnt in the default
> setup - i've been behind a limited corporate firewall in a former life
> and having HTTP access is indeed very handy and pragmatic. Often hotel
> WLANs are HTTP only as well.
>
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
>
Ingo, thank you for your work.
I can clone more, but error still occurs:
Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
error: transfer closed with 8280 bytes remaining to read
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
^ permalink raw reply
* [PATCH] tests: shell negation portability fix
From: Jeff King @ 2008-10-13 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
---
I had totally forgotten about this monstrosity until my autobuild broke.
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index bc7a8a8..8f6aea4 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -72,7 +72,7 @@ test_expect_success 'apply --directory (delete file)' '
echo content >some/sub/dir/delfile &&
git add some/sub/dir/delfile &&
git apply --directory=some/sub/dir/ --index patch &&
- ! git ls-files | grep delfile
+ ! (git ls-files | grep delfile)
'
cat > patch << 'EOF'
^ permalink raw reply related
* [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-13 9:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, gitster, spearce
In-Reply-To: <alpine.LNX.1.00.0810121501590.19665@iabervon.org>
Some confusing tutorials suggested that it would be a good idea to fetch
into the current branch with something like this:
git fetch origin master:master
(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically
is plain wrong when the current branch is "master".
As noticed by Junio, this behavior should be triggered by _not_ passing
the --update-head-ok option, but somewhere along the lines we lost that
behavior.
NOTE: this patch does not completely resurrect the original behavior
without --update-head-ok: the check for the current branch is now _only_
performed in non-bare repositories.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sun, 12 Oct 2008, Daniel Barkalow and Shawn Pearce sent some
good suggestions to fix the first version of the patch.
This is the updated version. In particular, the test is only
performed without the option "--update-head-ok", the function
branch_get(NULL) is called to get the current branch, a test was
added to verify that --update-head-ok works as expected, and the
commit message was modified in the hope that it confuses less now.
Strangely, some more tests refused to pass this time, because they
did not use --update-head-ok; this was fixed, too.
builtin-fetch.c | 15 +++++++++++++++
t/t5405-send-pack-rewind.sh | 2 +-
t/t5505-remote.sh | 2 +-
t/t5510-fetch.sh | 12 ++++++++++++
t/t9300-fast-import.sh | 2 +-
5 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..57c161d 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -534,6 +534,19 @@ static void find_non_local_tags(struct transport *transport,
string_list_clear(&new_refs, 0);
}
+static void check_not_current_branch(struct ref *ref_map)
+{
+ struct branch *current_branch = branch_get(NULL);
+
+ if (is_bare_repository() || !current_branch)
+ return;
+
+ for (; ref_map; ref_map = ref_map->next)
+ if (ref_map->peer_ref && !strcmp(current_branch->refname,
+ ref_map->peer_ref->name))
+ die("Refusing to fetch into current branch");
+}
+
static int do_fetch(struct transport *transport,
struct refspec *refs, int ref_count)
{
@@ -558,6 +571,8 @@ static int do_fetch(struct transport *transport,
}
ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
+ if (!update_head_ok)
+ check_not_current_branch(ref_map);
for (rm = ref_map; rm; rm = rm->next) {
if (rm->peer_ref)
diff --git a/t/t5405-send-pack-rewind.sh b/t/t5405-send-pack-rewind.sh
index 86abc62..cb9aacc 100755
--- a/t/t5405-send-pack-rewind.sh
+++ b/t/t5405-send-pack-rewind.sh
@@ -12,7 +12,7 @@ test_expect_success setup '
mkdir another && (
cd another &&
git init &&
- git fetch .. master:master
+ git fetch --update-head-ok .. master:master
) &&
>file2 && git add file2 && test_tick &&
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..0103e1a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -188,7 +188,7 @@ test_expect_success 'prune --dry-run' '
test_expect_success 'add --mirror && prune' '
(mkdir mirror &&
cd mirror &&
- git init &&
+ git init --bare &&
git remote add --mirror -f origin ../one) &&
(cd one &&
git branch -m side2 side) &&
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 9aae496..9e679b4 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -323,4 +323,16 @@ test_expect_success 'auto tag following fetches minimum' '
)
'
+test_expect_success 'refuse to fetch into the current branch' '
+
+ test_must_fail git fetch . side:master
+
+'
+
+test_expect_success 'fetch into the current branch with --update-head-ok' '
+
+ git fetch --update-head-ok . side:master
+
+'
+
test_done
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 328444a..91b5ace 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -983,7 +983,7 @@ test_expect_success \
git checkout subuse1 &&
rm -rf sub && mkdir sub && cd sub &&
git init &&
- git fetch .. refs/heads/sub:refs/heads/master &&
+ git fetch --update-head-ok .. refs/heads/sub:refs/heads/master &&
git checkout master &&
cd .. &&
git submodule init &&
--
1.6.0.2.749.g0cc32
^ permalink raw reply related
* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Johannes Schindelin @ 2008-10-13 9:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20081012184727.GE4856@spearce.org>
Hi,
On Sun, 12 Oct 2008, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Some confusing tutorials suggest that it would be a good idea to call
> > > something like this:
> > >
> > > git pull origin master:master
> > >
> > > While it might make sense to store what you want to merge, it typically
> > > is plain wrong.
> >
> > I am somewhat confused.
>
> The description is confusing, yes. It should be about git fetch,
> not git pull.
However, it was a "git pull origin master:master" that was the issue.
That's why I wrote it in the commit message.
> > This "confusion" has been there for very long time and (at least the
> > scripted version of) git-pull/git-fetch pair has supported a
> > workaround in the form of --update-head-ok option.
Good point. I completely had forgotten about that feature.
> I think "git fetch url side:master" when master is the current branch
> and we have omitted --update-head-ok is broken. Specifically Dscho's
> last hunk which adds this test. The test fails on current master.
Thanks for testing; I ran out of my Git time budget yesterday. Will send
an updated patch as a reply to Daniel's reply.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7vskr1c976.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 12 Oct 2008, Junio C Hamano wrote:
> Shawn had this queued in pu, but it appears to even fail its own tests
> on my machine, when applied on top of 'master'.
Sorry, I cannot reproduce at all.
I tested this on two machines, i686 and x86_64 (of course, on top of my
patches to 'next', but now repeated the test with the commit
cherry-picked to your 5c283eb(Merge branch 'maint')).
It passes.
Ciao,
Dscho
P.S.: I even made "make clean && make -j50 test", just in case we have
some dependency issue in the Makefile (happened before). Still passes.
P.P.S.: It would be nice if you could run the test with -i -v (and maybe
with sh -x) and post the output. Thank you very much.
P.P.P.S.: Just for reference: this is what the cherry-picked commit
format-patches to:
-- snipsnap --
[PATCH] Introduce core.keepHardLinks
When a tracked file was hard linked, we used to break the hard link
whenever Git writes to that file. Make that optional.
To keep the implementation simple, mode changes will still break the
hard links.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 4 +++
cache.h | 1 +
config.c | 5 ++++
entry.c | 7 ++++-
environment.c | 1 +
t/t0056-hardlinked.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 t/t0056-hardlinked.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..aacaeae 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -207,6 +207,10 @@ core.symlinks::
file. Useful on filesystems like FAT that do not support
symbolic links. True by default.
+core.keepHardLinks::
+ If true, do not break hard links by deleting and recreating the
+ files. Off by default.
+
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
of establishing direct connection to the remote server when
diff --git a/cache.h b/cache.h
index 991544c..d6348a1 100644
--- a/cache.h
+++ b/cache.h
@@ -478,6 +478,7 @@ enum rebase_setup_type {
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
+extern int keep_hard_links;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index b8d289d..944e18e 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.keephardlinks")) {
+ keep_hard_links = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/entry.c b/entry.c
index aa2ee46..dfddf83 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,8 @@ static void remove_subtree(const char *path)
static int create_file(const char *path, unsigned int mode)
{
mode = (mode & 0100) ? 0777 : 0666;
- return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+ return open(path, O_WRONLY | O_CREAT |
+ (keep_hard_links ? O_TRUNC : O_EXCL), mode);
}
static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
@@ -225,7 +226,9 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
if (!state->force)
return error("%s is a directory", path);
remove_subtree(path);
- } else if (unlink(path))
+ } else if ((!keep_hard_links || !S_ISREG(st.st_mode) ||
+ st.st_mode != ce->ce_mode) &&
+ unlink(path))
return error("unable to unlink old '%s' (%s)", path, strerror(errno));
} else if (state->not_new)
return 0;
diff --git a/environment.c b/environment.c
index 0693cd9..ef721e0 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int keep_hard_links = 0;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/t/t0056-hardlinked.sh b/t/t0056-hardlinked.sh
new file mode 100644
index 0000000..934c2bc
--- /dev/null
+++ b/t/t0056-hardlinked.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='read-tree and checkout respect hardlinked files'
+
+. ./test-lib.sh
+
+cat > file << EOF
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6
+8. e4 Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4
+14. Bxe7 Qb6 15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+
+20. Kf1 Nxd4+ 21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1
+26. h3 Rxa2 27. Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4
+32. Qb8 b5 33. h4 h5 34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+
+38. Kd1 Bb3+ 39. Kc1 Ne2+ 40. Kb1 Nc3+
+EOF
+
+ln file link || {
+ say "Could not hard link; skipping test"
+ test_done
+ exit
+}
+
+test_expect_success setup '
+
+ git config core.keepHardLinks true &&
+ test_cmp file link &&
+ cp file old &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo "41. Kc1 Rc2#" >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m 2nd &&
+ test_cmp file link &&
+ ! test_cmp file old
+
+'
+
+test_expect_success 'checking a file out does not break the hard link' '
+
+ git checkout HEAD^ -- file &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_expect_success 'read-tree -u -m does not break the hard link' '
+
+ git reset --hard &&
+ test_cmp file link &&
+ git read-tree -u -m HEAD^ &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_done
--
1.6.0.2.749.g0cc32
^ permalink raw reply related
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 8:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20081012183855.GA5255@spearce.org>
Hi,
On Sun, 12 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > When a tracked file was hard linked, we used to break the hard link
> > whenever Git writes to that file. Make that optional.
>
> Why would anyone want to do this?
>
> I cannot fathom why a user wants this much rope to hang themselves
> with...
The question is not so much why anyone want to do this, but _if_.
And the answer is: yes.
Ciao,
Dscho
^ permalink raw reply
* Re: User Authentication ?
From: Jakub Narebski @ 2008-10-13 8:23 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0810130109k56e2e976kd00678e2ca3bc558@mail.gmail.com>
Neshama Parhoti wrote:
> On Sat, Oct 11, 2008 at 8:28 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Neshama Parhoti" <pneshama@gmail.com> writes:
>>
>>> I want to setup a git server on the web but I need user
>>> authentication.
>>> I really don't want to give ssh logins for people who I just want to
>>> be able to access my repository...
>>
>> First, you can always set git-shell as shell for those git only
>> accounts. [...]
>
> Thank you ! That should really be good. Any chance you are aware of
> documentation or further guidance about how to set this up ?
I have never had the need, but for Gitosis the seminal reference is
I think
"Hosting Git repositories, The Easy (and Secure) Way"
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Matthieu Moy @ 2008-10-13 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Sixt, git
In-Reply-To: <7vk5cddtzh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The textconv filter is primarily for humans to be able to view the diff,
> as far as I understand it, but what would this facility do to the patch
> exchange workflow? There needs either one or both of the following:
>
> - A command line option to Porcelains to override textconv so that an
> applicable binary diff can be obtained upon request (or format-patch
> always disables textconv); and/or
To me (and others in this thread AIUI), the textconv should only
replace the (frustrating) "binary files differ" in porcelain.
> - You teach git-apply to use a reverse transformation of textconv, so
> that it does, upon reception of a textconv diff:
>
> (1) pass existing preimage through textconv;
> (2) apply the patch;
> (3) convert the result back to binary.
I can imagine corner-case scenarios where this would be applicable and
somehow usefull (like: modifying _only_ the EXIF tags on one end, and
expect to be able to view and apply the tags modification on the other
end), but I don't think that's something important to worry about. As
other said, it would be really hard to set up for users, with little
benefits.
One possibility that would be simpler to set up would be to include
both the binary diff and the textconved diff in format-patch, and have
"git apply" just verify that the textconv actually matches the binary
diff after applying it. But that reduces the security issue without
really solving it: one could very well send a binary patch that
changes both the image and the exiftags, and claim it only changes the
tags.
In short: agreed with Peff ;-).
--
Matthieu
^ permalink raw reply
* [PATCH (GITK) v3 3/4] gitk: Implement batch lookup and caching of encoding attrs.
From: Alexander Gavrilov @ 2008-10-13 8:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1223885554-27718-3-git-send-email-angavrilov@gmail.com>
When the diff contains thousands of files, calling git-check-attr
once per file is very slow. With this patch gitk does attribute
lookup in batches of 30 files while reading the diff file list,
which leads to a very noticeable speedup.
It may be possible to reimplement this even more efficiently,
if git-check-attr is modified to support a --stdin-paths option.
Additionally, it should quote the ':' character in file paths,
or provide a more robust way of column separation.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 5f35f61..8cd3171 100755
--- a/gitk
+++ b/gitk
@@ -6531,6 +6531,7 @@ proc gettreediffline {gdtf ids} {
global cmitmode vfilelimit curview limitdiffs
set nr 0
+ set sublist {}
while {[incr nr] <= 1000 && [gets $gdtf line] >= 0} {
set i [string first "\t" $line]
if {$i >= 0} {
@@ -6540,8 +6541,10 @@ proc gettreediffline {gdtf ids} {
}
set file [encoding convertfrom $file]
lappend treediff $file
+ lappend sublist $file
}
}
+ cache_gitattr encoding $sublist
if {![eof $gdtf]} {
return [expr {$nr >= 1000? 2: 1}]
}
@@ -9816,18 +9819,48 @@ proc tcl_encoding {enc} {
}
proc gitattr {path attr default} {
- if {[catch {set r [exec git check-attr $attr -- $path]}]} {
+ global path_attr_cache
+ if {[info exists path_attr_cache($attr,$path)]} {
+ set r $path_attr_cache($attr,$path)
+ } elseif {[catch {set r [exec git check-attr $attr -- $path]}]} {
set r unspecified
} else {
set r [join [lrange [split $r :] 2 end] :]
regsub {^ } $r {} r
}
+ set path_attr_cache($attr,$path) $r
if {$r eq {unspecified}} {
return $default
}
return $r
}
+proc cache_gitattr {attr pathlist} {
+ global path_attr_cache
+ set newlist {}
+ foreach path $pathlist {
+ if {[info exists path_attr_cache($attr,$path)]} continue
+ lappend newlist $path
+ }
+ while {$newlist ne {}} {
+ set head [lrange $newlist 0 29]
+ set newlist [lrange $newlist 30 end]
+ if {![catch {set rlist [eval exec git check-attr $attr -- $head]}]} {
+ foreach row [split $rlist "\n"] {
+ set cols [split $row :]
+ set path [lindex $cols 0]
+ set value [join [lrange $cols 2 end] :]
+ if {[string index $path 0] eq "\""} {
+ set path [encoding convertfrom [lindex $path 0]]
+ }
+ regsub {^ } $value {} value
+ set path_attr_cache($attr,$path) $value
+ }
+ }
+ update
+ }
+}
+
proc get_path_encoding {path} {
global gui_encoding
set tcl_enc [tcl_encoding $gui_encoding]
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v3 4/4] gitk: Optimize encoding name resolution using a lookup table.
From: Alexander Gavrilov @ 2008-10-13 8:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1223885554-27718-4-git-send-email-angavrilov@gmail.com>
Current implementation of tcl_encoding uses linear search,
and is rather slow when called hundreds of times. This commit
reimplements it using a lookup table, which is efficiently
calculated on the first run. After that, resolution costs two
calls to [info exists], and one actual fetch from the table.
This is a port of git-gui commit a1c3feb7fac7.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 84 ++++++++++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/gitk b/gitk
index 8cd3171..134df00 100755
--- a/gitk
+++ b/gitk
@@ -9783,39 +9783,63 @@ set encoding_aliases {
{ Big5 csBig5 }
}
-proc tcl_encoding {enc} {
- global encoding_aliases
- set names [encoding names]
- set lcnames [string tolower $names]
- set enc [string tolower $enc]
- set i [lsearch -exact $lcnames $enc]
- if {$i < 0} {
- # look for "isonnn" instead of "iso-nnn" or "iso_nnn"
- if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
- set i [lsearch -exact $lcnames $encx]
+proc build_encoding_table {} {
+ global encoding_aliases encoding_lookup_table
+
+ # Prepare the lookup list; cannot use lsort -nocase because
+ # of compatibility issues with older Tcl (e.g. in msysgit)
+ set names [list]
+ foreach item [encoding names] {
+ lappend names [list [string tolower $item] $item]
+ }
+ set names [lsort -ascii -index 0 $names]
+ # neither can we use lsearch -index
+ set lnames [list]
+ foreach item $names {
+ lappend lnames [lindex $item 0]
+ }
+
+ foreach grp $encoding_aliases {
+ set target {}
+ foreach item $grp {
+ set i [lsearch -sorted -ascii $lnames \
+ [string tolower $item]]
+ if {$i >= 0} {
+ set target [lindex $names $i 1]
+ break
+ }
+ }
+ if {$target eq {}} continue
+ foreach item $grp {
+ set encoding_lookup_table([string tolower $item]) $target
+ }
}
- }
- if {$i < 0} {
- foreach l $encoding_aliases {
- set ll [string tolower $l]
- if {[lsearch -exact $ll $enc] < 0} continue
- # look through the aliases for one that tcl knows about
- foreach e $ll {
- set i [lsearch -exact $lcnames $e]
- if {$i < 0} {
- if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
- set i [lsearch -exact $lcnames $ex]
- }
+
+ foreach item $names {
+ set encoding_lookup_table([lindex $item 0]) [lindex $item 1]
+ }
+}
+
+proc tcl_encoding {enc} {
+ global encoding_lookup_table
+ if {$enc eq {}} {
+ return {}
+ }
+ if {![info exists encoding_lookup_table]} {
+ build_encoding_table
+ }
+ set enc [string tolower $enc]
+ if {![info exists encoding_lookup_table($enc)]} {
+ # look for "isonnn" instead of "iso-nnn" or "iso_nnn"
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
+ set enc $encx
}
- if {$i >= 0} break
- }
- break
}
- }
- if {$i >= 0} {
- return [lindex $names $i]
- }
- return {}
+ if {[info exists encoding_lookup_table($enc)]} {
+ return $encoding_lookup_table($enc)
+ } else {
+ return {}
+ }
}
proc gitattr {path attr default} {
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v3 2/4] gitk: Enhance file encoding support.
From: Alexander Gavrilov @ 2008-10-13 8:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1223885554-27718-2-git-send-email-angavrilov@gmail.com>
The previous patch has added functions that implement
per-file contents encoding selection logic. This one
modifies core gitk code to use them.
Since diffs usually contain multiple files, which may
have different values of the encoding attribute, they
are initially read as binary, and encoding conversion
is applied to individual lines, based on the active
set of diff headers.
As a side job, this patch also fixes some bugs in
handling of non-ASCII filenames. Core git apparently
supports only locale-encoded filenames, so processing
is done using the system encoding.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 35 +++++++++++++++++++++++++++--------
1 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/gitk b/gitk
index 8682838..5f35f61 100755
--- a/gitk
+++ b/gitk
@@ -6229,7 +6229,7 @@ proc gettree {id} {
set treepending $id
set treefilelist($id) {}
set treeidlist($id) {}
- fconfigure $gtf -blocking 0
+ fconfigure $gtf -blocking 0 -encoding binary
filerun $gtf [list gettreeline $gtf $id]
}
} else {
@@ -6251,11 +6251,12 @@ proc gettreeline {gtf id} {
set line [string range $line 0 [expr {$i-1}]]
if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
set sha1 [lindex $line 2]
- if {[string index $fname 0] eq "\""} {
- set fname [lindex $fname 0]
- }
lappend treeidlist($id) $sha1
}
+ if {[string index $fname 0] eq "\""} {
+ set fname [lindex $fname 0]
+ }
+ set fname [encoding convertfrom $fname]
lappend treefilelist($id) $fname
}
if {![eof $gtf]} {
@@ -6296,7 +6297,7 @@ proc showfile {f} {
return
}
}
- fconfigure $bf -blocking 0
+ fconfigure $bf -blocking 0 -encoding [get_path_encoding $f]
filerun $bf [list getblobline $bf $diffids]
$ctext config -state normal
clear_ctext $commentend
@@ -6334,6 +6335,7 @@ proc mergediff {id} {
global diffids
global parents
global diffcontext
+ global diffencoding
global limitdiffs vfilelimit curview
set diffmergeid $id
@@ -6347,9 +6349,10 @@ proc mergediff {id} {
error_popup "[mc "Error getting merge diffs:"] $err"
return
}
- fconfigure $mdf -blocking 0
+ fconfigure $mdf -blocking 0 -encoding binary
set mdifffd($id) $mdf
set np [llength $parents($curview,$id)]
+ set diffencoding [get_path_encoding {}]
settabs $np
filerun $mdf [list getmergediffline $mdf $id $np]
}
@@ -6357,6 +6360,7 @@ proc mergediff {id} {
proc getmergediffline {mdf id np} {
global diffmergeid ctext cflist mergemax
global difffilestart mdifffd
+ global diffencoding
$ctext conf -state normal
set nr 0
@@ -6368,18 +6372,22 @@ proc getmergediffline {mdf id np} {
}
if {[regexp {^diff --cc (.*)} $line match fname]} {
# start of a new file
+ set fname [encoding convertfrom $fname]
$ctext insert end "\n"
set here [$ctext index "end - 1c"]
lappend difffilestart $here
add_flist [list $fname]
+ set diffencoding [get_path_encoding $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
$ctext insert end "$pad $fname $pad\n" filesep
} elseif {[regexp {^@@} $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
} elseif {[regexp {^[0-9a-f]{40}$} $line] || [regexp {^index} $line]} {
# do nothing
} else {
+ set line [encoding convertfrom $diffencoding $line]
# parse the prefix - one ' ', '-' or '+' for each parent
set spaces {}
set minuses {}
@@ -6514,7 +6522,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
- fconfigure $gdtf -blocking 0
+ fconfigure $gdtf -blocking 0 -encoding binary
filerun $gdtf [list gettreediffline $gdtf $ids]
}
@@ -6530,6 +6538,7 @@ proc gettreediffline {gdtf ids} {
if {[string index $file 0] eq "\""} {
set file [lindex $file 0]
}
+ set file [encoding convertfrom $file]
lappend treediff $file
}
}
@@ -6587,6 +6596,7 @@ proc getblobdiffs {ids} {
global diffcontext
global ignorespace
global limitdiffs vfilelimit curview
+ global diffencoding
set cmd [diffcmd $ids "-p -C --no-commit-id -U$diffcontext"]
if {$ignorespace} {
@@ -6600,7 +6610,8 @@ proc getblobdiffs {ids} {
return
}
set diffinhdr 0
- fconfigure $bdf -blocking 0
+ set diffencoding [get_path_encoding {}]
+ fconfigure $bdf -blocking 0 -encoding binary
set blobdifffd($ids) $bdf
filerun $bdf [list getblobdiffline $bdf $diffids]
}
@@ -6634,6 +6645,7 @@ proc getblobdiffline {bdf ids} {
global diffids blobdifffd ctext curdiffstart
global diffnexthead diffnextnote difffilestart
global diffinhdr treediffs
+ global diffencoding
set nr 0
$ctext conf -state normal
@@ -6671,10 +6683,13 @@ proc getblobdiffline {bdf ids} {
} else {
set fname [string range $line 2 [expr {$i - 1}]]
}
+ set fname [encoding convertfrom $fname]
+ set diffencoding [get_path_encoding $fname]
makediffhdr $fname $ids
} elseif {[regexp {^@@ -([0-9]+)(,[0-9]+)? \+([0-9]+)(,[0-9]+)? @@(.*)} \
$line match f1l f1c f2l f2c rest]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
set diffinhdr 0
@@ -6684,6 +6699,7 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
+ set fname [encoding convertfrom $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -6694,6 +6710,8 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
+ set fname [encoding convertfrom $fname]
+ set diffencoding [get_path_encoding $fname]
makediffhdr $fname $ids
} elseif {[string compare -length 3 $line "---"] == 0} {
# do nothing
@@ -6705,6 +6723,7 @@ proc getblobdiffline {bdf ids} {
$ctext insert end "$line\n" filesep
} else {
+ set line [encoding convertfrom $diffencoding $line]
set x [string range $line 0 0]
if {$x == "-" || $x == "+"} {
set tag [expr {$x == "+"}]
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Alexander Gavrilov @ 2008-10-13 8:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
Currently GUI tools don't provide enough support for
viewing files that contain non-ASCII characters. This set of
patches addresses this issue. The git-gui part of the series
is based on patches that were in the 'pu' branch of the
git-gui repository.
UPDATE: the git-gui part of the series is in master.
File encoding can be specified in the following ways:
1) It defaults to the current locale encoding.
2) It can be overridden by setting the gui.encoding option.
3) It can be further set on per-file basis by specifying
the 'encoding' attribute in gitattributes.
4) Finally, git-gui allows directly selecting encodings
through a popup menu.
Since git apparently cannot work with filenames in non-locale
encodings anyway, I did not try to do anything about it apart
from fixing some obvious bugs.
CHANGES v2:
- Wrote better comments for the first three patches.
- Added a patch to speed up loading of very large diffs.
CHANGES v3:
- Killed get_cached_encoding, replacing it with get_path_encoding.
- Squashed file name and content patches into one.
- Added the tcl_encoding reimplementation patch. I should
say that without the second cache this really makes a
difference with thousand-file diffs.
GITK:
gitk: Port new encoding logic from git-gui.
---
gitk | 39 ++++++++++++++++++++++++++++++++++++---
1 files changed, 36 insertions(+), 3 deletions(-)
gitk: Enhance file encoding support.
---
gitk | 35 +++++++++++++++++++++++++++--------
1 files changed, 27 insertions(+), 8 deletions(-)
gitk: Implement batch lookup and caching of encoding attrs.
---
gitk | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
gitk: Optimize encoding name resolution using a lookup table.
---
gitk | 84 ++++++++++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 54 insertions(+), 30 deletions(-)
^ permalink raw reply
* [PATCH (GITK) v3 1/4] gitk: Port new encoding logic from git-gui.
From: Alexander Gavrilov @ 2008-10-13 8:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Recently handling of file encodings in GIT-GUI has
been greatly enhanced. It now follows these rules:
- File encoding defaults to the system encoding.
- It can be overridden by setting the gui.encoding option.
- Finally, the 'encoding' attribute is checked on
per-file basis; it has the last word.
This patch inserts copies of git-gui functions necessary
for supporting this into gitk. The following patch will
connect them to the rest of the code.
Note: Since git-check-attr does not provide support for
reading attributes from trees, attribute lookup is done
using files from the working directory.
It also extends the range of supported encoding
names, to match changes in git-gui.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 39 ++++++++++++++++++++++++++++++++++++---
1 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index dce17e9..8682838 100755
--- a/gitk
+++ b/gitk
@@ -9727,7 +9727,7 @@ set encoding_aliases {
{ ISO-8859-16 iso-ir-226 ISO_8859-16:2001 ISO_8859-16 latin10 l10 }
{ GBK CP936 MS936 windows-936 }
{ JIS_Encoding csJISEncoding }
- { Shift_JIS MS_Kanji csShiftJIS }
+ { Shift_JIS MS_Kanji csShiftJIS ShiftJIS Shift-JIS }
{ Extended_UNIX_Code_Packed_Format_for_Japanese csEUCPkdFmtJapanese
EUC-JP }
{ Extended_UNIX_Code_Fixed_Width_for_Japanese csEUCFixWidJapanese }
@@ -9769,7 +9769,7 @@ proc tcl_encoding {enc} {
set i [lsearch -exact $lcnames $enc]
if {$i < 0} {
# look for "isonnn" instead of "iso-nnn" or "iso_nnn"
- if {[regsub {^iso[-_]} $enc iso encx]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
set i [lsearch -exact $lcnames $encx]
}
}
@@ -9781,7 +9781,7 @@ proc tcl_encoding {enc} {
foreach e $ll {
set i [lsearch -exact $lcnames $e]
if {$i < 0} {
- if {[regsub {^iso[-_]} $e iso ex]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
set i [lsearch -exact $lcnames $ex]
}
}
@@ -9796,6 +9796,34 @@ proc tcl_encoding {enc} {
return {}
}
+proc gitattr {path attr default} {
+ if {[catch {set r [exec git check-attr $attr -- $path]}]} {
+ set r unspecified
+ } else {
+ set r [join [lrange [split $r :] 2 end] :]
+ regsub {^ } $r {} r
+ }
+ if {$r eq {unspecified}} {
+ return $default
+ }
+ return $r
+}
+
+proc get_path_encoding {path} {
+ global gui_encoding
+ set tcl_enc [tcl_encoding $gui_encoding]
+ if {$tcl_enc eq {}} {
+ set tcl_enc [encoding system]
+ }
+ if {$path ne {}} {
+ set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
+ if {$enc2 ne {}} {
+ set tcl_enc $enc2
+ }
+ }
+ return $tcl_enc
+}
+
# First check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
show_error {} . [mc "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
@@ -9818,6 +9846,11 @@ if {$tclencoding == {}} {
puts stderr "Warning: encoding $gitencoding is not supported by Tcl/Tk"
}
+set gui_encoding [encoding system]
+catch {
+ set gui_encoding [exec git config --get gui.encoding]
+}
+
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: User Authentication ?
From: Neshama Parhoti @ 2008-10-13 8:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3y70vj8ag.fsf@localhost.localdomain>
Hi,
On Sat, Oct 11, 2008 at 8:28 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Neshama Parhoti" <pneshama@gmail.com> writes:
>
>> I want to setup a git server on the web but I need user
>> authentication.
>> I really don't want to give ssh logins for people who I just want to
>> be able to access my repository...
>
> First, you can always set git-shell as shell for those git only
> accounts.
Thank you ! That should really be good. Any chance you are aware of
documentation
or further guidance about how to set this up ?
thanks!
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #02; Sun, 12)
From: Stephen Haberman @ 2008-10-13 6:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20081012212543.GG4856@spearce.org>
> * sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
> - rebase--interactive: fix parent rewriting for dropped commits
>
> A prior version of sh/rebase-i-p. This should be dropped.
maint-rebase3 is actually a separate issue than sh/rebase-i-p.
maint-rebase3 deals with commits dropped because they are recognized as
cherry picks, while rebase-i-p deals with commits that can be ignored
from the todo because their parents are not being changed.
I'm surprised they both applied cleanly to pu--I was expecting a
conflict, as I noted in one of my posts. I just fetched pu and they
seem to have each broke the each other's tests as well.
To fix this, I have some local changes to pu that gets both tests
passing again. Should I submit my integration changes as a diff on top
of pu? Or should I try and integrate the two patches into one series?
Technically these two fixes are different things, and I assert you
could apply one or the other, but if you apply both, they require
integration, so I'm not sure what to do.
(...nuts, t3404#22 is failing, so my maint3-rebase/rebase-i-p
integration patch is not quite ready yet.)
(I also have a test comment typo and test_expect_failure change to make
to rebase-i-p from Junio's feedback and would like to know the
preferred way to submit those--e.g. a patch on top of your pu, a patch
on top of the existing series, or a new series all together. Given it
is not next, I'm guessing a new series all together.)
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Alex Riesen @ 2008-10-13 6:18 UTC (permalink / raw)
To: Johannes Sixt
Cc: Dmitry Potapov, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <48F2E410.2080504@viscovery.net>
2008/10/13 Johannes Sixt <j.sixt@viscovery.net>:
> Alex Riesen schrieb:
>> I looked at the callers (briefly). Performance could be a problem: add
>> and checkout can work with real big file lists and long pathnames.
>> So ok, than. It is critical.
>
> You are kidding, aren't you? What you win by a few CPU instructions here
> is dwarfed by the time that the stat() implementation requires. Dmitry,
> please use the more readable tolower().
It is called for every element in a path, not just for every filename.
And maybe it is dwarfed, but they both are part of the same operation.
And this code makes it more CPU intensive.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Junio C Hamano @ 2008-10-13 6:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <alpine.DEB.1.00.0810111344241.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Shawn had this queued in pu, but it appears to even fail its own tests on
my machine, when applied on top of 'master'.
I tentatively dropped this from pu.
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Johannes Sixt @ 2008-10-13 6:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <20081013041525.GA32629@coredump.intra.peff.net>
Jeff King schrieb:
> On Sun, Oct 12, 2008 at 09:00:50PM -0700, Junio C Hamano wrote:
>> - You teach git-apply to use a reverse transformation of textconv, so
>> that it does, upon reception of a textconv diff:
>>
>> (1) pass existing preimage through textconv;
>> (2) apply the patch;
>> (3) convert the result back to binary.
>
> The problem with this approach is that it requires that the textconv be
> a reversible mapping. And the two motivating examples (dumping exif tags
> and converting word processor documents to text) are not; they are lossy
> conversions.
>
> It's possible that one could, given the binary preimage and the two
> lossy textconv'd versions, produce a custom binary merge that would just
> munge the tags, or just munge the text, or whatever. But that is an
> order of magnitude more work than writing a textconv, which is usually
> as simple as "/path/to/existing/conversion-script".
I fully agree with you. .texconv should only be used for human
consumption. We already have a reversible binary<->text conversion: the
binary diffs.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Johannes Sixt @ 2008-10-13 6:00 UTC (permalink / raw)
To: Alex Riesen
Cc: Dmitry Potapov, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <20081012181836.GA10626@steel.home>
Alex Riesen schrieb:
> I looked at the callers (briefly). Performance could be a problem: add
> and checkout can work with real big file lists and long pathnames.
> So ok, than. It is critical.
You are kidding, aren't you? What you win by a few CPU instructions here
is dwarfed by the time that the stat() implementation requires. Dmitry,
please use the more readable tolower().
-- Hannes
^ permalink raw reply
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-13 4:33 UTC (permalink / raw)
To: gitster; +Cc: spearce, dpotapov, git, Mark Levedahl
In-Reply-To: <7vd4i5fkny.fsf@gitster.siamese.dyndns.org>
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/config.txt | 4 +++-
compat/cygwin.c | 20 +++++++++++++++-----
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..780375e 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,22 +91,32 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if the trust_executable_bit is set, we must use the Cygwin posix
+ * stat/lstat as the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+extern int trust_executable_bit;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "core.ignorecygwinfstricks"))
- native_stat = git_config_bool(var, value);
- return 0;
+ if (!strcmp(var, "core.ignorecygwinfstricks")) {
+ native_stat = git_config_bool(var, value);
+ return 0;
+ }
+ return git_default_config(var, value, cb);
}
static int init_stat(void)
{
if (have_git_dir()) {
git_config(git_cygwin_config, NULL);
- cygwin_stat_fn = native_stat ? cygwin_stat : stat;
- cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
+ if (!trust_executable_bit && native_stat) {
+ cygwin_stat_fn = cygwin_stat;
+ cygwin_lstat_fn = cygwin_lstat;
+ } else {
+ cygwin_stat_fn = stat;
+ cygwin_lstat_fn = lstat;
+ }
return 0;
}
return 1;
--
1.6.0.2.535.ga11fa.dirty
^ permalink raw reply related
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-13 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: spearce, dpotapov, git
In-Reply-To: <7vd4i5fkny.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I was wondering if git_cygwin_config() was originally written not to call
> git_default_config() because some command implementations do not to want
> to call git_default_core_config() (and/or read trust_executable_bit
> variable from the configuration) for some reason (which would be just
> hiding bugs in other parts of the system, I suspect).
>
> If that is the case, we would have to fix such broken parts of the system,
> but until that happens your original patch to use a separate variable and
> keeping trust_executable_bit untouched would be much safer than this
> latest patch. Hence the question.
>
I was worried about altering the startup code, which is why I tried to
introduce as little change as possible. However, having rewritten the
patch using git_default_config() everything seems fine (the testsuite
passes, or at least as well as it usually does under Cygwin, and I
assume that is sufficient as this is Cygiwn specific). So, that patch
follows.
Mark
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Jeff King @ 2008-10-13 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <7vk5cddtzh.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 12, 2008 at 09:00:50PM -0700, Junio C Hamano wrote:
> exchange workflow? There needs either one or both of the following:
>
> - A command line option to Porcelains to override textconv so that an
> applicable binary diff can be obtained upon request (or format-patch
> always disables textconv); and/or
format-patch should always disable textconv. I admit that I didn't test
it, but assumed it was covered under the same code path as external
diff (i.e., just not reading in the config). But it doesn't seem to be.
So that is definitely broken in my patch series. But even once that is
fixed, I agree there should be a porcelain switch for turning this off.
I sometimes do "git diff >patch" and read the result into my MUA.
Obviously I would not want textconv'ing there.
> - You teach git-apply to use a reverse transformation of textconv, so
> that it does, upon reception of a textconv diff:
>
> (1) pass existing preimage through textconv;
> (2) apply the patch;
> (3) convert the result back to binary.
The problem with this approach is that it requires that the textconv be
a reversible mapping. And the two motivating examples (dumping exif tags
and converting word processor documents to text) are not; they are lossy
conversions.
It's possible that one could, given the binary preimage and the two
lossy textconv'd versions, produce a custom binary merge that would just
munge the tags, or just munge the text, or whatever. But that is an
order of magnitude more work than writing a textconv, which is usually
as simple as "/path/to/existing/conversion-script".
And the whole point of this exercise was to make it simple to set this
conversion up.
> I'd say that format-patch should always disable textconv so that we won't
> have to worry about it for now.
Agreed, if you remove "for now". I had never intended for these to be
anything but a human-readable display (and while I am generally OK with
generalizing functionality when we can, I think there is real value in
the simplicity here).
If somebody really wants to send patches with converted text for
reference, I would suggest producing a patch with the textconv'd output
as a comment, and including the full binary patch to actually be
applied (and yes, obviously they a malicious attacker could make them
not match, but given the binary patch, we can trivially regenerate the
textconv'd version and confirm it).
-Peff
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-13 4:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar wrote:
>
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
>
Yes, and Shawn Pierce is working on making HTTP a proper "smart" access
method, based on a proposal I submitted. That is the proper solution,
since it avoids all the braindamage of "dumb" access methods. We
[kernel.org] intend to deploy it as soon as it is available.
-hpa
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-13 4:07 UTC (permalink / raw)
To: Petr Baudis
Cc: Ingo Molnar, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012153952.GV10544@machine.or.cz>
Petr Baudis wrote:
> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
>> hm, -tip's .git/hooks/post-update already contained this, for the last 2
>> months:
>>
>> exec git update-server-info
>>
>> so ... _despite_ us having this in the git repo, the HTTP protocol still
>> does not work. Why?
>
> I think your problem is that HTTP does not know where to look for
> objects coming from alternates; IIRC this would work if you used
> relative paths in objects/info/alternates, or you can create
> objects/info/http-alternates like
>
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
Yes, alternates must not contain paths referencing /home/ftp.
-hpa
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Junio C Hamano @ 2008-10-13 4:00 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081013012311.GE3768@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> The logic behind the original behaviour was that the file ought to be
>> "diff-able" if you are setting up funcname pattern because the funcname
>> pattern only makes sense if you are doing the textual diff. In other
>> words, "should we do textual diff?" and "what funcname pattern should we
>> use?" are _not_ orthogonal, as wanting to configure the latter does imply
>> that you do want to see the change in the textual diff format.
>
> Yeah, I don't think I can really disagree with that. I had some vague
> notion that it opens the path for adding orthogonal options later. But
> really, I'm not sure that any exist, since they are, by definition
> related to the diff. Unless we want to have diff driver options for how
> to do a binary diff.
I actually have an independent worry about this whole thing.
The textconv filter is primarily for humans to be able to view the diff,
as far as I understand it, but what would this facility do to the patch
exchange workflow? There needs either one or both of the following:
- A command line option to Porcelains to override textconv so that an
applicable binary diff can be obtained upon request (or format-patch
always disables textconv); and/or
- You teach git-apply to use a reverse transformation of textconv, so
that it does, upon reception of a textconv diff:
(1) pass existing preimage through textconv;
(2) apply the patch;
(3) convert the result back to binary.
Even if we do not implement the latter right now in the first round, if we
want to leave the door open for later for it, we would somehow need to
mark such a patch between textconv output so that what kind of reverse
transformation needs to be applied.
I'd say that format-patch should always disable textconv so that we won't
have to worry about it for now. If we enable textconv for format-patch,
we do need to include what textconv filter (or "diff attribute") was used
for the path in the output, so that the receiving end can pick a
corresponding reverse transformation.
^ 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