* Brand new Enhanced male power and unlimited prowess with your girl The best products for the winning guys
From: Richie @ 2006-07-27 16:27 UTC (permalink / raw)
To: glenda
Dear client.
Boost your manhood to astonishing levels Everything a real man would ever need.Make your girlfriend or wife speechless with increased hardness, richer orgsms and more power in bed
Masculine performance has never been so easy to increase with these products
See our shop: http://www.isohyetab.com
Richie Rossi
Elementary sartorial techniques initially applied obviate the need for repetitive similar actions to the square of three.Youth is wasted on the young A faithful friend is a medicine for life.
Every path has its puddle. Love is the strangest thing
^ permalink raw reply
* Re: Projects using git now
From: Pavel Roskin @ 2006-07-27 17:28 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: git
In-Reply-To: <b8bf37780607271004x45092f60rfd35e29fc1fc922c@mail.gmail.com>
On Thu, 2006-07-27 at 13:04 -0400, André Goddard Rosa wrote:
> Sorry to bother, I already found these two pages:
>
> http://git.or.cz/gitwiki/GitProjects
> http://en.wikipedia.org/wiki/Git_(software)
>
> Do you think they are updated?
See history or "recent changes" on both pages.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Projects using git now
From: André Goddard Rosa @ 2006-07-27 17:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1154021317.13273.3.camel@dv>
On 7/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2006-07-27 at 13:04 -0400, André Goddard Rosa wrote:
> > Sorry to bother, I already found these two pages:
> >
> > http://git.or.cz/gitwiki/GitProjects
> > http://en.wikipedia.org/wiki/Git_(software)
> >
> > Do you think they are updated?
>
> See history or "recent changes" on both pages.
I'm so sorry, thank you! I made that but asked first. :|
--
[]s,
André Goddard
^ permalink raw reply
* Re: Licensing and the library version of git
From: Linus Torvalds @ 2006-07-27 17:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Jon Smirl, git
In-Reply-To: <20060727172329.GC13776@pasky.or.cz>
On Thu, 27 Jul 2006, Petr Baudis wrote:
>
> That said, Git still requires RCS for the merge operation. Any plans
> to finally switch to diff3 and toss out another useless dependency?
If libxdiff ever gets a real 3-way merge, I think we'd do it in a
heartbeat.
Right now it has a function called "xdl_merge3()", but it doesn't actually
have anythign to do with a real merge:
"The function works by creating a differential between mmfo and mmf2 and
by applying the resulting patch to mmf1"
so it's really just a "diff + patch".
I asked Davide about it some time ago, and I think he said that he'd like
to do it properly, but it's always been on his back-burner and that he
didn't foresee that changing in the immediate future..
So we can hope. Or somebody who knows the algorithms could just implement
it and send it to both us and Davide (libxdiff _is_ LGPL, btw).
Linus
^ permalink raw reply
* Re: Licensing and the library version of git
From: Jon Smirl @ 2006-07-27 17:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607270941400.4168@g5.osdl.org>
On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I seriously doubt that Eclipse or Visual Stupido could ever actually
> _understand_ what git does, so the only parts you actually would want to
> use for those is literally the trivial stuff - the "look up objects" and
> "generate commits" part.
Typically an integrated IDE can move, delete, rename directories and
files. Get a log. Push, pull and commit. Revert a change. Generate
diffs to previous versions.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: Linus Torvalds @ 2006-07-27 17:50 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <b8bf37780607271025m1a611006x65a900e9e487ce1b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 391 bytes --]
On Thu, 27 Jul 2006, André Goddard Rosa wrote:
>
> The problem happened again, and it stalls AFAICS.
> Can you reproduce there?
>
> # git clone git://source.mvista.com/git/linux-davinci-2.6.git
Nope. I have a fairly constant 120kbps, and:
[torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
Checking files out...)
100% (19754/19754) done
here
Linus
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 17:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607271049460.4168@g5.osdl.org>
On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 27 Jul 2006, André Goddard Rosa wrote:
> >
> > The problem happened again, and it stalls AFAICS.
> > Can you reproduce there?
> >
> > # git clone git://source.mvista.com/git/linux-davinci-2.6.git
>
> Nope. I have a fairly constant 120kbps, and:
>
> [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> Checking files out...)
> 100% (19754/19754) done
> here
Do you think you can reproduce the server timeout by CTRL + Z and
stopping the process for a while?
I sent an email to the last one who commited in that tree asking for
updating the git version there. I also sent and email to the maillist
owner asking this.
Thanks again,
--
[]s,
André Goddard
^ permalink raw reply
* Re: local clone performance
From: Petr Baudis @ 2006-07-27 18:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910607261637w75c99a2ehcb25b6c81449d298@mail.gmail.com>
Dear diary, on Thu, Jul 27, 2006 at 01:38:00AM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> Comparing git-clone to cg-clone
>
> [jonsmirl@jonsmirl apps]$ time git-clone git foo
> ......
> real 0m5.755s
> user 0m4.548s
> sys 0m0.512s
>
> [jonsmirl@jonsmirl apps]$ time cg-clone git foo
> ....
> real 0m18.970s
> user 0m10.737s
> sys 0m1.392s
>
> Why does it take cg clone so long to set up the missing tags?
> git-clone is over 3x faster.
How many tags do you have?
It's true that cg-clone does not scale very well with big amounts of
tags, because it won't fetch tagged objects you wouldn't get otherwise
(so if you tagged some random huge blob or a history line which is not
part of any branch you have, cg-clone won't grab it all). This
unfortunately costs us one special fetch invocation per tag; I will look
into hacking git-local-fetch to accept multiple commit ids at once, that
should speed it up considerably.
That said, with cg-clone -a I will be able to cut that difference
entirely and blindly take everything from the other repository.
Could you please try the patch below and check if it has at least
any measurable impact on the performance at all? Thanks.
diff --git a/cg-fetch b/cg-fetch
index a6e6959..23e0e77 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -54,7 +54,6 @@ _git_wc_unneeded=1
fetch_progress()
{
- [ $verbose -ge 2 ] && exec cat
if [ -t 1 ]; then
exec "${COGITO_LIB}"cg-Xfetchprogress "$_git_objects"
else
@@ -166,7 +165,11 @@ fetch_http()
{
whead=
[ "$3" ] && whead="-w $3"
- (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
+ if [ $verbose -ge 2 ]; then
+ git-http-fetch -a -v $whead $recovery "$1" "$2/"
+ else
+ (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
+ fi
return ${PIPESTATUS[0]}
}
@@ -197,7 +200,11 @@ fetch_local()
{
whead=
[ "$3" ] && whead="-w $3"
- (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
+ if [ $verbose -ge 2 ]; then
+ git-local-fetch -a -l -v $whead $recovery "$1" "$2"
+ else
+ (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
+ fi
return ${PIPESTATUS[0]}
}
@@ -230,6 +237,7 @@ fetch_tags()
# if so, fetch the tag -- which should be
# a cheap operation -- to complete the chain.
echo -n "Missing tag ${tagname#tags/}... "
+ local verbose=2
if $fetch "$tagname" "$uri" "$tagname" 2>/dev/null >&2; then
echo "retrieved"
else
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: local clone performance
From: Jon Smirl @ 2006-07-27 18:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060727181554.GD13776@pasky.or.cz>
On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Jul 27, 2006 at 01:38:00AM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > Comparing git-clone to cg-clone
> >
> > [jonsmirl@jonsmirl apps]$ time git-clone git foo
> > ......
> > real 0m5.755s
> > user 0m4.548s
> > sys 0m0.512s
> >
> > [jonsmirl@jonsmirl apps]$ time cg-clone git foo
> > ....
> > real 0m18.970s
> > user 0m10.737s
> > sys 0m1.392s
> >
> > Why does it take cg clone so long to set up the missing tags?
> > git-clone is over 3x faster.
>
> How many tags do you have?
I am cloning the git source tree. It looks to have about 40 tags.
> It's true that cg-clone does not scale very well with big amounts of
> tags, because it won't fetch tagged objects you wouldn't get otherwise
> (so if you tagged some random huge blob or a history line which is not
> part of any branch you have, cg-clone won't grab it all). This
> unfortunately costs us one special fetch invocation per tag; I will look
> into hacking git-local-fetch to accept multiple commit ids at once, that
> should speed it up considerably.
>
> That said, with cg-clone -a I will be able to cut that difference
> entirely and blindly take everything from the other repository.
>
> Could you please try the patch below and check if it has at least
> any measurable impact on the performance at all? Thanks.
New timings
real 0m11.259s
user 0m9.977s
sys 0m1.280s
That's a 40% improvement.
> diff --git a/cg-fetch b/cg-fetch
> index a6e6959..23e0e77 100755
> --- a/cg-fetch
> +++ b/cg-fetch
> @@ -54,7 +54,6 @@ _git_wc_unneeded=1
>
> fetch_progress()
> {
> - [ $verbose -ge 2 ] && exec cat
> if [ -t 1 ]; then
> exec "${COGITO_LIB}"cg-Xfetchprogress "$_git_objects"
> else
> @@ -166,7 +165,11 @@ fetch_http()
> {
> whead=
> [ "$3" ] && whead="-w $3"
> - (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
> + if [ $verbose -ge 2 ]; then
> + git-http-fetch -a -v $whead $recovery "$1" "$2/"
> + else
> + (git-http-fetch -a -v $whead $recovery "$1" "$2/" 2>&1 /dev/null) | fetch_progress
> + fi
> return ${PIPESTATUS[0]}
> }
>
> @@ -197,7 +200,11 @@ fetch_local()
> {
> whead=
> [ "$3" ] && whead="-w $3"
> - (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
> + if [ $verbose -ge 2 ]; then
> + git-local-fetch -a -l -v $whead $recovery "$1" "$2"
> + else
> + (git-local-fetch -a -l -v $whead $recovery "$1" "$2" 2>&1 /dev/null) | fetch_progress
> + fi
> return ${PIPESTATUS[0]}
> }
>
> @@ -230,6 +237,7 @@ fetch_tags()
> # if so, fetch the tag -- which should be
> # a cheap operation -- to complete the chain.
> echo -n "Missing tag ${tagname#tags/}... "
> + local verbose=2
> if $fetch "$tagname" "$uri" "$tagname" 2>/dev/null >&2; then
> echo "retrieved"
> else
>
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Snow falling on Perl. White noise covering line noise.
> Hides all the bugs too. -- J. Putnam
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git clone stalls at a read(3, ...) saw using strace
From: Pavel Roskin @ 2006-07-27 18:41 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0607271049460.4168@g5.osdl.org>
On Thu, 2006-07-27 at 10:50 -0700, Linus Torvalds wrote:
> Nope. I have a fairly constant 120kbps, and:
>
> [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> Checking files out...)
> 100% (19754/19754) done
Same thing here. Current git from the master branch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Licensing and the library version of git
From: David Lang @ 2006-07-27 18:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607270936200.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> (*) I will, in fact, claim that the difference between a bad programmer
> and a good one is whether he considers his code or his data structures
> more important. Bad programmers worry about the code. Good programmers
> worry about data structures and their relationships.
personally I'd add to this that after the data structures are defined and you
turn to the code the API is significantly more important then the code itself.
David Lang
^ permalink raw reply
* [PATCH] Remove -d from *-fetch usage strings
From: Petr Baudis @ 2006-07-27 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is a really ancient remnant of the short era of delta objects stored
directly in the object database.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
http-fetch.c | 2 +-
local-fetch.c | 2 +-
ssh-fetch.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 12493fb..dc286b7 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1245,7 +1245,7 @@ int main(int argc, char **argv)
arg++;
}
if (argc < arg + 2) {
- usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
+ usage("git-http-fetch [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url");
return 1;
}
commit_id = argv[arg];
diff --git a/local-fetch.c b/local-fetch.c
index ffa4887..65a803a 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -194,7 +194,7 @@ int fetch_ref(char *ref, unsigned char *
}
static const char local_pull_usage[] =
-"git-local-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
+"git-local-fetch [-c] [-t] [-a] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
/*
* By default we only use file copy.
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 28f7fd9..a8a6cfb 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -120,7 +120,7 @@ int fetch_ref(char *ref, unsigned char *
static const char ssh_fetch_usage[] =
MY_PROGRAM_NAME
- " [-c] [-t] [-a] [-v] [-d] [--recover] [-w ref] commit-id url";
+ " [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url";
int main(int argc, char **argv)
{
char *commit_id;
^ permalink raw reply related
* Re: Git clone stalls at a read(3, ...) saw using strace
From: André Goddard Rosa @ 2006-07-27 19:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Git Mailing List, Linus Torvalds, Ribeiro, Humberto Plinio
In-Reply-To: <1154025679.13273.5.camel@dv>
On 7/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2006-07-27 at 10:50 -0700, Linus Torvalds wrote:
> > Nope. I have a fairly constant 120kbps, and:
> >
> > [torvalds@g5 ~]$ git clone git://source.mvista.com/git/linux-davinci-2.6.git
> > Checking files out...)
> > 100% (19754/19754) done
>
> Same thing here. Current git from the master branch.
Forgot to say that we are using this script in GIT_PROXY_COMMAND
environment variable:
(echo "CONNECT $1:$2 HTTP/1.0"; echo; cat ) | nc <proxy_add> <portnum>
| (read a; read a; cat )
The first 'read a' removes the 'CONNECT SUCCESS HTTP RESPONSE 200' and
the second removes an empty line as described here:
http://www.gelato.unsw.edu.au/archives/git/0605/20664.html
I will try from home later again.
Thanks,
--
[]s,
André Goddard
^ permalink raw reply
* Re: Licensing and the library version of git
From: Daniel Barkalow @ 2006-07-27 19:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Grzegorz Kulewski, Jon Smirl, Petr Baudis, Johannes Schindelin,
git
In-Reply-To: <Pine.LNX.4.64.0607271003270.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> >
> > I think that part of the anwser for question "Why do people use GIT?" is that
> > they trust you and other maintainers that you do a good and stable job. Won't
> > creating several ports/forks/whatever destroy at least part of this?
>
> Sure. But the point is, the GPLv2 isn't exactly up for discussion. People
> can complain all they want, but if they want to trust me, they'll take the
> GPLv2. It's that easy.
I think there'd be a justification for licensing part of git like sparse
is licensed, for the same reasons. It wouldn't include any of the
interesting operations, probably, but it would be worth having a canonical
implementation of reading and writing the data structures, so other
implementations don't screw that up. I wouldn't like to have someone write
a version that generated subtly corrupt git objects that it accepts along
with proper objects, such that we have to work around the breakage. It's a
bit less likely to happen if there's no licensing reason not to use the
same code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git bisect: merge problem with deleted file
From: Meelis Roos @ 2006-07-27 19:37 UTC (permalink / raw)
To: git
mroos@nartsiss:~/compile/linux-2.6$ git bisect start
mroos@nartsiss:~/compile/linux-2.6$ git bisect good 9be2f7c38e0bd64e8a0f74ea68df1e73e2ddfcc3
mroos@nartsiss:~/compile/linux-2.6$ git bisect bad 9676489866a75fdd56b0d3e40ec7884298bb1338
Bisecting: 43 revisions left to test after this
fatal: Untracked working tree file 'Documentation/filesystems/devfs/ChangeLog' would be overwritten by merge.
Got this while trying to bisec Linus' linux-2.6 tree. I have 1
uncommited change in the tree so this might influence the need for
merging.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: Licensing and the library version of git
From: Linus Torvalds @ 2006-07-27 19:44 UTC (permalink / raw)
To: David Lang; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.63.0607271140100.11253@qynat.qvtvafvgr.pbz>
On Thu, 27 Jul 2006, David Lang wrote:
>
> > (*) I will, in fact, claim that the difference between a bad programmer
> > and a good one is whether he considers his code or his data structures
> > more important. Bad programmers worry about the code. Good programmers
> > worry about data structures and their relationships.
>
> personally I'd add to this that after the data structures are defined and you
> turn to the code the API is significantly more important then the code itself.
I think people sometimes put too much emphasis on ABI's.
Sure, if you're depending on a library, the ABI is supremely important.
But I literally believe that one of the things that makes open source
technically superior to most other projects is the fact that ABI's can be
changed more easily, and sometimes at all.
If you have good data structures, the ABI's are largely irrelevant, and if
you have a problem with an existing ABI, you can just write a new
entrypoint instead (and leave the old ABI alone).
On the other hand, if you have bad datastructures, the ABI often reflects
that, and having the balls to say that your ABI's are broken and need to
be re-done in order to fix the data structures is _very_ important.
Otherwise you'll never be able to fix anything.
So I think that ABI's are often _way_ overhyped. If they are good,
everybody is happy. But if the interfaces are bad, you had better be
willing to just say "screw the ABI" and just fix it.
Now, that doesn't mean that you should change ABI's on a whim, and
regardless of any other issues, your user base is always important. But I
don't think ABI's are, or should be, "sacred".
For example, one thing git did early on was to just admit that some ABI's
are horribly horribly bad. For example, the CVS "annotate" ABI is just a
mistake, and trying to support that would just have held git back from
realizing that you can be so much more.
That may not be a "Application Binary Interface" kind of ABI, but it's an
interface, and it's exactly the same thing - sometimes you just have to
have the cajones to say "screw that, we'll be so much better if we can
change the interface".
Linus
^ permalink raw reply
* Re: Licensing and the library version of git
From: David Lang @ 2006-07-27 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607271232090.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> On Thu, 27 Jul 2006, David Lang wrote:
>>
>>> (*) I will, in fact, claim that the difference between a bad programmer
>>> and a good one is whether he considers his code or his data structures
>>> more important. Bad programmers worry about the code. Good programmers
>>> worry about data structures and their relationships.
>>
>> personally I'd add to this that after the data structures are defined and you
>> turn to the code the API is significantly more important then the code itself.
>
> I think people sometimes put too much emphasis on ABI's.
I was careful to say aPi, not aBi :-)
> Sure, if you're depending on a library, the ABI is supremely important.
> But I literally believe that one of the things that makes open source
> technically superior to most other projects is the fact that ABI's can be
> changed more easily, and sometimes at all.
very true
> If you have good data structures, the ABI's are largely irrelevant, and if
> you have a problem with an existing ABI, you can just write a new
> entrypoint instead (and leave the old ABI alone).
>
> On the other hand, if you have bad datastructures, the ABI often reflects
> that, and having the balls to say that your ABI's are broken and need to
> be re-done in order to fix the data structures is _very_ important.
> Otherwise you'll never be able to fix anything.
however it's possible to have a good data structure and a bad API. I'm just
emphisising the API over the 'elegance', etc of the code that implements it.
> So I think that ABI's are often _way_ overhyped. If they are good,
> everybody is happy. But if the interfaces are bad, you had better be
> willing to just say "screw the ABI" and just fix it.
>
> Now, that doesn't mean that you should change ABI's on a whim, and
> regardless of any other issues, your user base is always important. But I
> don't think ABI's are, or should be, "sacred".
I'm not meaning to imply in any way that API's are sacred, just that they are
very important and deserve a lot of thought before implementation.
David Lang
^ permalink raw reply
* Re: Licensing and the library version of git
From: Wolfgang Denk @ 2006-07-27 19:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com>
In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
>
> I see that someone is already writing a pure Java version which will
> work around the GPL problem assuming the Java version is released
> under a compatible license.
... and assuming it is a clean-room implementation which does not
borrow from the GPL code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Be careful what you wish for. You never know who will be listening.
- Terry Pratchett, _Soul Music_
^ permalink raw reply
* Re: [PATCH] Per branch properties for pull and fetch
From: Matthias Lederhofer @ 2006-07-27 20:26 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060727120220.GD27593@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> The current default is to always use the remote's master branch, right?
> What do others think: does it make sense to default to the same
> branchname on the remote side?
I like the separate-remote option too and having one simple command
that pulls the changes from the correct remote branch would be nice.
It should do something like
$ git pull ${1:-origin} $(git-symbolic-ref HEAD | cut -d / -f 3-)
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:38 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, Jon Smirl, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.63.0607271245200.11436@qynat.qvtvafvgr.pbz>
Hi
On Thu, 27 Jul 2006, David Lang wrote:
> On Thu, 27 Jul 2006, Linus Torvalds wrote:
>
> > On Thu, 27 Jul 2006, David Lang wrote:
> > >
> > > > (*) I will, in fact, claim that the difference between a bad programmer
> > > > and a good one is whether he considers his code or his data structures
> > > > more important. Bad programmers worry about the code. Good programmers
> > > > worry about data structures and their relationships.
> > >
> > > personally I'd add to this that after the data structures are defined and
> > > you
> > > turn to the code the API is significantly more important then the code
> > > itself.
> >
> > I think people sometimes put too much emphasis on ABI's.
>
> I was careful to say aPi, not aBi :-)
All Linus said about ABIs is true for APIs, too. The only difference
between the two is, that people depend on the sacredness of ABIs even more
than on APIs.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Jon Smirl, git
In-Reply-To: <20060727195614.7EDAE353B04@atlas.denx.de>
Hi,
On Thu, 27 Jul 2006, Wolfgang Denk wrote:
> In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
> >
> > I see that someone is already writing a pure Java version which will
> > work around the GPL problem assuming the Java version is released
> > under a compatible license.
>
> ... and assuming it is a clean-room implementation which does not
> borrow from the GPL code.
>From a standpoint of copyright (which the GPL relies on), this is not
possible: you cannot include C code into Java. And if it is _translated_
from C into Java, it is not copyrighted any more.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:41 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, Grzegorz Kulewski, Jon Smirl, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0607271457250.9789@iabervon.org>
Hi,
On Thu, 27 Jul 2006, Daniel Barkalow wrote:
> On Thu, 27 Jul 2006, Linus Torvalds wrote:
>
> > On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> > >
> > > I think that part of the anwser for question "Why do people use GIT?" is that
> > > they trust you and other maintainers that you do a good and stable job. Won't
> > > creating several ports/forks/whatever destroy at least part of this?
> >
> > Sure. But the point is, the GPLv2 isn't exactly up for discussion. People
> > can complain all they want, but if they want to trust me, they'll take the
> > GPLv2. It's that easy.
>
> I think there'd be a justification for licensing part of git like sparse
> is licensed, for the same reasons. It wouldn't include any of the
> interesting operations, probably, but it would be worth having a canonical
> implementation of reading and writing the data structures, so other
> implementations don't screw that up.
You could probably even get away just copying these I/O operations,
because there is obviously no other way to do it. Ergo, no enforcable
copyright on those code sections.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Petr Baudis @ 2006-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> >From a standpoint of copyright (which the GPL relies on), this is not
> possible: you cannot include C code into Java. And if it is _translated_
> from C into Java, it is not copyrighted any more.
now that's a pretty strong statement - did a lawyer tell you that?
(Lawyer in what country? Germany?) Because copyrights are generally
retained over translations, otherwise I could freely publish
e.g. Czech translation of someone else's English book without any
permissions and such, which is obviously not the case.
There has been actually similar issue with OpenTTD - it was created by
translating Transport Tycoon Deluxe assembly to C without permission of
original TTD copyright owner (not that anyone actually knows for sure
who that is, after series of company mergers and buyouts). I don't think
anyone consulted a lawyer about legality of that either but I believe
that most people agree that this is basically illegal (but most likely,
noone will ever sue, or care at all).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 21:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <20060727205158.GE13776@pasky.or.cz>
Hi,
On Thu, 27 Jul 2006, Petr Baudis wrote:
> Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > >From a standpoint of copyright (which the GPL relies on), this is not
> > possible: you cannot include C code into Java. And if it is _translated_
> > from C into Java, it is not copyrighted any more.
>
> now that's a pretty strong statement - did a lawyer tell you that?
<politics>
No. And I hate the fact that more and more people are actually accepting
the idea of being dictated how they should live by lawyers.
If a law is not clear to a layman, it should not be enforcable.
</politics>
> (Lawyer in what country? Germany?) Because copyrights are generally
> retained over translations, otherwise I could freely publish
> e.g. Czech translation of someone else's English book without any
> permissions and such, which is obviously not the case.
<message="I am not a lawyer... sh1t, I am disgusted by those">
The bigger problem is to _prove_ that it is a translation. It is much
easier with a 300-page book you translated from English into Czech.
It is almost impossible to prove something was copied if the source
language is a procedural computer language, and the target language is an
object-oriented computer language. Given the technical abilities of
judges, I even doubt that the act of the translation would _not_ be deemed
a non-literal transformation of the source code (and thus not be a
copyright case).
</message>
> There has been actually similar issue with OpenTTD - it was created by
> translating Transport Tycoon Deluxe assembly to C without permission of
> original TTD copyright owner (not that anyone actually knows for sure
> who that is, after series of company mergers and buyouts). I don't think
> anyone consulted a lawyer about legality of that either but I believe
> that most people agree that this is basically illegal (but most likely,
> noone will ever sue, or care at all).
<politics again=true>
Let's be honest: lawyers will only be interested in the money they get.
They will not care one wit about what is right or wrong: just look in some
newspaper of your choice. This is a sad fact about our world (but there is
a remedy: look into the Hitchhiker's guide to the galaxy).
The consequence is: no lawyer will properly defend the work of open source
people, since they tend to be poor (well, at least not rich). You just
cannot make much money by being nice.
</politics>
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Wolfgang Denk @ 2006-07-27 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In message <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de> you wrote:
>
> > ... and assuming it is a clean-room implementation which does not
> > borrow from the GPL code.
>
> >From a standpoint of copyright (which the GPL relies on), this is not
> possible: you cannot include C code into Java. And if it is _translated_
> from C into Java, it is not copyrighted any more.
Gulp. What have you been smoking lately? Your understanding of
copyright (and of the GPL) is fundamentally broken.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Mr. Cole's Axiom:
The sum of the intelligence on the planet is a constant;
the population is growing.
^ 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