* Re: Few Questions
From: Jakub Narebski @ 2009-01-20 15:44 UTC (permalink / raw)
To: m.arya; +Cc: git
In-Reply-To: <726600.29783.qm@web35708.mail.mud.yahoo.com>
"Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> Hi,
>
> I am new to Git. Earlier I have configured svn with LDAP auth and
> svnwebclient.
>
> I want to have following with Git
>
> - LDAP and ssh authentication.
>
Instead of inventing (and failing) its own protocol and its own
authentication git uses established solutions for authentication: SSH
for "smart" server, and WebDAV for push via (currently only "dumb")
HTTPS protocol.
There exist solutions that help with setting up SSH for git:
git-shell, ssh_acl, and I think most commonly used Gitosis (see
seminal reference about Gitosis on http://git.or.cz/gitwiki/BlogPosts).
> - checkin and checkout using web interface and ssh
>
Git is distributed version control system: checkin (named 'commit' in
git) and checkout are _local_ operations. Fetch (getting new changes
from remote repository) and clone (creating new local repository
following or forking specified remote repository) can be done via
local filesystem, via git:// protocol, via "dumb" HTTP, and via SSH.
Push (sending changes to remote repository) needs autheticated
channel: most common used is SSH, but you can also use WebDAV with
HTTPS.
There are web interfaces for Git, something like SVN::Web or ViewVC,
like gitweb (in Perl, developed in git.git repository) and cgit (in C).
See also "Web interfaces" section on InterfacesFrontendsAndTools page
on git wiki.
> - when ever someone checkin something then a email should be send to
> a email address (a mailing list)
If by 'checkin' you mean publishing changes to a server (i.e. push in
git terminology), see for example contrib/hooks/post-receive-email
hook.
> please let me know how to do this with Git
Please learn that Git is _different_ from Subversion, and not try to
follow your SVN workflow and expectations blindly.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Rename detection: Avoid repeated filespec population
From: Björn Steinbrink @ 2009-01-20 15:59 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
In diffcore_rename, we assume that the blob contents in the filespec
aren't required anymore after estimate_similarity has been called and thus
we free it. But estimate_similarity might return early when the file sizes
differ too much. In that case, cnt_data is never set and the next call to
estimate_similarity will populate the filespec again, eventually rereading
the same blob over and over again.
To fix that, we first get the blob sizes and only when the blob contents
are actually required, and when cnt_data will be set, the full filespec is
populated, once.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
This actually affects the copy detection way more than the pure
rename detection, due to the larger number of candidates, but it's the
same code, and I only realized that when I reran the stuff to get some
numbers to show off. ;-)
Test with linux-2.6.git and hot caches:
git diff-tree -p db30c705758^2..db30c705758
| unpatched | patched
------------------------------
plain | 3s | 3s
-M | 4s | 3s
-C | 2m 25s | 9s
-C -C | 4m 30s | 24s
diffcore-rename.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 168a95b..0b0d6b8 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -153,9 +153,9 @@ static int estimate_similarity(struct diff_filespec *src,
* is a possible size - we really should have a flag to
* say whether the size is valid or not!)
*/
- if (!src->cnt_data && diff_populate_filespec(src, 0))
+ if (!src->cnt_data && diff_populate_filespec(src, 1))
return 0;
- if (!dst->cnt_data && diff_populate_filespec(dst, 0))
+ if (!dst->cnt_data && diff_populate_filespec(dst, 1))
return 0;
max_size = ((src->size > dst->size) ? src->size : dst->size);
@@ -173,6 +173,11 @@ static int estimate_similarity(struct diff_filespec *src,
if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
return 0;
+ if (!src->cnt_data && diff_populate_filespec(src, 0))
+ return 0;
+ if (!dst->cnt_data && diff_populate_filespec(dst, 0))
+ return 0;
+
delta_limit = (unsigned long)
(base_size * (MAX_SCORE-minimum_score) / MAX_SCORE);
if (diffcore_count_changes(src, dst,
--
1.6.1.135.g3cf3b
^ permalink raw reply related
* git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-20 15:46 UTC (permalink / raw)
To: git
Hello all,
Back in June I had done a test convert of our CVS repo using git 1.5.5.1
and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
week to finish!). Recently I wanted to try again with the latest
versions of git and cvs2svn.
When I get to the final stage (running git fast-import to build the
converted repo), I get the following output:
cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
fast-import
fatal: Unsupported command: '.
fast-import: dumping crash report to .git/fast_import_crash_19097
The crash is 18MB and I'd rather not post it, but the only bits that
seem somewhat interesting are:
fast-import crash report:
fast-import process: 19097
parent process : 19095
at Mon Jan 19 11:44:42 2009
fatal: Unsupported command: '.
Most Recent Commands Before Crash
---------------------------------
(...)
reset refs/tags/T_9772
from :1000007127
reset refs/heads/TAG.FIXUP
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
* '.
Has anyone got any ideas how to resolve this?
Thanks,
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere Learn more at
www.mqsoftware.com
^ permalink raw reply
* Re: Few Questions
From: Shawn O. Pearce @ 2009-01-20 16:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: m.arya, git
In-Reply-To: <m3r62yx9qi.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> >
> > I want to have following with Git
> >
> > - LDAP and ssh authentication.
> >
>
> Instead of inventing (and failing) its own protocol and its own
> authentication git uses established solutions for authentication: SSH
> for "smart" server, and WebDAV for push via (currently only "dumb")
> HTTPS protocol.
>
> There exist solutions that help with setting up SSH for git:
> git-shell, ssh_acl, and I think most commonly used Gitosis (see
> seminal reference about Gitosis on http://git.or.cz/gitwiki/BlogPosts).
Yup. Gitosis is very popular for this.
At my last job I rolled my own Gitosis-lite, but in Perl, because
they are a Perl based shop. It also uses the update-paranoid hook
for access controls, as its more flexible (and easier to confuse
the heck out of yourself) than Gitosis. But if you can get along
with Gitosis, its a good choice. Unfortunately its authentication
is limited to public keys registered in the authorized keys file
of the "git" user.
<plug type="not-quite-ready-but-will-be-soon">
Gerrit2 is also likely to enter this "market" soon. I'm trying to
get it production ready and live for one major project before the
end of this month. It embeds its own SSH daemon on a non-standard
port, completely disconnected from the OS authentication. This may
make it slightly more palatable in some enviroments then Gitosis,
as you don't need a huge authorized_keys file, and you don't have
to worry quite so much about attack vectors.
Unlike with Gitosis, public key management is placed on end-users
by using web authentication to identify the user, and letting the
user manage their own "authorized key list". It also has a full
blown web based code review system built in. Which right now a
project must use if it is hosted by Gerrit2. :-)
</plug>
--
Shawn.
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-20 16:04 UTC (permalink / raw)
To: Kelly F. Hickel, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
> Back in June I had done a test convert of our CVS repo using git
> 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well
That's a typo. The June conversion used git 1.5.5.1 and cvs2svn 2.1.1
(not 2.2.0 as previously stated).
Sorry for the confusion.
-Kelly
^ permalink raw reply
* CR codes from git commands
From: Brent Goodrick @ 2009-01-20 16:26 UTC (permalink / raw)
To: git
Hi,
I am considering converting from CVS over to using git. I'm currently
using git version 1.5.6.5 on Debian Linux "testing". One of the first
things I ran into was having to set PAGER to "cat" to avoid the
problems when running git from anything other than a terminal. The
second thing is that "git pull" (and possibly other commands) are
emitting ^M (octal 013) codes on output, possibly caused by the same
assumption as causes the problem that is fixed by setting PAGER to
"cat". This is not a big deal on small repos, but on larger ones I
actually do want to see status line output (or be given some option to
see them), so that I can then run "tail -1lf" on the log file that is
written during a long "git pull" operation.
Is there some configuration option or some environment variable I can
set that tells git to stop treating every invocation as if it is
coming from a terminal?
You can reproduce this on Linux with the following script (look for
the CR codes on the final git pull at the end of the script):
-- cut below this line ---
#!/bin/sh
# I could have simply used "set -x" here but then I wouldn't see the
# redirection syntax like ">file1", so instead use a PrintRun
# function:
PrintRun ()
{
echo "COMMAND: $*"
eval "$*; exitcode=\$?"
if [ $exitcode != 0 ]
then
echo "ERROR: Command failed: $*"
exit 1
fi
}
# Failed attempt at hacking around git insisting on using ^M codes on stderr:
# cat >/tmp/git_pager <<EOF
# sed 's%^% >> %g'
# # This doesn't work either since the output I want to filter is on stderr
# # tr '\013' '\012'
# EOF
# chmod a+x /tmp/git_pager
# GIT_PAGER=/tmp/git_pager; export GIT_PAGER
# Clear out the scratch areas:
PrintRun rm -rf /tmp/git_area1
PrintRun rm -rf /tmp/git_area2
# Populate the initial area:
PrintRun mkdir -p /tmp/git_area1
PrintRun cd /tmp/git_area1
PrintRun git init
PrintRun "echo a new file 1 >file1"
PrintRun "echo a new file 2 >file2"
PrintRun git add file1
PrintRun git add file2
PrintRun git status
PrintRun "git commit -m \"first commit in git_area1\""
PrintRun find .
# Clone from the first area into a second area and add a file there:
PrintRun rm -rf /tmp/git_area2
PrintRun cd /tmp
PrintRun git clone /tmp/git_area1 git_area2
PrintRun cd /tmp/git_area2
PrintRun find .
PrintRun "echo a new file 3 >file3"
PrintRun git add file3
PrintRun git status
PrintRun "git commit -m \"second commit but in git_area2\""
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git status; true" # true means don't fail inside PrintRun
# Now attempt to somehow refresh (what is the "git" word for "cvs update"?) into the first area:
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
# PrintRun "git pull /tmp/git_area2 master 2>&1"
# PrintRun "git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012'"
PrintRun git pull /tmp/git_area2 master
-- cut above this line ---
Attempts at hacking around the problem: Redirecting stderr output from
git and then manually translating CR codes into LF codes yeilds the
following output (but I can't do this in practice and, no, I can't use
aliases in Bourne scripts (Bash/KSH yes, Bourne no)):
git> COMMAND: git pull /tmp/git_area2 master 2>&1
git> remote: Counting objects: 4, done.
git> remote: Compressing objects: 50% (1/2)
git> --> remote: Compressing objects: 100% (2/2)
git> --> remote: Compressing objects: 100% (2/2 )Unpacking objects: 33% (1/3)
git> --> Unpacking objects: 66% (2/3)
git> --> Unpacking objects: 100% (3/3)
git> --> Unpacking objects: 100% (3/3), done.
git> remote: , done.
git> remote: Total 3 (delta 0), reused 0 (delta 0)
git> From /tmp/git_area2
git> * branch master -> FETCH_HEAD
git> Updating b2f942d..4f9ba90
git> Fast forward
git> file3 | 1 +
git> 1 files changed, 1 insertions(+), 0 deletions(-)
git> create mode 100644 file3
Trying to automatically filter this with redirection and use of tr
fails to show the progress output completely which is a non-option
either:
git> COMMAND: git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012'
git> From /tmp/git_area2
git> * branch master -> FETCH_HEAD
git> Updating 49b1897..bb5f57c
git> Fast forward
git> file3 | 1 +
git> 1 files changed, 1 insertions(+), 0 deletions(-)
git> create mode 100644 file3
Thanks,
bgoodr
^ permalink raw reply
* Re: [PATCH] Add tests for diff.color-words configuration option.
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901201057080.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Tuesday 2009 January 20 03:58:37 Johannes Schindelin wrote:
>On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> I'm not sure why the diff is crazy long.
>
>Because you changed things that need no changing, such as "cat > expect"
>-> "cat > expect.blabla",
I suppose I could have gotten away with doing this differently, but I did need
to save off some of those results to different files because I wanted to
resuse the results.
>and because you inserted your test instead of
>adding it at the end.
I put the tests in that order explicitly to test that .gitattributes overrides
the configuration option.
I'm going to be reworking both patches anyway, so I should be able to
rearrange things less, in this file.
Thanks for the feedback.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* feature request mergetool, skip, abort
From: Caleb Cushing @ 2009-01-20 16:39 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
firstly my patch sucks, and I know it. but hopefully it'll give some
idea of what I'm trying to do and someone can implement it properly.
basically there are some files, that I can't merge with git, but I
need to merge other files before I can fix those and I like to use
mergetool, so I want a way to skip the files I'm not going to be able
to merge.
--
Caleb Cushing
http://xenoterracide.blogspot.com
[-- Attachment #2: 0001-preliminary-merge-skip-abort-patch.patch --]
[-- Type: application/octet-stream, Size: 1223 bytes --]
From b43603bcd408cccea7ba55041a8356d0ca536989 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] preliminary merge/skip/abort patch
---
git-mergetool.sh | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..c0b27ed 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,11 +177,25 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
- fi
+ while true; do
+ printf "Use (m)erge file or (s)skip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*)
+ break
+ ;;
+ [sS]*)
+ return 0 #go to the next file, needs to clean up
+ ;;
+ [aA]*)
+ return 1 #should exit immediately, doesn't
+ ;;
+ esac
+ done
+ fi
- case "$merge_tool" in
+ case "$merge_tool" in
kdiff3)
if base_present ; then
("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
--
1.6.1
^ permalink raw reply related
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Johannes Schindelin @ 2009-01-20 16:41 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
Hi,
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
That is strange. The command "data 88" should read the next 88 bytes and
not stop at the line starting with '.
Just to test, I successfully imported this:
-- snip --
commit refs/heads/testing/test
mark :1
committer cvs2svn <cvs2svn> 1002043747 +0000
data 3
'.
-- snap --
So I guess the problem lies much earlier: I could imagine that there is
_another_ "data" command that has a bogus length and just happens to end
after the line "data 88".
Maybe that helps?
I could also imagine that the '. actually is the end of an example
inside a blob, that literally looks like a fast-import script, but
actually is not meant for _this_ fast-import run.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 16:51 UTC (permalink / raw)
To: Brian Foster; +Cc: Reece Dunn, git list
In-Reply-To: <200901200912.14432.brian.foster@innova-card.com>
On Tue, Jan 20, 2009 at 1:42 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
> On Monday 19 January 2009 15:37:06 Dilip M wrote:
>> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
>> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
>> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
>> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
>> >> not found'
>> >
>> > Who is the owner of the repository directory (and the .git directory)
>> > and what are the permissions on the directory? [ ... ]
>>
>> dm-laptop:~/repos/atria> id -a
>> uid=1000(dm) gid=1000(dm) [ ... ]
>> dm-laptop:~/repos/atria> ls -lh .git/
>>[... all looks Ok ...]
>
> repeating Reece's question, what is the permissions/owner
> _of_the_directory_which_contains_ the '.git/' directory?
> I can reproduce this behaviour (git 1.6.0.4) simply by
> denying myself search (née execute) permission on that
> directory, for entirely obvious reasons.
It's the same issue....Any ENV variable I can set to debug this...?
dm-laptop:~/repos/atria> id -a
uid=1000(dm) gid=1000(dm)
groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),1000(dm)
dm-laptop:~/repos/atria> ls -ld .git
drwxr-xr-x 8 dm dm 4096 2009-01-19 22:34 .git
dm-laptop:~/repos/atria> ls -la .git
total 68
drwxr-xr-x 8 dm dm 4096 2009-01-19 22:34 .
drwxr-xr-x 6 dm dm 4096 2009-01-18 23:28 ..
drwxr-xr-x 2 dm dm 4096 2009-01-18 23:24 branches
-rw-r--r-- 1 dm dm 20 2009-01-19 22:28 COMMIT_EDITMSG
-rw-r--r-- 1 dm dm 256 2009-01-18 23:28 config
-rw-r--r-- 1 dm dm 58 2009-01-18 23:24 description
-rw-r--r-- 1 dm dm 89 2009-01-19 20:15 FETCH_HEAD
-rw-r--r-- 1 dm dm 23 2009-01-19 21:49 HEAD
drwxr-xr-x 2 dm dm 4096 2009-01-18 23:24 hooks
-rw-r--r-- 1 dm dm 5280 2009-01-19 22:28 index
drwxr-xr-x 2 dm dm 4096 2009-01-19 22:34 info
drwxr-xr-x 3 dm dm 4096 2009-01-19 22:34 logs
drwxr-xr-x 4 dm dm 4096 2009-01-19 22:34 objects
-rw-r--r-- 1 dm dm 41 2009-01-19 20:15 ORIG_HEAD
-rw-r--r-- 1 dm dm 153 2009-01-19 22:34 packed-refs
drwxr-xr-x 5 dm dm 4096 2009-01-18 23:28 refs
dm-laptop:~/repos/atria> umask
22
-- DM
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901201058520.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
On Tuesday 2009 January 20 04:02:00 you wrote:
>On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> diff --git a/diff.c b/diff.c
>> index 9fcde96..c53e1d1 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -23,6 +23,7 @@ static int diff_detect_rename_default;
>> static int diff_rename_limit_default = 200;
>> static int diff_suppress_blank_empty;
>> int diff_use_color_default = -1;
>> +static const char *diff_color_words_cfg = NULL;
>> static const char *external_diff_cmd_cfg;
>
>Guess why external_diff_cmd_cfg is not set to NULL? All variables
>defined outside a function are set to all-zero anyway.
I suppose I just initialize variables by reflex, having been bitten with too
many sometimes-crashes due to variables that were usually-zero. Assuming C
does guarantee that it is zeroed, I'll drop the " = NULL" line noise in the
next version.
>> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char
>> *value, void *cb) }
>> if (!strcmp(var, "diff.external"))
>> return git_config_string(&external_diff_cmd_cfg, var, value);
>> + if (!strcmp(var, "diff.color-words"))
>
>I'd call it diff.wordregex, because that's what it is.
I don't like runtogetherwords because they are hard to read for me; I tend to
choose the wrong word breaks if it is ambiguous. There are other
configuration values that use camelCaseWords so I will convert over to using
that.
I thought "word regex" made more sense, but I wanted to match the command-line
option. Will change.
>> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
>> o->word_regex = userdiff_word_regex(one);
>> if (!o->word_regex)
>> o->word_regex = userdiff_word_regex(two);
>> + if (!o->word_regex)
>> + o->word_regex = diff_color_words_cfg;
>
>IMHO this is the wrong order. config should not override attributes,
>which are by definition more specific.
You are up too late Dscho. This ordering makes the config not override
attributes. If one of the files has a diff driver, o->word_regex will be set
to it (and become non-NULL). That will prevent execution of the body of the
added "if (!o->word_regex)" -- preventing the configuration option from being
used.
>> diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
>> index 6ebce9d..a207d9e 100755
>> --- a/t/t4034-diff-words.sh
>> +++ b/t/t4034-diff-words.sh
>> @@ -105,7 +105,7 @@ a = b + c<RESET>
>> EOF
>> cp expect.non-whitespace-is-word expect
>>
>> -test_expect_failure 'use default supplied by config' '
>> +test_expect_success 'use default supplied by config' '
>
>Let's squash the two, okay?
Will do. I expected the code changes to be larger than the test, and when I
finished it was completely the other way. My next patch will be all-in-one.
Thanks for your feedback.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add tests for diff.color-words configuration option.
From: Johannes Schindelin @ 2009-01-20 16:54 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201034.22478.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> On Tuesday 2009 January 20 03:58:37 Johannes Schindelin wrote:
> >On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
> >> I'm not sure why the diff is crazy long.
> >
> >Because you changed things that need no changing, such as "cat > expect"
> >-> "cat > expect.blabla",
>
> I suppose I could have gotten away with doing this differently, but I
> did need to save off some of those results to different files because I
> wanted to resuse the results.
Why didn't you do that, then?
cp expect expect.for-later-use
> >and because you inserted your test instead of adding it at the end.
>
> I put the tests in that order explicitly to test that .gitattributes
> overrides the configuration option.
Why not just remove the .gitattributes for your second test?
It would be much clearer that you did not modify any existing tests, then.
Ciao,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901201001.54979.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On Tuesday 2009 January 20 03:01:50 Thomas Rast wrote:
>It was really intended as a toy patch, but if people find it useful
>(Boyd?) I can add the rest of the options so that all searches can be
>chosen independently, and shape it as a "real" contrib patch.
I'll test it out later today and get back to you.
[OT]
I actually prefer Stephen; My father is Boyd.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-20 17:08 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <18805.64312.289059.660023@hungover.brentg.com>
Hi,
On Tue, 20 Jan 2009, Brent Goodrick wrote:
> I am considering converting from CVS over to using git. I'm currently
> using git version 1.5.6.5 on Debian Linux "testing".
First of all, 1.5.6.5 is from last August, so chances are that the
behavior you complain about was fixed in the meantime. We're at 1.6.1 at
the moment.
> One of the first things I ran into was having to set PAGER to "cat" to
> avoid the problems when running git from anything other than a terminal.
> The second thing is that "git pull" (and possibly other commands) are
> emitting ^M (octal 013) codes on output, possibly caused by the same
> assumption as causes the problem that is fixed by setting PAGER to
> "cat".
The only place I can think about where a CR is output is when showing the
progress of downloading.
Usually, our code checks if stdout is a tty, and does not show progress.
As a work-around, piping into cat should work, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 17:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901201058520.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
>> }
>> if (!strcmp(var, "diff.external"))
>> return git_config_string(&external_diff_cmd_cfg, var, value);
>> + if (!strcmp(var, "diff.color-words"))
>
> I'd call it diff.wordregex, because that's what it is.
If we want to add a new word-oriented option to diff that is not about
coloring the word differences, is it safe and sane to reuse the same
definition? That is, "git diff --color-words" would be affected when
diff.wordregex is set to some value, so does any new word-oriented
operation we will add, and the single regex configured would be used as
the default value to define how a word would look like.
I think it makes sense; I do not think of a case offhand where you would
want to define what a word is for the purpose of coloring diffs in one
way, and would want to use a different definition for another
word-oriented operation.
>> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
>> o->word_regex = userdiff_word_regex(one);
>> if (!o->word_regex)
>> o->word_regex = userdiff_word_regex(two);
>> + if (!o->word_regex)
>> + o->word_regex = diff_color_words_cfg;
>
> IMHO this is the wrong order. config should not override attributes,
> which are by definition more specific.
Isn't it merely giving a fallback value when attributes does not give one?
By the way, wouldn't it make sense to optimize the precontext of that hunk
by doing _something_ like:
if (!o->word_regex && strcmp(one->path, two->path))
o->word_regex = userdiff_word_regex(two);
"Something like" comes from special cases like /dev/null for new/deleted
files, etc.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 17:14 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201053.03256.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> You are up too late Dscho.
You, sir, are absolutely correct.
> >Let's squash the two, okay?
>
> Will do. I expected the code changes to be larger than the test, and
> when I finished it was completely the other way. My next patch will be
> all-in-one.
FWIW I think it is the correct thing to start with the test script, so
that you get a better idea what to look out for.
And for patches of which I don't know if they are still necessary, I like
to "git checkout <name>^ && make -j50 && git checkout <name> && (cd t &&
sh <test>)".
But for submission, I think it makes sense to squash them, except if you
submit a bug report with a test script to show the validity of the report
first, and only later decide that you want to fix it yourself.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Matthieu Moy @ 2009-01-20 17:10 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901200851n21c6d67r3c43e3efd435e3db@mail.gmail.com>
"Dilip M" <dilipm79@gmail.com> writes:
>> repeating Reece's question, what is the permissions/owner
>> _of_the_directory_which_contains_ the '.git/' directory?
>> I can reproduce this behaviour (git 1.6.0.4) simply by
>> denying myself search (née execute) permission on that
>> directory, for entirely obvious reasons.
>
> It's the same issue....
You didn't answer the question.
> Any ENV variable I can set to debug this...?
GIT_TRACE can help.
--
Matthieu
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Johannes Schindelin @ 2009-01-20 17:16 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901200851n21c6d67r3c43e3efd435e3db@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1266 bytes --]
Hi,
On Tue, 20 Jan 2009, Dilip M wrote:
> On Tue, Jan 20, 2009 at 1:42 PM, Brian Foster
> <brian.foster@innova-card.com> wrote:
> > On Monday 19 January 2009 15:37:06 Dilip M wrote:
> >> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> >> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
> >> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> >> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> >> >> not found'
> >> >
> >> > Who is the owner of the repository directory (and the .git directory)
> >> > and what are the permissions on the directory? [ ... ]
> >>
> >> dm-laptop:~/repos/atria> id -a
> >> uid=1000(dm) gid=1000(dm) [ ... ]
> >> dm-laptop:~/repos/atria> ls -lh .git/
> >>[... all looks Ok ...]
> >
> > repeating Reece's question, what is the permissions/owner
> > _of_the_directory_which_contains_ the '.git/' directory?
> > I can reproduce this behaviour (git 1.6.0.4) simply by
> > denying myself search (née execute) permission on that
> > directory, for entirely obvious reasons.
>
> It's the same issue....Any ENV variable I can set to debug this...?
I'd try running it with strace, and then search the output for stat()
calls involving <something>/.git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 17:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <7vskndkip9.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 20 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
> >> }
> >> if (!strcmp(var, "diff.external"))
> >> return git_config_string(&external_diff_cmd_cfg, var, value);
> >> + if (!strcmp(var, "diff.color-words"))
> >
> > I'd call it diff.wordregex, because that's what it is.
>
> If we want to add a new word-oriented option to diff that is not about
> coloring the word differences, is it safe and sane to reuse the same
> definition? That is, "git diff --color-words" would be affected when
> diff.wordregex is set to some value, so does any new word-oriented
> operation we will add, and the single regex configured would be used as
> the default value to define how a word would look like.
>
> I think it makes sense; I do not think of a case offhand where you would
> want to define what a word is for the purpose of coloring diffs in one
> way, and would want to use a different definition for another
> word-oriented operation.
Why not cross that bridge when we're there? Should we ever feel the need
for different word regexes, we would just introduce color.wordregex.
> >> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
> >> o->word_regex = userdiff_word_regex(one);
> >> if (!o->word_regex)
> >> o->word_regex = userdiff_word_regex(two);
> >> + if (!o->word_regex)
> >> + o->word_regex = diff_color_words_cfg;
> >
> > IMHO this is the wrong order. config should not override attributes,
> > which are by definition more specific.
>
> Isn't it merely giving a fallback value when attributes does not give one?
Yep. Boyd (or Stephen, as he wants to be called, making it hard to guess
from his email address, but that's all part of the fun, in't it?) already
realized that I was up too late and got the order wrong myself.
> By the way, wouldn't it make sense to optimize the precontext of that
> hunk by doing _something_ like:
>
> if (!o->word_regex && strcmp(one->path, two->path))
> o->word_regex = userdiff_word_regex(two);
>
> "Something like" comes from special cases like /dev/null for new/deleted
> files, etc.
You mean to avoid the cost of initializing the regex in case one and the
same file is diffed against itself? But that would be better handled
before calling builtin_diff(), don't you think?
I do not know off-hand if diffcore_std() handles that already, so that the
diff_flush() ... builtin_diff() cascade is not even called.
But you raise a valid concern: the regular expression is initialized every
time we look at a file. We probably should have a member
word_regex_compiled in diff_options, then, and only initialize it the
first time.
Ciao,
Dscho "who does not have the time to work on Git right now"
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 17:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <vpq4oztgaz8.fsf@bauges.imag.fr>
On Tue, Jan 20, 2009 at 10:40 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Dilip M" <dilipm79@gmail.com> writes:
>
>>> repeating Reece's question, what is the permissions/owner
>>> _of_the_directory_which_contains_ the '.git/' directory?
>>> I can reproduce this behaviour (git 1.6.0.4) simply by
>>> denying myself search (née execute) permission on that
>>> directory, for entirely obvious reasons.
>>
>> It's the same issue....
>
> You didn't answer the question.
Sorry..I read it for .git directory...
.git's parent directory is owned by user who us issuing gitk command
and permisssion bit of 755 is set.
dm-laptop:~/repos/atria> ls -ld .
drwxr-xr-x 6 dm dm 4096 2009-01-18 23:28 .
dm-laptop:~/repos/atria> ls -ld .git/
drwxr-xr-x 8 dm dm 4096 2009-01-20 22:22 .git/
>> Any ENV variable I can set to debug this...?
>
> GIT_TRACE can help.
I tried with that but it didn't help for gitk. But sure, it helps with
git command(s).
-- DM
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Markus Heidelberg @ 2009-01-20 17:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Johannes Schindelin, Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <7v1vuympie.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.01.2009:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>
> > When diff is invoked with --color-words (w/o =regex), use the regular
> > expression the user has configured as diff.color-words.
> >
> > diff drivers configured via attributes take precedence over the
> > diff.color-words setting. If the user wants to change them, they have
> > their own configuration variables.
>
> This needs an entry in Documentation/config.txt
>
> None of the existing configuration variables defined use hyphens in
> multi-word variable names.
Except for diff.suppress-blank-empty
Should it be converted or is it intention to reflect GNU diff's option?
Markus
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: Kirill Smelkov @ 2009-01-20 17:56 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20090120002103.GA12549@lapse.rw.madduck.net>
On Tue, Jan 20, 2009 at 11:21:03AM +1100, martin f krafft wrote:
> also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.19.0206 +1100]:
> > I don't understand why this gets ignored. Maybe I do something wrong?
>
> I am not ignoring it, I am just currently flooded and travelling.
> I don't see any obvious problems with your patch, but I do not have
> the time to test it right now. I will do my best to do another
> release when I return from Tasmania, hopefully on the plane trip
> home. Maybe Petr can get around to it before I do.
>
> Cheers, and sorry,
No problem and take your time.
It was just me having no idea about what's going on.
Happy travelling,
Kirill
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-20 17:58 UTC (permalink / raw)
To: markus.heidelberg
Cc: Junio C Hamano, Johannes Schindelin, Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <200901201842.24000.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Tuesday 2009 January 20 11:42:23 Markus Heidelberg wrote:
>Junio C Hamano, 20.01.2009:
>> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>> > When diff is invoked with --color-words (w/o =regex), use the regular
>> > expression the user has configured as diff.color-words.
>> >
>> > diff drivers configured via attributes take precedence over the
>> > diff.color-words setting. If the user wants to change them, they have
>> > their own configuration variables.
>>
>> This needs an entry in Documentation/config.txt
>>
>> None of the existing configuration variables defined use hyphens in
>> multi-word variable names.
>
>Except for diff.suppress-blank-empty
>Should it be converted or is it intention to reflect GNU diff's option?
I think best would be to have a project policy, use that for the wordRegex
option and other options moving forward, then fix the others at some point in
the future (1.7?) while having some period of time where both old and "per
policy" names work. But, then I'm a big fan of standardization.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Reece Dunn @ 2009-01-20 18:00 UTC (permalink / raw)
To: Dilip M; +Cc: Matthieu Moy, Brian Foster, git list
In-Reply-To: <c94f8e120901200935t75dba11fw3ce14b4ba965c878@mail.gmail.com>
2009/1/20 Dilip M <dilipm79@gmail.com>:
> On Tue, Jan 20, 2009 at 10:40 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> "Dilip M" <dilipm79@gmail.com> writes:
>>
>>>> repeating Reece's question, what is the permissions/owner
>>>> _of_the_directory_which_contains_ the '.git/' directory?
>>>> I can reproduce this behaviour (git 1.6.0.4) simply by
>>>> denying myself search (née execute) permission on that
>>>> directory, for entirely obvious reasons.
>>>
>>> It's the same issue....
>>
>> You didn't answer the question.
>
> Sorry..I read it for .git directory...
>
> .git's parent directory is owned by user who us issuing gitk command
> and permisssion bit of 755 is set.
>
>>> Any ENV variable I can set to debug this...?
>>
>> GIT_TRACE can help.
>
> I tried with that but it didn't help for gitk. But sure, it helps with
> git command(s).
So can you run git commands that modify the git tree, e.g. git add? If
these are failing, that may explain why gitk is failing, and you can
use GIT_TRACE.
Also, do you know what commands are being executed by gitk that are
causing the failure you are experiencing?
Or... is your ENV (e.g. your PATH) the same for dm and root? In
particular, can they find the git commands? This would also be visible
by not being able to do things like `git log` (or, if it is an issue
with the deprecation of the `git-foo`-style command invocation, is the
GIT_EXEC_PATH set to point to the correct location and does dm have
the rights to execute it -- that is, is the x bit set for the
GIT_EXEC_PATH directory, as per
http://www.digizenstudio.com/blog/2008/11/09/weird-git-gui-startup-problem/?).
What error message are you getting from gitk? Is it possible to debug
gitk to find out what command is being executed and what error
code/exception it is returning/throwing?
- Reece
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <alpine.DEB.1.00.0901201815010.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 10:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 'd try running it with strace, and then search the output for stat()
> calls involving <something>/.git.
Seems like we are almost there....here is the log..
dm-laptop:~/repos/atria> grep gitk /tmp/gitk_1.log
execve("/usr/bin/gitk", ["/usr/bin/gitk"], [/* 37 vars */]) = 0
open("/usr/bin/gitk", O_RDONLY) = 3
execve("/usr/bin/wish8.4", ["/usr/bin/wish8.4", "/usr/bin/gitk",
"--"], [/* 37 vars */]) = 0
stat("/usr/bin/gitk", {st_mode=S_IFREG|0755, st_size=237778, ...}) = 0
open("/usr/bin/gitk", O_RDONLY) = 6
lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/usr/share/gitk/lib/msgs/en_in.msg", F_OK) = -1 ENOENT (No
such file or directory) <======
lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/usr/share/gitk/lib/msgs/en.msg", F_OK) = -1 ENOENT (No such
file or directory) <======
stat("/home/dm/.gitk", {st_mode=S_IFREG|0644, st_size=683, ...}) = 0
open("/home/dm/.gitk", O_RDONLY) = 6
writev(5, [{"\22\0\7\0\16\0@\3\'\0\0\0\37\0\0\0\10NG\0\4\0\0\0gitk\20"...,
48}], 1) = 48
writev(5, [{"\22\0\7\0\16\0@\3(\1\0\0\37\1\0\0\10AME\4\0\0\0gitk\22"...,
112}], 1) = 112
dm-laptop:~/repos/atria> ls -l /usr/share/gitk/lib/msgs/en_in.msg
ls: cannot access /usr/share/gitk/lib/msgs/en_in.msg: No such file or directory
But how is it working when I do 'sudo'..
-- DM
^ 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