* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 17:40 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503171538.GC9820@thunk.org>
On Wed, 3 May 2006, Theodore Tso wrote:
>
> Yeah, but the fact that you have to use repack and prune in order to
> keep the disk space usage from exploding (especially with the Linux
> 2.6 tree) , means that we have to expose that mess to the beginning
> user.
No you don't. You get it packed when it's cloned, and the disk usage
doesn't go up _that_ fast. By the time you need to worry about disk usage
you have certainly had time to learn the basics.
No need to start talking about fsck or repacking until the second day.
> Could git be made to do the repacking automatically when it makes sense
> using some hueristic algorithm?
This was discussed, and yeah, it _could_, but I suspect you really don't
want to repack in the middle of some op. Even if your repo was _mostly_
packed, it's an irritating hickup at a time when you don't need to.
I think it's much better to teach people to repack once a week (if that).
But to teach them only after they've already _used_ it for a week and
aren't intimidated by the basic ops any longer.
Linus
^ permalink raw reply
* Re: git-unpack-objects
From: Josh Boyer @ 2006-05-03 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu089qr4t.fsf@assigned-by-dhcp.cox.net>
On 5/1/06, Junio C Hamano <junkio@cox.net> wrote:
>
> unpack tries to unpack and if it already has the object it
> skips.
>
> If you really wanted to do it, here is a way to do so.
>
> mv .git/objets/pack/pack-49*.pack \
> .git/objets/pack/pack-49*.idx .
> git unpack-objects <pack-49*.pack
Hm.. so it seems that git-unpack-objects is more intended to unpack a
pack one has gotten with git-fetch-pack, right?
I was looking for something more along the lines of an
"un-git-repack", where you have existing pack(s) and want to undo
them. Maybe you want to repack everything into a single pack or
something like that.
josh
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Theodore Tso @ 2006-05-03 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030958370.4086@g5.osdl.org>
On Wed, May 03, 2006 at 10:06:25AM -0700, Linus Torvalds wrote:
> Even the "everyday git in 20 commands" actually starts out scaring people
> with listing commands that they don't need to know about immediately. The
> whole fsck/count-object/pruning thing shouldn't even be mentioned until
> after you've shown how easy it is to just do
>
> git init-db
> git add .
> git commit -a
>
> to import an old project, and then do an example commit or something
> (one of the early examples).
Yeah, but the fact that you have to use repack and prune in order to
keep the disk space usage from exploding (especially with the Linux
2.6 tree) , means that we have to expose that mess to the beginning
user. Could git be made to do the repacking automatically when it
makes sense using some hueristic algorithm?
- Ted
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 17:06 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503164732.GB9820@thunk.org>
On Wed, 3 May 2006, Theodore Tso wrote:
>
> Of course, a lot of it is that git *is* much more powerful, much like
> the difference between a stickshift with a racing clutch (git) and a
> car with an automatic transmission (hg).
I don't think that's necessarily a good comparison.
The "easy things" are easy even with git. Our explanation pages and
tutorials just tend to want to show off, and do more than they need to.
Even the "everyday git in 20 commands" actually starts out scaring people
with listing commands that they don't need to know about immediately. The
whole fsck/count-object/pruning thing shouldn't even be mentioned until
after you've shown how easy it is to just do
git init-db
git add .
git commit -a
to import an old project, and then do an example commit or something
(one of the early examples).
So yeah. We should have a main page that starts off with the "everyday
git" link (preferably further simplified) very prominently, and just looks
less scary.
People are probably already expecting the worst - partly because git is
newer than some of the other projects (not hg, but svn/svk/monotone etc),
and partly because I was actively trying to not over-promise or over-sell
early on when it wasn't clear how good git was going to get..
So looking pretty and easy to use is clearly important, and I think git
has the _capability_ for that, we've not just documented it that way.
Linus
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 16:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17496.7073.507895.484698@cargo.ozlabs.ibm.com>
On Wed, 3 May 2006, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > The obvious way to do it would be to just have two buttons per view: one
> > exclusive one (for the main view - only one selected at a time), and the
> > other one for the "highlight" one where you could allow multiple views to
> > be selected for highlighting.
>
> That's hard to do in a menu, but I could do it in a separate pane.
> Or, I could draw a series of tabs between the menu bar and the
> graph/headline/author/date panes. Each tab would have the view name,
> a radiobutton to select it for highlighting, and a close button.
Actually, having used this thing (and thought about) some more, I'm afraid
that I'll have to just admit that my whole "highlight" thing was
misdesigned.
One is just an interface issue, and I think that it would be fixed by just
removing the highlight entry from the "view" menu, and making it a menu of
its own. That, I think, would fix the user interface to be more obvious
and intuitive.
But the real thing I found is that when I decided I wanted to highlight, I
didn't actually want to highlight by "git-rev-list" at all. At least not
most of the time.
So far, what I've wanted to highlight by is:
- "does it touch this file/directory/pathspec"
This is _close_ to "git-rev-list", and you can (and do) actually
implement it as that, but it's stupid to do it that way. You just spend
extra time. It's literally much better to do
cat commit-list | git-diff-tree -s --stdin -- <pathspec>
which is a hell of a lot more efficient, since you already have the
commit-list you're interested in (and, in fact, this allows you to do
things efficiently only for the current _visible_ commits, if you want
to, which might be an important optimization for large views).
- "Does the author/committer match xyz*"
I ended up using the "search" button for this, and it worked, but the
highlight feature would just have done it much better. Especially if
there was a way to do "go to next highlight", instead of just "go to
next commit"
Again, this is actually most easily done by just using the commit-list
you already _have_. Not with adding a new argument to "git-rev-list"
and trying to filter two views. Also, again, this can actually be done
for just the "visible" ones, not the whole view.
- "highlight the commits [not] reachable from the selected commit"
Now, this literally is "git-rev-list", but it's a variation on it: you
don't want a new view, you really want the _old_ view (exact same
git-rev-list arguments), but you add "^commit" to the list of
revisions. And then you (conditionally) invert the highlighting if you
wanted "reachable" rather than "not reachable".
And the current "create a new view, and overlay that on the old one"
approach really isn't that good. My mistake, it was me who suggested it.
What do you think?
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Theodore Tso @ 2006-05-03 16:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030817580.4086@g5.osdl.org>
Mercurial also has an easier learning curve; and while the "Everyday
Git with 20 commands or so" is a very good document, and I've found it
invaluable for getting started, if you compare it to the "Quick Start
for the Impatient" page on the front page of the Mercurial Wiki, for
many people Mercurial will *appear* to be an order of magitude simpler
and is yet powerful enough for their project.
Of course, a lot of it is that git *is* much more powerful, much like
the difference between a stickshift with a racing clutch (git) and a
car with an automatic transmission (hg). So maybe one thing that
would help git would be a stronger emphasis of cogito for those
projects that don't need the full power of using git "straight up".
Just a thought....
- Ted
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605030919xf54e1c2j1e27c4ce04b6864d@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 5/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> As to content, we could I think use material found at Wikipedia Git page,
>> and on External Links in Wikipedia Git_(software) article, not repeating
>> of course what is in official Git Documentation/
>
> I just added the TODO list link but I'm not a wiki expert, if you know
> how to link to the article from Wikipedia please do it ;-)
I thought about copying contents, not making a link to WikiPedia article.
I tried to make InterWiki link, WikiPedia:Git_(software) but MoinMoin engine
doesn't deal well with parentheses.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* RE: problem with plain git clone
From: Haruki Dai-r35557 @ 2006-05-03 16:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
Hi Kumar,
Could you enable post update hook? I couldn't clone through http:.
Thanks,
Dai
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Kumar Gala
> Sent: Wednesday, May 03, 2006 10:46 AM
> To: Shawn Pearce
> Cc: git@vger.kernel.org
> Subject: Re: problem with plain git clone
>
>
> On May 3, 2006, at 9:31 AM, Shawn Pearce wrote:
>
> > Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Anyone see an issues like the following:
> >>
> >> [kgala@kgala_lnx z]$ git clone
> git://git.kernel.org:/pub/scm/boot/u-
> >> boot/galak/u-boot.git
> >> git clone
> git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
> >> fatal: unable to connect a socket (Connection timed out)
> >
> > There's no GIT daemon running on the empty port. Notice the ':'
> > appearing right after '.org'.
> >
> > Hmm, that sounds like a bug in the protocol URL parser...
>
> Yeah, that was it. thanks.
>
> - kumar
> -
> 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
>
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3al00$1dj$1@sea.gmane.org>
On 5/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Linus Torvalds wrote:
> > On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> >>
> >> Perhaps is just a silly idea, but would be possible for OSDL to host a
> >> web site (www.git.org) where we can host pages/wiki an so on?
> >
> > I don't think hosting it would be a problem (it probably would be the same
> > kernel.org thing - OSDL is partly involved in maintaining it). The problem
> > is the content, and the artistic talent.
>
> As to content, we could I think use material found at Wikipedia Git page,
> and on External Links in Wikipedia Git_(software) article, not repeating of
> course what is in official Git Documentation/
I just added the TODO list link but I'm not a wiki expert, if you know
how to link to the article from Wikipedia please do it ;-)
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605030856540.4086@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>>
>> Perhaps is just a silly idea, but would be possible for OSDL to host a
>> web site (www.git.org) where we can host pages/wiki an so on?
>
> I don't think hosting it would be a problem (it probably would be the same
> kernel.org thing - OSDL is partly involved in maintaining it). The problem
> is the content, and the artistic talent.
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 16:06 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030839i2bb5de8dka8a4af27755051cf@mail.gmail.com>
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>
> Perhaps is just a silly idea, but would be possible for OSDL to host a
> web site (www.git.org) where we can host pages/wiki an so on?
I don't think hosting it would be a problem (it probably would be the same
kernel.org thing - OSDL is partly involved in maintaining it). The problem
is the content, and the artistic talent.
_I_ personally have what I'd call "negative artistic talent". I think I'm
occasionally good at designing beautiful data structures (and I think git
is that, including the pack-files), but that clearly doesn't translate to
any visual ability what-so-ever. None. Nada. Zilch.
Maybe the new Wiki can evolve into that. It sure looks better today than
it looked yesterday (now, when I first saw it, it was so ugly that I had
to dig my eyeballs out with a spoon, so that's not necessarily saying all
that much ;)
Linus
^ permalink raw reply
* Re: problem with plain git clone
From: Kumar Gala @ 2006-05-03 15:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060503143130.GA9172@spearce.org>
On May 3, 2006, at 9:31 AM, Shawn Pearce wrote:
> Kumar Gala <galak@kernel.crashing.org> wrote:
>> Anyone see an issues like the following:
>>
>> [kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
>> boot/galak/u-boot.git
>> git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
>> fatal: unable to connect a socket (Connection timed out)
>
> There's no GIT daemon running on the empty port. Notice the ':'
> appearing right after '.org'.
>
> Hmm, that sounds like a bug in the protocol URL parser...
Yeah, that was it. thanks.
- kumar
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 15:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030817580.4086@g5.osdl.org>
On 5/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 3 May 2006, Andreas Ericsson wrote:
> >
> > Considering Sun's CEO's common comments on Solaris' superiority over Linux I
> > think it's safe to assume that the same CEO wouldn't exactly jump of joy if
> > his employees started depending on a tool fathered by Linus.
>
> I doubt it went that high up, but with any kind of politics it's obviously
> possible that somebody consciously or unconsciously felt it might become a
> political problem, and it might have made a difference.
>
> However, I think the _real_ issue is that Mercurial has a much nicer
> introductory phase. The standard mercurial web-page is so much more
> professional and nice to look at than any git page I have ever seen, and
> let's face it: first looks _do_ count.
I can only agree.
I'm not a git developer, I'm even not a _real_ developer, I only hack
for fun during my very poor spare time but web pages, wiki and
introduction offered by Mercurial are really a lot nicer to what git
is offering at the moment.
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* [PATCH] Add a simple makefile
From: Pavel Roskin @ 2006-05-03 15:34 UTC (permalink / raw)
To: Catalin Marinas, git
From: Pavel Roskin <proski@gnu.org>
---
Makefile | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..df77d97
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,23 @@
+PREFIX = $(HOME)
+DESTDIR = /
+PYTHON = python
+
+all:
+ $(PYTHON) setup.py build
+
+install:
+ $(PYTHON) setup.py install --prefix=$(PREFIX) --root=$(DESTDIR)
+
+doc:
+ cd doc && $(MAKE) all
+
+test:
+ cd t && $(MAKE) all
+
+clean:
+ for dir in doc t; do \
+ (cd $$dir && $(MAKE) clean); \
+ done
+ rm -rf build
+ rm -f stgit/*.pyc
+ rm -f stgit/commands/*.pyc
^ permalink raw reply related
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605030824v40017178o366a9d8aa83557e8@mail.gmail.com>
Paolo Ciarrocchi wrote:
> Would be fantastic to see a fair comparison of the two tools but I
> can't find anything useful on the web.
Three tools: Git/Cogito, Mercurial and Monotone.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 15:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4458C5D7.8010501@op5.se>
On Wed, 3 May 2006, Andreas Ericsson wrote:
>
> Considering Sun's CEO's common comments on Solaris' superiority over Linux I
> think it's safe to assume that the same CEO wouldn't exactly jump of joy if
> his employees started depending on a tool fathered by Linus.
I doubt it went that high up, but with any kind of politics it's obviously
possible that somebody consciously or unconsciously felt it might become a
political problem, and it might have made a difference.
However, I think the _real_ issue is that Mercurial has a much nicer
introductory phase. The standard mercurial web-page is so much more
professional and nice to look at than any git page I have ever seen, and
let's face it: first looks _do_ count.
Also, the fact that Solaris had the unfortunate bug with signals probably
didn't much help to endear git to them, since it made it look like git had
problems. Never mind that we solved it - I think it took us a while to
even realize that Solaris had a problem, because we weren't intimately
involved.
Which brings me to the final point, which is that I think the hg team was
very active and supporting, perhaps Matt himself. That's _important_ - the
OpenSolaris people probably felt very comfortable with strong support from
the developers. It can often be _the_ best (and biggest) reason to choose
any product - regardless of anything else.
Even if I think the git mailing list itself is very responsive, I think
the hg people were just more directly and actively involved. For git, they
had to come to us.
I also suspect that some people find python scripts somewhat less
intimidating than C. I'll also happily admit that my coding standards tend
to lean towards the "sparse" when it comes to comments, and I much prefer
the "small and well-named functions" approach, and git seems to have stuck
to that with Junio. Which just turns some people off.
So I don't think you need politics to explain it. I think hg is doing
quite well. It took some different design decisions, and while I
personally think the git ones are better, I'm somewhat biased ;)
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 15:24 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Shawn Pearce, Nicolas Pitre, Petr Baudis, Junio C Hamano, git
In-Reply-To: <4458C5D7.8010501@op5.se>
On 5/3/06, Andreas Ericsson <ae@op5.se> wrote:
> >>On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> >>
> >>>On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> >>>
> >>>>Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> >>>>where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> >>>>
> >>>>>On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> >>>>>
> >>>>>BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> >>>>>(they choose Mercurial).
> >>>>
> >>>>I think it's explained somewhere in their forums (or mailing lists or
> >>>>whatever they actually _are_).
> >>>
> >>>I only found the announcement, not the rationales.
> >>
> >>http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
> >>
> >>Looks like they didn't buy the argument about the uselessness of
> >>recording file renames.
> >
> >
> > The final evaluations are available from here (at the very bottom
> > of the page):
> >
> > http://opensolaris.org/os/community/tools/scm/
> >
> > It looks like Mercurial doesn't support renames either, but a lot
> > of users are asking for it to be supported. So I don't think that's
> > the reason. It looks more like they didn't enjoy porting GIT 1.2.2
> > (as 1.2.4 was found to not work in all cases) to Solaris and the
> > tester ran into some problems with the conflict resolution support.
> >
> > My own reading of the two final evaluations for GIT and Mercurial
> > leaves me feeling like GIT is a more mature tool which is faster
> > and more stable then Mercurial. GIT seemed to be more reliable
> > during testing then Mercurial was, despite the cloning issue.
> > Which makes me surprised that OpenSolaris selected Mercurial instead.
> >
>
Would be fantastic to see a fair comparison of the two tools but I
can't find anything useful on the web.
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Andreas Ericsson @ 2006-05-03 15:01 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nicolas Pitre, Paolo Ciarrocchi, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503142957.GA9056@spearce.org>
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>
>>On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>>
>>>On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
>>>
>>>>Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
>>>>where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
>>>>
>>>>>On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
>>>>>
>>>>>BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
>>>>>(they choose Mercurial).
>>>>
>>>>I think it's explained somewhere in their forums (or mailing lists or
>>>>whatever they actually _are_).
>>>
>>>I only found the announcement, not the rationales.
>>
>>http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>>
>>Looks like they didn't buy the argument about the uselessness of
>>recording file renames.
>
>
> The final evaluations are available from here (at the very bottom
> of the page):
>
> http://opensolaris.org/os/community/tools/scm/
>
> It looks like Mercurial doesn't support renames either, but a lot
> of users are asking for it to be supported. So I don't think that's
> the reason. It looks more like they didn't enjoy porting GIT 1.2.2
> (as 1.2.4 was found to not work in all cases) to Solaris and the
> tester ran into some problems with the conflict resolution support.
>
> My own reading of the two final evaluations for GIT and Mercurial
> leaves me feeling like GIT is a more mature tool which is faster
> and more stable then Mercurial. GIT seemed to be more reliable
> during testing then Mercurial was, despite the cloning issue.
> Which makes me surprised that OpenSolaris selected Mercurial instead.
>
Considering Sun's CEO's common comments on Solaris' superiority over
Linux I think it's safe to assume that the same CEO wouldn't exactly
jump of joy if his employees started depending on a tool fathered by Linus.
No offence intended to Mercurial or its developers. Although I don't
know anything about how it works I'm fairly sure Sun's developers would
never agree to be forced to use an inferior tool (congrats Mercurial
devs). However, I *do* think that in a tie-break Mercurial would win for
political reasons.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-log --parents broken post v1.3.0
From: Linus Torvalds @ 2006-05-03 14:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Junio C Hamano
In-Reply-To: <46a038f90605030510x6d582804w6c0d2fec60bd56e5@mail.gmail.com>
On Thu, 4 May 2006, Martin Langhoff wrote:
> On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > Soon after v1.3.0 git-log --parents got broken. When using --parents,
>
> Ok -- perhaps that was a bit of a rushed statement. Reading back on
> the archives, it seems like it may have been intentional.
No it wasn't. "git log --parents" was definitely supposed to still work.
That said, I suspect a git-cvsserver kind of usage is better off using
"git-rev-list --parents HEAD" instead, which didn't break in the first
place.
> I have to confess, I don't quite follow the changes happening in that
> series of commits. If --parents is really not coming back I'll change
> the log entry parsing in cvsserver. However, I suspect git-log should
> error out on it ("fatal: deprecated option") so porcelains break
> explicitly, rather than silently.
No, the option really isn't deprecated, it was just missed because nothing
seemed to use it.. How about this diff?
Signed-off-by: Yadda yadda
Linus
---
diff --git a/log-tree.c b/log-tree.c
index 9634c46..f9c6f7c 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -3,6 +3,15 @@ #include "diff.h"
#include "commit.h"
#include "log-tree.h"
+static void show_parents(struct commit *commit, int abbrev)
+{
+ struct commit_list *p;
+ for (p = commit->parents; p ; p = p->next) {
+ struct commit *parent = p->item;
+ printf(" %s", diff_unique_abbrev(parent->object.sha1, abbrev));
+ }
+}
+
void show_log(struct rev_info *opt, struct log_info *log, const char *sep)
{
static char this_header[16384];
@@ -14,7 +23,10 @@ void show_log(struct rev_info *opt, stru
opt->loginfo = NULL;
if (!opt->verbose_header) {
- puts(sha1_to_hex(commit->object.sha1));
+ fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
+ if (opt->parents)
+ show_parents(commit, abbrev_commit);
+ putchar('\n');
return;
}
@@ -40,6 +52,8 @@ void show_log(struct rev_info *opt, stru
printf("%s%s",
opt->commit_format == CMIT_FMT_ONELINE ? "" : "commit ",
diff_unique_abbrev(commit->object.sha1, abbrev_commit));
+ if (opt->parents)
+ show_parents(commit, abbrev_commit);
if (parent)
printf(" (from %s)", diff_unique_abbrev(parent->object.sha1, abbrev_commit));
putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
^ permalink raw reply related
* Re: problem with plain git clone
From: Shawn Pearce @ 2006-05-03 14:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <7CAB7A96-2C63-4B05-B0C6-72FC5B74D960@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote:
> Anyone see an issues like the following:
>
> [kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
> boot/galak/u-boot.git
> git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
> fatal: unable to connect a socket (Connection timed out)
There's no GIT daemon running on the empty port. Notice the ':'
appearing right after '.org'.
Hmm, that sounds like a bug in the protocol URL parser...
--
Shawn.
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-03 9:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030501x1d97f60at4d10c8e2c7b4304c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
my version is 1.3.1. I'll d/l 1.3.0 and test with that.
Martin Langhoff wrote:
> Bill,
>
> haven't been able to repro your problem at this end. Can you check
> your git version? Apparently cvsserver was broken soon after 1.3.0.
> Can you try with v1.3.0?
>
> cheers,
>
>
> martin
>
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Shawn Pearce @ 2006-05-03 14:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Paolo Ciarrocchi, Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030934220.28543@localhost.localdomain>
Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> > On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> > > Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> > > where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> > > > On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> > > >
> > > > BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> > > > (they choose Mercurial).
> > >
> > > I think it's explained somewhere in their forums (or mailing lists or
> > > whatever they actually _are_).
> >
> > I only found the announcement, not the rationales.
>
> http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>
> Looks like they didn't buy the argument about the uselessness of
> recording file renames.
The final evaluations are available from here (at the very bottom
of the page):
http://opensolaris.org/os/community/tools/scm/
It looks like Mercurial doesn't support renames either, but a lot
of users are asking for it to be supported. So I don't think that's
the reason. It looks more like they didn't enjoy porting GIT 1.2.2
(as 1.2.4 was found to not work in all cases) to Solaris and the
tester ran into some problems with the conflict resolution support.
My own reading of the two final evaluations for GIT and Mercurial
leaves me feeling like GIT is a more mature tool which is faster
and more stable then Mercurial. GIT seemed to be more reliable
during testing then Mercurial was, despite the cloning issue.
Which makes me surprised that OpenSolaris selected Mercurial instead.
--
Shawn.
^ permalink raw reply
* problem with plain git clone
From: Kumar Gala @ 2006-05-03 14:18 UTC (permalink / raw)
To: git
Anyone see an issues like the following:
[kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
boot/galak/u-boot.git
git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
fatal: unable to connect a socket (Connection timed out)
fetch-pack from 'git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-
boot.git' failed.
I've clearly done something crazy, but I setup this repository today
with a simple:
git clone -n rsync://rsync.denx.de/git/u-boot.git
mv u-boot/.git/ u-boot.git
- kumar
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Nicolas Pitre @ 2006-05-03 13:41 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030213r625ce87fw5cbee554f1c20fbd@mail.gmail.com>
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> > Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> > where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> > > On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> > >
> > > BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> > > (they choose Mercurial).
> >
> > I think it's explained somewhere in their forums (or mailing lists or
> > whatever they actually _are_).
>
> I only found the announcement, not the rationales.
http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
Looks like they didn't buy the argument about the uselessness of
recording file renames.
Nicolas
^ permalink raw reply
* [PATCH] Add a conversion tool to migrate remote information into the config
From: Johannes Schindelin @ 2006-05-03 13:27 UTC (permalink / raw)
To: git, junkio
Use this tool to rewrite the .git/remotes/* files into the config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
contrib/remotes2config.sh | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/contrib/remotes2config.sh b/contrib/remotes2config.sh
new file mode 100644
index 0000000..25901e2
--- /dev/null
+++ b/contrib/remotes2config.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+# Use this tool to rewrite your .git/remotes/ files into the config.
+
+. git-sh-setup
+
+if [ -d "$GIT_DIR"/remotes ]; then
+ echo "Rewriting $GIT_DIR/remotes" >&2
+ error=0
+ # rewrite into config
+ {
+ cd "$GIT_DIR"/remotes
+ ls | while read f; do
+ name=$(echo -n "$f" | tr -c "A-Za-z0-9" ".")
+ sed -n \
+ -e "s/^URL: \(.*\)$/remote.$name.url \1 ./p" \
+ -e "s/^Pull: \(.*\)$/remote.$name.fetch \1 ^$ /p" \
+ -e "s/^Push: \(.*\)$/remote.$name.push \1 ^$ /p" \
+ < "$f"
+ done
+ echo done
+ } | while read key value regex; do
+ case $key in
+ done)
+ if [ $error = 0 ]; then
+ mv "$GIT_DIR"/remotes "$GIT_DIR"/remotes.old
+ fi ;;
+ *)
+ echo "git-repo-config $key "$value" $regex"
+ git-repo-config $key "$value" $regex || error=1 ;;
+ esac
+ done
+fi
+
+
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox