* git rev-list ordering
From: Ian Hilt @ 2008-11-16 0:44 UTC (permalink / raw)
To: Git Mailing List
Why is it that this command,
git rev-list --reverse --max-count=1 <branch>
results in the same SHA1 as,
git rev-list --max-count=1 <branch>
So far, the documentation and the mailing list archives haven't helped.
^ permalink raw reply
* Re: [PATCH v2 07/11] gitweb: add 'remotes' action
From: Jakub Narebski @ 2008-11-16 0:29 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811150432s2f3ae4bfkc0fc29d92accc635@mail.gmail.com>
On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
> On Sat, Nov 15, 2008 at 1:16 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 13 Nov 2008, Giuseppe "Oblomov" Bilotta wrote:
>>
>>> This action is similar to the 'heads' action, but it displays
>>> remote heads, grouped by remote repository.
>>
>> I think I would prefer would go together with the change that split
>> the 'heads' ('branches') part of summary view into 'heads' and
>> 'remotes', so that both section title header, and '...' continuation
>> if present, lead to proper view.
>>
>> So either
>>
>> [heads] # or [branches]
>> master
>> to-submit
>> origin/master
>> origin/next
>> ...
>>
>> where both '[heads]' and (possibly) '...' link to 'heads' view showing
>> _both_ local branches (refs/heads/*) and remote-tracking branches
>> (refs/remotes/*), like in first patch of series (perhaps with some
>> subdivision).
>>
>> Or
>>
>> [heads]
>> master
>> to-submit
>> ...
>> [remotes]
>> origin/master
>> origin/next
>> ...
>>
>> where '[heads]' link to 'heads' view which shows only local branches
>> (refs/heads/*), and '[remotes]' link to 'remotes' view which shows only
>> remote-tracking branches.
>
> That's funny, I just squashed this patch with the summary list split
> view patch 8-) I'm going for the second option, to have [heads] link
> to heads which only lists local heads, and [remotes] linking to
> remotes that lists the remotes. We may or may not want to rather have
> [branches] instead of [heads], and keep the heads action to mean *all*
> heads, local and remote, but I'm not sure about it.
Errr... that was what I meant. First patch adding feature, and adding
remotes (not separated) to 'heads' section and 'heads' view (it could
have renamed 'heads' section to 'branches' but I feel that unnecessary),
and second patch squashed which adds 'remotes' section _and_ 'remotes'
action.
>> Nice. I see the difference from git_heads is using $project . ' remotes'
>> in place of $project in git_print_header_div() (why?),
>
> FWIW, I decided to scratch that additional ' remotes' string when
> squashing this patch.
Hmmm... I'm not sure if $project in git_print_header_div() for those
two actions is good thing to have...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Any overview available on jgit codebase?
From: Farrukh Najmi @ 2008-11-16 0:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Kyle Moffett, Robin Rosenberg, git
In-Reply-To: <20081115231537.GD2932@spearce.org>
Shawn O. Pearce wrote:
> Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
>> At minimum could anyone tell me what packages and classes to look at in
>> order to make changes to jgit so it uses a database instead of
>> filesystem to references.
>>
>
> See RefDatabase, created by Repository. You would want to replace
> RefDatabase with your own implementation, which means abstracting
> that class to be an abstract base class or an interface.
>
> RefUpdate and RefLogWriter are connected to RefDatabase, so you
> would likely need to modify those too in order to make the change,
> especially since RefUpdate is the "INSERT OR UPDATE OR DELETE"
> logic. :)
>
> BTW, I want to do that RefDatabase abstraction anyway, because I'd
> like to get an in-memory only version of RefDatabase, to make unit
> testing easier. So abstracting this code may be useful beyond just
> your desire to back Git with a JDBC-style database.
>
This is just what I was hoping for. Thanks Shawn. I will try and do this
next week and ask for help as needed. Thank you.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] gitk: Highlight found text only for when search type is "containing".
From: Mark Burton @ 2008-11-16 0:05 UTC (permalink / raw)
To: git
In-Reply-To: <1226790769-25019-1-git-send-email-markb@ordern.com>
Hi,
The patch got sent without this blurb (not really sure how to send
patches to the list with leading blurb).
Anyway, I thought I would try and stop gitk from always highlighting
the text in the commit and comment panes that matches the text in the
search field. To me, it only makes sense to highlight the text when the
search type is "containing". For the other search types (definitely
for the touching paths type), I don't really see how having occurrences
of the search text highlighted helps.
I don't really understand how gitk operates but the patch does what I
want. I'm sure those in the know can improve on it if what it does is
useful.
Cheers,
Mark
^ permalink raw reply
* Yes, SymPy should be LGPL! (please help)
From: Kirill Smelkov @ 2008-11-16 0:07 UTC (permalink / raw)
To: sympy
Cc: sage-devel, maxima, ginac-list, linux-kernel, git,
mercurial-devel, cairo, wine-devel
In-Reply-To: <20081115114859.GB23252@phare.normalesup.org>
[First of all, sorry for off-topic to those lists not related to SymPy]
This email is posted here in hope to reach people who share my
point of view, and to ask to please help to
_____________________________________________________
/\ \
\_| Advocate switching SymPy license from BSD to LGPL |
| |
| ________________________________________________|_
\_/__________________________________________________/
Start of this thread is here:
http://groups.google.com/group/sympy/browse_thread/thread/b5addd939ee0c803
Introduction
============
Currently SymPy is distributed under new BSD license.
But this was not always so -- originally the project was licensed under
GPL (!), but in the beginning of 2007, after Pearu Peterson has proposed
to switch to LGPL or BSD [1], developers decided to take permissive
approach -- BSD.
I've joined SymPy project later - in 2007 summer, and now I'm
proposing we change SymPy license to LGPL (Lesser GPL) which I
see as a golden median between beeing too permissive (BSD) and too
strict (GPL). |
|
v
BSD ---- LGPL ---- GPL
+------------------------->
strictness
Read below why
[1] http://code.google.com/p/sympy/issues/detail?id=138
On Wed, 12 Nov 2008 13:24:39 -0800, Robert Kern wrote:
> FWIW, my vote is for BSD. I, personally, don't work on (weak or
> strong) copyleft projects. Copyleft licenses are intrinsically
> attached to an agenda which I don't share so I don't use them. I'm not
> a fan of agendas.
>
> I can see the point for some pieces of software where there is a known
> threat (e.g. the LGPLed work on GMP gets enhanced slightly by a
> proprietary product and resold with lots of bragging about how they're
> better than the open source GMP), but is there an actual threat to
> sympy? Hypothetical threats don't impress me much.
Really?
Even if it is not evident to the casual observer, in the begginning of a
chess play, there is already a threat to your figures, and your king and
queen, so chessplayers usually try to analyze the situation early and
look into the future for at least several turns. And the player, who can
analyze more turns than the other, wins.
My understanding is that SymPy is close to enter "serious CAS" market,
and as Ondrej says below, SymPy has a lot of potential. To me what is
needed to be done for this is to go into compiled mode for core, and to
refine core design and it's data structures. Plus constantly trying to
apply SymPy to real-world problems, so that we could be sure we have
good engine connected to good user interface.
As during the last year I've touched both internal and high-level stuff
quite a bit, I think I'm keeping my hand at pulse here, and my
understanding is that together with all the polishing, assuming the
previous temp of work, this transition should take 6 - 12 months.
And after this transition is done, wouldn't it be like the case with
GMP, in which you say you see the points for LGPL?
Only then it would be late (or much more difficult than today) to protect
SymPy from abuse -- That's why I care *now*.
On Thu, 13 Nov 2008 01:54:23 -0800, Andy Ray Terrel wrote:
> This is something of a tough discussion for me, mostly because I
> disagree and agree with a large number of points made here. I
> ultimately reject that the 4 freedoms of Richard M. Stallman (RMS) are
> some how fundamental to a computer user. I prefer the arguments given
> by Lawrence Lessig, that a free culture is a better more productive
> culture. RMS does make a very nice point that a way to preserve this
> free culture is to practice the 4 freedoms and require those who use
> our software to comply. Lessig's Creative Commons licenses allow for
> this structure as well as others. Nevertheless I also hold firmly
> that it is rather the community of developers and not the legal
> structure it stands on that make open source such a great experience.
> I and many friends have developed BSD, GNU, and proprietary licensed
> software with similar goals to promote technology and human progress,
> much less motivated by secret agendas or monetary reward. A lesson I
> have learned, projects that are *only* about money are never the
> innovators of technology.
>
> The debate I do agree with RMS on is in the view of labor rights of
> the computer programmer. Programmers are not the first community of
> artisans where it is easy to manipulate their works for personal gain
> rather than that of the community. By following a copyleft license
> the computer programmer is investing in her community and protecting
> that investment from those who would falsely claim the work as their
> own. Agreeing with Linus Torvalds, this does not mean to me one
> cannot work with proprietary projects but rather the investment in the
> community creates better software. The BSD license protects the
> developer, the GNU set of licenses protect the community. I find a
> nice balance in the LGPL license because it does allow proprietary
> development and marketing but still protects the community.
Yes, in essence, this is what I'm advocating for:
a nicely balanced LGPL license which allows proprietary development
and marketing but still protects the community
> You are going to lose users for many reasons. Losing them because do
> not wish to conform to policies in place to protect the creative
> investment of the community is not a bad reason.
Yes, users and developers come and go.
A lot of people listed in our README already went away for various
reasons. Some did not fit into team-development and respect-each-other
and dont-break-existing stuff rule, some got afraid of patch review (I
suspect I was the main source of disaster), some got busy with other
stuff, etc...
It is not possible to be good for everyone -- that's why I don't try to
satisfy all the people, but instead try to be good for me myself, and do
whatever I think is better for me and for SymPy code, and if the result
could be somehow useful for others - I don't mind at all.
I hope that the last year shows that this approach worked quite well.
> I think sympy is a great community not because of its license but
> because of the people and I will continue to invest in such a
> community no matter what the license.
Likewise did I.
I've put licensing stuff on shelve in harder times, just to concentrate
on technical bits and defend SymPy. But after that investment (it was in
spare time + several day offs, compare with e.g. 6 months full-time
grant sponsored development of sympycore [1]), it became much more evident
that developers effort have to be protected.
Yes, to me developers effort have to be respected and protected. And if
this could be done in a compromise way, it should be done.
Please read below, where I'm advocating LGPL in more details.
[1] http://code.google.com/p/sympy/wiki/SymPyCore
On Thu, 13 Nov 2008 09:27:29 -0800, Vinzent Steinberg wrote:
> First of all I want to thank you, Kirill, it was great to enjoy your
> support. You are certainly one of the most constructive persons I
> know.
Thank you Vinzent for you kind words. This proposition gives me one more
reason to think that this time, I'm too proposing something
constructive.
> I think the problem is quite fundamental. Many developers are
> investing quite a lot in an open source project, and they don't want
> others to modify it without profiting from their modification. This
> point I perfectly valid.
>
> Given that sympy would be picked up by an company and they would turn
> it into a closed source mathematica2, some sympy probably developers
> would say: "Great, this draws much attention to our open source
> project, and we will profit from the research they will do, because we
> can see how they solved problems, even if they don't share their code
> with us. And after all, it's better they invest in this area without
> sharing code than not investing anything (due to restrictive
> licenses)." For this kind of developers, the BSD license is better,
> because they think it's better for the project and the code in their
> opinion.
I'll tell you one story about me and physics:
I was working on some physics research and developed my own routines
pack for this. At seminar, after I've talked about current progress, one
of my collegues asked me:
"Kirill, you have done nice job with developing you routines pack,
may I borrow them for my research too?"
Sure, my answer was
"Yes, please. Here you are."
On the next seminar that collegue was talking about his progress, and he
mentioned my routines, and that he enhanced them a bit.
This time, I've asked him:
"Nice job, could you please give your versions of my routinse to me?
I'd like to use them too"
and, the answer was
"No, I can't. I need the result to be published first, so that I
have acknowledgment for my research. After I'll publish the
results, I'll give you your original routines enhanced by me"
I thought.
"Ok. I was not going to compete with this guy and steal his credits
in the first place anyway, but it seems he wants to be extra sure
in this, so even if it is a bit pity, that I can't use the
enhancements yet, so be it."
Time has passed, and on the next seminar, my collegue was talking about
his new progress, and mentioned his recently published paper with great
results obtained with the help of my routines. It turned out that this
time, they were again enhanced slightly more.
I've asked him:
"Now you have your paper published, could you please give me my
enhanced routines, so that I can use them for my research too?"
I was sure, he would say "yes, please", but I've made a mistake:
"No, if I give you your enhanced routines, this would make us equal,
and I could not be sure to win this tasty new grant we'll be
competing for on the next week."
I thought huh!? How is it possible that I've shared my research in the
first place, and now he says he is not going to do the same, even when
his work stood on my basis?
Needles to say, that the next time, when I talked about my progress and
new software which I had to develop along the way, I refused to give it
to my collegue, because I though that he plays unfair:
"Last time you took my routines and enjoyed using them, but when I
asked you to share your enhancements, you refused for various
reasons.
So why should I give my work to you this time?"
This conflicting situation became known to our management, and they
tried to analyze it and asked me:
"Kirill, at our department we do different kind of research, and we
have lots of groups. How we work was always cooperative in spirit -
we always used to share the results internally and give advices to
each other.
Yes, sometimes there is concurency between groups, but this was
never an obstacle for cooperative research, because everyone is
aware and confirming to good science ethics - not to publish
overlapping results before the original author.
Why are you refusing to share your work with collegue?"
I told them that we used to share codes, but somehow contributing flow
became unidirectional, and that I think this is not fair to only take
and not to give back:
"I'm ok with my collegues developing their own private codes, even
if they are using mine, but I'd like them to share back their
changes to _mine_ code. It's _their_ behaviour which is not
cooperative."
This story is imaginary, but I think it fairly well illustrates
qualitively the situation I have in mind. You can think of two
physicians, two mathematitians, or sympy development community v.s. some
company which ships locked down sympy to its customers.
And it's this "we only take and locally modify" which I propose to
legally prevent.
---
As to
"Great, this draws much attention to our open source
project, and we will profit from the research they will do, because we
can see how they solved problems, even if they don't share their code
with us. And after all, it's better they invest in this area without
sharing code than not investing anything (due to restrictive
licenses)."
I disagree that in the long run, the original project will profit.
Practice shows that instead, usually it's closed neighbour draw
developers (key developers are usually just hired) and users, but after
this happens, the main project stays with even less resources, and this
strikes back at both open and closed projects. End of story.
Please read below about how this happens.
> But others would mention: "I want my project to be open, closed source
> is completely useless for me. I spent my work to let others share, not
> that someone grabs it to make money with it without giving anything
> back to the community. Freedom is one of the most important things
> about our project, and this company is destroying freedom. Because
> they have more resources they will have a more polished product and
> drawing off our users and contributors. It's ok if they use it to earn
> money, but they have to give something back"
>
> These opinions are quite polarized and are probably not well
> formulated by me. Mainly I want to say that both opinions are equally
> right. It's up to everyone to decide which license and use of his very
> work pleases him most and to respect the decisions and motivations of
> developers preferring other licenses. You can't make both groups
> happy.
You *can*. For example glibc being mostly LGPL is used by every program
and every library on Linux system, including e.g. Python which is
BSD-like licensed, and every proprietary program which runs on GNU/Linux.
My point here is that LGPL (Lesser GPL) is a good compromise between
beeing too strict (GPL) and too permissive (BSD).
Actually my license would be the "Fair use of SymPy"
"""
Fair use of SymPy
-----------------
You can use SymPy as you want, and we encourage you to build various
products on top of SymPy including commercial and closed-source ones.
Your own code that uses SymPy as a library can perfectly stay
proprietary.
But if you change SymPy itself -- you have to share your modifications
to SymPy, your other code still stays yours.
To legally state what we think is our "Fair use of SymPy" we adopt LGPL
license.
"""
As last line says, its simply LGPL who is the closest-in-spirit
translation of this terms which is composed by legal-aware people and is
tested.
> An example for such an scenario is Wine. They switched from MIT to
> LGPL due to a company not contributing changes back to the core
> project.
Yes, Wine is a good example.
And before switching, they were too wanting "Wine to be used as wide as
possible" - that's why they were licensed by MIT (similar to BSD).
But when they started to be abused by TransGaming (who developed closed
WineX and did not contributed back their changes), they decided to
switch to LGPL, because LGPL'ed Wine is still perfectly allowed to be
used by essentially any software (closed and open), but changes to Wine
itself have to be always made shared with whom you distribute Wine.
http://wiki.winehq.org/FAQ#head-72731b215bbd1ce36e3b84ac7ce114925ce16460
http://wiki.winehq.org/WineHistory
So they changed from BSD to LGPL and this is what happened:
"""
The immediate effect was the creation of the ReWind project to further
the X11-licensed codebase. Many key developers agreed to allow their
additions to be used by both the X11 and LGPL Wine code. Most have
decided to focus their efforts on synchronizing with the LGPL'ed Wine
and the vast majority of development and new features appear there
first. Picking a favorite software license is left as an exercise for
the reader.
Shortly after changing the license development began to pick up at a
greater pace. More patches began to appear, Alexandre made more CVS
commits, and more applications were reported to work. By the end of
2003 DLL separation achieved a milestone with the split of the
kernel32/ntdll combination. Most of the architectural changes to
support a beta release were in place. Another developer's conference
was held in January, 2004 in St. Paul Minnesota sponsored by
CodeWeavers. Once again, a roadmap was laid out for tasks that needed
to be completed.
"""
So it seems LGPL also boosted Wine development.
> I would count myself to the first group (I wouldn't mind if a company
> would do such things to sympy), but I comprehend very well others like
> Kirill who do not want this.
Yes, I strongly mind when someone only takes, modifies, and gives
nothing back. As said above, I'm ok if anyone takes SymPy and uses it in
a closed-source proprieary product, but if he changes SymPy itself, I
strongly mind for that SymPy-changes to be closed.
> > "make private modifications to sympy and keep them secret."
>
> If I understand the GPL correctly, it won't prevent this. It does not
> force you to give modifications back. It only forces you to distribute
> your program with sources. This means they can keep modifications
> private as long as they don't sell the software. And this practically
> means that modifications won't be secret of course. :)
>
> I don't like that GPL is so viral. It's often incompatible to other
> open source licenses. But it's a great choice if you want to to avoid
> these "private and secret modifications".
Please, why are you talking about GPL here?
I'm proposing LGPL which is a different, "non viral" license [1].
When you mix GPL here, you create confusion, and I think that confusion
is the first step towards creating FUD (Fear, Uncertainty and Doubt)
[2].
As to you statement - yes, I don't care about someone keeping private
modifications without redistributing them -- all I care about is
redistribution, and this is covered by LGPL.
[1] http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
[2] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
On Sat, Nov 15, 2008 at 12:48:59PM +0100, Gael Varoquaux wrote:
> On Wed, Nov 12, 2008 at 09:47:18PM +0100, Ondrej Certik wrote:
> > it's a very nice and honest email. Kirr has done a stellar job over
> > the past year and half and we definitely would not be as advanced with
> > sympy without him. I'll reply to his arguments in my next email.
>
> I'll use my mail to reply mainly to Kirr (I hope he is still listening)
> because I hugely respect and value a man who has invested a large amount
> of quality time in a community project.
>
> Kirr, you have been a fantastic actor of the project. You are now saying
> that you are tired. This is actually a fairly common problem. We all
> fight with lack of time, to many various interests. Software development
> comes with its load of difficulties and disappointments. Too much
> sacrifices ruin private life.
>
> I am off course very sad if you quit this project that I follow (without
> contributing, sorry) and in which I believe. However, what I really want
> is to thank you for all your work. I hope you had as much fun as
> possible, and I hope that your will keep good memories of your time with
> sympy, rather than the reasons that made you quit. And besides, no
> decisions is irreversible. I believe that you will have friends in the
> sympy team whether you are contributing or not. Life and friendship are
> more important than software.
Thanks Gaël for your words too.
Being friends is one thing, protecting the results of hard work from
abuse is another one. That's why I'm here.
> > But I'd like to use this occasion to make a survey among our
> > developers and users ---- do you think we should stay with BSD, or
> > switch to LGPL? I am interested in all opinions from anyone. Whenever
> > there is some occasion, I am discussing this with people around sympy
> > and so far my observation is that most people either prefer BSD, or
> > don't mind either, but would like to hear good arguments why LGPL
> > should be better. There are also some who clearly prefer LGPL, for
> > example Kirill or some people from the Sage community, but I think
> > given all the circumstances (i.e. sympy aspiring to become the
> > symbolic manipulation library for Python, and together with numpy,
> > scipy, matplotlib, mayavi and others form a BSD like environment for
> > scientific computing, that people can build on and given the community
> > where sympy belongs), the right license for sympy is BSD.
>
> We have discussed this a few times, including over a few beers in Prague,
> you know my point of view. I won't dwell on it long.
>
> Briefly. I personally realized that I don't care much about the license
> of the software that I write. I care more that it is used by as many
> people as much as possible. The thing that worries me most with software
> is the amount of wheel reinvention, and lousy, half-complete,
> implementations of a solution to a given problem. This is why I believe
> free software has a future. This is indeed the Lessig point of view. The
> reason I feel a BSD license help is that many companies (especially large
> ones) are not afraid of hiring scores of developers to reinvent the
> wheel, just because they want to possess it and control it. The driver
> for free software adoption in companies is not cost, but control.
Yes, usually companies wants control, and usually that control hurts the
project. That's why I think that SymPy should be independent from any
company at any give time.
Please read below about it.
> Of course the license debate changes whether you consider your software
> as a component, that needs to be integrate in a larger infrastructure, or
> as a finished good.
> Linux, (GPL, fantastic example of free software success) is clearly a
> finished good.
You forget that it was not "finished good" from the day0, but it was GPL
from almost the begginning. Also, please note, that in Linux kernel case
GPL works essentially like LGPL -- please read about it below.
So it *evoloved* to "finished good" with the license it carries today. And
even before Linux was _started_, FreeBSD & friends were already there,
right?
How it turned out that today Linux outperforms (my subjective point of
view) FreeBSD with respect to almost all areas? For example FreeBSD had
much better networking stack than Linux some years ago, but today the
situation is different.
Doesn't it points that somehow the license is too mixed into success?
To me, the answer is "yes" - read about below why.
> Wine (now LGPL) may also be a finished good.
The same points as with Linux kernel - it too was not "finished good" from
the start, plus as said above Wine switched to LGPL to protect itself
from abuse back in 2002.
And even today, both Linux and WINE are _not_ finished goods.
They are developing at a very high pace - especially Linux. For example
transition from 2.6.26 to 2.6.27 which lasted for ~ 3 months brought a
lots of new features [1] and had ~ 10000 (ten thouthands) commits (!)
[2]. Compare this with SymPy, which has ~ 2500 commits for _all_ its
history! Roughly saying every new kernel version is like ~ 3-4 man-work
of the *whole* sympy development and this is even more, if you'll bear
in mind, that the kernel patch quality rules are much higher than in
sympy.
I'd not call it as "finished good."
[1] http://kernelnewbies.org/Linux_2_6_27
[2] http://lwn.net/Articles/302061/
> Scientific computing libraries on the other hand, are not
> finished goods. A company, or a research lab, may want to fork them to
> keep a competitive advantage, and maybe not even redistribute the
> resulting binaries. And that's fair enough by me, because I think the
> world is a better place if these people use my software as a start,
> rather than building on crappy bases.
As pointed above "finished good" or not is not an argument for me.
Besides, don't this people constantly reinvent "lousy wheels"? And why
the world is a "better place" with those "louse wheels" forked from your
base.
Wouldn't it be better to cooperate on common playground?
> besides, if they later decide to
> share, it will be possible if the built on common abstraction. Finally, I
> hope that as the world evolve, people (mostly managers and lawyers) will
> understand the gain that there is to share 90% of the code, may it be
> with 10% kept secret for a competitive advantage.
My point is that we should not wait untill those managers understand
something (or not), but create a world in which a manager that does not
understand this something, can't effectively manage, so he/she will just
have to educate him/herself.
Read about this below.
> For me the golden example of successful free scientific software is VTK.
> VTK is a 3D plotting library. 3D plotting is a forever-reinvented
> problem. Each particular application is actually fairly simple, but when
> you try to do something a bit more general, it gets really hard. So
> people (companies, research labs) start out with a specific problem they
> want to solve, and code a quick implementation, then as they evolve,
> their small implementation grows to be a huge one, and most of the time
> lies on crappy abstractions and data structure. VTK was born as a spin
> off of GE: the code used in medical visualization was split off to a
> start up (Kitware) and BSDed. GE still have their own proprietary bunch
> of codes, for their medical devices, but VTK lives on, and unites the
> efforts of many companies and labs with diverging problems and goals. In
> the case of VTK, individual actors have learned that they need to
> contribute back, because the cost of have their own abstraction and
> algorithm to maintain and to impedance-match with the rest of the world
> was very high. They make a careful decision as to what is open-sourced
> and what isn't.
>
> This is my model of development, and my 2 cents.
I can't say about VTK, because I don't know this area, and also I admit
there are good projects under BSD license but wouldn't the same work if
VTK would be LGPL'ed?
Let's forget for a moment that some companies are afraid of *GPL, and
try to see -- what would be an obstacle to keep VTK, which is open,
under LGPL, and to keep private additional development private?
For me it's better to have clear rules, what _have_ to be always common
and belong to everyone. When such rules does _not_ force other
not-covered components (e.g. an aplication which uses sympy) into which
license to use, I call it non-intrusive.
And to me, LGPL is non-intrusive (read about glibc, libgcc, and wine
v.s. picassa) and it protects developers. That's why I propose we use
it.
On Wed, 12 Nov 2008 13:59:07 -0800, Ondrej Certik wrote:
> On Wed, Nov 12, 2008 at 8:44 PM, Kirill Smelkov
> <kirr@landau.phys.spbu.ru> wrote:
> > Compared to bad science, or locked down or proprietary software, it is a
> > very good thing!
> >
> > I'd like to explain better, but now I'm too sleepy, and I have 10
> > minutes left, and tommorow I have to go to work and concentrate there
> > ...
> >
> > <so from now on it goes unstructured>
> >
> >
> > What is important is that the software should be free as in free speech
> > - one should always be able to:
> >
> > - run it
> > - study it
> > - modify it
> > - share it
>
> Yes. You should also be able to compile it (=run it) using only free
> software. E.g. that's what Debian main distribution preserves.
>
> > There are mechanisms to legally make contracts with software users,
> > which protects this freedom, mainly strong copyleft (GPL) and weak
> > copyleft (LGPL).
>
> It is important to note, that not even GPL protects all kinds of
> "abuse". In my opinion, the far bigger "threat" are the internet based
> applications, like gmail, that are completely without sources and the
> companies can even run GPLed code behind it --- but you have no chance
> to study/run/modify or share the program.
>
> But as long as I am not forced to use such a service, I don't mind.
> And I use gmail, because it's good. But I don't have to, I can
> administer my own email server and use mutt. As long as I have this
> second option, I don't mind using non-free software (I also sometimes
> use google earth and skype and picasa and other things). I just don't
> want to depend on it.
Yes, such kind of thing exists. Let's try to agree on our terms "in
spirit" first -- if we do - we'll work all the technical and wording
details out. Is my "Fair use of SymPy" ok? If so, let's just adopt
closest existing solution on license market which is not-intrusive.
Agree?
NB: Also I think that every time you say "I can" (administer your own
mail server, use mail client, ...), and someday you need to turn some of
this points into reality, multiply the probablility that the whole thing
will happen, say by 0.1 for each 'can'. Then you'll understand, that
when there are too much this "can(s)", what you get in essence is that
you can't.
> > From almost the beggining I was talking to Ondrej that I think it's
> > better to use LGPL for SymPy, that is anyone could be able to build
> > application or other libraries whichever license they choose (including
> > proprietary) on top of SymPy, but SymPy should always stays free as in
> > free speech. Mainly one should be disallowed to "make private
> > modifications to sympy and keep them secret."
>
> Here we disagree. For me personally, this right is very important,
> that not only I, but anyone can make any modification and do what he
> wants with it, including keeping it secret.
What's your rationale on this? Why you need the right to keep
modifications of sympy secret? Is there any reason this is good for
sympy?
As I've stated above I strongly mind about secret modification which are
redistribted in closed form, and I think this is not fair.
Read below about my understanding of why you need to reserve such rights
as "keeping modifications secret."
> > LGPL is a good compromise, and it does not force users of a library into
> > any license, so why can't it be used.
>
> Well, it depends on your personal point of view, but many people,
> including me view it in a way that it forces, because LGPL is not
> compatible with every license out there. Actually, I think there are
> even some problems with mixing LGPL 2 and LGPL 3 code.
I'm not a lawyer, but as I've said above, isn't GLibc (coverd by LGPL),
which is used by essentially *every* program, is not a problem? What
about libgcc (GPL + linking exception) ?
I insist on that we should settle on "Fair use of SymPy", and if we do,
it would be straightforward to adopt the closest license out there on
the market, and work out all the details to eliminate license
incompatibility out there if any.
> > Why on earth, say I as a hobbyst, spending my spare time, would want the
> > result be used as a starting ground for closed software? BSD allows it
> > explicitly, and this is not ok with me.
>
> I respect your point of view and I think it's perfectly consistent.
> But I don't share it --- I am also a hobbyist to some extent, well as
> to sympy I still am, and I just want my code and my work to be used.
> Because I believe it is good for me and the whole community in the
> end. I do sympy because I very strongly believe in its potential and
> that we get to a point (and we are almost there) where I could use it
> regularly for my research. For example our recent work with Brian
> shows, that we could actually do atomic physics using only open source
> software in Python. That's very exciting.
>
> And if someone uses it in some commercial product? I believe it will
> help us, not hurt us. I believe it's about the community which is
> around sympy. Commercial product can have a community, but a different
> one --- I am pretty sure we all use sympy exactly because we have the
> source code and because it's opensource.
Commercial != Closed
You can build a commercial product on top of open development. An
example of this is CodeWeavers (CrossOver -- WINE) and RedHat (RHEL --
Fedora)
I think commercial parties are ok, and essential for success, but the
whole thing works well, when there is no control in one hand, and when
parties (commercial or not) play by the same rules.
Also, since I propose we use LGPL, it would be perfectly possible to
build proprietary/closed software on top of sympy.
What's the problem with this?
> > Actually at my work, With one of my collegues, we've made an
> > observation, that usually motivated people, who are interested first in
> > developing interesting things, to achive great result, to care about the
> > project and it's ecosystem in general, and only then in money, usually
> > prefer LGPL to BSD, and on contrary side, people who tend to work for
> > money first, and care less about result, about fitting their development
> > with others, about achiving good results, pushing harder when needed,
> > prefer BSD. They usually say that "BSD is the license that companys
> > prefer, and for which they pay money"
>
> I think both ways are possible. I believe that Python itself and all
> the BSD like tools around it show that people can do BSD software and
> care about the project.
There are exceptions from the pattern, and examples of both good BSD and
bad LGPL projects.
Every project is somewhat unique with additional balancing forces (e.g.
PostgreSQL - read below), but to mee the tendency is clear.
> > Do you see the pattern?
> >
> > LGPL, being a fair contract, is good for everyone -->
>
> Here we disagree. I respect that for you "LGPL is good for everyone".
> But for me, "BSD is just as fair for everyone".
How is it fair, if let's say I've developed sympy for a year in my spare
time at evenings, and someone would just take it, work on it full-time
and enhance it, and sell it, and keep the modifications secret?
It seems we have different understanding of fairness.
And what about GLibc which is LGPL'ed? Any problems in using this
library? I bet 90% of people out there even dont _think_ of this issue
when they run their programs, that they depend on Glibc.
Another news: libgcc (The GCC low-level runtime library) is licensed by
GPL (!) + linking exception [2] and is used by every program which is
compiled with GCC !. No problem with this???
[1] http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
[2]
http://git.infradead.org/gcc.git?a=blob;f=gcc/libgcc2.c;h=5a82f82f7cd2f2e2ff8a19b157ec13529b3d8251;hb=HEAD
> > (e.g. GTK+ is LGPL'ed, and there is a lot of free and proprietary
> > software which uses it without a problem)
> >
> > --> is choosen by people who care, whereas BSD is choosen by people who
> > want money first.
>
> I understand what you mean. But I don't think that people around
> sympy, or scipy or numpy don't care and want money first. So I
> disagree with that statement.
Actually some people we all know want money first [1], or stop working
on their "babies" after their grant is finished [2], or want to be paid
working for companies which want to keep their modifications secret [3],
...
Other's (usually more young) just don't understand the issue and don't
care about licensing --
-- BSD is essentially a gift, and you know when you are a student you
can afford yourself to give gifts whatever way you like, and also there
was a culture in the university to share things "simply" -- this is all
good. -->
HISTORICAL REMARK: BSD-like licenses were born in the universities,
where the research and development were done on taxpayer's money, so
it was logical that the result belongs to all the taxpayers --
basically everyone -- commercial and open parties -- all the people.
That's why BSD-style licenses are so permissive -- actually BSD, MIT
and the like are very close to Public Domain.
Today most of the development is not done on taxpayer's money, so
likewise, there is no obligation for the result to stay close to
Public Domain -- that's why usually software developers who do the
actual work in their spare time are those who decide on which terms
they distribute the software.
--> But we are not in the university where there are > 95% good people, and
why would I want some bad guy to use the code I spent my time on to use
in a bad way? I say - 'use it as you like, but if you enhance it, you
cannot enjoy your advantages alone - you have to share this'. I think
this is 100% fair and thus LGPL is 100% ok with me.
[1] http://code.google.com/p/sympy/issues/detail?id=748#c25
[2] http://landau.phys.spbu.ru/~kirr/cgi-bin/hg.cgi/sympycore--hg/
[3] http://groups.google.com/group/sympy/msg/74a5c4bc7506ab68
> > Money is ok, but I even can say that usually who want money first, get
> > _less_ money than people who do care about the project in the first
> > place.
>
> Yes, I agree. I believe in american dream which says that you can get
> what you want, but you need to work hard and it may take a long time,
> but you'll get there eventually.
>
> > Also I can say that in our company we use a lot of LGPL'ed software, and
> > this is legally 100% ok, and that we even sponsor some LGPL'ed
> > development, so to me there is just no rational reason why LGPL is not
> > good for SymPy.
>
> There are pros and cons to all three BSD and LGPL and BSD. You stated
> the pros of LGPL. The cons is that LGPL creates a barrier of
> contributions, from a lot (but not all) people and also usage, because
> simply LGPL is more restrictive.
1. What is the usage barrier of LGPL? I remind you about GLibc, and
libgcc. Please answer in details about this barrier - to me it is
mythical.
2. What is the contribution barrier of LGPL? I know there are people who
hates GPL (no L) and automatically projects their attitude on LGPL,
and also that there are companies who like BSD and cultivated this
(read about it below).
But what rational is in this barrier?
Also, as you say that LGPL creates barriers, I state that BSD *TOO*
creates barriers:
Look, they say GPL is viral, and some time ago I undersood that BSD
is viral *too* -- it forces all to use BSD -- look at scipy -- they are
reluctant to take LGPL parts even it it is (maybe) legally ok to ship
combined BSD + LGPL library (part1 is BSD, part2 is LGPL)
so BSD creates barriers TOO.
This is also justifed by people like me, Gary from SAGE and others
refusing to contribute to a BSD licensing projects.
> Whenever you put more restrictions (I
> am not saying it is necessarily bad) you lose some users. So while
> LGPL is maybe good for sympy, BSD is imho better.
1. As shown above LGPL does NOT create barrier for _users_,
2. With BSD you loose (at least) some developers (me, Gary, other SAGE
people)
So why is BSD better, when LGPL being almost the same for users,
protects _developers_? Because companies can't "keep their modifications
secret"?
> > I've failed to win Ondrej's mind, and I think I'll fail to convince most
> > of you, and it makes me very sad, that so much evident common sence is
> > not accepted, that I stopped thinking to be like at home with sympy
> > recently.
>
> I am sorry about that. But I think it is not a common sence.
I insist on it being common sense.
> > either having a rest, going for a walk, for a talk with a human you
> > love, or either to develop sympy, is _precious_.
>
> I agree with this too. We all die once, so our time is limited and so
> we should spend it very effectively.
Yes, but effectivness depends on what you trying to achieve. If someone
wants to make money, he is effective in his own way.
I want sympy to be useful for me first, and to protect it from abuse.
Also I think in such a case it should be useful for people like me,
e.g. physicists.
Untill now I think I was effective in makeing SymPy useful, but not
effective in protecting SymPy from abuse.
And now I'm trying.
> > For me I just can't afford to spend that _precious_ spare time without
> > legally protecting the result from abuse.
>
> I think I understand how you feel. But as I said above, I think LGPL
> maybe protects some abuse in some situations, but definitely not all
> abuse in all situations (see my example with gmail above) and also
> from the way you look at it, I don't even thinkl it is abuse --
> depends on circumstances of course.
There is no 100% perfect solution, but this does not mean we should not
at least create some protection. and as i've already said LGPL is a
compromise between BSD and GPL.
I've tried to show in every possible detail, that with LGPL in fact
there is just *NO* barrier for users, and (to me) very irrational
barrier for developers + BSD creats its own barriers, while, as Andy
said LGPL protects the community.
Summary
=======
BSD is bad because weird companies can take the code and eat it and give
nothing back. Big examples are:
Microsoft, who took BSD IP stack,
Apple who took code from FreeBSD to their OSX
http://en.wikipedia.org/wiki/BSD_licenses#Proprietary_software_licenses_compatibility
Let's also look at what other developers think:
Linus: “making Linux GPL'd was definitely the best thing I ever did.”
http://en.wikipedia.org/wiki/History_of_Linux#Linux_under_the_GNU_GPL
Fernando: "I happen to actually really like the LGPL."
http://groups.google.com/group/sympy/msg/5f757166b695d35c
Gary: "I will never contribut to BSD project"
seen on IRC if I recall correctly
Gael: "Companies like BSD because they can keep their modifications
secret"
http://groups.google.com/group/sympy/msg/74a5c4bc7506ab68
Pearu: "May I propose something that is more relaxed licence model than
GPL: LGPL or BSD-like that numpy has?"
http://groups.google.com/group/sympy/msg/1a1ee12c8c2928c1
Ondrej: "What I like on GPL is that if someone takes it, he needs to
distribute his changes and code also as GPL, and cannot just
steal it and used it in a proprietary product without releasing
his code as opensource. I have nothing against someone taking
our code and selling it, however, I want him to release it as
open-source (GPL). I think that's fair."
http://code.google.com/p/sympy/issues/detail?id=138
but then you conclude that "BSD is better than GPL"
Kirill: "I understand that licensing is only part of the game, and in
hard times I put the question on the shelve fighting against
the fork and defending SymPy, but now when I'm almost exhausted
I just cant afford myself spending _precious_ free time and
_health_ on SymPy if it is under BSD license, because companies
like M$ or Apple or someone else can take it and make it
proprietary.
I'm 100% ok for someone selling sympy, makeing proprietary
applications or other libraries on top of it, but I 100%
request for me that sympy itself must be always free as in free
speech.
LGPL is good for both: for me it's sympy protection, for
other's it's fair use, even if they want to make their products
proprietary.
It's fair, and it's a win-win for all!
Companies who benefit from BSD cultivated that "BSD is better
than GPL (and automatically LGPL)" mood just to benefit them.
When you are a student with lots of free time and energy, you
are "young and naive," and can afford yourself to ignore the
issue, but
I think when it boils down to that you have eps free time to
work on the project and you spend your health on it, you have
to think very carefully whether you can afford yourself to play
this game.
I still love SymPy very much, but the price to play this game
under BSD rules is just too high for me."
this mail
Also interesting:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
http://www.dwheeler.com/essays/floss-license-slide.html
http://www.dwheeler.com/essays/gpl-compatible.html
http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
In Linux kernel case, GPL effectively works like LGPL!
------------------------------------------------------
That's because we can think of the kernel like of a libary, to which we
make system calls from user space. And since GPL works only at kernel
space, user-space code can use whatever license it finds best, so see,
this
user-space | kernel-space
partitioning works similarly to
application | library,
or
library2 | library1
partitioning.
And since Linux license don't affect anything beyond that borded I claim
that in practice this works *exactly* like LGPL.
And now:
> Linus: “making Linux GPL'd was definitely the best thing I ever did.”
>
> http://en.wikipedia.org/wiki/History_of_Linux#Linux_under_the_GNU_GPL
and
> http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
P.S. in that blog from 2006 dwheeler says that BSD projects can do fine
too, e.g. Apache.
I have news for you that now M$ is actively trying to affect apache
development:
http://lwn.net/Articles/291628/
P.P.S. BSD encourages companies to build on BSD code and hire brightest
developers, but as described in that blog entry from 2006 it's bad for
the project and it's bad for that developers in the long run.
For some time I started to think most of scipy/numpy/sympy developers
are positive about BSD because this opens job opportunities for them at
enthough/etc...
I really hope that Linux example shows that with good managment and
"must cooperate" (i.e. can't keep modifications secret) rules, talaneted
team and bright ideas, it should grow up and
set _our_ rules for companies instead of being driven by potential
sponsors wishes and desires.
This all shows that Protected-Freedom and Independence is always good.
And again, this is *weak* copyleft! Anyone can build proprietary things
on top of it!
If there are people, who share my views, please
__________________
( Vote for LGPL!!! )
------------------
o ^__^
o (oo)\_______
(__)\ )\/\
||----w |
|| ||
Thanks beforehand,
Kirill.
Appendix I
==========
For the reference here are some excerpts of our internal conversation
with Ondrej which I've edited and extended. I only quote myself so I
think this is ok.
The text is a bit sharp -- that because I call things by their names.
SymPy was already abused
------------------------
SymPy was already abused ("old new core" and [1]), and if i recall
correctly, it was me, who told you what to do ("lets do patch review")
and defended this and made everything possible to not letting the
project split.
Now I'm telling you that when we move forward, sooner or later, there
will be another kind of abuse, but you don't want to listen to me. It's
a pity and makes me sad.
[1] http://code.google.com/p/sympy/wiki/SymPyCore
Community is not weaker
-----------------------
The problem with your approach is that you implicitly assume that
community is always weakier and companies are always stronger, so it's
better to receive at least anything than nothing.
But I say, that is should be that every player plays on a common ground
-- a company, a developer, a community at large, another company -- all
must have equal rights with respect to sympy.
Freedom have to be protected
---------------------------
(1)
And when you are only in university environemtn that's ok, but I think I'm not
that dense case who got up almost up to phd in university and also to maybe the
same level in industry. And being in both this two places i can say for sure:
"freedom have to be protected" i think people part to those who know this, and
to those who will know this.
(2)
My another topic is that freedom *have* to be protected. BSD was ok in
universities when/where there was already a culture to share scientific
results, (at least after they are published).
But this days we have another situation -- there are a lot of greedy
people/companies, when SymPy matures they could take it as a start, hire
qualified developers, and run it.
We are hobbyst, it would be impossible to compete with full-time gang.
I hope you at least agree with "Fair use of SymPy". If yes, I take the
task to find relatevile easy way to make it legal and try to convince
people. ok?
On John Hunter's License Pitch
------------------------------
(http://www.scipy.org/License_Compatibility)
Grr, I'll sumarize what John pitches about LGPL:
1. many companies are still loath to use it because of their phobias
2. you cannot reuse LGPL code in a proprietary product
That's all.
My answers:
1. If a company does not understand what our license means what could we
do? All the world understands it, and if we'd put "Fair Use of Sympy"
before the license to show our spirit I think it would be clear for
99.9% of people.
2. You *can* reuse LGPL code in a proprietary product in the form of
library -- look at glibc - it is LGPL an every program reuses it. After
all good code reuse is not copy-paste, but reuse in form of libraries,
so what is the problem here??? (Yes, if you want to modify the library,
you have to share your changes, but only to the library, and other your
code stays only yours)
We all BSD, Proprietary, LGPL, GPL, DONTCARE *use* LGPL library - at
least glibc (LGPL) and libgcc (GPL + linking exception).
What's the problem?????!
LGPL is the golden median between BSD and GPL
---------------------------------------------
When I first knew about Linux and Free Software, it was a "no question"
for me that it is a good thing, and I just wanted to be part of it. And
I took it the balanced way - LGPL. For me it is absolutely ok when I use
LGPL'ed library at work when we ship proprietary software, and I just
don't understand why it is bad for others. I take BSD and GPL as
extremes in this respect, but why, just oh why the balance can't work?
LGPL examples in common use both in open and closed worlds
----------------------------------------------------------
Yes, and I've shown you other examples recently:
- winelib(LGPL) + google picassa (?) for linux (proprietary),
- gtk(LGPL) + lots of written stuff both open and closed,
- glibc (some small parts BSD, most LGPL) + everything,
- libgcc(GPL + linking exception) + everything.
On about most of scientific stuff around Python is BSD
------------------------------------------------------
Yes, it turns out most of scientific code around Python is BSD, and some of
the code was _forced_ to change it's license to BSD (IPython was
essentially _forced_ to go LGPL -> BSD [1])
I claim again, that because it benefits some companies, they created
such a pro-BSD athmosphere and they've reached criticall mass.
But again I say -- just open your mind and drop this bullshit -- you
started from fair rules:
"""
What I like on GPL is that if someone takes it, he needs to distribute
his
changes and code also as GPL, and cannot just steal it and used it in a
proprietary product without releasing his code as opensource. I have
nothing against someone taking our code and selling it, however, I want
him
to release it as open-source (GPL). I think that's fair.
"""
Just substitude GPL -> LGPL and this is ok for all.
With LGPL we are _not_ forcing anyone to be of some particular license
-- software B which uses SymPy can be of esenntially _any_ license both
proprietary and open.
All we need then is good team and hard work and if we succeed they will
_have_ to use us.
But I really don;t care about whether we are in EPD.
What I care about is that SymPy is useful and fast for my physicists use
cases, and also I care about other guys problems who ask questions in a
constructive manner.
And I claim that doing so and starting from small set of goals, if we do
everything right we'll achieve greater goals. Success is _never_ planned
-- we should just do what is best for us. And it is _completey_ _fair_
to use some weak protections -- LGPL. By myself and Gary and a lot of
other developers I can say that they actually _care_ to which project to
contribute -- a lot of them tend say "will never contribute something
nontrivial to BSD."
[1]
http://projects.scipy.org/pipermail/ipython-dev/2004-October/001398.html
LGPL says "must cooperate"
--------------------------
Let's ask ourself - to help what?
If it is just used by Mathematica - that's no problem in any case -- in
BSD and in LGPL, because we explicitely allow that both in spirit and in
legal words.
But didn't Wolfram ever hit any bug in gmp? Even a small bug?
I doubt it -- no software is perfect.
So if
a) they are hitting a bug, and
b) they want to ship modified gmp
they _must_ cooperate on gmp.
Even if they don't send patches to gmp itself, they have to provide
sources to their users, and soon they should learn that maintaining lots
of patches could sometimes be problematic.
So they are essentially _forced_ to fix that bugs and contribute back.
In this sense LGPL helps, and BSD don't.
And also, should they wish to enhance gmp non-trivially they will _have_
to cooperate, because gmp is LGPL. I don't know what the probablility
for this is (Wolfram wants to enhance gmp), but I'm sure it is not zero.
And voala, all should benefit for _sure_.
BSD is in fashion
-----------------
(1)
Companies like Enthough and others who benefit from BSD code tought
some developers to "like" BSD. Some really believe BSD is better, some
just want to be in fashion and to have job oportunities.
I want fair use and freedom. (and I'm ok for others to build other
software components on top of SymPy whatever license they want,
including proprietary), so it's not viral!
(2)
I don't see much legal problems with LGPL v2 and LGPL v3 -- all problems
could be overcomed if one want this thing in spirit, but what I see now
is that new generation
"Does not want to care at all"
And all those viral BSD nature only helps it -- everyone wants to be
BSD, so there are no "legal obstacles and scary things" people could get
afraid of. That's it - most people just don't want to care because they
were taught not to, and the only lesson from history is complete
oblivion of all of its lessons, its only ~ 20 year ago, all the world
was "proprietary"...
Kirr wants protection
---------------------
(1)
Look at me, Fernando, Gary etc.
Initially I was in a shape and could afford myself working on sympy
without protection, but when it started to be very tough, I have to
either have 100% protection or stop risking my health. So you see, at
least from me and Gary "BSD is less patches," and also Fernando says he
likes LGPL very much, so I'm grateful to Pearu that he started his fork
-- I had to overwork myself and feel very strongly that the issue must
be resolved or I have to stop spending my time.
I don't want to force anyone, but also I don't want to force myself to
play by the rules I can't accept.
(2)
Because I don't want SymPy freedom to depend on us always being good
managers and always being full of time and energy etc.
I want protection and insurance, that in no case it goes proprietary.
Why? Becasue I've put and I want to put my energy and my soul into the
project, but I can't afford myself for SymPy to go proprietary or be
forked or be used unfair and I want to be 100% sure.
So not "why not LGPL," but I myself subjectively want a _must_ have
protection. For sure, 100%.
(3)
As I'm telling you all the time, BSD is ok for proprietary closed forks.
LGPL protects and enourage to give back.
Now with good management we'll have better chances to run, but even if
we fail at management, or will run completely out of time, or someone of
us is hired by e.g. Enthough,
SymPy always stays independent and free as in free speech.
With BSD they could hire some key developer(s) for full-time job and
tell them control SymPy -- _they_ will decide whether SymPy stays open
or closed. Developers are just "engenieers".
I think if I care about the project, I have to protect it from the above
scenario, and so I think you'd better too.
(4)
You ask "why LGPL?", the answer is that
LGPL does guarantee that something stays free as in free speech always.
In contrast BSD does not provide such guaranties - one can jump to
proprietary at any point.
(5)
But doing things right is always harder than flowing along the stream...
Unfortunately to prove myself right I'd need two things:
1. a lot of time passed to see what way SymPy evolves and how it is used
2. realized probability that SymPy is misused.
I don't have this two, and I admit that good managment could keep BSD
only project out of bad guys too, but this managment should be *really*
good and have to last forever...
Kirr thinks the same as DWheeler
--------------------------------
But isn't the following just my imagination?
Company X hires key developer Y.
Y develops advanced features that go to X's product only. It takes users
from 'open' version of the project and starting from some time you
either have to re-implement what Y did in their private branch or
somehow join them.
This is extreme case, but I think not so impossible.
Why companies like BSD and why LGPL should be good for them too
---------------------------------------------------------------
I know Google prefer BSD or X11 or whatever is equivalent.
They do so here like Enthough -- to have the ability to get the code at
any point and close it and make benefits from it.
I'm not saying they will do so, they try to do it socially first -- to
get momentum and benefit, but when things comes to serious competiotion
they will do so, I'm sure.
My example was that LGPL allowed Google perfectly ok to build its
proprietary product on top of WINE and that's ok for all.
If SymPy was first developed by some company it was that company choice
which license to use, but when it is developed by individauls I think
_we_ choose.
And you know I advocate for choosing for balanced protection.
On PostgreSQL
-------------
As to PostgreSQL - yes, it's BSD, but it was originated first in BSD
environment and now PG core developers team _carefully_ avoid working in
one company -- to keep the balance and independence.
So in PG case they managed to keep it up and running and be independent,
but I think everything would be simpler if it will be LGPL.
Too often I hear from people that they would not contribute to a BSD
licensed project exactly because of the reasons I think, and this is not
only around SciPy.
EPD can ship LGPL
-----------------
So my point is this:
a. for immediate users it is equally both good to have either BSD or
LGPL
b. but for users starting to be developers, and developers who put their
soul into a thing, it is important that the software stays free as in
free speech.
So if LGPL is ok for users, and LGPL protects software, what's wrong
with it?
They usually just compare BSD with GPL, and don't look at the golden
median. Some becase they don't understand the topic, others because they
want to benefit from BSD:
o companies: they can keep control on the code and release BSD+their
modifications closed, and tie customers to them
o developers: some of them want to be hired/contracted by such
companies, and thus they play by their rules.
I think _we_ should set the rules, not some company, and if _we_ manage
SymPy to be succcessful product, EPD would just be _forced_ to ship it.
It's just bullshit they can't ship LGPL.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
^ permalink raw reply
* Re: [PATCH v2 11/11] gitweb: CSS style and refs mark for detached HEAD
From: Jakub Narebski @ 2008-11-16 0:08 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226620461-25168-2-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 14 Nov 2008, Giuseppe Bilotta wrote:
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.css | 5 +++++
> gitweb/gitweb.perl | 2 +-
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 751749f..c0c4540 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -523,6 +523,11 @@ span.refs span.head {
> border-color: #ccffcc #00cc33 #00cc33 #ccffcc;
> }
>
> +span.refs span.detached {
> + background-color: #ffaaaa;
> + border-color: #ccffcc #00cc33 #00cc33 #ccffcc;
> +}
Nice and good. I think.
> +
> span.atnight {
> color: #cc0000;
> }
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 256c962..51e133d 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2298,7 +2298,7 @@ sub git_get_references {
> my %refs;
> if (git_is_head_detached()) {
> my $hash = git_get_head_hash($project);
> - $refs{$hash} = [ 'HEAD' ];
> + $refs{$hash} = [ 'detached/HEAD' ];
This, not so much.
Please, if you use some _*hack*_, and adding 'detached/' prefix is
certainly hack (you could have modified format_ref_marker() instead,
and that is probably better solution), you really should explain it
in detail in commit message. Otherwise some time later somebody would
examine the code, say 'WTF?!?'... and even git-blame would not help ;-/
> }
> # 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
> # c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 10/11] gitweb: add HEAD to list of shortlog refs if detached
From: Jakub Narebski @ 2008-11-15 23:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226620461-25168-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 14 Nov 2008, Giuseppe Bilotta wrote:
> Subject: [PATCH v2 10/11] gitweb: add HEAD to list of shortlog refs if detached
Errr... what?!?
It is not "list of shortlog refs", it is list of _ref markers_.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ceb0271..256c962 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2296,6 +2296,10 @@ sub git_get_last_activity {
> sub git_get_references {
> my $type = shift || "";
> my %refs;
> + if (git_is_head_detached()) {
> + my $hash = git_get_head_hash($project);
+ if ($hash = git_is_head_detached()) {
if using provided (in response to previous patch) implementation, but
even that can be simplified out by using "git show-ref -h ...";
see below
> + $refs{$hash} = [ 'HEAD' ];
> + }
Overly complicated. The '-h'/'--head' option to git-show-ref is there
for a reason.
> # 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
> # c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
> open my $fd, "-|", git_cmd(), "show-ref", "--dereference",
> ($type ? ("--", "refs/$type") : ()) # use -- <pattern> if $type
- ($type ? ("--", "refs/$type") : ()) # use -- <pattern> if $type
+ ($type ? ("--", "refs/$type") : ('-h')) # use -- <pattern> if $type
> or return;
This is I think simpler.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitk: try to set program icon
From: Giuseppe Bilotta @ 2008-11-15 23:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
We add the git icon in three formats (.xbm, .ico, .ppm), which we try to
set as window icon.
---
Ugh. This rather simple patch cost me _way_ more time than I expected to
dedicate to it. Making those pesky iconbitmap and iconphoto commands do what
they were supposed to do is not as trivial as it seems. Thanks the people on
Freenode/#tcl for giving me a hand in understading they very restricted way in
which they could work.
Also, I'm not really sure the gitk program path itself is the best place to put
the icon files in, but I couldn't think of a better place so feel free to
suggest alternatives (it's a real pity that you can't embed the icon data in
the program itself).
gitk-git/Makefile | 3 +++
gitk-git/gitk | 9 +++++++++
gitk-git/gitk.ico | Bin 0 -> 318 bytes
gitk-git/gitk.ppm | Bin 0 -> 781 bytes
gitk-git/gitk.xbm | 6 ++++++
5 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 gitk-git/gitk.ico
create mode 100644 gitk-git/gitk.ppm
create mode 100644 gitk-git/gitk.xbm
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..a55f905 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -31,6 +31,7 @@ endif
PO_TEMPLATE = po/gitk.pot
ALL_POFILES = $(wildcard po/*.po)
ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
+LOGO_FILES = gitk.ico gitk.xbm gitk.ppm
ifndef V
QUIET = @
@@ -43,8 +44,10 @@ install:: all
$(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
$(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
+ $(foreach p,$(LOGO_FILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(bindir_SQ)' &&) true
uninstall::
+ $(foreach p,$(LOGO_FILES), $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/$(notdir $p) &&) true
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..25cf627 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10797,6 +10797,15 @@ set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
makewindow
+# try to set the window icon, testing the logos from the worst to the best
+# quality. XBM is likely to fail on Windows, ICO is likely to fail on other
+# systems, and PPM with iconphoto only works for 8.4.9 or later
+catch { wm iconbitmap . @[file join [file dirname [file normalize $argv0]] gitk.xbm] }
+catch { wm iconbitmap . @[file join [file dirname [file normalize $argv0]] gitk.ico] }
+catch {
+ image create photo gitlogo -file [file join [file dirname [file normalize $argv0]] gitk.ppm]
+ wm iconphoto . -default gitlogo
+}
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
diff --git a/gitk-git/gitk.ico b/gitk-git/gitk.ico
new file mode 100644
index 0000000000000000000000000000000000000000..db349141ec3f510d98751fc117ff63eb4fc465c0
GIT binary patch
literal 318
zcmb7;u?~PB5JL-bbGgIB8JYM@Kg~bGR>MNVK*{Tc_J#ujpPA7&)Bv0SDlw9Ya_J_=
p{-aI+&sVh8AXZgo@^Ym@^W;wJQ<3sf8Bxc^KF5CcU%hwSe*yPC7a#xt
literal 0
HcmV?d00001
diff --git a/gitk-git/gitk.ppm b/gitk-git/gitk.ppm
new file mode 100644
index 0000000000000000000000000000000000000000..b6ea231fc8eb12827dced0cee8390bd0a2a424d1
GIT binary patch
literal 781
zcmWGA<1#c;Ff`*bGBxG;Kk~o<1_n3+`X0^(GBCNAA_UdbAw(G(7=Q?F5iwl28VCay
X7icDa1!%GmH^5CJh6{K0U|;|M>w9nk
literal 0
HcmV?d00001
diff --git a/gitk-git/gitk.xbm b/gitk-git/gitk.xbm
new file mode 100644
index 0000000..ce5871d
--- /dev/null
+++ b/gitk-git/gitk.xbm
@@ -0,0 +1,6 @@
+#define gitk_width 16
+#define gitk_height 16
+static char gitk_bits[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xDE, 0x7B,
+ 0xDE, 0x7B, 0x00, 0x00, 0x00, 0x00, 0x8C, 0x31, 0xDE, 0x7B, 0xDE, 0x7B,
+ 0x8C, 0x31, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Jakub Narebski @ 2008-11-15 23:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-10-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
> The function checks if the HEAD for the current project is detached by
> checking if 'git branch' returns "* (no branch)"
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
In my opinion this patch should really be squashed together with
previous one. They belong together.
> ---
> gitweb/gitweb.perl | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index a168f6f..ceb0271 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1844,6 +1844,13 @@ sub git_get_head_hash {
> return $retval;
> }
>
> +# check if current HEAD is detached
> +sub git_is_head_detached {
> + my @x = (git_cmd(), 'branch');
> + my @ret = split("\n", qx(@x));
> + return 0 + grep { /^\* \(no branch\)$/ } @ret;
> +}
First, not git-branch. Second, you can use Perl-only solution:
+# check if current HEAD is detached
+sub git_is_head_detached {
+ my $head_file = "$project/HEAD";
+ return if -l $head_file; # symlink
+ open my $fd, '<', $head_file
+ or return;
+ my $head_hash = <$fd>;
+ close $fd;
+ return if $head_hash =~ /^ref: /;
+ return $head_hash;
+}
Alternate solution would be to create git_get_symbolic_ref, and use
"!defined $current_branch" in place of "git_is_head_detached()".
> +
> # get type of given object
> sub git_get_type {
> my $hash = shift;
> @@ -2673,11 +2680,9 @@ sub git_get_heads_list {
> my @headslist;
>
> if (grep { $_ eq 'heads' } @class) {
> - my @x = (git_cmd(), 'branch');
> - my @ret = split("\n", qx(@x));
> - if (grep { /^\* \(no branch\)$/ } @ret) { ;
> + if (git_is_head_detached()) {
> my %ref_item;
> - @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
> + my @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
Hmmm... git-log, git-show, or perhaps parse_commit?
> my ($hash, $epoch, $title) = split("\n", qx(@x), 3);
>
> $ref_item{'class'} = 'head';
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitk: Highlight found text only for when search type is "containing".
From: Mark Burton @ 2008-11-15 23:12 UTC (permalink / raw)
To: git; +Cc: Mark Burton
Highlighting the text in the commit list and comments that match the find
string is useful but only really when the search type is "containing".
This patch suppresses the highlighting for the other search types.
Signed-off-by: Mark Burton <markb@ordern.com>
---
gitk-git/gitk | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..dea8bc8 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -4302,6 +4302,7 @@ proc askfindhighlight {row id} {
global nhighlights commitinfo iddrawn
global findloc
global markingmatches
+ global gdttype
if {![info exists commitinfo($id)]} {
getcommit $id
@@ -4326,7 +4327,7 @@ proc askfindhighlight {row id} {
bolden_name $row mainfontbold
}
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -5565,6 +5566,7 @@ proc drawcmitrow {row} {
global filehighlight fhighlights findpattern nhighlights
global hlview vhighlights
global highlight_related rhighlights
+ global gdttype
if {$row >= $numcommits} return
@@ -5595,7 +5597,7 @@ proc drawcmitrow {row} {
set iddrawn($id) 1
incr nrows_drawn
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -6227,7 +6229,8 @@ proc findselectline {l} {
set markingmatches 1
set findcurline $l
selectline $l 1
- if {$findloc == [mc "All fields"] || $findloc == [mc "Comments"]} {
+ if {$gdttype eq [mc "containing:"] &&
+ ($findloc == [mc "All fields"] || $findloc == [mc "Comments"])} {
# highlight the matches in the comments
set f [$ctext get 1.0 $commentend]
set matches [findmatches $f]
--
1.6.0.4
^ permalink raw reply related
* Re: Any overview available on jgit codebase?
From: Shawn O. Pearce @ 2008-11-15 23:15 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Kyle Moffett, Robin Rosenberg, git
In-Reply-To: <491F2F5E.20206@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> At minimum could anyone tell me what packages and classes to look at in
> order to make changes to jgit so it uses a database instead of
> filesystem to references.
See RefDatabase, created by Repository. You would want to replace
RefDatabase with your own implementation, which means abstracting
that class to be an abstract base class or an interface.
RefUpdate and RefLogWriter are connected to RefDatabase, so you
would likely need to modify those too in order to make the change,
especially since RefUpdate is the "INSERT OR UPDATE OR DELETE"
logic. :)
BTW, I want to do that RefDatabase abstraction anyway, because I'd
like to get an in-memory only version of RefDatabase, to make unit
testing easier. So abstracting this code may be useful beyond just
your desire to back Git with a JDBC-style database.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2 08/11] gitweb: display HEAD in heads list when detached
From: Jakub Narebski @ 2008-11-15 22:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-9-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
First, I think that _at least_ the first two patches dealing with
detached should be squashed.
Second, not this way!
But I think that support for detached HEAD (I am not sure if it should
have to be explicitly turned on using some %feature, or reusing some
existing feature like 'remote_heads') is a very good idea. Especially
for git-instaweb.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 21 +++++++++++++++++++++
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 09728cb..a168f6f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2672,6 +2672,27 @@ sub git_get_heads_list {
> my @refs = map { "refs/$_" } @class;
> my @headslist;
>
> + if (grep { $_ eq 'heads' } @class) {
First, IMHO layering violation. Resolving detached HEAD should not be
in my opinion left to git_get_heads_list, which is wrapped around
git-for-each-ref, which for some reason (contrary for example to
"git ls-remote ." or "git show-ref -h") doesn't show HEAD even if it
is detached. Probably misfeature / a bug in git-for-each-ref. I guess
that we should resolve detached HEAD in caller.
But I am not sure about this decision. Maybe instead of showing
detached HEAD (if it is detached) for 'heads', we should show it if
there is 'HEAD' in @class (well, @refs would have to be corrected,
too)?
> + my @x = (git_cmd(), 'branch');
> + my @ret = split("\n", qx(@x));
^^^^^^^- bit strange
Especially compared to almost everywhere else using open ... "-|"
> + if (grep { /^\* \(no branch\)$/ } @ret) { ;
^
WTF? -------------------------|
Second, if we go the route of manually resolving detached HEAD,
instead of adding [-h|--head] (from git-show-ref) option equivalent
to git-for-each-ref, which would work only for detached HEAD (fixing
kind of a bug), this is *not* the way to do it.
A. It should be done using encapsulation, adding is_HEAD_detached() or
git_is_head_detached() subroutine (squashing the next patch), or
simply using !defined($current_branch), where $current_branch would
be set using git_get_symbolic_ref('HEAD') or something.
B. Using porcelain, especially end-user porcelain such as git-branch,
which can change its output format (because they are porcelain). Use
equivalent plumbing, be if git-symbolic-ref ("git symbolic-ref -q HEAD"
to be more exact) to get current branch name[1], or just simply do
that in Perl: check if it is symlink, or if it starts with "ref: "
if it is regular file (IIRC HEAD, even detached HEAD, cannot get
packed into .git/packed-refs and deleted... at least I think so).
[1] This means that we have better way of detecting (and showing)
which branch is current one than comparing sha1 with resolved HEAD.
($head_hash).
> + my %ref_item;
> + @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
> + my ($hash, $epoch, $title) = split("\n", qx(@x), 3);
Errr... if we don't fix git-for-each-ref, and go that route, why not
simply use parse_commit subroutine, and extract relevant info from
there, instead of handcrafting git-log (why not git-show?) call?
You get more info than needed, but I think the cost of getting it is
almost the same, and you can reuse existing code.
And if we go --pretty=format:<...> or --pretty=tformat:<...> route for
git-log, git-rev-list or git-show, wouldn't it be possible to generate
the same output format as git-for-each-ref below?
> +
> + $ref_item{'class'} = 'head';
> + $ref_item{'name'} = 'HEAD';
> + $ref_item{'id'} = $hash;
> + $ref_item{'title'} = $title || '(no commit message)';
> + if ($ref_item{'epoch'} = $epoch) {
> + $ref_item{'age'} = age_string(time - $ref_item{'epoch'});
Hmmm...
> + } else {
> + $ref_item{'age'} = "unknown";
> + }
> + push @headslist, \%ref_item;
> + }
> + }
> +
> open my $fd, '-|', git_cmd(), 'for-each-ref',
> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
> '--format=%(objectname) %(refname) %(subject)%00%(committer)',
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* What's in git.git (Nov 2008, #03; Sat, 15)
From: Junio C Hamano @ 2008-11-15 22:12 UTC (permalink / raw)
To: git
Consider that the tip of 'master' is 1.6.1-rc0, although I haven't tagged
it as such. There are a handful more topics cooking in 'next' and they
are worthy of being in 1.6.1 final.
* The 'maint' branch has these fixes since the last announcement.
Brandon Casey (1):
revision.c: use proper data type in call to sizeof() within xrealloc
Christian Couder (1):
Documentation: fix links to "everyday.html"
Jan Krüger (1):
Documentation: git-svn: fix example for centralized SVN clone
Linus Torvalds (1):
date/time: do not get confused by fractional seconds
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (14):
gitk: Allow forcing branch creation if it already exists
gitk: Fix file list context menu for merge commits
gitk: Allow starting gui blame for a specific line
gitk: Add Return and Escape bindings to dialogs
gitk: Make gitk dialog windows transient
gitk: Make cherry-pick call git-citool on conflicts
gitk: Implement a user-friendly Edit View dialog
git-gui: Fix focus transition in the blame viewer.
git-gui: Add the Show SSH Key item to the clone dialog.
git-gui: Request blame metadata in utf-8.
gitk: Add accelerators to frequently used menu commands
gitk: Fix transient windows on Win32 and MacOS
gitk: Fix commit encoding support
Documentation: New GUI configuration and command-line options.
Brandon Casey (10):
t7700: demonstrate mishandling of objects in packs with a .keep file
packed_git: convert pack_local flag into a bitfield and add pack_keep
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
repack: do not fall back to incremental repacking with [-a|-A]
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
t7700: demonstrate mishandling of loose objects in an alternate ODB
sha1_file.c: split has_loose_object() into local and non-local
counterparts
pack-objects: extend --local to mean ignore non-local loose objects too
t7700: test that 'repack -a' packs alternate packed objects
Brian Gernhardt (1):
Avoid using non-portable `echo -n` in tests.
David M. Syzdek (4):
Build: add NO_UINTMAX_T to support ancient systems
Add Makefile check for FreeBSD 4.9-SECURITY
Make Pthread link flags configurable
Add autoconf tests for pthreads
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (2):
git-svn: proper detection of bare repositories
git-svn: proper detection of bare repositories
Eric Wong (4):
git-svn: don't escape tilde ('~') for http(s) URLs
git-svn: respect i18n.commitencoding config
git-svn: don't escape tilde ('~') for http(s) URLs
git-svn: respect i18n.commitencoding config
Giuseppe Bilotta (3):
gitweb: make the supported snapshot formats array global
gitweb: retrieve snapshot format from PATH_INFO
gitweb: embed snapshot format parameter in PATH_INFO
Jakub Narebski (1):
gitweb: Better processing format string in custom links in navbar
Jeff King (11):
diff: add missing static declaration
document the diff driver textconv feature
refactor userdiff textconv code
userdiff: require explicitly allowing textconv
only textconv regular files
wt-status: load diff ui config
add userdiff textconv tests
enable textconv for diff in verbose status/commit
t5516: refactor oddball tests
receive-pack: detect push to current branch of non-bare repo
commit: Fix stripping of patch in verbose mode.
Junio C Hamano (3):
t5303: work around printf breakage in dash
t5303: fix printf format string for portability
Update draft release notes to 1.6.1
Linus Torvalds (4):
Add a 'source' decorator for commits
revision: make tree comparison functions take commits rather than trees
Make '--decorate' set an explicit 'show_decorations' flag
revision traversal: '--simplify-by-decoration'
Marten Svanfeldt (dev) (2):
Git.pm: Make _temp_cache use the repository directory
git-svn: Update git-svn to use the ability to place temporary files
within repository directory
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Miklos Vajna (4):
Implement git remote rename
remote: add a new 'origin' variable to the struct
git-remote rename: migrate from remotes/ and branches/
git-remote: document the migration feature of the rename subcommand
Nanako Shiraishi (2):
Document "git log --source"
Document "git log --simplify-by-decoration"
Nicolas Pitre (9):
close another possibility for propagating pack corruption
better validation on delta base object offsets
make unpack_object_header() non fatal
make packed_object_info() resilient to pack corruptions
make check_object() resilient to pack corruptions
make find_pack_revindex() aware of the nasty world
pack-objects: allow "fixing" a corrupted pack without a full repack
extend test coverage for latest pack corruption resilience improvements
pack-objects: don't leak pack window reference when splitting packs
Paul Mackerras (8):
gitk: Fix some off-by-one errors in computing which line to blame
gitk: Add a menu item to show where a given line comes from
gitk: Make the background color of marked lines configurable
gitk: Unify handling of merge diffs with normal 2-way diffs
gitk: Make "show origin of this line" work on fake commits
gitk: Cope with unmerged files in local changes
gitk: Improve cherry-pick error handling
gitk: Fix linehtag undefined error with file highlighting
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
Santi Béjar (1):
rev-list documentation: clarify the two parts of history simplification
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Pierre Habouzit @ 2008-11-15 22:12 UTC (permalink / raw)
To: Miklos Vajna
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <20081115193327.GS24201@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
On Sat, Nov 15, 2008 at 07:33:27PM +0000, Miklos Vajna wrote:
> On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > Under LGPL, you must provide linkable object files to your (possibly
> > closed source) program, so that people who made changes to (or obtained an
> > updated version of) a LGPL'ed library can re-link your program and use the
> > updated library. The above does not ask you to do so.
> >
> > The way I read LGPL is that "We deeply care about our LGPL library and any
> > improvements to it. Although we do not care at all about how your crappy
> > closed source program is written, we want to make sure that the users can
> > keep using your program after improvements are made to our library.". I
> > do not think it makes a practical difference when your program uses the
> > LGPL library as a shard library from that point of view.
>
> Ah, I see - so this is a "Lesser LGPL". :)
LGPL also has a clause that allow the user to make it become GPLv2 or
later, even if you chose LGPL v2.1 *only* (as in not LGPL v2.1 or later).
Seeing how the FSF has just decided to use those upgrade clauses with
the GFDL, I'm not really likely to fancy the use of any license that
forces me to accept an "or later" clause. I would be _really_ against
the LGPL FWIW.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Re* [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-15 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxlwlcid.fsf_-_@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Thu, Nov 13, 2008 at 12:01:46AM +0000, Junio C Hamano wrote:
> This patch on top of your [2/4] illustrates what I had in mind (it also
> removes the "print foo" while at it).
I like it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-15 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
On Wed, Nov 12, 2008 at 12:14:20AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Oh you mean that if one use --no-format-patch you don't wan't _any_
> > option to be passed to format-patch?
>
> The option name --no-format-patch sounded like "I do not want you to act
> as a frontend, ever", i.e. if you type master..next by mistake on the
> command line, the command would barf when the option is given. Not even
> "pass to format-patch", but "do not run format-patch to begin with".
>
> It is not a big deal especially for interactive use (and that is why I
> said "somewhat" unfortunate).
>
> > If we're really doing this, then maybe we want a 5-state kind of option:
> > 1 disallow any file name ;
> > 2 if conflict, chose the revision ;
> > 3 barf if any conflict arises (default) ;
> > 4 if conflict chose the file ;
> > 5 disallow any kind of revision argument.
> >
> > My proposal implements 2 as --format-patch, 3 as default, and 4 as
> > --no-format-patch. You propose basically (5) for --no-format-patch
> > instead, well I say this makes sense, but it's somehow "sad" not to have
> > (1) too in that case.
>
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes. For such a usage,
> Documentation/ should not be taken as a maildir. If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
You can do that doing:
git send-email --format-patch master..fixes -- Documentation/
I've kept the `--` usual meaning, and it's sent to git-format-patch
verbatim and it'll work, so it's not required to change the meaning of
the options for that.
[sorry for the late reply, I've been somehow busy lately]
The sole conflict we have is when there is a path/rev conflict *before*
the `--` because of the legacy of git-send-email. I believe that
--format-patch should still allow to send patches passed on the command
line, this way.
> As to options, how about doing this:
>
> --no-format-patch means never ever run format-patch, behave exactly as
> before;
>
> --format-patch means what you have in your patch. guess and favor
> format-patch parameter when ambiguous;
>
> without either option, guess and favor mbox/maildir but still run
> format-patch if remaining parameters and options need to
> (e.g. "send-email my-cover-letter origin/master..master" will find
> my-cover-letter which is not tracked and take it as mbox, and grab
> patches from commits between origin/master..master, and send all of
> them).
That's sane and I like it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Any overview available on jgit codebase?
From: Farrukh Najmi @ 2008-11-15 20:21 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Robin Rosenberg, git
In-Reply-To: <f73f7ab80811140638m4045cf83p311c593aff066002@mail.gmail.com>
I am looking for any available docs that will help me learn the layout
of the jgit code base.
In the ideal world here is what would help newbies get productive with
the project quickly:
1. Have a clear one line description available in the javadocs for each
package.
2. Have a clear one line description available in javadocs for each
class in each package.
3. Have a clear one line description available in javadocs for each
method in each class.
I would gladly do this and contribute the changes back but its a chicken
and egg situation since I do not know the code base.
I realize its a lot to ask but would anyone familiar with code base
volunteer to do at least (1) above?
At minimum could anyone tell me what packages and classes to look at in
order to make changes to jgit so it uses a database instead of
filesystem to references.
Lastly, where can I find information on the structure of the .git directory?
Thanks for your help.
Kyle Moffett wrote:
> On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
>
>> The problem I am trying to solve is this. In my service I need to store
>> metadata in a relational db and content in git such that both either commit
>> or not in a single transaction. If one commits and the other does not that
>> is a serious integrity issue. Seems to me, two phase commit would be the
>> right solution for that in the long run. This what JDBC + JMS topologies do.
>>
>
> That's really easy! First tweak jgit so that *instead* of using
> .git/refs, it uses your database to store references and exports them
> on a routine basis to .git/refs for debugging purposes. Then, for
> each database update:
>
> (1) Start transaction
> (2) Commit the change to GIT (adds ref update to the transaction)
> (3) Make other metadata updates
> (4) Commit transaction
>
> Then set up periodic garbage collection and you're done! If the
> transaction is aborted, there will simply be a bunch of random loose
> objects in the git repository, which will be cleaned up the next time
> you garbage collect. The ref update will be atomic and conditional
> with the rest of the transaction, and in git the *only* part that
> really matters for atomicity is the ref.
>
> Cheers,
> Kyle Moffett
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Miklos Vajna @ 2008-11-15 19:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <7vk5b55ekb.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Under LGPL, you must provide linkable object files to your (possibly
> closed source) program, so that people who made changes to (or obtained an
> updated version of) a LGPL'ed library can re-link your program and use the
> updated library. The above does not ask you to do so.
>
> The way I read LGPL is that "We deeply care about our LGPL library and any
> improvements to it. Although we do not care at all about how your crappy
> closed source program is written, we want to make sure that the users can
> keep using your program after improvements are made to our library.". I
> do not think it makes a practical difference when your program uses the
> LGPL library as a shard library from that point of view.
Ah, I see - so this is a "Lesser LGPL". :)
Thank you both Junio and David.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 19:23 UTC (permalink / raw)
To: git; +Cc: gitster
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 +++++
builtin-fetch.c | 19 ++++++------
builtin-merge.c | 21 +++++++++----
git-pull.sh | 10 ++++--
parse-options.c | 22 ++++++++++++++
parse-options.h | 6 ++++
t/t5521-pull-options.sh | 60 +++++++++++++++++++++++++++++++++++++++
7 files changed, 126 insertions(+), 20 deletions(-)
create mode 100755 t/t5521-pull-options.sh
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index f151cfa..7568163 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,7 +22,7 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok, verbosity;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
@@ -30,8 +30,7 @@ static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT__VERBOSITY(&verbosity),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +191,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +208,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity > 0)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +364,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity >= 0 && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity >= 0)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -637,9 +636,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity >= 2)
transport->verbose = 1;
- if (quiet)
+ if (verbosity < 0)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..7c2b90c 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static int verbosity;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -171,6 +172,7 @@ static struct option builtin_merge_options[] = {
OPT_CALLBACK('m', "message", &merge_msg, "message",
"message to be used for the merge commit (if any)",
option_parse_message),
+ OPT__VERBOSITY(&verbosity),
OPT_END()
};
@@ -250,7 +252,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity >= 0)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +334,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity >= 0)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity >= 0 && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +876,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity < 0)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1019,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity >= 0)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 664fe34..a9dc713 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity=-q ;;
+ -v|--verbose)
+ verbosity="$verbosity -v" ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
@@ -182,4 +186,4 @@ test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head
+ "$merge_name" HEAD $merge_head $verbosity
diff --git a/parse-options.c b/parse-options.c
index fd08bb4..9eb55cc 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -484,6 +484,28 @@ int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
return 0;
}
+int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ int *target = opt->value;
+
+ if (unset)
+ /* --no-quiet, --no-verbose */
+ *target = 0;
+ else if (opt->short_name == 'v') {
+ if (*target >= 0)
+ (*target)++;
+ else
+ *target = 1;
+ } else {
+ if (*target <= 0)
+ (*target)--;
+ else
+ *target = -1;
+ }
+ return 0;
+}
+
/*
* This should really be OPTION_FILENAME type as a part of
* parse_options that take prefix to do this while parsing.
diff --git a/parse-options.h b/parse-options.h
index 5199950..034162e 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -150,9 +150,15 @@ extern int parse_options_end(struct parse_opt_ctx_t *ctx);
/*----- some often used options -----*/
extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
+extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
+#define OPT__VERBOSITY(var) \
+ { OPTION_CALLBACK, 'v', "verbose", (var), NULL, "be more verbose", \
+ PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }, \
+ { OPTION_CALLBACK, 'q', "quiet", (var), NULL, "be more quiet", \
+ PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }
#define OPT__DRY_RUN(var) OPT_BOOLEAN('n', "dry-run", (var), "dry run")
#define OPT__ABBREV(var) \
{ OPTION_CALLBACK, 0, "abbrev", (var), "n", \
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
new file mode 100755
index 0000000..83e2e8a
--- /dev/null
+++ b/t/t5521-pull-options.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='pull options'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q' '
+ mkdir clonedq &&
+ cd clonedq &&
+ git pull -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull' '
+ mkdir cloned &&
+ cd cloned &&
+ git pull "$D/parent" >out 2>err &&
+ test -s out
+'
+cd "$D"
+
+test_expect_success 'git pull -v' '
+ mkdir clonedv &&
+ cd clonedv &&
+ git pull -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -v -q' '
+ mkdir clonedvq &&
+ cd clonedvq &&
+ git pull -v -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q -v' '
+ mkdir clonedqv &&
+ cd clonedqv &&
+ git pull -q -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4ac8254d0811150942s7d4f5444xbc2b068beecbb44f@mail.gmail.com>
On Sat, Nov 15, 2008 at 6:42 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Sat, Nov 15, 2008 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> @@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>>> remote = remote_get(argv[0]);
>>>
>>> transport = transport_get(remote, remote->url[0]);
>>> - if (verbose >= 2)
>>> + if (verbosity == VERBOSE)
>>> transport->verbose = 1;
>>> - if (quiet)
>>> + if (verbosity == QUIET)
>>> transport->verbose = -1;
>>> if (upload_pack)
>>> set_option(TRANS_OPT_UPLOADPACK, upload_pack);
>>
>> In the original code, the variable verbose can be ">= 2" when "-v -v" is
>> given, so transport->verbose is not turned on with a single "-v" alone
>> (this correctly mimics the original behaviour in the scripted version).
>>
>
> Doesn't this also mean that we need to be able to concatenate
> multiple -v options in git-pull.sh similar to what one of the first
> versions of my patch did?
>
> <snip>
>
The next patch revision arriving here in a minute or two
will do the following in git-pull.sh:
1) if -q then verbosity=-q
2) if -v then verbosity=verbosity + -v
This means that git pull -v -q will reset verbosity to -q
and allow counting of -v instances. If this is not desired
or incorrect another change is needed :-).
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:53 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac0811150228k291b8850idc34cb474f455aa7@mail.gmail.com>
On Sat, Nov 15, 2008 at 11:28:39AM +0100, Pau Garcia i Quiles wrote:
>> Shawn posted the exact text. The spirit of that license is that anyone can
>> use an unmodified version of the library for whatever they want, but it's
>> illegal to link non-GPL software to an altered version of the library. That
>> is, the git community will get all changes back while other projects can
>> use the official version of the library without having to worry about
>> licensing issues. EvilCompany cannot make changes to the library and then
>> link non-GPL'd software to their changed version. They can do that if they
>> send their library changes upstream and then only use them once they're
>> considered "official" though.
>
>Do you mean if I write a patch to libgit2, send it upstream and make
>it public on my website but it is not accepted upstream, I cannot link
>my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>software? It looks insane to me: I wrote the patch and made it public
>but you guys did not accept it!
The license is not clear on this, at all. Since under the GPLv2, you
are allowed to make a derivative work, and distribute that, you are
then basing your binary off of your particular distribution. The
license does not have a notion of an "official" version. So, it might
be satisfied as long as you base it off of something that is
distributed.
But, yes, it is vaguely worded and unclear in it's intent.
David
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:49 UTC (permalink / raw)
To: Miklos Vajna
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <20081115123916.GN24201@genesis.frugalware.org>
On Sat, Nov 15, 2008 at 01:39:16PM +0100, Miklos Vajna wrote:
>On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> In addition to the permissions in the GNU General Public License,
>> the authors give you unlimited permission to link the compiled
>> version of this file into combinations with other programs,
>> and to distribute those combinations without any restriction
>> coming from the use of this file. (The General Public License
>> restrictions do apply in other respects; for example, they cover
>> modification of the file, and distribution when not linked into
>> a combined executable.)
>
>IANAL - what is the difference between this and the LGPL?
This clause allows static linking, and distribution of only the final
binary. The LGPL always requires source to be made available to the
libaray. This clause does not require that source to be distributed.
In other words, it allows libgit2 to be linked into a proprietary
program and the distributor of that program to _not_ include the
source of libgit2. It is not clear if they have to provide source to
modifications that they have made, or if making those modifications
under the exception is even allowed.
There are numerous other versions of this exception, some of which
might be better worded than this.
David
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811150256140.27509@xanadu.home>
On Sat, Nov 15, 2008 at 03:04:29AM -0500, Nicolas Pitre wrote:
>libgcc is a dynamic library on most modern systems these days. Yet they
>routinely execute non-GPL programs. If that text intentionally excluded
>the dynamic case then every non-GPL applications on such systems would
>have been breaking the license for a long time. So I don't think anyone
>could have substance for such a claim.
Sure they can. Lack of enforcement doesn't dilute copyright like it
does trademark.
It may be that the gcc authors intend for it to be allowed for dynamic
libraries, and therefore wouldn't sue for that usage, but that's not
what they're saying in their license.
What I'm saying is that if I was in a position to review the license
and determine what was permitted, this license with exception does not
appear to allow dynamic linking against the library. It doesn't
explicitly forbid this, but it is ambiguous about it.
David
^ permalink raw reply
* Fix machine-parseability of 'git log --source'
From: Linus Torvalds @ 2008-11-15 18:02 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Paul Mackerras
The space between the commit and the source attribute is not easily
machine-parseable: if we combine --source with --parents and give a SHA1
as a starting point, it's unnecessarily hard to see where the list of
parents ends and the source decoration begins.
Example:
git show --parents --source $(git rev-list HEAD)
which is admittedly contrived, but can easily happen in scripting.
So use a <tab> instead of a space as the source separator.
The other decorations didn't have this issue, because they were surrounded
by parenthesis, so it's obvious that they aren't parent SHA1's.
It so happens that _visually_ this makes no difference for "git log
--source", since "commit <40-char SHA1>" is 47 characters, so both a space
and a <tab> will end up showing as a single commit. Of course, with
'--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the
difference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is all partly because I also wish that 'gitk' would use --decorate to
give decorations rather than look them up by hand. I'm not entirely source
--source is useful for gitk (since it wants _all_ branches), but I do know
that I hate knowing that
gitk --source
just results in parse errors.
log-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 5444f08..194ddb1 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -58,7 +58,7 @@ void show_decorations(struct rev_info *opt, struct commit *commit)
struct name_decoration *decoration;
if (opt->show_source && commit->util)
- printf(" %s", (char *) commit->util);
+ printf("\t%s", (char *) commit->util);
if (!opt->show_decorations)
return;
decoration = lookup_decoration(&name_decoration, &commit->object);
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i7594cx.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>> remote = remote_get(argv[0]);
>>
>> transport = transport_get(remote, remote->url[0]);
>> - if (verbose >= 2)
>> + if (verbosity == VERBOSE)
>> transport->verbose = 1;
>> - if (quiet)
>> + if (verbosity == QUIET)
>> transport->verbose = -1;
>> if (upload_pack)
>> set_option(TRANS_OPT_UPLOADPACK, upload_pack);
>
> In the original code, the variable verbose can be ">= 2" when "-v -v" is
> given, so transport->verbose is not turned on with a single "-v" alone
> (this correctly mimics the original behaviour in the scripted version).
>
Doesn't this also mean that we need to be able to concatenate
multiple -v options in git-pull.sh similar to what one of the first
versions of my patch did?
<snip>
^ 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