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
#
# is the package name;
# is the number of people who installed this package;
# is the number o
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, t
after so many years of software development (and with the policy of never
having conflicting command names) what three letter combinations are still
avilable?
I'm assuming that the much smaller pool of two letter commands was long
since exhausted, but if not what two letter commands are availa
Also attempt to build a source package for debian.
---
Makefile |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
b263f24ce4f12dd39cfcd922c56a32292c6232c9
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -238,14 +238,14 @@ rpm: dist
deb: dist
rm -rf $(GIT_TA
It long supported -q flag to suppress progress meter without
properly being documented.
---
Documentation/git-unpack-objects.txt |8 +++-
unpack-objects.c |2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
7d4cacb2e5ba94c45c3d5438c1703d0ea80d4ef1
diff --git a
This is a beginning of resurrecting the multi-head pulling support
for git-fetch-pack command. The git-fetch-script wrapper still
only knows about fetching a single head, without renaming, so it is
not very useful unless you directly call git-fetch-pack itself yet.
It also fixes a longstanding ob
In http://www.kernel.org/pub/software/scm/git/, I have placed
the following binary packages:
git-core-0.99.4.tar.gz
git-core-0.99.4-1.i386.rpm
git-core-0.99.4-1.src.rpm
git-core-debuginfo-0.99.4-1.i386.rpm
debian/git-core_0.99.4-2.dsc
debian/git-core_0.99.4-2.tar.gz
debian/git
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
Dear diary, on Fri, Aug 12, 2005 at 11:41:34AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Also attempt to build a source package for debian.
> ---
>
> Makefile |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> b263f24ce4f12dd39cfcd922c56a322
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
For consistency reasons, the names of all scripts should end in "-script".
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
This may be a bit controversial (people might find it unnecessary).
Subject to discussion.
---
Makefile | 15 ---
git-cherry-
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(-)
a72d370d43c397238a26c1c7f260a3fd640
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 *.d
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 th
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Petr Baudis <[EMAIL PROTECTED]> writes:
> >> Yes, but cg-clone doesn't - it naively depended on the core git tools
> >> actually, er.. working. ;-)
>
> Sorry about that. I used to have a wrapper to de
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
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Note the missing "\ No newline at end of file". The same happens on
> sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
> server.
>
> How to go about that? Silently ignore the missing line in apply.c? Force
> users to update th
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 also something in forma
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 ne
Hi,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> writes:
>
> > Note the missing "\ No newline at end of file". The same happens on
> > sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
> > server.
> >
> > How to go about that? Silently
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 thi
On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
> Linus, I need a bit of guidance from you about this one; an
> ancient commit 4f7770c87ce3c302e1639a7737a6d2531fe4b160 removed
> the multi-head support fetch-pack once had, labelling it as "a
> misguided attempt", and I would like to know if I am maki
Hi,
On Fri, 12 Aug 2005, Linus Torvalds wrote:
> Wouldn't it be simpler/cleaner to just do
>
> head=($(git-fetch-pack "$merge_repo" "$merge_head"))
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!
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> 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
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
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
On Fri, 12 Aug 2005, Johannes Schindelin wrote:
>
> I seem to remember Junio does not like bash arrays...
Well, fair enough, although they aren't really "bash" arrays, they
appeared in other shells before "bash".
At least ksh and zsh have them, although the zsh implementation seems to
be pre
I've just got around to noticing some of the new (to
me) features in git, and started experimenting with
branches.
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
> On Wed, Aug 10, 2005 at 03:59:02PM +, Hubert Tonneau wrote:
>
>>The 'V' column on http://www.kernel.org/ is very convienient to review what
>>has changed in a new kernel (files list, then simple clic diff access to the
>>selected file).
>>
>>Now, the git changelog is also interesting (provid
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); the message I received s
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 git-tk_${VER
"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 c
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 mos
On Wed, Aug 10, 2005 at 01:31:13AM -0700, Mitchell Blank Jr wrote:
> Ian Campbell wrote:
> > I used to subscribe to the kernel RSS feed (using blam) but I found I
> > was only getting the most recent 20 commits, which wasn't much good when
> > a big batch went in because I would miss some.
>
> Yes
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 pl
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 Fe
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 /
> > c
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) $(SCR
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 #125286
On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
> I have never liked the original -script name convention. It
> only meant that they are implemented as scripts (as opposed to
> those on the $(PROG) Makefile variable), but the end users who
> end up typing their names from the command line, and to
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 ;-)
> > peo
On Fri, Aug 12, 2005 at 02:55:01PM -0700, Linus Torvalds wrote:
>
> Sure, I could have called it ".sh" instead to make it look even more like
> a shell script thing, but I actually think "-script" describes any
> scripting language - shell, perl, you name it..
See, for example, the history on g
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 realiz
> 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 git-tk_${VERSION}_all.deb, instead
> of whatever architecture I happened to build it?
It is correct to have Architecture: i386, as you'd natu
> > 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
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 project
> - 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:
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
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 s
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.
Hi,
Martin Langhoff:
> It is correct to have Architecture: i386, as you'd naturally have
> multiple binary packages.
However, git(-t)k doesn't contain any i386 code, just a tk script.
> Packages with arch 'all' are interpreted languages.
Exactly. ;-)
--
Matthias Urlichs | {M:U} IT Design
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?
If each developer
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 acc
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, wr
Hi, Junio C Hamano wrote:
> I have been trying, admittably perhaps not very successfully, to
> stay away from bashism in the core GIT scripts.
We should probably use #!/bin/bash for scripts with bashisms...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer:
On Sat, 13 Aug 2005, Petr Baudis wrote:
>
> Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
> 90% of my GIT network activity happens with kernel.org; the rest is with
> my notebook, and I want to keep that ssh.)
Maybe. I don't know what the status of that is, but the pla
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 fi
Hi, Mitchell Blank Jr wrote:
> 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 to the master repository -- suddenly there's, say,
> 400 new commits since the last time my aggregator chec
Gar, got caught by the 'reply-to' going to Tony only...
Dave
--- Begin Message ---
On Fri, Aug 12, 2005 at 10:31:17AM -0700, Luck, Tony wrote:
> I've just got around to noticing some of the new (to
> me) features in git, and started experimenting with
> branches.
Seems a good
On Sat, 13 Aug 2005, Dave Jones wrote:
>
> My git snapshot creator that builds the hourly tarballs at
> http://www.codemonkey.org.uk/projects/git-snapshots/
> currently does an rsync, and then a checkout, and finally
> it cleans up by removing all the checked out files.
> It currently does this b
Linus Torvalds wrote:
BTW, is the pack protocol flexible enough to be extended to support
pushing?
The _protocol_ could handle it, but you obviously need some kind of secure
authentication, and quite frankly, one of the selling points on git-daemon
right now is that it's all read-only and v
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 wi
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 r
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
On Fri, 12 Aug 2005, Linus Torvalds 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".
Btw, I just checked that git-tar-tree is documented and has a man-page. It
does. However, that man-p
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 th
69 matches
Mail list logo
