On Thursday 11 August 2005 23:53, Linus Torvalds wrote:
Hands up people. Does anybody _use_ GNU interactive tools? None of this I
have a package crap.
http://popcon.debian.org/by_inst
#Format
#
#name is the package name;
#inst is the number of people who installed this package;
#vote is the
Hi, Alan Chandler wrote:
Not sure I understand the proper use of dpkg-divert in Debian, but could
_this_ git-core package perhaps ask the user which set of the two
packages he wish to keep as git command and use dpkg-divert to change
the other to another name to some other name?
IIRC,
Hi,
David Lang:
after so many years of software development (and with the policy of never
having conflicting command names) what three letter combinations are still
avilable?
Lots.
I'm assuming that the much smaller pool of two letter commands was long
since exhausted, but if not what
Hi,
big was my surprise when my daily routine of git pull make test
failed. git bisect revealed that commit 8e832e: String comparison of
test is done with '=', not '=='. was the culprit.
But it isn't. The version of diff present on my iBook (OS 10.2.8) does not
work properly in this case:
This adds the option --sign to git-format-patch-script which adds
a Signed-off-by: line automatically.
Signed-off-by: Johannes Schindelin [EMAIL PROTECTED]
---
git-format-patch-script | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
Petr Baudis [EMAIL PROTECTED] writes:
This makes me a bit nervous - why are you making the rules more general?
make clean removing random tarballs of mine happenning to dwell in that
directory is fearsome.
That is a valid concern. I'd drop that *.tar.gz part at
least and probably the *.deb
Johannes Schindelin [EMAIL PROTECTED] writes:
For consistency reasons, the names of all scripts should end in -script.
This may be a bit controversial (people might find it unnecessary).
Subject to discussion.
I have never liked the original -script name convention. It
only meant that they
Good intentions, but I'd rather see these S-O-B lines in the
actual commit objects. Giving format-patch this option would
discourage people to do so. Maybe a patch to git commit would
be more appropriate, methinks.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a
hI,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin [EMAIL PROTECTED] writes:
For consistency reasons, the names of all scripts should end in -script.
This may be a bit controversial (people might find it unnecessary).
Subject to discussion.
I have never liked the
Hi,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
Good intentions, but I'd rather see these S-O-B lines in the
actual commit objects. Giving format-patch this option would
discourage people to do so. Maybe a patch to git commit would
be more appropriate, methinks.
Maybe in addition to this
Johannes Schindelin [EMAIL PROTECTED] writes:
I'd prefer to deprecate that diff program by telling so in the test.
Something along the lines blabla. If this fails, chances are you have a
borked diff. Try GNU diff...
Wouldn't it give the people with broken diff a false impression
that their
Johannes Schindelin [EMAIL PROTECTED] writes:
I seem to remember Junio does not like bash arrays... And in a recent
commit message, he even admits to using something different than bash!
Correct and somewhat misleading. My usual shell is bash but
from time to time I try to run things with
Matthias Urlichs [EMAIL PROTECTED] writes:
- Split gitk off to its own package;
it needs tk installed, but nothing else does.
I just noticed from dpkg --info output that the generated
git-tk has Architecture: i386. Shouldn't it read all and
resulting package also named
Luck, Tony [EMAIL PROTECTED] writes:
I see that when I switch view to a different
branch with:
$ git checkout -f someoldbranch
that any files that exist in my previous branch view
but not in someoldbranch are not deleted.
... I wondered whether this was a deliberate choice
Not
On Wed, Aug 10, 2005 at 06:53:40AM +0100, Ian Campbell wrote:
On Tue, 2005-08-09 at 21:58 +0200, Kay Sievers wrote:
I was hoping people that want stuff like this would use a RSS reader. :)
I used to subscribe to the kernel RSS feed (using blam) but I found I
was only getting the most
Wolfgang Denk [EMAIL PROTECTED] writes:
Has anybody any information if SourceForge is going to provide git /
cogito / ... for the projects they host? I asked SF, and they openend
a new Feature Request (item #1252867); the message I received sounded
as if I was the first person on the planet
On Fri, 12 Aug 2005, Wolfgang Denk wrote:
This is somewhat off topic here, so I apologize, but I didn't know
any better place to ask:
Has anybody any information if SourceForge is going to provide git /
cogito / ... for the projects they host? I asked SF, and they openend
a new Feature
On Fri, Aug 12, 2005 at 04:46:34PM -0400, Daniel Barkalow wrote:
On Fri, 12 Aug 2005, Wolfgang Denk wrote:
This is somewhat off topic here, so I apologize, but I didn't know
any better place to ask:
Has anybody any information if SourceForge is going to provide git /
cogito / ...
Kay Sievers wrote:
It's 30 now and up to 150 if they are not older than 48 hours.
We can change the numbers, if you hava a better idea...
Is it really hard to just make it purely time-based (git-rev-list --max-age)?
Think of if Linus is merging with a lot of people and then pushes the results
Documentation's install target now depends on man since
it installs manpages. It now also installs the .txt files, to
$prefix/share/doc/cogito/txt/ by default. A separate install-html target
was added for installing .html files to $prefix/share/doc/cogito/html/. It
isn't part of the install target
Dear diary, on Fri, Aug 12, 2005 at 11:11:45PM CEST, I got a letter
where Petr Baudis [EMAIL PROTECTED] told me that...
diff --git a/tools/Makefile b/tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -18,7 +18,7 @@ git-%: %.c
all: $(PROGRAMS)
install: $(PROGRAMS) $(SCRIPTS)
-
Wolfgang Denk wrote:
This is somewhat off topic here, so I apologize, but I didn't know
any better place to ask:
Has anybody any information if SourceForge is going to provide git /
cogito / ... for the projects they host? I asked SF, and they openend
a new Feature Request (item #1252867);
In message [EMAIL PROTECTED] you wrote:
The git architecture makes the central server less important, and it's
easy to run your own. Also, kernel.org is providing space to a set of
Yes, cou can - but for a popular project like U-Boot in our case you
don't really want to ;-)
people with
On Fri, 12 Aug 2005, Daniel Barkalow wrote:
The git architecture makes the central server less important, and it's
easy to run your own.
On the other hand:
- the git architecture is admirably suited to an _untrusted_ central
server, ie exactly the SourceForge kind of setup. I realize
I don't think he wants sourceforge to host git, I think he'd like
sourceforge to provide access to source trees via git, instead of
cvs. Read that as, I want to do:
Correct, that's what I am looking for. My hope is that if enough
people ask SF might actually provide such a service.
On Fri, 12 Aug 2005, Linus Torvalds wrote:
And it's possible that git usage won't expand all that much either. But
quite frankly, I think git is a lot better than CVS (or even SVN) by now,
and I wouldn't be surprised if it started getting some use outside of the
git-only and kernel projects
- the git architecture is admirably suited to an _untrusted_ central
server, ie exactly the SourceForge kind of setup. I realize that the
Definitely. And beyond that too. Using SF for CVS means that when SF's
CVS service is down (often enough) you can't commit (or even fscking
diff) until
On Sat, 13 Aug 2005, Martin Langhoff wrote:
Yes, developers can just merge with each other directly
I take it that you mean an exchange of patches that does not depend on
having public repos. What are the mechanisms available on that front,
other than patchbombs?
Just have a shared
git-tk should be architecture independent.
git-core forgot to depend on perl.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
---
Hi,
Junio C Hamano:
Matthias Urlichs [EMAIL PROTECTED] writes:
- Split gitk off to its own package;
it needs tk installed, but nothing else does.
I just
Hello,
I've wondered how slow the protocols other than rsync are, and the
(well, a bit dubious; especially wrt. caching on the remote side)
results are:
git clone-pack:ssh 25s
git rsync 27s
git http-pull 47s
git dumb-http
On Sat, 13 Aug 2005, Petr Baudis wrote:
Anyway, clone-pack is a clear winner for networks (but someone should
re-check that, especially compared to rsync, wrt. server-side file
caching); really cool fast, but not very practical for anonymous access.
git-daemon is for the anonymous access
Dear diary, on Sat, Aug 13, 2005 at 04:12:26AM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Sat, 13 Aug 2005, Petr Baudis wrote:
Anyway, clone-pack is a clear winner for networks (but someone should
re-check that, especially compared to rsync, wrt.
On Fri, Jul 29, 2005 at 08:10:51AM +, Petr Baudis wrote:
Exactly. I want much more freedom in pushing, the only requirement being
that the to-be-replaced remote head is ancestor of the to-be-pushed
local head. I think (am I wrong?) git-send-pack localhead:remotehead
would work just fine
Petr Baudis wrote:
In my tests, the git daemon was noticeably faster than ssh, if only
because the authentication actually tends to be a big part of the overhead
in small pulls.
Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
90% of my GIT network activity happens
On Fri, 12 Aug 2005, H. Peter Anvin wrote:
Running it over ssh would be a good way to do authentication...
Well, if you have ssh as an option, you don't need git-daemon any more,
since the protocol that git-daemon does runs quite well over ssh on its
own...
The only point of git-daemon
On Fri, Aug 12, 2005 at 10:05:11PM -0700, Linus Torvalds wrote:
HOWEVER, if all you want to do is just a tar-file, then there's a better
solution. It's called
snap=git-snapshot-$(date +%Y%m%d)
git-tar-tree HEAD $snap | gzip -9 $snap.tar.gz
which is even easier, and a
On Sat, 13 Aug 2005, Dave Jones wrote:
Git actually has a _lot_ of nifty tools. I didn't realize that people
didn't know about such basic stuff as git-tar-tree and git-ls-files.
Maybe its because things are moving so fast :) Or maybe I just wasn't
paying attention on that day. (I
37 matches
Mail list logo