Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Petr Baudis wrote: Dear diary, on Tue, Apr 12, 2005 at 11:50:48AM CEST, I got a letter Well, yes, but the last merge point search may not be so simple: A --1---26---7 B\ `-4-. / C `-3-5' Now, when at 7, your last merge point is not 1, but 2. ...and this is obviously wrong, sorry. You would lose 3 this way. Wouldn't the delta betweeen 2 and 5 include any contribution from 3? Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Tue, Apr 12, 2005 at 11:50:48AM CEST, I got a letter where Petr Baudis <[EMAIL PROTECTED]> told me that... > Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter > where Geert Uytterhoeven <[EMAIL PROTECTED]> told me that... > > On Tue, 12 Apr 2005, Petr Baudis wrote: > ..snip.. > > > Basically, when you look at merge(1) : > > > > > > SYNOPSIS > > >merge [ options ] file1 file2 file3 > > > DESCRIPTION > > >merge incorporates all changes that lead from file2 to file3 > > > into file1. > > > > > > The only big problem is how to guess the best file2 when you give it > > > file3 and file1. > > > > That's either the point just before you started modifying the file, or your > > last merge point. Sounds simple, but if your SCM system doesn't track > > merges, > > your SOL... > > Well, yes, but the last merge point search may not be so simple: > > A --1---26---7 > B\ `-4-. / > C `-3-5' > > Now, when at 7, your last merge point is not 1, but 2. ...and this is obviously wrong, sorry. You would lose 3 this way. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter where Geert Uytterhoeven <[EMAIL PROTECTED]> told me that... > On Tue, 12 Apr 2005, Petr Baudis wrote: ..snip.. > > Basically, when you look at merge(1) : > > > > SYNOPSIS > >merge [ options ] file1 file2 file3 > > DESCRIPTION > >merge incorporates all changes that lead from file2 to file3 > > into file1. > > > > The only big problem is how to guess the best file2 when you give it > > file3 and file1. > > That's either the point just before you started modifying the file, or your > last merge point. Sounds simple, but if your SCM system doesn't track merges, > your SOL... Well, yes, but the last merge point search may not be so simple: A --1---26---7 B\ `-4-. / C `-3-5' Now, when at 7, your last merge point is not 1, but 2. What I have proposed at the git mailing list was to have simple merging tracking - merges/branch1/branch2 directory structure which would store merges from branch2 to branch1. Then, when merging say to branch3, you traverse all of them and if any of the branch1/* commits is newer than branch3/*, you update it. The disadvantage is that you now need to strictly use gitmerge.sh to do the merges - Linus' revtree solution is nicer in the regard that it works without any explicit bookkeeping, and tracks any merges properly recorded with commit-file; it is more complex and more expensive, though. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On Tue, 12 Apr 2005, Petr Baudis wrote:
> Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter
> where "Adam J. Richter" <[EMAIL PROTECTED]> told me that...
> > >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
> > >where "Adam J. Richter" <[EMAIL PROTECTED]> told me that...
> > >..snip..
> > >> Graydon Hoare. (By the way, I would prefer that git just punt to
> > >> user level programs for diff and merge when all of the versions
> > >> involved are different or at least have a very thin interface
> > >> for extending the facility, because I would like to do some character
> > >> based merge stuff.)
> > >..snip..
> >
> > >But this is what git already does. I agree it could do it even better,
> > >by checking environment variables for the appropriate tools (then you
> > >could use that to pass diff e.g. -p etc.).
> >
> > This message from Linus seemed to imply that git was going to get
> > its own 3-way merge code:
> >
> > | Then the bad news: the merge algorithm is going to suck. It's going to be
> > | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
> > | understanding of renames etc. I'll try to find the best parent to base the
> > | merge off of, although early testers may have to tell the piece of crud
> > | what the most recent common parent was.
>
> Well, from what I can read it says "just plain 3-way merge, the same
> RCS/CVS thing you've seen before". :-)
>
> Basically, when you look at merge(1) :
>
> SYNOPSIS
>merge [ options ] file1 file2 file3
> DESCRIPTION
>merge incorporates all changes that lead from file2 to file3
> into file1.
>
> The only big problem is how to guess the best file2 when you give it
> file3 and file1.
That's either the point just before you started modifying the file, or your
last merge point. Sounds simple, but if your SCM system doesn't track merges,
your SOL...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter where "Adam J. Richter" <[EMAIL PROTECTED]> told me that... > >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter > >where "Adam J. Richter" <[EMAIL PROTECTED]> told me that... > >..snip.. > >> Graydon Hoare. (By the way, I would prefer that git just punt to > >> user level programs for diff and merge when all of the versions > >> involved are different or at least have a very thin interface > >> for extending the facility, because I would like to do some character > >> based merge stuff.) > >..snip.. > > >But this is what git already does. I agree it could do it even better, > >by checking environment variables for the appropriate tools (then you > >could use that to pass diff e.g. -p etc.). > > This message from Linus seemed to imply that git was going to get > its own 3-way merge code: > > | Then the bad news: the merge algorithm is going to suck. It's going to be > | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no > | understanding of renames etc. I'll try to find the best parent to base the > | merge off of, although early testers may have to tell the piece of crud > | what the most recent common parent was. Well, from what I can read it says "just plain 3-way merge, the same RCS/CVS thing you've seen before". :-) Basically, when you look at merge(1) : SYNOPSIS merge [ options ] file1 file2 file3 DESCRIPTION merge incorporates all changes that lead from file2 to file3 into file1. The only big problem is how to guess the best file2 when you give it file3 and file1. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote: > Hello, > please do not trim the cc list so agressively. Sorry. I read the list from a web site that does not show the cc lists. I'll try to cc more people from the relevant discussions though. On the other hand, I've dropped Linus from this message, as it just points to something he previously said. >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter >where "Adam J. Richter" <[EMAIL PROTECTED]> told me that... >..snip.. >> Graydon Hoare. (By the way, I would prefer that git just punt to >> user level programs for diff and merge when all of the versions >> involved are different or at least have a very thin interface >> for extending the facility, because I would like to do some character >> based merge stuff.) >..snip.. >But this is what git already does. I agree it could do it even better, >by checking environment variables for the appropriate tools (then you >could use that to pass diff e.g. -p etc.). This message from Linus seemed to imply that git was going to get its own 3-way merge code: | Then the bad news: the merge algorithm is going to suck. It's going to be | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no | understanding of renames etc. I'll try to find the best parent to base the | merge off of, although early testers may have to tell the piece of crud | what the most recent common parent was. ( from http://marc.theaimsgroup.com/?l=linux-kernel&m=111320013100822&w=2 ) __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Hello, please do not trim the cc list so agressively. Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter where "Adam J. Richter" <[EMAIL PROTECTED]> told me that... ..snip.. > Graydon Hoare. (By the way, I would prefer that git just punt to > user level programs for diff and merge when all of the versions > involved are different or at least have a very thin interface > for extending the facility, because I would like to do some character > based merge stuff.) ..snip.. But this is what git already does. I agree it could do it even better, by checking environment variables for the appropriate tools (then you could use that to pass diff e.g. -p etc.). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
* Petr Baudis: >> Almost certainly, v3 will be incompatible with v2 because it adds >> further restrictions. This means that your proposal would result in >> software which is not redistributable by third parties. > > Hmm, what would be actually the point in introducing further > restrictions? Anyone who then wants to get around them will just > distribute the software with the "any later version" provision under > GPLv2, and GPLv3 will have no impact expect for new software with "v3 or > any later version" provision. What am I missing? Software continues to evolve. The copyright owners can relicense the code base under v3, and use v3 for all subsequent changes to the software. The trouble with relicensing is that you have to contact all copyright holders (or remove their code). This tends to be impossible in long-running projects without contractual agreements between the developers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On 2005-04-11, Linus Torvalds wrote:
>I'm inclined to go with GPLv2 just because it's the most common one [...]
You may want to use a file from GPL'ed monotone that
implements a substantial diff optimization described in the August
1989 paper by Sun Wu, Udi Manber and Gene Myers ("An O(NP) Sequence
Comparison Algorithm"). According to th file, that implementation
was a port of some Scheme code written by Aubrey Jaffer to C++ by
Graydon Hoare. (By the way, I would prefer that git just punt to
user level programs for diff and merge when all of the versions
involved are different or at least have a very thin interface
for extending the facility, because I would like to do some character
based merge stuff.)
It looks to me like the anti-patent provisions of OSLv2.1
could be circumvented by an offender creating a separate company
to do patent litigation. So, I think you'll find that the software
reuse benefits (both to GIT and to other software projects) of the
more widely used GPL ougtweigh the anti-patent benefits of OSLv2.1.
Although I like the idea of anti-patent provisions, such
as those in OSLv2.1, I think mutual compatability of free
software is probably more consequential, even from a purely
political perspective.
Perhaps you might want to consider offering the code
under the distributor's choice of either license if you want
to offer the very minor benefits of slightly easier compliance
to those who do not litigate software patents, or, perhaps more
importantly, the ability of the software to be copied into
OSLv2.1 projects (if there are any).
__ __
Adam J. Richter\ /
[EMAIL PROTECTED] | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Mon, Apr 11, 2005 at 10:40:00AM CEST, I got a letter where Florian Weimer <[EMAIL PROTECTED]> told me that... > * Ingo Molnar: > > > is there any fundamental problem with going with v2 right now, and then > > once v3 is out and assuming it looks ok, all newly copyrightable bits > > (new files, rewrites, substantial contributions, etc.) get a v3 > > copyright? (and the collection itself would be v3 too) That method > > wouldnt make it fully v3 automatically once v3 is out, but with time > > there would be enough v3 bits in it to make it essentially v3. > > Almost certainly, v3 will be incompatible with v2 because it adds > further restrictions. This means that your proposal would result in > software which is not redistributable by third parties. Hmm, what would be actually the point in introducing further restrictions? Anyone who then wants to get around them will just distribute the software with the "any later version" provision under GPLv2, and GPLv3 will have no impact expect for new software with "v3 or any later version" provision. What am I missing? I've been doing a lot of LKML catching up, and I remember someone suggesting using GPLv2 (for kernel, but should apply to git too), with a provision to let someone trusted (Linus) decide when GPLv3 is out whether you can use GPLv3 for the kernel too. Does it make sense? And is it even legally doable without sending signed written documents to Linus' tropical hacienda? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
* Ingo Molnar: > is there any fundamental problem with going with v2 right now, and then > once v3 is out and assuming it looks ok, all newly copyrightable bits > (new files, rewrites, substantial contributions, etc.) get a v3 > copyright? (and the collection itself would be v3 too) That method > wouldnt make it fully v3 automatically once v3 is out, but with time > there would be enough v3 bits in it to make it essentially v3. Almost certainly, v3 will be incompatible with v2 because it adds further restrictions. This means that your proposal would result in software which is not redistributable by third parties. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > Btw, does anybody have strong opinions on the license? I didn't put in > a COPYING file exactly because I was torn between GPLv2 and OSL2.1. > > I'm inclined to go with GPLv2 just because it's the most common one, > but I was wondering if anybody really had strong opinions. For > example, I'd really make it "v2 by default" like the kernel, since I'm > sure v3 will be fine, but regardless of how sure I am, I'm _not_ a > gambling man. is there any fundamental problem with going with v2 right now, and then once v3 is out and assuming it looks ok, all newly copyrightable bits (new files, rewrites, substantial contributions, etc.) get a v3 copyright? (and the collection itself would be v3 too) That method wouldnt make it fully v3 automatically once v3 is out, but with time there would be enough v3 bits in it to make it essentially v3. This way we wouldnt have to blanket trust v3 before having seen it, and wouldnt be stuck at v2 either. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
> Btw, does anybody have strong opinions on the license? I didn't put in a > COPYING file exactly because I was torn between GPLv2 and OSL2.1. I think GPLv2 would create the least amount of objection in the community, so I'd probably want to go with that. Nur Hussein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Mon, Apr 11, 2005 at 02:20:52AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Btw, does anybody have strong opinions on the license? I didn't put in a > COPYING file exactly because I was torn between GPLv2 and OSL2.1. > > I'm inclined to go with GPLv2 just because it's the most common one, but I > was wondering if anybody really had strong opinions. For example, I'd > really make it "v2 by default" like the kernel, since I'm sure v3 will be > fine, but regardless of how sure I am, I'm _not_ a gambling man. Oh, I wanted to ask about this too. I'd mostly prefer GPLv2 (I have no problem with the version restriction, I usually do it too), it's the one I'm mostly familiar with and OSL appears to be incompatible with GPL (at least FSF says so about OSL1.0), which might create various annoying issues. I hate when licenses get in my way and prevent me to possibly include some useful code. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
