* trivial: O_EXCL makes O_TRUNC redundant
From: Alex Riesen @ 2006-01-05 8:58 UTC (permalink / raw)
To: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 49 bytes --]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Attachment #2: 0001-O_EXCL-makes-O_TRUNC-redundant.txt --]
[-- Type: text/plain, Size: 1127 bytes --]
Subject: [PATCH] O_EXCL makes O_TRUNC redundant
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
apply.c | 2 +-
entry.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
4d5e4d8d468c0eedf489104e9f02f86c635c8ac2
diff --git a/apply.c b/apply.c
index d5e7bfd..9eba034 100644
--- a/apply.c
+++ b/apply.c
@@ -1588,7 +1588,7 @@ static int try_create_file(const char *p
if (S_ISLNK(mode))
return symlink(buf, path);
- fd = open(path, O_CREAT | O_EXCL | O_WRONLY | O_TRUNC, (mode & 0100) ? 0777 : 0666);
+ fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
if (fd < 0)
return -1;
while (size) {
diff --git a/entry.c b/entry.c
index 15b34eb..410b758 100644
--- a/entry.c
+++ b/entry.c
@@ -60,7 +60,7 @@ static void remove_subtree(const char *p
static int create_file(const char *path, unsigned int mode)
{
mode = (mode & 0100) ? 0777 : 0666;
- return open(path, O_WRONLY | O_TRUNC | O_CREAT | O_EXCL, mode);
+ return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
}
static int write_entry(struct cache_entry *ce, const char *path, struct checkout *state)
--
1.0.GIT
^ permalink raw reply related
* trivial: retval of waitpid is not errno
From: Alex Riesen @ 2006-01-05 8:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
...but is used as such and passed to strerror.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Attachment #2: 0003-retval-of-waitpid-is-not-errno.txt --]
[-- Type: text/plain, Size: 623 bytes --]
Subject: [PATCH] retval of waitpid is not errno
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
fetch-clone.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
a1dd9ab6b49a6c4e7abb6519933bf2bb22594bd4
diff --git a/fetch-clone.c b/fetch-clone.c
index 2b2aa15..f46fe6e 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -47,7 +47,7 @@ static int finish_pack(const char *pack_
if (retval < 0) {
if (errno == EINTR)
continue;
- error("waitpid failed (%s)", strerror(retval));
+ error("waitpid failed (%s)", strerror(errno));
goto error_die;
}
if (WIFSIGNALED(status)) {
--
1.0.GIT
^ permalink raw reply related
* Fix nasty approxidate bug
From: Linus Torvalds @ 2006-01-05 3:33 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Stupid me.
If approxidate ends up with a month that is ahead of the current month, it
decrements the year to last year.
Which is correct, and means that "last december" does the right thing.
HOWEVER. It should only do so if the year is the same as the current year.
Without this fix, "5 days ago" ends up being in 2004, because it first
decrements five days, getting us to December 2005 (correct), but then it
also ends up decrementing the year once more to turn that December into
"last year" (incorrect, since it already _was_ last year).
Duh. Pass me a donut.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/date.c b/date.c
index 3e11500..73037c7 100644
--- a/date.c
+++ b/date.c
@@ -640,7 +640,7 @@ unsigned long approxidate(const char *da
}
if (number > 0 && number < 32)
tm.tm_mday = number;
- if (tm.tm_mon > now.tm_mon)
+ if (tm.tm_mon > now.tm_mon && tm.tm_year == now.tm_year)
tm.tm_year--;
return mktime(&tm);
}
^ permalink raw reply related
* [PATCH] AIX compile fix for repo-config.c
From: Amos Waterland @ 2006-01-05 0:31 UTC (permalink / raw)
To: junkio; +Cc: git
AIX 5 has a /usr/include/regex.h containing this code:
#ifdef _NO_PROTO
extern char *regex();
extern char *regcmp();
#else /* _NO_PROTO */
extern char *regex(const char *, const char *, ...);
extern char *regcmp(const char *, ...);
#endif /* _NO_PROTO */
This means that repo-config.c is trying to redefine the `regex' symbol.
Here is a simple patch that just uses `regexp' as the symbol name instead.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
--- repo-config.c.orig Wed Jan 4 18:58:21 2006
+++ repo-config.c Wed Jan 4 18:59:15 2006
@@ -6,7 +6,7 @@
static char* key = NULL;
static char* value = NULL;
-static regex_t* regex = NULL;
+static regex_t* regexp = NULL;
static int do_all = 0;
static int do_not_match = 0;
static int seen = 0;
@@ -14,9 +14,9 @@
static int show_config(const char* key_, const char* value_)
{
if (!strcmp(key_, key) &&
- (regex == NULL ||
+ (regexp == NULL ||
(do_not_match ^
- !regexec(regex, value_, 0, NULL, 0)))) {
+ !regexec(regexp, value_, 0, NULL, 0)))) {
if (do_all) {
printf("%s\n", value_);
return 0;
@@ -46,8 +46,8 @@
regex_++;
}
- regex = (regex_t*)malloc(sizeof(regex_t));
- if (regcomp(regex, regex_, REG_EXTENDED)) {
+ regexp = (regex_t*)malloc(sizeof(regex_t));
+ if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n", regex_);
return -1;
}
@@ -59,9 +59,9 @@
free(value);
}
free(key);
- if (regex) {
- regfree(regex);
- free(regex);
+ if (regexp) {
+ regfree(regexp);
+ free(regexp);
}
if (do_all)
^ permalink raw reply
* Re: Strange unable to unlink error with git-prune-packed
From: Martin Langhoff @ 2006-01-04 22:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601040828590.3668@g5.osdl.org>
On 1/5/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Does it happen for all your files? All your repositories? Or just one
> repo?
Good questions -- should have sorted those basic things out before
posting. Apologies. In any case, I haven't seen that before, but I
don't run git-prune-packed that often on the OSX commandline. My main
dev host is a linux machine, and I have a weekly cron that does repack
and prune packed on all my repos.
> Or just one subdirectory in that repo?
It refused to unlink _any_ files within .git/objects
> The code is _literally_ just doing a
>
> if (unlink(pathname) < 0)
> error("unable to unlink %s", pathname);
>
> but maybe you could just make it print out the reason too. So add a "(%s)"
> and a "strerror(errno)" to that error line..
This morning, after a reboot, I patched prune-packed.c as suggested
and ran it... and it all worked.
Initially I suspected the files were locked somehow, but I just did a
new clone && git-repack && git-prune-packed and it just worked...
Grrr.
> I don't see why you couldn't unlink those files. Maybe it's some strange
> HFS issue and you can't just unlink() things that have attributes or
> something? Maybe some crazy file manager has added a default icon
> attribute to your files if you happened to look at the .git objects
> directory?
It is indeed HFS but I'm pretty sure things should be transparent to
the unix side of things. In any case, the (crazy filemanager) Finder
wasn't involved, as this is a newish repo, I haven't looked at any
directory around it with Finder, and it's known to leave hidden files
all over the place.
In any case, I've got my git-prune-packed patched now, and will be
trying to repro the bug.
cheers,
martin
^ permalink raw reply
* Re: git-ls-files -o no recurse?
From: Linus Torvalds @ 2006-01-04 21:31 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Git Mailing List
In-Reply-To: <1136400692.5919.11.camel@localhost.localdomain>
On Wed, 4 Jan 2006, Darrin Thompson wrote:
>
> Would it be hard to make git-ls-files optionally do this?
Something like the appended may or may not be what you're looking for..
Linus
---
diff --git a/ls-files.c b/ls-files.c
index 5e9ac71..2e3e2e8 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -19,6 +19,7 @@ static int show_stage = 0;
static int show_unmerged = 0;
static int show_modified = 0;
static int show_killed = 0;
+static int show_ignored_directories = 0;
static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
@@ -233,6 +234,19 @@ static void add_name(const char *pathnam
dir[nr_dir++] = ent;
}
+static int dir_exists(const char *dirname, int len)
+{
+ int pos = cache_name_pos(dirname, len);
+ if (pos >= 0)
+ return 1;
+ pos = -pos-1;
+ if (pos >= active_nr)
+ return 0;
+ if (strncmp(active_cache[pos]->name, dirname, len))
+ return 0;
+ return active_cache[pos]->name[len] == '/';
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -280,6 +294,10 @@ static void read_directory(const char *p
continue;
/* fallthrough */
case DT_DIR:
+ if (show_ignored_directories) {
+ if (!dir_exists(fullname, baselen + len))
+ break;
+ }
memcpy(fullname + baselen + len, "/", 2);
read_directory(fullname, fullname,
baselen + len + 1);
@@ -622,6 +640,10 @@ int main(int argc, const char **argv)
show_killed = 1;
continue;
}
+ if (!strcmp(arg, "--directory")) {
+ show_ignored_directories = 1;
+ continue;
+ }
if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
/* There's no point in showing unmerged unless
* you also show the stage information.
^ permalink raw reply related
* git-ls-files -o no recurse?
From: Darrin Thompson @ 2006-01-04 18:51 UTC (permalink / raw)
To: Git Mailing List
git-ls-files -o reports _all_ the unknown files it finds in a work area.
Subversion and probably other systems "simply ignore all the files
and directories inside an unknown directory and just note the directory
as unknown." (A quote from my porcelain's mailing list.)
I'd like to make this friendly behavior the default in my porcelain.
Unfortunately, getting the same result from a porcelain requires
implementing a non-trivial algorithm to discover common prefixes, worry
about performance on large projects, etc.
Would it be hard to make git-ls-files optionally do this?
--
Darrin
^ permalink raw reply
* Re: Strange unable to unlink error with git-prune-packed
From: Linus Torvalds @ 2006-01-04 16:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90601032046l31f51742k93f3f9f5a826bef1@mail.gmail.com>
On Wed, 4 Jan 2006, Martin Langhoff wrote:
>
> When I invoke git-prune-packed I am greeted by (3-line sample):
>
> error: unable to unlink .git/objects/43/2251e8488dc3c72d94d698ed69003137c47244
> error: unable to unlink .git/objects/43/6bc8b274ab96944a6f8c3cf5e3fbeef422042b
> error: unable to unlink .git/objects/43/fe47e9508289ad4eca71613a9f20d7f3323602
Does it happen for all your files? All your repositories? Or just one
repo? Or just one subdirectory in that repo?
The code is _literally_ just doing a
if (unlink(pathname) < 0)
error("unable to unlink %s", pathname);
but maybe you could just make it print out the reason too. So add a "(%s)"
and a "strerror(errno)" to that error line..
> $ ls -la .git/objects/43
> total 24
> drwxr-xr-x 5 martin martin 170 4 Jan 17:37 .
I don't see why you couldn't unlink those files. Maybe it's some strange
HFS issue and you can't just unlink() things that have attributes or
something? Maybe some crazy file manager has added a default icon
attribute to your files if you happened to look at the .git objects
directory?
Linus
^ permalink raw reply
* [PATCH] update-hook: Major overhaul (handling tags, mainly).
From: Andreas Ericsson @ 2006-01-04 16:17 UTC (permalink / raw)
This is the update hook we use in all our git-repos.
It has some improvements over the original version, namely:
* Don't send every commit since dawn of time when adding a new tag.
* When updating an annotated tag, just send the diffs since the last tag.
* Add diffstat output for 'normal' commits (top) and annotated tags (bottom).
* Block un-annotated tags in shared repos.
I'm a bit uncertain about that last one, but it demonstrates how to
disallow updates of a ref which we use, so I kept it.
Note that git-describe is needed for the "changes since last annotated tag"
thing to work.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
templates/hooks--update | 71 +++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 65 insertions(+), 6 deletions(-)
f10cd7de04bb84f381cc7a3d65ede0233900de44
diff --git a/templates/hooks--update b/templates/hooks--update
index 6db555f..27cea17 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -1,6 +1,7 @@
#!/bin/sh
#
# An example hook script to mail out commit update information.
+# It also blocks tags that aren't annotated.
# Called by git-receive-pack with arguments: refname sha1-old sha1-new
#
# To enable this hook:
@@ -8,16 +9,74 @@
# (2) make this file executable by "chmod +x update".
#
-recipient="commit-list@example.com"
+project=$(cat $GIT_DIR/description)
+recipients="commit-list@somewhere.com commit-list@somewhereelse.com"
-if expr "$2" : '0*$' >/dev/null
+ref_type=$(git cat-file -t "$3")
+
+# Only allow annotated tags in a shared repo
+# Remove this code to treat dumb tags the same as everything else
+case "$1","$ref_type" in
+refs/tags/*,commit)
+ echo "*** Un-annotated tags are not allowed in this repo" >&2
+ echo "*** Use 'git tag [ -a | -s ]' for tags you want to propagate."
+ exit 1;;
+refs/tags/*,tag)
+ echo "### Pushing version '${1##refs/tags/}' to the masses" >&2
+ # recipients="release-announce@somwehere.com announce@somewhereelse.com"
+ ;;
+esac
+
+# set this to 'cat' to get a very detailed listing.
+# short only kicks in when an annotated tag is added
+short='git shortlog'
+
+# see 'date --help' for info on how to write this
+# The default is a human-readable iso8601-like format with minute
+# precision ('2006-01-25 15:58 +0100' for example)
+date_format="%F %R %z"
+
+(if expr "$2" : '0*$' >/dev/null
then
- echo "Created a new ref, with the following commits:"
- git-rev-list --pretty "$3"
+ # new ref
+ case "$1" in
+ refs/tags/*)
+ # a pushed and annotated tag (usually) means a new version
+ tag="${1##refs/tags/}"
+ if [ "$ref_type" = tag ]; then
+ eval $(git cat-file tag $3 | \
+ sed -n '4s/tagger \([^>]*>\)[^0-9]*\([0-9]*\).*/tagger="\1" ts="\2"/p')
+ date=$(date --date="1970-01-01 00:00:00 $ts seconds" +"$date_format")
+ echo "Tag '$tag' created by $tagger at $date"
+ git cat-file tag $3 | sed -n '5,$p'
+ echo
+ fi
+ prev=$(git describe "$3^" | sed 's/-g.*//')
+ # the first tag in a repo will yield no $prev
+ if [ -z "$prev" ]; then
+ echo "Changes since the dawn of time:"
+ git rev-list --pretty $3 | $short
+ else
+ echo "Changes since $prev:"
+ git rev-list --pretty $prev..$3 | $short
+ echo ---
+ git diff $prev..$3 | diffstat -p1
+ echo ---
+ fi
+ ;;
+
+ refs/heads/*)
+ branch="${1##refs/heads/}"
+ echo "New branch '$branch' available with the following commits:"
+ git-rev-list --pretty "$3"
+ ;;
+ esac
else
base=$(git-merge-base "$2" "$3")
case "$base" in
"$2")
+ git diff "$3" "^$base" | diffstat -p1
+ echo
echo "New commits:"
;;
*)
@@ -25,6 +84,6 @@ else
;;
esac
git-rev-list --pretty "$3" "^$base"
-fi |
-mail -s "Changes to ref $1" "$recipient"
+fi) |
+mail -s "$project: Changes to '${1##refs/heads/}'" $recipients
exit 0
--
1.0.6-g58e3
^ permalink raw reply related
* [PATCH] Ignore tags that contain colons in their names
From: Simon Richter @ 2006-01-04 13:13 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 190 bytes --]
Hi,
a repo I was trying to clone contained a tag that somehow had a colon in
its name, which is illegal. The attached patch makes git-fetch ignore
these tags rather than barf.
Simon
[-- Attachment #1.2: ignore-colon-tags.diff --]
[-- Type: text/plain, Size: 264 bytes --]
diff --git a/git-fetch.sh b/git-fetch.sh
index 125bcea..6d930b2 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -191,6 +191,7 @@ then
taglist=$(git-ls-remote --tags "$remote" |
sed -e '
/\^/d
+ /:/d
s/^[^ ]* //
s/.*/.&:&/')
if test "$#" -gt 1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply related
* Re: [PATCH] qgit: increase the space between the lanes.
From: Martin Atukunda @ 2006-01-04 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <43BAF7F2.6060906@yahoo.it>
On Wednesday 04 January 2006 01:17, Marco Costalba wrote:
> Martin Atukunda wrote:
> > Hmm, I need to re-think how to do this properly. Any ideas?
>
> Hi Martin,
>
>
> What about this?
>
> If it is Ok for you I will push the change.
>
Looks Good. Please apply.
- Martin -
--
Due to a shortage of devoted followers, the production of great leaders has
been discontinued.
^ permalink raw reply
* RE: [OT] Shameless troll ;o)
From: Linus Torvalds @ 2006-01-04 4:56 UTC (permalink / raw)
To: Brown, Len; +Cc: H. Peter Anvin, Theodore Ts'o, walt, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B300596583E@hdsmsx401.amr.corp.intel.com>
On Tue, 3 Jan 2006, Brown, Len wrote:
>
> While not the WSJ (which I actually read) or the Economist (which I haven't
> had time to read since parenthood), I think that Business Week is also
> a step up -- as evidenced by its classy cover!:-)
I prefer the Jessica Simpson covers personally, but hey, I can't fault
your taste.
Linus
^ permalink raw reply
* git format-patch shell quoting bug
From: Kyle McMartin @ 2006-01-04 4:55 UTC (permalink / raw)
To: git
Hi,
There's apparently a quoting bug in git-format-patch. When I import
a patch with apply-mbox, for example
From: Carlos O'Donell <carlos@parisc-linux.org>
The author field is correctly set, including the "'" in Carlos' name.
So when I go to rebase my tree, or send out patches, I
"git-format-patch origin" and get...
/usr/bin/git-format-patch: eval: line 200: unexpected EOF while looking for
matching `''
/usr/bin/git-format-patch: eval: line 201: syntax error: unexpected end of file
Which produces a bogus output patch with a blank From and Date,
Subject: [PATCH] ...
From:
Date:
[...]
I believe this recently crept in, as I don't recall seeing it before.
Cheers,
Kyle
^ permalink raw reply
* Strange unable to unlink error with git-prune-packed
From: Martin Langhoff @ 2006-01-04 4:46 UTC (permalink / raw)
To: Git Mailing List
Weilding a recent git version 1.0.6-g58e3 it turns out I cannot run
git-prune-packed on a simple repo on my OSX (Panther 10.3.9). The
local repo looks fine in my eyes, and permissions are similar to those
on Linux. Relaxing permissions doesn't help either, so there may be
something else afoot.
When I invoke git-prune-packed I am greeted by (3-line sample):
error: unable to unlink .git/objects/43/2251e8488dc3c72d94d698ed69003137c47244
error: unable to unlink .git/objects/43/6bc8b274ab96944a6f8c3cf5e3fbeef422042b
error: unable to unlink .git/objects/43/fe47e9508289ad4eca71613a9f20d7f3323602
File modes after I ran chmod -R u+w .git/objects to see if
prune-packed was taking the mode too seriously on OSX
$ ls -la .git/objects/43
total 24
drwxr-xr-x 5 martin martin 170 4 Jan 17:37 .
drwxr-xr-x 229 martin martin 7786 4 Jan 17:37 ..
-rw-r--r-- 1 martin martin 211 30 Dec 11:21
2251e8488dc3c72d94d698ed69003137c47244
-rw-r--r-- 1 martin martin 53 30 Dec 11:21
6bc8b274ab96944a6f8c3cf5e3fbeef422042b
-rw-r--r-- 1 martin martin 152 30 Dec 11:21
fe47e9508289ad4eca71613a9f20d7f3323602
This is low priority for me, and so weird that it has to be a pilot
error -- OTOH I may do a bisect to try and figure out whether it's a
recent change...
cheers,
martin
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Greg KH @ 2006-01-04 3:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Ts'o, H. Peter Anvin, walt, git
In-Reply-To: <Pine.LNX.4.64.0601031546430.3668@g5.osdl.org>
On Tue, Jan 03, 2006 at 03:55:11PM -0800, Linus Torvalds wrote:
> On Tue, 3 Jan 2006, Theodore Ts'o wrote:
> > I'm not actually aware of any bad experience IBM had with Mr. Lyons,
> > and I'm not aware of any "don't talk to Dan Lyons" warning from
> > management, other than the standard rules requesting IBM engineers not
> > talk with _any_ journalist or analyst without first clearing things
> > with press or analyst relations --- but that's pretty standard for any
> > large corporation.
If you ask IBM PR, I'm sure they will be able to give you the reasons
they don't allow IBM employees to talk to Dan.
> Yes. And when trying to clear it with IBM legal, Greg KH was told not to
> talk to Dan Lyons.
Yeah, and because I wasn't allowed to talk to him, he wrote a funny
(well, funny to me at least) article about how IBM was muzzling their
Linux developers. It was quite accurate, and I've not had any problems
in dealing with him since I left IBM (probably due to my current
employer allowing me to talk to him...)
thanks,
greg k-h
^ permalink raw reply
* Recursive merge still doesn't handle reorganized repositories
From: H. Peter Anvin @ 2006-01-04 1:58 UTC (permalink / raw)
To: Git Mailing List
Well, I got the chance to try out "git-merge -s recursive" to try to
deal with the two different reorganized klibc repositories. I'm sad to
report that it doesn't really work, and that every merge has to be
propagated manually.
The two repos are at:
git://git.kernel.org/pub/scm/libs/klibc/klibc.git
git://git.kernel.org/pub/scm/libs/klibc/klibc-renamed.git
What I want is for a change to the first to propagate naturally to the
second.
-hpa
^ permalink raw reply
* RE: [OT] Shameless troll ;o)
From: Brown, Len @ 2006-01-04 1:49 UTC (permalink / raw)
To: Linus Torvalds, H. Peter Anvin; +Cc: Theodore Ts'o, walt, git
>Yes, Forbes is...
>... a small step up from the check-out counter magazines
>that alternately glorify and vilify Jessica Simpson or whoever is the
>celebrity of the week.
While not the WSJ (which I actually read) or the Economist (which I haven't
had time to read since parenthood), I think that Business Week is also
a step up -- as evidenced by its classy cover!:-)
http://www.businessweek.com/magazine/content/05_05/b3918002_mz001.htm
^ permalink raw reply
* Re: how to find outstanding patches in non-linux-2.6 repositories ?
From: Tom Prince @ 2006-01-04 1:26 UTC (permalink / raw)
To: git
In-Reply-To: <43BAD1F2.8040209@op5.se>
On Tue, Jan 03, 2006 at 08:35:14PM +0100, Andreas Ericsson wrote:
> "origin..HEAD" is a valid and fairly common range.
> "HEAD..origin" is not (well, it is, but it doesn't include any commits
> since it's going backwards).
>
It depends on what you are doing. When I update my git repository, I do
git fetch
git-whatchanged master..origin
git pull
to find out what changed since I last updated.
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Chuck Lever @ 2006-01-04 1:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Ts'o, H. Peter Anvin, walt, git
In-Reply-To: <Pine.LNX.4.64.0601031546430.3668@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Linus Torvalds wrote:
>
> On Tue, 3 Jan 2006, Theodore Ts'o wrote:
>
>>I'm not aware of any positive articles ever written from Dan Lyons; if
>>you know of any, feel free to send me the URL.
>
>
> Well, here's one I know Dan researched..
>
> http://www.forbes.com/forbes/2004/0920/180_print.html
>
> The fact that you don't like the man, and that he's more critical than
> over-the-top enthusiastic, hey. That doesn't make him unprofessional or
> mean that he has no journalistic integrity. Being critical is way too
> seldom seen, and as you admit, Lyons is by no means one-sidedly critical.
>
> So maybe his glass is half full. Still no reason to dismiss him.
as one of the people featured in the "peace love and paychecks" article,
i found the reporting to be surprisingly accurate (ie it could have been
much much worse). i often tell people who ask me "what do you do" to
read a copy of it. i haven't read any of his other pieces, though, so i
can't really comment on bias or accuracy over the body of his work.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 254 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Network Appliance, Incorporated;Open Source NFS Client Engineering
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Linus Torvalds @ 2006-01-04 0:06 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: H. Peter Anvin, walt, git
In-Reply-To: <Pine.LNX.4.64.0601031546430.3668@g5.osdl.org>
On Tue, 3 Jan 2006, Linus Torvalds wrote:
>
> The fact is, they all have their biases. The fact that open source tends
> to strike a chord with them and they almost universally end up
> understanding about freedom of the GPL kind is usually a big help. The
> fact that some have other biases don't make them worse journalists. It
> just means that you see different kinds of stories from them.
Btw, I actually in many ways prefer the critical ones over the positive
ones, which may be one reason I actually appreciate Dan Lyons even though
obviously a lot of people don't. I find it interesting to see what the
other side thinks, even if it's often something you know is wrong.
The fact is, journalists seldom get any tech story really right. If they
did, they'd be technical people. You can react to it two ways: either
realize that some people see it that way (which can be illuminating - if
only because you might realize that stories you _believed_ in might not
be exactly true either) or just dismissing the story and the teller of the
story.
Yeah, I even watch Fox news occasionally.
I think the news stories that disagree with our own beliefs are often the
ones that tell us the most.
Admittedly, sometimes they just tell us that people are idiots ;)
Linus
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Linus Torvalds @ 2006-01-03 23:55 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: H. Peter Anvin, walt, git
In-Reply-To: <20060103222802.GA29610@thunk.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2332 bytes --]
On Tue, 3 Jan 2006, Theodore Ts'o wrote:
>
> I'm not aware of any positive articles ever written from Dan Lyons; if
> you know of any, feel free to send me the URL.
Well, here's one I know Dan researched..
http://www.forbes.com/forbes/2004/0920/180_print.html
The fact that you don't like the man, and that he's more critical than
over-the-top enthusiastic, hey. That doesn't make him unprofessional or
mean that he has no journalistic integrity. Being critical is way too
seldom seen, and as you admit, Lyons is by no means one-sidedly critical.
So maybe his glass is half full. Still no reason to dismiss him.
> Web logs are the prized platform of an online lynch mob
> spouting liberty but spewing lies, libel and invective. Their
> potent allies in this pursuit include Google and Yahoo.
>
> People can make their own decision whether they would consider this
> "balanced journalism".
Hey, he's been vilified by some of those blogs. Unnecessarily, I say.
> I'm not actually aware of any bad experience IBM had with Mr. Lyons,
> and I'm not aware of any "don't talk to Dan Lyons" warning from
> management, other than the standard rules requesting IBM engineers not
> talk with _any_ journalist or analyst without first clearing things
> with press or analyst relations --- but that's pretty standard for any
> large corporation.
Yes. And when trying to clear it with IBM legal, Greg KH was told not to
talk to Dan Lyons.
> Certainly, journalists are people; but they are supposed to check
> their biases at the door when they start writing (except on the
> editorials page); that's part of the stated advantages of
> "professional journalists" over the undiscplined bloggers which Dan
> Lyons so gleefully trashed in most recent cover article. Given that
> he makes no effort hide his biases, at least in my book that makes him
> a lousy journalist.
What naïve school did you go through where journalists aren't idealistic
puppies with an agenda?
The fact is, they all have their biases. The fact that open source tends
to strike a chord with them and they almost universally end up
understanding about freedom of the GPL kind is usually a big help. The
fact that some have other biases don't make them worse journalists. It
just means that you see different kinds of stories from them.
Linus
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Johannes Schindelin @ 2006-01-03 23:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43BAFF1B.6080607@op5.se>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 823 bytes --]
Hi,
On Tue, 3 Jan 2006, Andreas Ericsson wrote:
> That said, journalists are actually supposed to be biased (how can you have
> opinions for something you don't think anything about?), but in a stylishly
> blasé and preferrably entertaining sort of way.
I happened to read two or three articles of Dan Lyons (yes, I read Groklaw
and tried to find out if Dan Lyons really investigated the facts, or left
out unpleasing details deliberately). I found that he not only lacks in
style, but in presenting all the facts.
It's one thing to be biased.
It's another thing completely, to leave out facts you don't want to be
true.
As Linus said, everybody is opinionated. But if somebody twists the facts
to say something what they didn't originally, I don't read his articles
any longer. As simple as that.
Ciao,
Dscho
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Andreas Ericsson @ 2006-01-03 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060103222802.GA29610@thunk.org>
Theodore Ts'o wrote:
>
> Certainly, journalists are people; but they are supposed to check
> their biases at the door when they start writing (except on the
> editorials page); that's part of the stated advantages of
> "professional journalists" over the undiscplined bloggers which Dan
> Lyons so gleefully trashed in most recent cover article. Given that
> he makes no effort hide his biases, at least in my book that makes him
> a lousy journalist.
>
Not necessarily. I've got a journalist background myself. When I went to
school we were taught to say what was true, how we came to know that,
what we *think* is true, why we think that and what our opinions are
about it, preferrably but not necessarily in that order. Speculations
and opinions are what differs a journalist from a reporter.
We were also taught that we, as reporters, should be the ones pushing
the boundaries and our editors should be holding us back. I think Mr.
Lyons editor is not doing a very good job. Some of the articles I
stumbled across were not worth the time it took to let google find them
for me.
I've never met Mr. Lyons or, until today, read anything he's written.
From what little I've gathered though, he seems to be stubborn,
narrowminded and rude, but not eloquent enough to pull it off with style.
That said, journalists are actually supposed to be biased (how can you
have opinions for something you don't think anything about?), but in a
stylishly blasé and preferrably entertaining sort of way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [OT] Shameless troll ;o)
From: Theodore Ts'o @ 2006-01-03 22:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, walt, git
In-Reply-To: <Pine.LNX.4.64.0601031152430.3668@g5.osdl.org>
On Tue, Jan 03, 2006 at 12:09:22PM -0800, Linus Torvalds wrote:
> He tends to look for problems, but not every piece he has written has been
> negative. In fact, some of them haven't been _nearly_ as negative as they
> have then been purported to be in groklaw. I think groklaw has had a
> somewhat unfortunate "either you're with us, or you're against us" herd
> mentality.
I'm not aware of any positive articles ever written from Dan Lyons; if
you know of any, feel free to send me the URL. And it's certainly
true that Linux is not the only thing that Mr. Lyons like to trash.
For example, his article in the November 2005 Forbes' cover story
began:
Web logs are the prized platform of an online lynch mob
spouting liberty but spewing lies, libel and invective. Their
potent allies in this pursuit include Google and Yahoo.
People can make their own decision whether they would consider this
"balanced journalism".
I'm not actually aware of any bad experience IBM had with Mr. Lyons,
and I'm not aware of any "don't talk to Dan Lyons" warning from
management, other than the standard rules requesting IBM engineers not
talk with _any_ journalist or analyst without first clearing things
with press or analyst relations --- but that's pretty standard for any
large corporation.
The only reason why I piped up was because (a) I didn't think six
months ago counted as "just published", and (b) it's not worth wasting
time or helping reward Forbes with ad clicks by reading an article
from someone who has far as I know, has always published nasty
articles about Linux and anything related to Open Source.
> And understand that journalists are very much people too, and react badly
> to the kind of totally uncalled for name-calling that Dan Lyons has gotten
> on groklaw over the last year or two (yeah, he got things wrong for one of
> his first pieces on the SCO saga. And he doesn't like IBM, and I can
> pretty much guarantee you that he _detests_ groklaw by now. And it will
> show in his reporting.).
Certainly, journalists are people; but they are supposed to check
their biases at the door when they start writing (except on the
editorials page); that's part of the stated advantages of
"professional journalists" over the undiscplined bloggers which Dan
Lyons so gleefully trashed in most recent cover article. Given that
he makes no effort hide his biases, at least in my book that makes him
a lousy journalist.
- Ted
^ permalink raw reply
* Re: [PATCH] qgit: increase the space between the lanes.
From: Marco Costalba @ 2006-01-03 22:17 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <200601032007.09081.matlads@dsmagic.com>
Martin Atukunda wrote:
>
> Hmm, I need to re-think how to do this properly. Any ideas?
>
Hi Martin,
What about this?
If it is Ok for you I will push the change.
Marco
diff --git a/src/mainimpl.cpp b/src/mainimpl.cpp
index 2f26b01..40a22e8 100644
--- a/src/mainimpl.cpp
+++ b/src/mainimpl.cpp
@@ -1451,7 +1451,7 @@ void MainImpl::setupPixmaps() {
// little hack to read items height
new QListViewItem(listViewLog);
ph = listViewLog->firstChild()->height();
- pw = ph / 2;
+ pw = 3 * ph / 4;
listViewLog->clear(); // remove and deletes items
QPixmap cm(pw, ph);
cm.fill();
@@ -1470,12 +1470,13 @@ void MainImpl::setupPixmaps() {
p.begin(pm);
p.setPen(QPen(colors[i % COLORS_NUM], 2));
int type = (i / COLORS_NUM) + 1;
+ QBrush myBrush(QBrush(colors[i % COLORS_NUM], Qt::SolidPattern));
switch(type) {
case ACTIVE:
p.drawLine(P_90, P_270);
p.save();
p.setPen(QPen(colors[i % COLORS_NUM], 1));
- p.setBrush(QBrush(colors[i % COLORS_NUM], Qt::SolidPattern));
+ p.setBrush(myBrush);
p.drawEllipse(pw/8, ph/8, 6*pw/8, 3*ph/8);
p.restore();
break;
@@ -1485,17 +1486,20 @@ void MainImpl::setupPixmaps() {
case MERGE_FORK:
p.drawLine(P_90, P_270);
p.drawLine(P_180, P_0);
- p.drawRect(pw/4, ph/4, pw/2, ph/2);
+ p.fillRect (pw/4, ph/4, pw/2, ph/2, myBrush);
+ p.drawRoundRect(pw/4, ph/4, pw/2, ph/2, 25, 25);
break;
case MERGE_FORK_R:
p.drawLine(P_90, P_270);
p.drawLine(P_180, P_OR);
- p.drawRect(pw/4, ph/4, pw/2, ph/2);
+ p.fillRect (pw/4, ph/4, pw/2, ph/2, myBrush);
+ p.drawRoundRect(pw/4, ph/4, pw/2, ph/2, 25, 25);
break;
case MERGE_FORK_L:
p.drawLine(P_90, P_270);
p.drawLine(P_OR, P_0);
- p.drawRect(pw/4, ph/4, pw/2, ph/2);
+ p.fillRect (pw/4, ph/4, pw/2, ph/2, myBrush);
+ p.drawRoundRect(pw/4, ph/4, pw/2, ph/2, 25, 25);
break;
case JOIN:
p.drawLine(P_90, P_270);
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ 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