* git bisect: merge problem with deleted file
From: Meelis Roos @ 2006-07-27 19:37 UTC (permalink / raw)
To: git
mroos@nartsiss:~/compile/linux-2.6$ git bisect start
mroos@nartsiss:~/compile/linux-2.6$ git bisect good 9be2f7c38e0bd64e8a0f74ea68df1e73e2ddfcc3
mroos@nartsiss:~/compile/linux-2.6$ git bisect bad 9676489866a75fdd56b0d3e40ec7884298bb1338
Bisecting: 43 revisions left to test after this
fatal: Untracked working tree file 'Documentation/filesystems/devfs/ChangeLog' would be overwritten by merge.
Got this while trying to bisec Linus' linux-2.6 tree. I have 1
uncommited change in the tree so this might influence the need for
merging.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: Licensing and the library version of git
From: Linus Torvalds @ 2006-07-27 19:44 UTC (permalink / raw)
To: David Lang; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.63.0607271140100.11253@qynat.qvtvafvgr.pbz>
On Thu, 27 Jul 2006, David Lang wrote:
>
> > (*) I will, in fact, claim that the difference between a bad programmer
> > and a good one is whether he considers his code or his data structures
> > more important. Bad programmers worry about the code. Good programmers
> > worry about data structures and their relationships.
>
> personally I'd add to this that after the data structures are defined and you
> turn to the code the API is significantly more important then the code itself.
I think people sometimes put too much emphasis on ABI's.
Sure, if you're depending on a library, the ABI is supremely important.
But I literally believe that one of the things that makes open source
technically superior to most other projects is the fact that ABI's can be
changed more easily, and sometimes at all.
If you have good data structures, the ABI's are largely irrelevant, and if
you have a problem with an existing ABI, you can just write a new
entrypoint instead (and leave the old ABI alone).
On the other hand, if you have bad datastructures, the ABI often reflects
that, and having the balls to say that your ABI's are broken and need to
be re-done in order to fix the data structures is _very_ important.
Otherwise you'll never be able to fix anything.
So I think that ABI's are often _way_ overhyped. If they are good,
everybody is happy. But if the interfaces are bad, you had better be
willing to just say "screw the ABI" and just fix it.
Now, that doesn't mean that you should change ABI's on a whim, and
regardless of any other issues, your user base is always important. But I
don't think ABI's are, or should be, "sacred".
For example, one thing git did early on was to just admit that some ABI's
are horribly horribly bad. For example, the CVS "annotate" ABI is just a
mistake, and trying to support that would just have held git back from
realizing that you can be so much more.
That may not be a "Application Binary Interface" kind of ABI, but it's an
interface, and it's exactly the same thing - sometimes you just have to
have the cajones to say "screw that, we'll be so much better if we can
change the interface".
Linus
^ permalink raw reply
* Re: Licensing and the library version of git
From: David Lang @ 2006-07-27 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607271232090.4168@g5.osdl.org>
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> On Thu, 27 Jul 2006, David Lang wrote:
>>
>>> (*) I will, in fact, claim that the difference between a bad programmer
>>> and a good one is whether he considers his code or his data structures
>>> more important. Bad programmers worry about the code. Good programmers
>>> worry about data structures and their relationships.
>>
>> personally I'd add to this that after the data structures are defined and you
>> turn to the code the API is significantly more important then the code itself.
>
> I think people sometimes put too much emphasis on ABI's.
I was careful to say aPi, not aBi :-)
> Sure, if you're depending on a library, the ABI is supremely important.
> But I literally believe that one of the things that makes open source
> technically superior to most other projects is the fact that ABI's can be
> changed more easily, and sometimes at all.
very true
> If you have good data structures, the ABI's are largely irrelevant, and if
> you have a problem with an existing ABI, you can just write a new
> entrypoint instead (and leave the old ABI alone).
>
> On the other hand, if you have bad datastructures, the ABI often reflects
> that, and having the balls to say that your ABI's are broken and need to
> be re-done in order to fix the data structures is _very_ important.
> Otherwise you'll never be able to fix anything.
however it's possible to have a good data structure and a bad API. I'm just
emphisising the API over the 'elegance', etc of the code that implements it.
> So I think that ABI's are often _way_ overhyped. If they are good,
> everybody is happy. But if the interfaces are bad, you had better be
> willing to just say "screw the ABI" and just fix it.
>
> Now, that doesn't mean that you should change ABI's on a whim, and
> regardless of any other issues, your user base is always important. But I
> don't think ABI's are, or should be, "sacred".
I'm not meaning to imply in any way that API's are sacred, just that they are
very important and deserve a lot of thought before implementation.
David Lang
^ permalink raw reply
* Re: Licensing and the library version of git
From: Wolfgang Denk @ 2006-07-27 19:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com>
In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
>
> I see that someone is already writing a pure Java version which will
> work around the GPL problem assuming the Java version is released
> under a compatible license.
... and assuming it is a clean-room implementation which does not
borrow from the GPL code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Be careful what you wish for. You never know who will be listening.
- Terry Pratchett, _Soul Music_
^ permalink raw reply
* Re: [PATCH] Per branch properties for pull and fetch
From: Matthias Lederhofer @ 2006-07-27 20:26 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060727120220.GD27593@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> The current default is to always use the remote's master branch, right?
> What do others think: does it make sense to default to the same
> branchname on the remote side?
I like the separate-remote option too and having one simple command
that pulls the changes from the correct remote branch would be nice.
It should do something like
$ git pull ${1:-origin} $(git-symbolic-ref HEAD | cut -d / -f 3-)
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:38 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, Jon Smirl, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.63.0607271245200.11436@qynat.qvtvafvgr.pbz>
Hi
On Thu, 27 Jul 2006, David Lang wrote:
> On Thu, 27 Jul 2006, Linus Torvalds wrote:
>
> > On Thu, 27 Jul 2006, David Lang wrote:
> > >
> > > > (*) I will, in fact, claim that the difference between a bad programmer
> > > > and a good one is whether he considers his code or his data structures
> > > > more important. Bad programmers worry about the code. Good programmers
> > > > worry about data structures and their relationships.
> > >
> > > personally I'd add to this that after the data structures are defined and
> > > you
> > > turn to the code the API is significantly more important then the code
> > > itself.
> >
> > I think people sometimes put too much emphasis on ABI's.
>
> I was careful to say aPi, not aBi :-)
All Linus said about ABIs is true for APIs, too. The only difference
between the two is, that people depend on the sacredness of ABIs even more
than on APIs.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Jon Smirl, git
In-Reply-To: <20060727195614.7EDAE353B04@atlas.denx.de>
Hi,
On Thu, 27 Jul 2006, Wolfgang Denk wrote:
> In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
> >
> > I see that someone is already writing a pure Java version which will
> > work around the GPL problem assuming the Java version is released
> > under a compatible license.
>
> ... and assuming it is a clean-room implementation which does not
> borrow from the GPL code.
>From a standpoint of copyright (which the GPL relies on), this is not
possible: you cannot include C code into Java. And if it is _translated_
from C into Java, it is not copyrighted any more.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 20:41 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, Grzegorz Kulewski, Jon Smirl, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0607271457250.9789@iabervon.org>
Hi,
On Thu, 27 Jul 2006, Daniel Barkalow wrote:
> On Thu, 27 Jul 2006, Linus Torvalds wrote:
>
> > On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> > >
> > > I think that part of the anwser for question "Why do people use GIT?" is that
> > > they trust you and other maintainers that you do a good and stable job. Won't
> > > creating several ports/forks/whatever destroy at least part of this?
> >
> > Sure. But the point is, the GPLv2 isn't exactly up for discussion. People
> > can complain all they want, but if they want to trust me, they'll take the
> > GPLv2. It's that easy.
>
> I think there'd be a justification for licensing part of git like sparse
> is licensed, for the same reasons. It wouldn't include any of the
> interesting operations, probably, but it would be worth having a canonical
> implementation of reading and writing the data structures, so other
> implementations don't screw that up.
You could probably even get away just copying these I/O operations,
because there is obviously no other way to do it. Ergo, no enforcable
copyright on those code sections.
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Petr Baudis @ 2006-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> >From a standpoint of copyright (which the GPL relies on), this is not
> possible: you cannot include C code into Java. And if it is _translated_
> from C into Java, it is not copyrighted any more.
now that's a pretty strong statement - did a lawyer tell you that?
(Lawyer in what country? Germany?) Because copyrights are generally
retained over translations, otherwise I could freely publish
e.g. Czech translation of someone else's English book without any
permissions and such, which is obviously not the case.
There has been actually similar issue with OpenTTD - it was created by
translating Transport Tycoon Deluxe assembly to C without permission of
original TTD copyright owner (not that anyone actually knows for sure
who that is, after series of company mergers and buyouts). I don't think
anyone consulted a lawyer about legality of that either but I believe
that most people agree that this is basically illegal (but most likely,
noone will ever sue, or care at all).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 21:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <20060727205158.GE13776@pasky.or.cz>
Hi,
On Thu, 27 Jul 2006, Petr Baudis wrote:
> Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > >From a standpoint of copyright (which the GPL relies on), this is not
> > possible: you cannot include C code into Java. And if it is _translated_
> > from C into Java, it is not copyrighted any more.
>
> now that's a pretty strong statement - did a lawyer tell you that?
<politics>
No. And I hate the fact that more and more people are actually accepting
the idea of being dictated how they should live by lawyers.
If a law is not clear to a layman, it should not be enforcable.
</politics>
> (Lawyer in what country? Germany?) Because copyrights are generally
> retained over translations, otherwise I could freely publish
> e.g. Czech translation of someone else's English book without any
> permissions and such, which is obviously not the case.
<message="I am not a lawyer... sh1t, I am disgusted by those">
The bigger problem is to _prove_ that it is a translation. It is much
easier with a 300-page book you translated from English into Czech.
It is almost impossible to prove something was copied if the source
language is a procedural computer language, and the target language is an
object-oriented computer language. Given the technical abilities of
judges, I even doubt that the act of the translation would _not_ be deemed
a non-literal transformation of the source code (and thus not be a
copyright case).
</message>
> There has been actually similar issue with OpenTTD - it was created by
> translating Transport Tycoon Deluxe assembly to C without permission of
> original TTD copyright owner (not that anyone actually knows for sure
> who that is, after series of company mergers and buyouts). I don't think
> anyone consulted a lawyer about legality of that either but I believe
> that most people agree that this is basically illegal (but most likely,
> noone will ever sue, or care at all).
<politics again=true>
Let's be honest: lawyers will only be interested in the money they get.
They will not care one wit about what is right or wrong: just look in some
newspaper of your choice. This is a sad fact about our world (but there is
a remedy: look into the Hitchhiker's guide to the galaxy).
The consequence is: no lawyer will properly defend the work of open source
people, since they tend to be poor (well, at least not rich). You just
cannot make much money by being nice.
</politics>
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Wolfgang Denk @ 2006-07-27 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In message <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de> you wrote:
>
> > ... and assuming it is a clean-room implementation which does not
> > borrow from the GPL code.
>
> >From a standpoint of copyright (which the GPL relies on), this is not
> possible: you cannot include C code into Java. And if it is _translated_
> from C into Java, it is not copyrighted any more.
Gulp. What have you been smoking lately? Your understanding of
copyright (and of the GPL) is fundamentally broken.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Mr. Cole's Axiom:
The sum of the intelligence on the planet is a constant;
the population is growing.
^ permalink raw reply
* Re: Licensing and the library version of git
From: Linus Torvalds @ 2006-07-27 21:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 27 Jul 2006, Johannes Schindelin wrote:
>
> From a standpoint of copyright (which the GPL relies on), this is not
> possible: you cannot include C code into Java. And if it is _translated_
> from C into Java, it is not copyrighted any more.
That is definitely not true. Translation does not take away anything from
the copyright. If I write a book in English, and you translate it to
German, _I_ remain the copyright holder, and you need my permission to
distribute the result. The fact that you translated it means nothing, and
you don't own it as a result.
Similarly, the fact that I and others hold the copyright on the source
code very much means that we also hold the copyright on any binaries you
"translate" that source code into, and the only thing that gives you a
right to distribute those binaries is not the translation phase, but the
fact that the GPLv2 allows you to distribute binaries (with certain
requirements, of course).
Now, on the other hand it's certainly true that certain elements are
potentially uncopyrightable. If there is effectively only one sane or
common way to actually write a git object to disk, the fact that your code
ends up looking very similar in Java to the way it is done in the original
C does not imply any copyright problems at all.
But that doesn't mean that you can take the C code and just rewrite it as
Java - it was still copyright protected. It just means that if your Java
code ends up looking like the C code, you can explain why it happened.
Now, some things have _no_ copyright protection at all, at least in
certain areas. Facts and things that did not involve any artistic
expression at all are simply not copyrightable. So if you list the first
million digits of PI, you can't complain if somebody copies them, for
example.
(But in some places, you can apparently claim that you "spent effort" on
gathering those digits of PI, and that others would have to spend that
same effort rather than copy your end result. I suspect that's a very weak
argument, but I suspect that there have been worse arguments made in front
of a judge in, say, places like Utah, to pick a random one).
And as usual, tech people talking legal issues is not very sane. So talk
to a lawyer if you really care.
Linus
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 21:16 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060727211046.C9FD5352625@atlas.denx.de>
Hi,
On Thu, 27 Jul 2006, Wolfgang Denk wrote:
> In message <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de> you wrote:
> >
> > > ... and assuming it is a clean-room implementation which does not
> > > borrow from the GPL code.
> >
> > >From a standpoint of copyright (which the GPL relies on), this is not
> > possible: you cannot include C code into Java. And if it is _translated_
> > from C into Java, it is not copyrighted any more.
>
> Gulp. What have you been smoking lately?
Nothing. I am a non-smoker. Maybe that is my problem?
> Your understanding of copyright (and of the GPL) is fundamentally
> broken.
You can read an article. And you can publish the contents in your own
words (you do not violate copyright by that). That is a fact.
And I do not buy into your "(and of the GPL)" thing. Either I get the
copyright, which the GPL is based on, or I don't get the copyright (but
still get that the GPL is based on it).
Ciao,
Dscho
^ permalink raw reply
* Re: Licensing and the library version of git
From: Johannes Schindelin @ 2006-07-27 21:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Wolfgang Denk, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0607271402230.4168@g5.osdl.org>
Hi,
On Thu, 27 Jul 2006, Linus Torvalds wrote:
> And as usual, tech people talking legal issues is not very sane. So talk
> to a lawyer if you really care.
Amen.
And I will not talk to a lawyer today: I had a lovely day, and I don't
want to spoil it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mailinfo: accept >From in message header
From: Junio C Hamano @ 2006-07-27 21:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20060727140343.GS9411@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> From Majordomo@vger.kernel.org Thu Jul 27 16:39:36 2006
>>From mtsirkin Thu Jul 27 16:39:36 2006
> Received: from yok.mtl.com [10.0.8.11]
> ....
>
> which confuses git-mailinfo since that does not recognize >From
> as a valid header line. The following patch makes git-applymbox
> work for me:
Wouldn't that kind of breakage confuse git-mailsplit as well?
^ permalink raw reply
* Re: [PATCH] mailinfo: accept >From in message header
From: Michael S. Tsirkin @ 2006-07-27 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqraoi9s.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] mailinfo: accept >From in message header
>
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>
> > From Majordomo@vger.kernel.org Thu Jul 27 16:39:36 2006
> >>From mtsirkin Thu Jul 27 16:39:36 2006
> > Received: from yok.mtl.com [10.0.8.11]
> > ....
> >
> > which confuses git-mailinfo since that does not recognize >From
> > as a valid header line. The following patch makes git-applymbox
> > work for me:
>
> Wouldn't that kind of breakage confuse git-mailsplit as well?
>
Hmm - I normally don't use it - just pipe stiff from mutt into git-applymbox.
A quick test seems to indicate git-mailsplit works fine.
But why should it - mailsplit just needs ^From to match new mail,
correct? So the escaped >From is good for it.
--
MST
^ permalink raw reply
* [PATCH 0/4] Fetching mass of objects at once
From: Petr Baudis @ 2006-07-27 21:53 UTC (permalink / raw)
To: git; +Cc: jonsmirl
Hi,
this series implements support for fetching many objects at once with
git-local-fetch and git-http-fetch, greatly helping Cogito's performance. It
would be of course nice to have this in Git 1.4.2, but it's probably too late
for that.
I didn't bother to convert git-ssh-fetch since I think noone uses that
anymore anyway (why would they...), or only some legacy users do.
I will followup with a patch for Cogito to take advantage of this. It's
now roughly on par with Git in cloning speed.
^ permalink raw reply
* [PATCH 1/4] Make pull() take some implicit data as explicit arguments
From: Petr Baudis @ 2006-07-27 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060727215326.24240.20118.stgit@machine>
Currently it's a bit weird that pull() takes a single argument
describing the commit but takes the write_ref from a global variable.
This makes it take that as a parameter as well, which might be nicer
for the libification in the future, but especially it will make for
nicer code when we implement pull()ing multiple commits at once.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
fetch.c | 6 ++----
fetch.h | 11 ++++-------
http-fetch.c | 4 ++--
local-fetch.c | 4 ++--
ssh-fetch.c | 4 ++--
5 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/fetch.c b/fetch.c
index 989d7a4..3255cc6 100644
--- a/fetch.c
+++ b/fetch.c
@@ -8,9 +8,6 @@ #include "tag.h"
#include "blob.h"
#include "refs.h"
-const char *write_ref = NULL;
-const char *write_ref_log_details = NULL;
-
int get_tree = 0;
int get_history = 0;
int get_all = 0;
@@ -213,7 +210,8 @@ static int mark_complete(const char *pat
return 0;
}
-int pull(char *target)
+int pull(char *target, const char *write_ref,
+ const char *write_ref_log_details)
{
struct ref_lock *lock = NULL;
unsigned char sha1[20];
diff --git a/fetch.h b/fetch.h
index 841bb1a..7bda355 100644
--- a/fetch.h
+++ b/fetch.h
@@ -22,12 +22,6 @@ extern void prefetch(unsigned char *sha1
*/
extern int fetch_ref(char *ref, unsigned char *sha1);
-/* If set, the ref filename to write the target value to. */
-extern const char *write_ref;
-
-/* If set additional text will appear in the ref log. */
-extern const char *write_ref_log_details;
-
/* Set to fetch the target tree. */
extern int get_tree;
@@ -46,6 +40,9 @@ extern int get_recover;
/* Report what we got under get_verbosely */
extern void pull_say(const char *, const char *);
-extern int pull(char *target);
+/* If write_ref is set, the ref filename to write the target value to. */
+/* If write_ref_log_details is set, additional text will appear in the ref log. */
+extern int pull(char *target, const char *write_ref,
+ const char *write_ref_log_details);
#endif /* PULL_H */
diff --git a/http-fetch.c b/http-fetch.c
index dc286b7..963d439 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1216,6 +1216,7 @@ int fetch_ref(char *ref, unsigned char *
int main(int argc, char **argv)
{
+ const char *write_ref = NULL;
char *commit_id;
char *url;
char *path;
@@ -1250,7 +1251,6 @@ int main(int argc, char **argv)
}
commit_id = argv[arg];
url = argv[arg + 1];
- write_ref_log_details = url;
http_init();
@@ -1268,7 +1268,7 @@ int main(int argc, char **argv)
alt->path_len = strlen(path);
}
- if (pull(commit_id))
+ if (pull(commit_id, write_ref, url))
rc = 1;
http_cleanup();
diff --git a/local-fetch.c b/local-fetch.c
index 65a803a..308ed00 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -204,6 +204,7 @@ static const char local_pull_usage[] =
*/
int main(int argc, char **argv)
{
+ const char *write_ref = NULL;
char *commit_id;
int arg = 1;
@@ -240,9 +241,8 @@ int main(int argc, char **argv)
usage(local_pull_usage);
commit_id = argv[arg];
path = argv[arg + 1];
- write_ref_log_details = path;
- if (pull(commit_id))
+ if (pull(commit_id, write_ref, path))
return 1;
return 0;
diff --git a/ssh-fetch.c b/ssh-fetch.c
index a8a6cfb..aef3aa4 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -123,6 +123,7 @@ static const char ssh_fetch_usage[] =
" [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url";
int main(int argc, char **argv)
{
+ const char *write_ref = NULL;
char *commit_id;
char *url;
int arg = 1;
@@ -159,7 +160,6 @@ int main(int argc, char **argv)
}
commit_id = argv[arg];
url = argv[arg + 1];
- write_ref_log_details = url;
if (setup_connection(&fd_in, &fd_out, prog, url, arg, argv + 1))
return 1;
@@ -167,7 +167,7 @@ int main(int argc, char **argv)
if (get_version())
return 1;
- if (pull(commit_id))
+ if (pull(commit_id, write_ref, url))
return 1;
return 0;
^ permalink raw reply related
* [PATCH 2/4] Make pull() support fetching multiple targets at once
From: Petr Baudis @ 2006-07-27 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060727215326.24240.20118.stgit@machine>
pull() now takes an array of arguments instead of just one of each kind.
Currently, no users use the new capability, but that'll change.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
fetch.c | 78 +++++++++++++++++++++++++++++++++------------------------
fetch.h | 2 +
http-fetch.c | 2 +
local-fetch.c | 2 +
ssh-fetch.c | 2 +
5 files changed, 49 insertions(+), 37 deletions(-)
diff --git a/fetch.c b/fetch.c
index 3255cc6..281df61 100644
--- a/fetch.c
+++ b/fetch.c
@@ -210,55 +210,67 @@ static int mark_complete(const char *pat
return 0;
}
-int pull(char *target, const char *write_ref,
+int pull(int targets, char **target, const char **write_ref,
const char *write_ref_log_details)
{
- struct ref_lock *lock = NULL;
- unsigned char sha1[20];
+ struct ref_lock **lock = xcalloc(targets, sizeof(struct ref_lock *));
+ unsigned char *sha1 = xmalloc(targets * 20);
char *msg;
int ret;
+ int i;
save_commit_buffer = 0;
track_object_refs = 0;
- if (write_ref) {
- lock = lock_ref_sha1(write_ref, NULL, 0);
- if (!lock) {
- error("Can't lock ref %s", write_ref);
- return -1;
+
+ for (i = 0; i < targets; i++) {
+ if (!write_ref[i])
+ continue;
+
+ lock[i] = lock_ref_sha1(write_ref[i], NULL, 0);
+ if (!lock[i]) {
+ error("Can't lock ref %s", write_ref[i]);
+ goto unlock_and_fail;
}
}
if (!get_recover)
for_each_ref(mark_complete);
- if (interpret_target(target, sha1)) {
- error("Could not interpret %s as something to pull", target);
- if (lock)
- unlock_ref(lock);
- return -1;
+ for (i = 0; i < targets; i++) {
+ if (interpret_target(target[i], &sha1[20 * i])) {
+ error("Could not interpret %s as something to pull", target[i]);
+ goto unlock_and_fail;
+ }
+ if (process(lookup_unknown_object(&sha1[20 * i])))
+ goto unlock_and_fail;
}
- if (process(lookup_unknown_object(sha1))) {
- if (lock)
- unlock_ref(lock);
- return -1;
+
+ if (loop())
+ goto unlock_and_fail;
+
+ if (write_ref_log_details) {
+ msg = xmalloc(strlen(write_ref_log_details) + 12);
+ sprintf(msg, "fetch from %s", write_ref_log_details);
+ } else {
+ msg = NULL;
}
- if (loop()) {
- if (lock)
- unlock_ref(lock);
- return -1;
+ for (i = 0; i < targets; i++) {
+ if (!write_ref[i])
+ continue;
+ ret = write_ref_sha1(lock[i], &sha1[20 * i], msg ? msg : "fetch (unknown)");
+ lock[i] = NULL;
+ if (ret)
+ goto unlock_and_fail;
}
+ if (msg)
+ free(msg);
- if (write_ref) {
- if (write_ref_log_details) {
- msg = xmalloc(strlen(write_ref_log_details) + 12);
- sprintf(msg, "fetch from %s", write_ref_log_details);
- }
- else
- msg = NULL;
- ret = write_ref_sha1(lock, sha1, msg ? msg : "fetch (unknown)");
- if (msg)
- free(msg);
- return ret;
- }
return 0;
+
+
+unlock_and_fail:
+ for (i = 0; i < targets; i++)
+ if (lock[i])
+ unlock_ref(lock[i]);
+ return -1;
}
diff --git a/fetch.h b/fetch.h
index 7bda355..75e48af 100644
--- a/fetch.h
+++ b/fetch.h
@@ -42,7 +42,7 @@ extern void pull_say(const char *, const
/* If write_ref is set, the ref filename to write the target value to. */
/* If write_ref_log_details is set, additional text will appear in the ref log. */
-extern int pull(char *target, const char *write_ref,
+extern int pull(int targets, char **target, const char **write_ref,
const char *write_ref_log_details);
#endif /* PULL_H */
diff --git a/http-fetch.c b/http-fetch.c
index 963d439..bc67db1 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1268,7 +1268,7 @@ int main(int argc, char **argv)
alt->path_len = strlen(path);
}
- if (pull(commit_id, write_ref, url))
+ if (pull(1, &commit_id, &write_ref, url))
rc = 1;
http_cleanup();
diff --git a/local-fetch.c b/local-fetch.c
index 308ed00..eb19f1a 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -242,7 +242,7 @@ int main(int argc, char **argv)
commit_id = argv[arg];
path = argv[arg + 1];
- if (pull(commit_id, write_ref, path))
+ if (pull(1, &commit_id, &write_ref, path))
return 1;
return 0;
diff --git a/ssh-fetch.c b/ssh-fetch.c
index aef3aa4..6e16568 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -167,7 +167,7 @@ int main(int argc, char **argv)
if (get_version())
return 1;
- if (pull(commit_id, write_ref, url))
+ if (pull(1, &commit_id, &write_ref, url))
return 1;
return 0;
^ permalink raw reply related
* [PATCH 3/4] Teach git-local-fetch the --stdin switch
From: Petr Baudis @ 2006-07-27 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060727215326.24240.20118.stgit@machine>
This makes it possible to fetch many commits (refs) at once, greatly
speeding up cg-clone.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-local-fetch.txt | 6 ++++++
fetch.c | 40 +++++++++++++++++++++++++++++++++++++
fetch.h | 6 ++++++
local-fetch.c | 32 ++++++++++++++++++++----------
4 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
index 87abec1..bd19820 100644
--- a/Documentation/git-local-fetch.txt
+++ b/Documentation/git-local-fetch.txt
@@ -29,6 +29,12 @@ OPTIONS
Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
+--stdin::
+ Instead of a commit id on the commandline (which is not expected in this
+ case), 'git-local-fetch' excepts lines on stdin in the format
+
+ <commit-id>['\t'<filename-as-in--w>]
+
Author
------
Written by Junio C Hamano <junkio@cox.net>
diff --git a/fetch.c b/fetch.c
index 281df61..2151c7b 100644
--- a/fetch.c
+++ b/fetch.c
@@ -7,6 +7,7 @@ #include "tree-walk.h"
#include "tag.h"
#include "blob.h"
#include "refs.h"
+#include "strbuf.h"
int get_tree = 0;
int get_history = 0;
@@ -210,6 +211,45 @@ static int mark_complete(const char *pat
return 0;
}
+int pull_targets_stdin(char ***target, const char ***write_ref)
+{
+ int targets = 0, targets_alloc = 0;
+ struct strbuf buf;
+ *target = NULL; *write_ref = NULL;
+ strbuf_init(&buf);
+ while (1) {
+ char *rf_one = NULL;
+ char *tg_one;
+
+ read_line(&buf, stdin, '\n');
+ if (buf.eof)
+ break;
+ tg_one = buf.buf;
+ rf_one = strchr(tg_one, '\t');
+ if (rf_one)
+ *rf_one++ = 0;
+
+ if (targets >= targets_alloc) {
+ targets_alloc = targets_alloc ? targets_alloc * 2 : 64;
+ *target = xrealloc(*target, targets_alloc * sizeof(**target));
+ *write_ref = xrealloc(*write_ref, targets_alloc * sizeof(**write_ref));
+ }
+ (*target)[targets] = strdup(tg_one);
+ (*write_ref)[targets] = rf_one ? strdup(rf_one) : NULL;
+ targets++;
+ }
+ return targets;
+}
+
+void pull_targets_free(int targets, char **target, const char **write_ref)
+{
+ while (targets--) {
+ free(target[targets]);
+ if (write_ref[targets])
+ free((char *) write_ref[targets]);
+ }
+}
+
int pull(int targets, char **target, const char **write_ref,
const char *write_ref_log_details)
{
diff --git a/fetch.h b/fetch.h
index 75e48af..be48c6f 100644
--- a/fetch.h
+++ b/fetch.h
@@ -40,6 +40,12 @@ extern int get_recover;
/* Report what we got under get_verbosely */
extern void pull_say(const char *, const char *);
+/* Load pull targets from stdin */
+extern int pull_targets_stdin(char ***target, const char ***write_ref);
+
+/* Free up loaded targets */
+extern void pull_targets_free(int targets, char **target, const char **write_ref);
+
/* If write_ref is set, the ref filename to write the target value to. */
/* If write_ref_log_details is set, additional text will appear in the ref log. */
extern int pull(int targets, char **target, const char **write_ref,
diff --git a/local-fetch.c b/local-fetch.c
index eb19f1a..84b68a6 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -8,8 +8,9 @@ #include "fetch.h"
static int use_link = 0;
static int use_symlink = 0;
static int use_filecopy = 1;
+static int commits_on_stdin = 0;
-static char *path; /* "Remote" git repository */
+static const char *path; /* "Remote" git repository */
void prefetch(unsigned char *sha1)
{
@@ -194,7 +195,7 @@ int fetch_ref(char *ref, unsigned char *
}
static const char local_pull_usage[] =
-"git-local-fetch [-c] [-t] [-a] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
+"git-local-fetch [-c] [-t] [-a] [-v] [-w filename] [--recover] [-l] [-s] [-n] [--stdin] commit-id path";
/*
* By default we only use file copy.
@@ -202,10 +203,11 @@ static const char local_pull_usage[] =
* If -s is specified, then a symlink is attempted.
* If -n is _not_ specified, then a regular file-to-file copy is done.
*/
-int main(int argc, char **argv)
+int main(int argc, const char **argv)
{
- const char *write_ref = NULL;
- char *commit_id;
+ int commits;
+ const char **write_ref = NULL;
+ char **commit_id;
int arg = 1;
setup_git_directory();
@@ -230,20 +232,30 @@ int main(int argc, char **argv)
else if (argv[arg][1] == 'v')
get_verbosely = 1;
else if (argv[arg][1] == 'w')
- write_ref = argv[++arg];
+ write_ref = &argv[++arg];
else if (!strcmp(argv[arg], "--recover"))
get_recover = 1;
+ else if (!strcmp(argv[arg], "--stdin"))
+ commits_on_stdin = 1;
else
usage(local_pull_usage);
arg++;
}
- if (argc < arg + 2)
+ if (argc < arg + 2 - commits_on_stdin)
usage(local_pull_usage);
- commit_id = argv[arg];
- path = argv[arg + 1];
+ if (commits_on_stdin) {
+ commits = pull_targets_stdin(&commit_id, &write_ref);
+ } else {
+ commit_id = (char **) &argv[arg++];
+ commits = 1;
+ }
+ path = argv[arg];
- if (pull(1, &commit_id, &write_ref, path))
+ if (pull(commits, commit_id, write_ref, path))
return 1;
+ if (commits_on_stdin)
+ pull_targets_free(commits, commit_id, write_ref);
+
return 0;
}
^ permalink raw reply related
* [PATCH 4/4] Teach git-http-fetch the --stdin switch
From: Petr Baudis @ 2006-07-27 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060727215326.24240.20118.stgit@machine>
Speeds up things quite a lot when fetching tags with Cogito.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-http-fetch.txt | 8 ++++++-
http-fetch.c | 45 ++++++++++++++++++++++++--------------
2 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
index bc1a132..bea522e 100644
--- a/Documentation/git-http-fetch.txt
+++ b/Documentation/git-http-fetch.txt
@@ -8,7 +8,7 @@ git-http-fetch - downloads a remote git
SYNOPSIS
--------
-'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] <commit> <url>
+'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
DESCRIPTION
-----------
@@ -32,6 +32,12 @@ commit-id::
-w <filename>::
Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
+
+--stdin::
+ Instead of a commit id on the commandline (which is not expected in this
+ case), 'git-http-fetch' excepts lines on stdin in the format
+
+ <commit-id>['\t'<filename-as-in--w>]
Author
------
diff --git a/http-fetch.c b/http-fetch.c
index bc67db1..1aad39b 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -36,6 +36,8 @@ #endif
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
+static int commits_on_stdin = 0;
+
static int got_alternates = -1;
static int corrupt_object_found = 0;
@@ -43,7 +45,7 @@ static struct curl_slist *no_pragma_head
struct alt_base
{
- char *base;
+ const char *base;
int path_len;
int got_indices;
struct packed_git *packs;
@@ -81,7 +83,7 @@ struct object_request
};
struct alternates_request {
- char *base;
+ const char *base;
char *url;
struct buffer *buffer;
struct active_request_slot *slot;
@@ -142,7 +144,7 @@ static size_t fwrite_sha1_file(void *ptr
return size;
}
-static void fetch_alternates(char *base);
+static void fetch_alternates(const char *base);
static void process_object_response(void *callback_data);
@@ -507,7 +509,7 @@ static void process_alternates_response(
(struct alternates_request *)callback_data;
struct active_request_slot *slot = alt_req->slot;
struct alt_base *tail = alt;
- char *base = alt_req->base;
+ const char *base = alt_req->base;
static const char null_byte = '\0';
char *data;
int i = 0;
@@ -612,7 +614,7 @@ static void process_alternates_response(
got_alternates = 1;
}
-static void fetch_alternates(char *base)
+static void fetch_alternates(const char *base)
{
struct buffer buffer;
char *url;
@@ -1185,7 +1187,7 @@ int fetch_ref(char *ref, unsigned char *
char *url;
char hex[42];
struct buffer buffer;
- char *base = alt->base;
+ const char *base = alt->base;
struct active_request_slot *slot;
struct slot_results results;
buffer.size = 41;
@@ -1214,11 +1216,12 @@ int fetch_ref(char *ref, unsigned char *
return 0;
}
-int main(int argc, char **argv)
+int main(int argc, const char **argv)
{
- const char *write_ref = NULL;
- char *commit_id;
- char *url;
+ int commits;
+ const char **write_ref = NULL;
+ char **commit_id;
+ const char *url;
char *path;
int arg = 1;
int rc = 0;
@@ -1238,19 +1241,26 @@ int main(int argc, char **argv)
} else if (argv[arg][1] == 'v') {
get_verbosely = 1;
} else if (argv[arg][1] == 'w') {
- write_ref = argv[arg + 1];
+ write_ref = &argv[arg + 1];
arg++;
} else if (!strcmp(argv[arg], "--recover")) {
get_recover = 1;
+ } else if (!strcmp(argv[arg], "--stdin")) {
+ commits_on_stdin = 1;
}
arg++;
}
- if (argc < arg + 2) {
- usage("git-http-fetch [-c] [-t] [-a] [-v] [--recover] [-w ref] commit-id url");
+ if (argc < arg + 2 - commits_on_stdin) {
+ usage("git-http-fetch [-c] [-t] [-a] [-v] [--recover] [-w ref] [--stdin] commit-id url");
return 1;
}
- commit_id = argv[arg];
- url = argv[arg + 1];
+ if (commits_on_stdin) {
+ commits = pull_targets_stdin(&commit_id, &write_ref);
+ } else {
+ commit_id = (char **) &argv[arg++];
+ commits = 1;
+ }
+ url = argv[arg];
http_init();
@@ -1268,13 +1278,16 @@ int main(int argc, char **argv)
alt->path_len = strlen(path);
}
- if (pull(1, &commit_id, &write_ref, url))
+ if (pull(commits, commit_id, write_ref, url))
rc = 1;
http_cleanup();
curl_slist_free_all(no_pragma_header);
+ if (commits_on_stdin)
+ pull_targets_free(commits, commit_id, write_ref);
+
if (corrupt_object_found) {
fprintf(stderr,
"Some loose object were found to be corrupt, but they might be just\n"
^ permalink raw reply related
* Re: [PATCH 0/4] Fetching mass of objects at once
From: Petr Baudis @ 2006-07-27 21:57 UTC (permalink / raw)
To: git; +Cc: jonsmirl
In-Reply-To: <20060727215326.24240.20118.stgit@machine>
Dear diary, on Thu, Jul 27, 2006 at 11:53:26PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> I will followup with a patch for Cogito to take advantage of this. It's
> now roughly on par with Git in cloning speed.
diff --git a/cg-Xfetchprogress b/cg-Xfetchprogress
index 53bcbd3..4a272db 100755
--- a/cg-Xfetchprogress
+++ b/cg-Xfetchprogress
@@ -67,7 +67,7 @@ sub getline {
if (m#^(link|symlink|copy|got) ([a-f0-9]{2})([a-f0-9]{38})#) {
$object = "$2/$3";
- } elsif (m#^(walk) ([a-f0-9]{2})([a-f0-9]{38})#) {
+ } elsif (m#^(ref|walk) ([a-f0-9]{2})([a-f0-9]{38})#) {
return 1; # redundant information
# rsync
diff --git a/cg-fetch b/cg-fetch
index a6e6959..9277f99 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -124,16 +124,10 @@ get_rsync()
return ${PIPESTATUS[0]}
}
-fetch_rsync()
+fetch_rsync_save()
{
- if [ $verbose -ge 2 ]; then
- # We must not pipe to prevent buffered I/O
- get_rsync -s -d "$2/objects" "$_git_objects"
- else
- get_rsync -s -d "$2/objects" "$_git_objects" | fetch_progress
- fi
ret=${PIPESTATUS[0]}
- if [ "$3" ] && [ "$ret" -eq "0" ]; then
+ if [ "$1" ] && [ "$ret" -eq "0" ]; then
if [ "$orig_head" ]; then
git-rev-list --objects $new_head ^$orig_head |
while read obj type; do
@@ -141,12 +135,29 @@ fetch_rsync()
done ||
die "rsync fetch incomplete, some objects missing"
fi
- cat "$_git/refs/${3%/*}/.${3##*/}-fetching" > "$_git/refs/$3"
+ cat "$_git/refs/${3%/*}/.${3##*/}-fetching" > "$_git/refs/$1"
fi
return $ret
}
+fetch_rsync()
+{
+ if [ $verbose -ge 2 ]; then
+ # We must not pipe to prevent buffered I/O
+ get_rsync -s -d "$2/objects" "$_git_objects"
+ else
+ get_rsync -s -d "$2/objects" "$_git_objects" | fetch_progress
+ fi
+ if [ x"$1" = x"--stdin" ]; then
+ while read c w; do
+ echo "$c" >"$_git/refs/$w"
+ done
+ else
+ fetch_rsync_save "$3"
+ fi
+}
+
get_http()
{
[ "$1" = "-b" ] && shift
@@ -229,21 +240,13 @@ fetch_tags()
# if so, fetch the tag -- which should be
# a cheap operation -- to complete the chain.
- echo -n "Missing tag ${tagname#tags/}... "
- if $fetch "$tagname" "$uri" "$tagname" 2>/dev/null >&2; then
- echo "retrieved"
- else
- # 17 is code from packed transport, which
- # will grab all of them en masse later
- if [ "$?" -ne "17" ]; then
- echo "unable to retrieve"
- else
- echo ""
- fi
- fi
- done
- [ "${PIPESTATUS[0]}" -eq "0" ] ||
- echo "unable to get tags list (non-fatal)" >&2
+ echo "Missing tag ${tagname#tags/}..." >&2
+ echo -e "$tagname"\\t"$tagname"
+ done |
+ sort | uniq | $fetch --stdin "$uri"
+ if [ "${PIPESTATUS[0]}" -ne 0 -o "$?" -ne 0 ]; then
+ echo "unable to fetch tags (non-fatal)" >&2
+ fi
return 0
}
@@ -364,21 +367,15 @@ if [ "$packed_transport" ]; then
fetch_pack_recorder "refs/heads/$name" "fetching pack failed" ||
exit
- export _cg_taglist="$(mktemp -t gitfetch.XXXXXX)"
record_tags_to_fetch () {
- echo "refs/$1" >>"$_cg_taglist"
- return 17
- }
- fetch=record_tags_to_fetch
- fetch_tags
- if [ -s "$_cg_taglist" ]; then
- ( cat "$_cg_taglist" | tr '\n' '\0' |
+ ( cut -f 1 | tr '\n' '\0' |
xargs -0 git-fetch-pack $cloneorfetch "$uri" ||
echo "failed" "$rembranch" ) |
fetch_pack_recorder "" "unable to retrieve tags (non-fatal)"
- fi
- rm "$_cg_taglist"
+ }
+ fetch=record_tags_to_fetch
+ fetch_tags
rm "$dirtyfile"
show_changes_summary "$orig_head" "$(cg-object-id "$name")"
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: Licensing and the library version of git
From: Anand Kumria @ 2006-07-28 0:24 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910607270911p50d25d97w1a898fc7a9119e7d@mail.gmail.com>
On Thu, 27 Jul 2006 12:11:00 -0400, Jon Smirl wrote:
> On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
>> > You may like trying to force GPL onto the app but many apps are
>> > stuck with the license they have and can't be changed since there is
>> > no way to contact the original developers.
>>
>> At this point, git-shortlog lists exactly 200 people (at least entries
>> like Unknown or No name are all linux@horizon.com ;-).
>
> Inability to integrate with Microsoft Visual Studio is going to have a
> lot of impact on the cross platform use of git.
Could you stop with the histrionics please?
> Is a conscious
> decision being made to stop this integration or is this just unplanned
> side effect of the original license? If this is an unplanned side
> effect, the quicker we move, the easier it is to fix.
So, using CVSNT (a GPL'd SCCI provider) and git-cvsserver would be a way
to continue. I'm assuming that the primary functionality they want via
their IDE is checkout/diff/commit/log.
Quite a lot of Windows developers have no problems using multiple tools
for things, I'd assume they would also be able to use any existent port
of git (to Windows) to do the esoteric things like branching/bisect/etc.
Anand
^ permalink raw reply
* Re: Licensing and the library version of git
From: Anand Kumria @ 2006-07-28 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910607271047r57fe0aa3hf29b4b9244c02f2c@mail.gmail.com>
On Thu, 27 Jul 2006 13:47:24 -0400, Jon Smirl wrote:
> On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> I seriously doubt that Eclipse or Visual Stupido could ever actually
>> _understand_ what git does, so the only parts you actually would want to
>> use for those is literally the trivial stuff - the "look up objects" and
>> "generate commits" part.
>
> Typically an integrated IDE can move, delete, rename directories and
> files. Get a log. Push, pull and commit. Revert a change. Generate
> diffs to previous versions.
Kind of what you can do via CVSNT and git-cvsserver, no?
Anand
^ permalink raw reply
* Re: Licensing and the library version of git
From: Jon Smirl @ 2006-07-28 0:43 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <eablgn$c6a$1@sea.gmane.org>
On 7/27/06, Anand Kumria <wildfire@progsoc.org> wrote:
> On Thu, 27 Jul 2006 12:11:00 -0400, Jon Smirl wrote:
>
> > On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> >> > You may like trying to force GPL onto the app but many apps are
> >> > stuck with the license they have and can't be changed since there is
> >> > no way to contact the original developers.
> >>
> >> At this point, git-shortlog lists exactly 200 people (at least entries
> >> like Unknown or No name are all linux@horizon.com ;-).
> >
> > Inability to integrate with Microsoft Visual Studio is going to have a
> > lot of impact on the cross platform use of git.
>
> Could you stop with the histrionics please?
It is usually wise not to make comments like this, they don't help in
building the community.
> > Is a conscious
> > decision being made to stop this integration or is this just unplanned
> > side effect of the original license? If this is an unplanned side
> > effect, the quicker we move, the easier it is to fix.
>
> So, using CVSNT (a GPL'd SCCI provider) and git-cvsserver would be a way
> to continue. I'm assuming that the primary functionality they want via
> their IDE is checkout/diff/commit/log.
Now, that's a great strategy. Tell the large project you are
interested in switching off from CVS to git that they need to run a
CVS emulation gateway forever. I don't think a switch has much of a
chance of happening.
> Quite a lot of Windows developers have no problems using multiple tools
> for things, I'd assume they would also be able to use any existent port
> of git (to Windows) to do the esoteric things like branching/bisect/etc.
>
> Anand
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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