* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-19 14:37 UTC (permalink / raw)
To: Reece Dunn; +Cc: git list
In-Reply-To: <3f4fd2640901190359w39ded50ds246903808e94246c@mail.gmail.com>
On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> 2009/1/19 Dilip M <dilipm79@gmail.com>:
>> Hi,
>>
>> ..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? You can run (on the
> command line from the Terminal program):
>
> ls -lh directory
>
> to find this out (where directory is the directory you are interested
> in) and run:
>
> sudo chown user -R directory
>
> to change ownership of that directory (and all of its content) to the
> specified user (i.e. the one you are currently logged in as). This
> will make it so that you own that directory and can make changes to
> it. This should allow you to run gitk without using sudo.
Even I suspected that it may be related to some permission and checked
them...But I couldn't find the actual cause.
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 -lh .git/
total 44K
drwxr-xr-x 2 dm dm 4.0K 2009-01-18 23:24 branches
-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 23 2009-01-18 23:28 HEAD
drwxr-xr-x 2 dm dm 4.0K 2009-01-18 23:24 hooks
-rw-r--r-- 1 dm dm 3.8K 2009-01-18 23:28 index
drwxr-xr-x 2 dm dm 4.0K 2009-01-18 23:24 info
drwxr-xr-x 3 dm dm 4.0K 2009-01-18 23:28 logs
drwxr-xr-x 4 dm dm 4.0K 2009-01-18 23:24 objects
-rw-r--r-- 1 dm dm 94 2009-01-18 23:28 packed-refs
drwxr-xr-x 5 dm dm 4.0K 2009-01-18 23:28 refs
'dm' is a user I created while installing Ubuntu.
dm-laptop:~/repos/atria> ls -l `which gitk`
-rwxr-xr-x 1 root root 237778 2008-04-08 22:31 /usr/bin/gitk
dm-laptop:~/repos/atria>
-- DM
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-19 15:35 UTC (permalink / raw)
To: Jing Xue; +Cc: git list
In-Reply-To: <20090119144836.GD5625@jabba.hq.digizenstudio.com>
On Mon, Jan 19, 2009 at 8:18 PM, Jing Xue <jingxue@digizenstudio.com> wrote:
> On Mon, Jan 19, 2009 at 03:46:41PM +0530, Dilip M wrote:
>> Hi,
>>
>> ..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'
>
> Do you have a 0027 umask?
>
> http://www.digizenstudio.com/blog/2008/11/09/weird-git-gui-startup-problem/
Mine is dm-laptop:~> umask
22
So, that's not a issue.
-- DM
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Julian Phillips @ 2009-01-19 16:29 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901181855400.20741@asgard.lang.hm>
On Sun, 18 Jan 2009, david@lang.hm wrote:
> for linux I want to track both the linus tree and the -stable tree. Ideally I
> want to be able to do a checkout of tags from either tree from the same
> directory (along with diffs between items in both trees, etc)
>
> I have found documentation on how to clone from each of them, but I haven't
> found any simple documentation on how to work with both of them.
You could always just use
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
? It already contains both the linus tree and all the stable trees ...
>
> David Lang
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Julian
---
Flattery is like cologne -- to be smelled, but not swallowed.
-- Josh Billings
^ permalink raw reply
* Shallow submodule update/clone?
From: Chas Emerick @ 2009-01-19 16:59 UTC (permalink / raw)
To: git
Is there a way to cause 'git submodule update' to perform a shallow
clone of some or all of a repo's submodules?
Ideally, I'd like to be able to specify that particular submodules be
shallowly cloned all the time (perhaps by specifying a default --depth
when doing 'git submodule add ...'). Just an idea, there.
Cheers,
- Chas
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Shawn O. Pearce @ 2009-01-19 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vwsct2xd1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then
> > + git update-index --refresh >/dev/null 2>&1 || w="*"
>
> This makes the feature unavailable for people who care about the stat
> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
Yup, and I'm one of those people who sets autorefresindex to false
in my ~/.gitconfig, usually before I even have user.{name,email} set.
I do like the idea of what Thomas is trying to do here, but its
so bloody expensive to compute dirty state on every prompt in
some repositories that I'd shoot myself. E.g. WebKit is huge,
computing the dirty state inside of the WebKit repository on each
prompt would absolutely kill CLI performance to a point of it not
being usuable. But git.git is small enough its OK on pretty much
everything except Cygwin.
So as much as I'd like to use this without the update-index --refresh
bit, I'm not sure its viable in every project out there. If we had
an inotify sort of daemon to keep the data current so the prompt
doesn't have to stat every source file on every display it would
be reasonable, but we don't have such a thing yet for Git.
--
Shawn.
^ permalink raw reply
* Re: [PATCH next resend] bash completion: refactor diff options
From: Shawn O. Pearce @ 2009-01-19 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vtz7xytdo.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > +__git_diff_common_options="--stat --numstat --shortstat --summary
> > --patch-with-stat --name-only --name-status --color
> > --no-color --color-words --no-renames --check
> > --full-index --binary --abbrev --diff-filter=
> > - --find-copies-harder --pickaxe-all --pickaxe-regex
> > + --find-copies-harder
>
> The changes around pickaxe made me "Huh?". For log pickaxe makes very
> good sense but for a single diff it doesn't, yet the original seems to
> have had them only on "git diff" and not on "git log", which feels wrong.
>
> Other than that, I think the patch tries to achieve a great thing in the
> longer term---we do not have to worry about common parts going out of sync
> between diff and log family of commands.
I agree completely. The pickaxe stuff in current completion is
just plain wrong. I'd like to see it fixed with this cleanup.
Maybe do it in two parts; fix the pickaxe options to be on log
and not diff, and then do the cleanup for the common options.
--
Shawn.
^ permalink raw reply
* [PATCH] shell: Document that 'cvs server' is a valid command
From: Lars Noschinski @ 2009-01-19 17:06 UTC (permalink / raw)
To: git; +Cc: gitster, Lars Noschinski
git-shell's man page explicitly lists all allowed commands, but 'cvs
server' was missing. Add it.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
Documentation/git-shell.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
index ff420f8..3f8d973 100644
--- a/Documentation/git-shell.txt
+++ b/Documentation/git-shell.txt
@@ -18,8 +18,9 @@ of server-side GIT commands implementing the pull/push functionality.
The commands can be executed only by the '-c' option; the shell is not
interactive.
-Currently, only the 'git-receive-pack' and 'git-upload-pack' commands
-are permitted to be called, with a single required argument.
+Currently, only three commands are permitted to be called, 'git-receive-pack'
+'git-upload-pack' with a single required argument or 'cvs server' (to invoke
+'git-cvsserver').
Author
------
--
1.6.0.6
^ permalink raw reply related
* Re: how to omit rename file when commit
From: Boyd Stephen Smith Jr. @ 2009-01-19 17:41 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901190135k71087673p85e995878e539a8f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On Monday 2009 January 19 03:35:41 you wrote:
>For example:
>there are 2 file. a.c and e.c
>I modify e.c.
>and git mv a.c b.c
>
>git update-index e.c
>
>I just want to commit e.c and don't commit rename(a.c -> b.c)
Here, it looks like all you need to do is follow the instructions given by git
status--use "git reset HEAD" on each file you want unstaged:
$ rm -rf test && mkdir test
$ cd test
/home/bss/test
$ git init
Initialized empty Git repository in /home/bss/test/.git/
$ echo b > a.c; echo d > e.c
$ git add a.c b.c e.c
$ git commit -m 'Setup'
Created initial commit fc9d26e: Setup
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 a.c
create mode 100644 e.c
$ git mv a.c b.c
$ echo e > e.c
$ git add e.c
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: a.c -> b.c
# modified: e.c
#
$ git reset HEAD -- a.c b.c
a.c: locally modified
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: e.c
#
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: a.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# b.c
$ git commit -m 'e.c: Fix typo'
Created commit c23b226: e.c: Fix typo
1 files changed, 1 insertions(+), 1 deletions(-)
$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: a.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# b.c
no changes added to commit (use "git add" and/or "git commit -a")
HTH.
--
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 6/7 v2] Compute prefix at runtime if RUNTIME_PREFIX is set
From: Johannes Schindelin @ 2009-01-19 17:41 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Sixt
In-Reply-To: <1232280015-8144-7-git-send-email-prohaska@zib.de>
Hi,
On Sun, 18 Jan 2009, Steffen Prohaska wrote:
> + if (!prefix) {
> + const char *strip[] = {
> + GIT_EXEC_PATH,
> + BINDIR,
> + 0
> + };
> + const char **s;
> +
> + for (s = strip; *s; s++) {
> + const char *sargv = argv0_path + strlen(argv0_path);
This does not need to be recomputed all the time, right?
> + const char *ss = *s + strlen(*s);
> + while (argv0_path < sargv && *s < ss
> + && (*sargv == *ss ||
> + (is_dir_sep(*sargv) && is_dir_sep(*ss)))) {
> + sargv--;
> + ss--;
> + }
> + if (*s == ss) {
> + struct strbuf d = STRBUF_INIT;
> + /* We also skip the trailing directory separator. */
> + assert(sargv - argv0_path - 1 >= 0);
> + strbuf_add(&d, argv0_path, sargv - argv0_path - 1);
> + prefix = strbuf_detach(&d, NULL);
> + break;
> + }
> + }
> + }
I have a definite feeling that this code would be easier to read if it
resembled this:
/* sets prefix if the suffix matches (modulo separator changes) */
static int strip_path_suffix(const char *path, const char *suffix,
char **prefix)
{
int path_len = strlen(path), suffix_len = strlen(suffix);
while (suffix_len) {
if (!path_len)
return 1;
path_len--; suffix_len--;
/* strip arbitrary amount of directory separators */
if (is_dir_sep(path[path_len]) &&
is_dir_sep(suffix[suffix_len])) {
while (path_len && is_dir_sep(path[path_len]))
path_len--;
while (suffix_len && is_dir_sep(suffix[suffix_len]))
suffix_len--;
}
else if (path[path_len] != suffix[suffix_len])
return 1;
}
while (path_len && is_dir_sep(path[path_len - 1]))
path_len--;
prefix = xstrndup(path, path_len);
return 0;
}
...
if (!prefix && strip_path_suffix(argv0_path, GIT_EXEC_PATH) &&
strip_path_suffix(argv0_path, BINDIR)) {
prefix = PREFIX;
...
Note: this function could be exported in path.c, as it also handles the
"a//bin" vs "a/bin" case.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT PATCH 8/8] Define a basic merge API, and a two-way tree merge strategy
From: Shawn O. Pearce @ 2009-01-19 17:42 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: Robin Rosenberg, git
In-Reply-To: <f299b4f30901171116y216835c9jc11df2d424ee0377@mail.gmail.com>
Tomi Pakarinen <tomi.pakarinen@gmail.com> wrote:
> testTrivialTwoWay_disjointhistories() failed because merge strategy
> didn't handle missing base
> version. Am'i right?
I don't think so.
> @@ -119,13 +120,26 @@ protected boolean mergeImpl() throws IOException {
> }
>
> final int modeB = tw.getRawMode(T_BASE);
Under a missing base condition modeB == 0. So,
> - if (modeB == modeO && tw.idEqual(T_BASE, T_OURS))
> - add(T_THEIRS, DirCacheEntry.STAGE_0);
If modeB == 0 and modeO == 0 its not in the base and its not in ours.
Both SHA-1s will be 0{40} and are thus idEqual, so we should enter
this add(T_THEIRS) block. Which is what you tried to write below in
your else block, isn't it?.
> - else if (modeB == modeT && tw.idEqual(T_BASE, T_THEIRS))
> - add(T_OURS, DirCacheEntry.STAGE_0);
Again, if modeB == 0 and modeT == 0 both SHA-1s will be 0{40} and
are idEqual, so we should enter this add(T_OURS) block if both base
and theirs are missing. Which again is what you tried to write in
your else block.
If that isn't coming out right then perhaps tw.idEqual() is busted
for when FileMode is FileMode.MISSING (aka 0). Granted, doing
idEqual on FileMode.MISSING is pointless and just wastes clock
cycles, but it shouldn't harm the algorithm's correctness.
> - else {
> - conflict();
> - hasConflict = true;
> + if (!FileMode.MISSING.equals(modeB)) {
> + if (modeB == modeO && tw.idEqual(T_BASE, T_OURS))
> + add(T_THEIRS, DirCacheEntry.STAGE_0);
> + else if (modeB == modeT && tw.idEqual(T_BASE, T_THEIRS))
> + add(T_OURS, DirCacheEntry.STAGE_0);
> + else {
> + conflict();
> + hasConflict = true;
> + }
> + } else {
> + if (!FileMode.MISSING.equals(modeO)
> + && FileMode.MISSING.equals(modeT))
> + add(T_OURS, DirCacheEntry.STAGE_0);
> + else if (FileMode.MISSING.equals(modeO)
> + && !FileMode.MISSING.equals(modeT))
> + add(T_THEIRS, DirCacheEntry.STAGE_0);
> + else {
> + conflict();
> + hasConflict = true;
> + }
> }
> }
> builder.finish();
> --
> 1.6.0.4
--
Shawn.
^ permalink raw reply
* Re: [PATCH] shell: Document that 'cvs server' is a valid command
From: Johannes Schindelin @ 2009-01-19 17:49 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, gitster
In-Reply-To: <1232384803-29373-1-git-send-email-lars@public.noschinski.de>
Hi,
On Mon, 19 Jan 2009, Lars Noschinski wrote:
> git-shell's man page explicitly lists all allowed commands, but 'cvs
> server' was missing. Add it.
Oops (has been there since Oct 7 _2007_). Thank you,
Dscho
^ permalink raw reply
* Re: [JGIT PATCH 8/8] Define a basic merge API, and a two-way tree merge strategy
From: Shawn O. Pearce @ 2009-01-19 17:51 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: Robin Rosenberg, git
In-Reply-To: <20090119174254.GC14053@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Tomi Pakarinen <tomi.pakarinen@gmail.com> wrote:
> > testTrivialTwoWay_disjointhistories() failed because merge strategy
> > didn't handle missing base
> > version. Am'i right?
>
> If that isn't coming out right then perhaps tw.idEqual() is busted
Yup, that's what it is, idEqual is busted.
The definition of TreeWalk.idEqual is:
public boolean idEqual(final int nthA, final int nthB) {
final AbstractTreeIterator ch = currentHead;
final AbstractTreeIterator a = trees[nthA];
final AbstractTreeIterator b = trees[nthB];
return a.matches == ch && b.matches == ch && a.idEqual(b);
}
The problem is this method always returns false if the name isn't
defined in either path. I think this is the definition we want
instead:
if (a.matches == ch && b.matches == ch)
return a.idEqual(b);
if (a.matches != ch && b.matches != ch) {
// If neither tree matches the current path node then neither
// tree has this entry. In such case the ObjectId is zero(),
// and zero() is always equal to zero().
//
return true;
}
return false;
Patch to follow.
--
Shawn.
^ permalink raw reply
* [JGIT PATCH] Fix TreeWalk.idEqual when both trees are missing the path
From: Shawn O. Pearce @ 2009-01-19 17:52 UTC (permalink / raw)
To: Robin Rosenberg, tomi.pakarinen; +Cc: git
The Javadoc of idEqual() says its simply a faster form of
getObjectId(nthA).equals(getObjectId(nthB)), but its code
didn't match that definition when both trees didn't exist
at the current path.
If a tree doesn't exist for the current path getObjectId() returns
ObjectId.zero(), indicating the "magic" 0{40} SHA-1 for the current
path. If both tree entries don't exist for the current path, we
should be doing a compare of ObjectId.zero() against ObjectId.zero(),
which must be true as the values are the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/treewalk/TreeWalk.java | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
index ecf8851..414587c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
@@ -616,7 +616,16 @@ public boolean idEqual(final int nthA, final int nthB) {
final AbstractTreeIterator ch = currentHead;
final AbstractTreeIterator a = trees[nthA];
final AbstractTreeIterator b = trees[nthB];
- return a.matches == ch && b.matches == ch && a.idEqual(b);
+ if (a.matches == ch && b.matches == ch)
+ return a.idEqual(b);
+ if (a.matches != ch && b.matches != ch) {
+ // If neither tree matches the current path node then neither
+ // tree has this entry. In such case the ObjectId is zero(),
+ // and zero() is always equal to zero().
+ //
+ return true;
+ }
+ return false;
}
/**
--
1.6.1.331.g9c367
^ permalink raw reply related
* Re: [PATCH] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 18:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119172939.GA14053@spearce.org>
On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> ... If we had
> an inotify sort of daemon to keep the data current so the prompt
> doesn't have to stat every source file on every display it would
> be reasonable, but we don't have such a thing yet for Git.
Note that inotify is not recursive and is a hog if you ask it to
monitor lots of dents.
I am not convinced that an inotify-enabled git is a good idea for
anything but small/mid-sized project. And such don't need it either.
In other words, the kernel's cache will outperform any userland
attempting to keep track of the fs via inotify.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Keith Cascio @ 2009-01-19 18:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901190446480.3586@pacific.mpi-cbg.de>
Fixed bug in diff whitespace ignore options. It is now
OK to specify more than one whitespace ignore option
on the command line.
Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
---
Dscho,
You are right. The code and the patch are more readable this way.
-- Keith
t/t4015-diff-whitespace.sh | 8 ++++----
xdiff/xutils.c | 6 ++++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index dbb608c..6d13da3 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -99,11 +99,11 @@ EOF
git diff -w > out
test_expect_success 'another test, with -w' 'test_cmp expect out'
git diff -w -b > out
-test_expect_failure 'another test, with -w -b' 'test_cmp expect out'
+test_expect_success 'another test, with -w -b' 'test_cmp expect out'
git diff -w --ignore-space-at-eol > out
-test_expect_failure 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
git diff -w -b --ignore-space-at-eol > out
-test_expect_failure 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
@@ -123,7 +123,7 @@ EOF
git diff -b > out
test_expect_success 'another test, with -b' 'test_cmp expect out'
git diff -b --ignore-space-at-eol > out
-test_expect_failure 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index d7974d1..04ad468 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -245,12 +245,14 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
while (ptr + 1 < top && isspace(ptr[1])
&& ptr[1] != '\n')
ptr++;
- if (flags & XDF_IGNORE_WHITESPACE_CHANGE
+ if (flags & XDF_IGNORE_WHITESPACE)
+ ; /* already handled */
+ else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
&& ptr[1] != '\n') {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
- if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
+ else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
&& ptr[1] != '\n') {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
--
1.6.1.213.g28da8.dirty
^ permalink raw reply related
* Re: [PATCH] bash: offer to show (un)staged changes
From: Shawn O. Pearce @ 2009-01-19 18:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > ... If we had
> > an inotify sort of daemon to keep the data current so the prompt
> > doesn't have to stat every source file on every display it would
> > be reasonable, but we don't have such a thing yet for Git.
>
> Note that inotify is not recursive and is a hog if you ask it to
> monitor lots of dents.
>
> I am not convinced that an inotify-enabled git is a good idea for
> anything but small/mid-sized project. And such don't need it either.
>
> In other words, the kernel's cache will outperform any userland
> attempting to keep track of the fs via inotify.
*sigh*
I was hoping it would work well for the really huge repository case,
like WebKit, where the stats against the work tree just kill the
user space application.
But if its only good for smaller sets of files, then yea, just
doing the stats on demand is going to be better than anything an
inotify daemon might be able to offer.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Mike Hommey @ 2009-01-19 18:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Langhoff, Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119181158.GH14053@spearce.org>
On Mon, Jan 19, 2009 at 10:11:58AM -0800, Shawn O. Pearce wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > ... If we had
> > > an inotify sort of daemon to keep the data current so the prompt
> > > doesn't have to stat every source file on every display it would
> > > be reasonable, but we don't have such a thing yet for Git.
> >
> > Note that inotify is not recursive and is a hog if you ask it to
> > monitor lots of dents.
> >
> > I am not convinced that an inotify-enabled git is a good idea for
> > anything but small/mid-sized project. And such don't need it either.
> >
> > In other words, the kernel's cache will outperform any userland
> > attempting to keep track of the fs via inotify.
>
> *sigh*
>
> I was hoping it would work well for the really huge repository case,
> like WebKit, where the stats against the work tree just kill the
> user space application.
I was hoping something like that too, especially for cold cache cases,
after resuming from hibernation, for instance, in which case the kernel
cache is empty and inotify tracking will help know if something changed.
Mike
^ permalink raw reply
* Re: [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Johannes Schindelin @ 2009-01-19 18:36 UTC (permalink / raw)
To: Keith Cascio; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.GSO.2.00.0901191000520.25883@kiwi.cs.ucla.edu>
Hi,
On Mon, 19 Jan 2009, Keith Cascio wrote:
> Fixed bug in diff whitespace ignore options. It is now
> OK to specify more than one whitespace ignore option
> on the command line.
>
> Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
ACK,
Dscho
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 18:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119181158.GH14053@spearce.org>
On Mon, Jan 19, 2009 at 1:11 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> *sigh*
>
> I was hoping it would work well for the really huge repository case,
> like WebKit, where the stats against the work tree just kill the
> user space application.
Even hot-cache? My perception is that in hot-cache conditions the perf is good.
If it is cold-cache, what in the end you are hoping for is "pegging"
some stuff in the cache. Perhaps there's a way to tell the kernel to
skew the cache eviction scheme. Still, if the kernel's algorythms are
good, the kernel knows more about your fs usage patterns than you
do...
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Boyd Stephen Smith Jr. @ 2009-01-19 19:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090119172939.GA14053@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Monday 2009 January 19 11:29:39 Shawn O. Pearce wrote:
>E.g. WebKit is huge,
>computing the dirty state inside of the WebKit repository on each
>prompt would absolutely kill CLI performance to a point of it not
>being usuable.
Is the performance any better on other VCSes for this operation? If not,
maybe its just a feature that's infeasible for large trees.
--
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] bash: offer to show (un)staged changes
From: Boyd Stephen Smith Jr. @ 2009-01-19 19:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Shawn O. Pearce, git
In-Reply-To: <46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On Monday 2009 January 19 12:00:10 Martin Langhoff wrote:
>On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org>
wrote:
>> ... If we had
>> an inotify sort of daemon to keep the data current so the prompt
>> doesn't have to stat every source file on every display it would
>> be reasonable, but we don't have such a thing yet for Git.
>
>[T]he kernel's cache will outperform any userland
>attempting to keep track of the fs via inotify.
Really? Why have inotify then? I thought its only purpose is "to keep track
of the fs". If it is never a net win, why even use/provide it?
--
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] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 19:12 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901191306.49979.bss@iguanasuicide.net>
On Mon, Jan 19, 2009 at 2:06 PM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> Really? Why have inotify then? I thought its only purpose is "to keep track
> of the fs". If it is never a net win, why even use/provide it?
Lots of programs want to monitor _one file_ or _one directory_. Cron
daemons monitor /etc/cron.*/ , incron monitors /etc/incron.d/ ,
programs that watch mailspool directories can be made more efficient
this way too.
You might find your system today has perhaps a dozen inotify watches.
Judiciously used, it's great.
cheers
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Junio C Hamano @ 2009-01-19 19:48 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090119122018.GA25566@chistera.yi.org>
Adeodato Simó <dato@net.com.org.es> writes:
> * Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:
> ...
>> A workdir is a new work area that is not a normal "work tree with a
>> full repository", but borrows from an existing repository. Any side
>> effect from the work you do in a workdir will be saved in the original
>> repository, and removing one would lose only the three kind of
>> information listed above. Creating a new workdir has the side effect
>> of enabling reflogs and rerere in the original repository.
>
>> But the last sentence somehow feels dirty.
>
> I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
> *enable* reflogs and rerere at all? Or, rather, it just gives an empty
> space for the workdirs "connecting" to it to save their reflogs and
> rerere stuff iff they are configured to do so?
I thought rerere does not kick in if rr-cache is absent, and it kicks in
if rr-cache is present when you do not explicitly disable it. So creation
of directory is a way to enable it. Besides, the net effect for a person
who does not want to have the bare repository contaminated with these
directories is the same. The original repository aquires them.
As I said already, I suspect that it would be more useful in practice to
create these directories as your patch did, than making the new workdir
inherit the lack of rerere and reflog support if the original repository
lacked them. I just wanted to see some documentation that makes it clear
that the original repository _is_ modified by a creation of a new workdir.
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: david @ 2009-01-19 21:08 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0901191627480.4115@reaper.quantumfyre.co.uk>
On Mon, 19 Jan 2009, Julian Phillips wrote:
> On Sun, 18 Jan 2009, david@lang.hm wrote:
>
>> for linux I want to track both the linus tree and the -stable tree. Ideally
>> I want to be able to do a checkout of tags from either tree from the same
>> directory (along with diffs between items in both trees, etc)
>>
>> I have found documentation on how to clone from each of them, but I haven't
>> found any simple documentation on how to work with both of them.
>
> You could always just use
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git ?
> It already contains both the linus tree and all the stable trees ...
I know it contains the releases, but does it contain the -rc trees?
David Lang
^ permalink raw reply
* [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Ralf Wildenhues @ 2009-01-19 20:34 UTC (permalink / raw)
To: Julius Naperkowski, git
In-Reply-To: <20090116094110.GD25275@ins.uni-bonn.de>
In a cross compile setup, configure tests that run programs
cannot be executed; in that case, provide pessimistic default
values.
Bug reported by Julius Naperkowski.
---
> I can post a patch to add sane default settings for AC_RUN_IFELSE in
> cross compile setups, this weekend.
configure.ac | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 363547c..4a208d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,6 +360,7 @@ AC_RUN_IFELSE(
else if (strcmp(buf, "12345"))
return 2;]])],
[ac_cv_c_c99_format=yes],
+ [ac_cv_c_c99_format=no],
[ac_cv_c_c99_format=no])
])
if test $ac_cv_c_c99_format = no; then
@@ -380,6 +381,7 @@ AC_RUN_IFELSE(
FILE *f = fopen(".", "r");
return f && fread(&c, 1, 1, f)]])],
[ac_cv_fread_reads_directories=no],
+ [ac_cv_fread_reads_directories=yes],
[ac_cv_fread_reads_directories=yes])
])
if test $ac_cv_fread_reads_directories = yes; then
@@ -414,6 +416,7 @@ AC_RUN_IFELSE(
if (snprintf(buf, 3, "%s", "12345") != 5
|| strcmp(buf, "12")) return 1]])],
[ac_cv_snprintf_returns_bogus=no],
+ [ac_cv_snprintf_returns_bogus=yes],
[ac_cv_snprintf_returns_bogus=yes])
])
if test $ac_cv_snprintf_returns_bogus = yes; then
--
1.6.1.137.g3d9e8
^ permalink raw reply related
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