* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: David Mansfield @ 2005-05-10 21:31 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Jan-Benedict Glaw, Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510095825.GI11221@kiste.smurf.noris.de>
Matthias Urlichs wrote:
> Hi,
>
> Jan-Benedict Glaw:
>
>>>Please don't change that without talking to Linus.
>>
>>I won't. You haven't seen a patch from me "fixing" this, too. *I*
>>consider this as a defect, but that doesn't mean that I'll force others
>>to take this view, too. But maybe I'll talk Linus into this when he's
>>back from his trip.
>
>
> That would be a good idea; I do support dropping (or at least relaxing)
> that rule. For excluding unwanted files, I'd suggest using a .git/ignore
> file with nice shiny patterns (*.a *.o *.swp ...) inside -- git already
> supports that anyway.
>
Speaking of which, for a large project, (such as the kernel) it is a
pain in the butt if exclude lists only consider the 'basename' of the
file, and cannot include any path matching information.
For a long time there were generated files in the kernel which had the
same names as non-generated files somewhere else in the kernel tree
(under a different path). Making an automated 'take latest patch from
Linus, apply, commit' was really a pain because of this.
Is there/will there be support for path matching in the ignore files?
If the answer is no, but people like the idea, I could look into it.
David
^ permalink raw reply
* Re: Core and Not-So Core
From: Diego Calleja @ 2005-05-10 21:45 UTC (permalink / raw)
To: eduardo; +Cc: dwmw2, jon, git
In-Reply-To: <26021.200.158.14.67.1115741989.squirrel@www.tendencies.com.br>
El Tue, 10 May 2005 13:19:49 -0300 (BRT),
"Eduardo Teixeira Dias" <eduardo@tendencies.com.br> escribió:
> - Just a .jar download
> - Installation without external dependencies
Someone who is going to hack the kernel can very well install more things.
And anyway, git is "the linux SCM tool" so all distros will package it. Also,
people who hacks the linux kernel usually runs it, so "git is not ported
to win32" is not a big problem.
...and I don't think people who use eclipse wants to have the fastest tool
on earth, so "java-invoking-C is slower than pure java" is not a great excuse
either...
Code reuse == good. Java programmers should know that. Anyway, people
is free to do whatever they want with their time :)
^ permalink raw reply
* [PATCH 4/4] split core-git.txt and update
From: David Greaves @ 2005-05-10 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing Lists
Makefile for html and man
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit 9b651818abae168f7e0dbfafda81c9a4298ea410
tree 4e3b4488b60547a6c90e8aefebb1befea26e0402
parent 6cec96ce19223f1852a12632ad44007822e2a3de
author David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:20:25 +0100
committer David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:20:25 +0100
Documentation/Makefile | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+)
Index: Documentation/Makefile
===================================================================
--- /dev/null (tree:0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c)
+++ 4e3b4488b60547a6c90e8aefebb1befea26e0402/Documentation/Makefile (mode:100644)
@@ -0,0 +1,24 @@
+DOC_SRC=$(wildcard git*.txt)
+DOC_HTML=$(patsubst %.txt,%.html,$(DOC_SRC))
+DOC_MAN=$(patsubst %.txt,%.1,$(DOC_SRC))
+
+all: $(DOC_HTML) $(DOC_MAN)
+
+html: $(DOC_HTML)
+
+man: $(DOC_MAN)
+
+git-%: %.c $(LIB_FILE)
+ $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
+
+clean:
+ rm -f *.xml *.html *.1
+
+%.html : %.txt
+ asciidoc -b css-embedded -d manpage $<
+
+%.1 : %.xml
+ xmlto man $<
+
+%.xml : %.txt
+ asciidoc -b docbook -d manpage $<
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* [PATCH 3/4] split core-git.txt and update
From: David Greaves @ 2005-05-10 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing Lists
Update git environment variable docs
Update first section of command docs (Manipulation commands section)
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit 6cec96ce19223f1852a12632ad44007822e2a3de
tree 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c
parent ce5e04ff2f337c625ab070315b4f4f9d309f635e
author David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:19:50 +0100
committer David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:19:50 +0100
Documentation/git-check-files.txt | 4 +
Documentation/git-commit-tree.txt | 9 ++-
Documentation/git-diff-tree-helper.txt | 4 +
Documentation/git-init-db.txt | 3 +
Documentation/git-ls-files.txt | 4 +
Documentation/git-mktag.txt | 23 ++++++-
Documentation/git-read-tree.txt | 6 +-
Documentation/git.txt | 95 +++++++++++++++++++++++++++++----
8 files changed, 128 insertions(+), 20 deletions(-)
Index: Documentation/git-check-files.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-check-files.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-check-files.txt (mode:100644)
@@ -31,7 +31,9 @@
Exits with a status code indicating success if all files are
up-to-date.
-see also: link:git-update-cache.html[git-update-cache]
+See Also
+--------
+link:git-update-cache.html[git-update-cache]
Author
Index: Documentation/git-commit-tree.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-commit-tree.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-commit-tree.txt (mode:100644)
@@ -64,7 +64,14 @@
entry is not provided via '<' redirection, "git-commit-tree" will just wait
for one to be entered and terminated with ^D
-see also: link:git-write-tree.html[git-write-tree]
+Diagnostics
+-----------
+You don't exist. Go away!::
+ The passwd(5) gecos field couldn't be read
+
+See Also
+--------
+link:git-write-tree.html[git-write-tree]
Author
Index: Documentation/git-diff-tree-helper.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-diff-tree-helper.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-diff-tree-helper.txt (mode:100644)
@@ -30,7 +30,9 @@
+
would show a diff to bring the working file back to what is in the <tree>.
-See also the section on generating patches in link:git-diff-cache.html[git-diff-cache]
+See Also
+--------
+The section on generating patches in link:git-diff-cache.html[git-diff-cache]
Author
Index: Documentation/git-init-db.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-init-db.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-init-db.txt (mode:100644)
@@ -16,6 +16,9 @@
This simply creates an empty git object database - basically a `.git`
directory and `.git/object/??/` directories.
+If the 'GIT_DIR' environment variable is set then it specifies a path
+to use instead of `./.git` for the base of the repository.
+
If the object storage directory is specified via the 'GIT_OBJECT_DIRECTORY'
environment variable then the sha1 directories are created underneath -
otherwise the default `.git/objects` directory is used.
Index: Documentation/git-ls-files.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-ls-files.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-ls-files.txt (mode:100644)
@@ -83,7 +83,9 @@
the user (or Cogito) to see what should eventually be recorded at the
path. (see read-cache for more information on state)
-see also: link:read-cache.html[read-cache]
+See Also
+--------
+link:read-cache.html[read-cache]
Author
Index: Documentation/git-mktag.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-mktag.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-mktag.txt (mode:100644)
@@ -9,12 +9,29 @@
SYNOPSIS
--------
-'git-mktag'
+'git-mktag' < signature_file
DESCRIPTION
-----------
-Reads a tag contents from its standard input and creates a tag object.
-The input must be a well formed tag object.
+Reads a tag contents on standard input and creates a tag object
+that can also be used to sign other objects.
+
+The output is the new tag's <object> identifier.
+
+Tag Format
+----------
+A tag signature file has a very simple fixed format: three lines of
+
+ object <sha1>
+ type <typename>
+ tag <tagname>
+
+followed by some 'optional' free-form signature that git itself
+doesn't care about, but that can be verified with gpg or similar.
+
+The size of the full object is artificially limited to 8kB. (Just
+because I'm a lazy bastard, and if you can't fit a signature in that
+size, you're doing something wrong)
Author
Index: Documentation/git-read-tree.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git-read-tree.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git-read-tree.txt (mode:100644)
@@ -14,7 +14,7 @@
DESCRIPTION
-----------
Reads the tree information given by <tree> into the directory cache,
-but does not actually _update_ any of the files it "caches". (see:
+but does not actually *update* any of the files it "caches". (see:
git-checkout-cache)
Optionally, it can merge a tree into the cache or perform a 3-way
@@ -133,7 +133,9 @@
worry about what is in the working directory, since it is never shown
and never used.
-see also: link:git-write-tree.html[git-write-tree], link:git-ls-files.html[git-ls-files]
+See Also
+--------
+link:git-write-tree.html[git-write-tree]; link:git-ls-files.html[git-ls-files]
Author
Index: Documentation/git.txt
===================================================================
--- 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git.txt (mode:100644)
+++ 0b343ac5a1a6f8d6a4cb796c523ef84bf7e7254c/Documentation/git.txt (mode:100644)
@@ -190,6 +190,44 @@
Indicates a filename - always relative to the root of
the tree structure GIT_INDEX_FILE describes.
+Symbolic Identifiers
+--------------------
+Any git comand accepting any <object> can also use the following symbolic notation:
+
+HEAD::
+ indicates the head of the repository (ie the contents of `$GIT_DIR/HEAD`)
+<tag>::
+ a valid tag 'name'+
+ (ie the contents of `$GIT_DIR/refs/tags/<tag>`)
+<head>::
+ a valid head 'name'+
+ (ie the contents of `$GIT_DIR/refs/heads/<head>`)
+<snap>::
+ a valid snapshot 'name'+
+ (ie the contents of `$GIT_DIR/refs/snap/<snap>`)
+
+
+File/Directory Structure
+------------------------
+The git-core manipulates the following areas in the directory:
+
+ .git/ The base (overridden with $GIT_DIR)
+ objects/ The object base (overridden with $GIT_OBJECT_DIRECTORY)
+ ??/ 'First 2 chars of object' directories
+
+It can interrogate (but never updates) the following areas:
+
+ refs/ Directories containing symbolic names for objects
+ (each file contains the hex SHA1 + newline)
+ heads/ Commits which are heads of various sorts
+ tags/ Tags, by the tag name (or some local renaming of it)
+ snap/ ????
+ ... Everything else isn't shared
+ HEAD Symlink to refs/heads/<something>
+
+Higher level SCMs may provide and manage additional information in the
+GIT_DIR.
+
Terminology
-----------
Each line contains terms used interchangeably
@@ -210,17 +248,52 @@
---------------------
Various git commands use the following environment variables:
-- 'GIT_AUTHOR_NAME'
-- 'GIT_AUTHOR_EMAIL'
-- 'GIT_AUTHOR_DATE'
-- 'GIT_COMMITTER_NAME'
-- 'GIT_COMMITTER_EMAIL'
-- 'GIT_DIFF_OPTS'
-- 'GIT_EXTERNAL_DIFF'
-- 'GIT_INDEX_FILE'
-- 'GIT_OBJECT_DIRECTORY'
-- 'GIT_ALTERNATE_OBJECT_DIRECTORIES'
-
+The git Repository
+~~~~~~~~~~~~~~~~~~
+These environment variables apply to 'all' core git commands. Nb: it
+is worth noting that they may be used/overridden by SCMS sitting above
+git so take care if using Cogito etc
+
+'GIT_INDEX_FILE'::
+ This environment allows the specification of an alternate
+ cache/index file. If not specified, the default of
+ `$GIT_DIR/index` is used.
+
+'GIT_OBJECT_DIRECTORY'::
+ If the object storage directory is specified via this
+ environment variable then the sha1 directories are created
+ underneath - otherwise the default `$GIT_DIR/objects`
+ directory is used.
+
+'GIT_ALTERNATE_OBJECT_DIRECTORIES'::
+ Due to the immutable nature of git objects, old objects can be
+ archived into shared, read-only directories. This variable
+ specifies a ":" seperated list of git object directories which
+ can be used to search for git objects. New objects will not be
+ written to these directories.
+
+'GIT_DIR'::
+ If the 'GIT_DIR' environment variable is set then it specifies
+ a path to use instead of `./.git` for the base of the
+ repository.
+
+git Commits
+~~~~~~~~~~~
+'GIT_AUTHOR_NAME'::
+'GIT_AUTHOR_EMAIL'::
+'GIT_AUTHOR_DATE'::
+'GIT_COMMITTER_NAME'::
+'GIT_COMMITTER_EMAIL'::
+ see link:git-commit-tree.html[git-commit-tree]
+
+git Diffs
+~~~~~~~~~
+GIT_DIFF_OPTS::
+GIT_EXTERNAL_DIFF::
+ see the "generating patches" section in :
+ link:git-diff-cache.html[git-diff-cache];
+ link:git-diff-files.html[git-diff-files];
+ link:git-diff-tree.html[git-diff-tree]
Author
------
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: H. Peter Anvin @ 2005-05-10 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Allen, git
In-Reply-To: <7vekceyeo9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"HPA" == H Peter Anvin <hpa@zytor.com> writes:
>
>
> HPA> That being said, there are also a whole bunch of assumptions that any
> HPA> object can be memory-mapped *plus* fit uncompressed in
> HPA> memory... that's obviously not going to be the case for large files.
>
> HPA> On the other hand, one has to start cleaning up somewhere...
>
> I agree to that, but on the other hand one also has to know
> where to stop. The primary purpose of GIT being to manage the
> source files for the Linux kernel project, not worrying about
> _huge_ files that would cause mmap+uncompressed or st.st_size
> not fitting in unsigned long may just be fine.
>
Using the correct data types is a good start, though.
-hpa
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Junio C Hamano @ 2005-05-10 21:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Mark Allen, git
In-Reply-To: <4280CAC6.4000805@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> That being said, there are also a whole bunch of assumptions that any
HPA> object can be memory-mapped *plus* fit uncompressed in
HPA> memory... that's obviously not going to be the case for large files.
HPA> On the other hand, one has to start cleaning up somewhere...
I agree to that, but on the other hand one also has to know
where to stop. The primary purpose of GIT being to manage the
source files for the Linux kernel project, not worrying about
_huge_ files that would cause mmap+uncompressed or st.st_size
not fitting in unsigned long may just be fine.
^ permalink raw reply
* Re: Core and Not-So Core
From: Davide Libenzi @ 2005-05-10 18:01 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc403205051010514cf183e2@mail.gmail.com>
On Wed, 11 May 2005, Jon Seymour wrote:
> On 5/11/05, Christoph Hellwig <hch@infradead.org> wrote:
>> On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:
>>> I have already explained all the pragmatic reasons for doing a GIT
>>> implementation in Java but you are prepared to ignore all of those
>>> reasons. You have ignored all these reasons rather than lift a finger
>>> to compose a well-reasoned rebuttal.
>>
>> You tried to argue for re-inventing the wheel. Fortunately you are
>> allowed to reinvent the wheel here (which isn't given anymore these
>> days). Just don't expect any support from people who have been burnt
>> by that before. And the Java world is re-inventing the wheel far to
>> often - I suspect that'll be cured when the community gets more mature
>> in a few years..
>>
>
> I am _not_ re-inventing any wheel. Merely building a road through
> different territory upon which the GIT wheel may roll more freely.
Would you mind fixing your mailer before, so that your messages won't
appear as new Subject: every time?
- Davide
^ permalink raw reply
* Core and Not-So Core
From: Jon Seymour @ 2005-05-10 17:51 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc40320505101051207c9ce4@mail.gmail.com>
On 5/11/05, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:
> > I have already explained all the pragmatic reasons for doing a GIT
> > implementation in Java but you are prepared to ignore all of those
> > reasons. You have ignored all these reasons rather than lift a finger
> > to compose a well-reasoned rebuttal.
>
> You tried to argue for re-inventing the wheel. Fortunately you are
> allowed to reinvent the wheel here (which isn't given anymore these
> days). Just don't expect any support from people who have been burnt
> by that before. And the Java world is re-inventing the wheel far to
> often - I suspect that'll be cured when the community gets more mature
> in a few years..
>
I am _not_ re-inventing any wheel. Merely building a road through
different territory upon which the GIT wheel may roll more freely.
Don't get me wrong. I appreciate the UNIX mindset of building small
tools and composing them freely. But the UNIX way isn't the only way
to interact with the world and it is being hopelessly dogmatic to
insist otherwise.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Core and Not-So Core
From: Christoph Hellwig @ 2005-05-10 17:41 UTC (permalink / raw)
To: jon; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <2cfc4032050510103664ebef28@mail.gmail.com>
On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:
> This might surprise you, but everything in the world is not a unix
> command line. Using tools designed for use on a unix command line in a
> highly interactive environment like Eclipse would produce an
> abominably clunky result.
The unix commandline is an highly interactive enviroment aswell,
and supports scripting in addition :)
> I have already explained all the pragmatic reasons for doing a GIT
> implementation in Java but you are prepared to ignore all of those
> reasons. You have ignored all these reasons rather than lift a finger
> to compose a well-reasoned rebuttal.
You tried to argue for re-inventing the wheel. Fortunately you are
allowed to reinvent the wheel here (which isn't given anymore these
days). Just don't expect any support from people who have been burnt
by that before. And the Java world is re-inventing the wheel far to
often - I suspect that'll be cured when the community gets more mature
in a few years..
> Instead you cling to a dogmatic insistence that GIT respositories only
> be accessed via the C toolsets.
The C toolchain is a well-defined interface. One that makes a lot
of sense.
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-10 17:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1115745912.16187.468.camel@hades.cambridge.redhat.com>
On 5/11/05, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2005-05-11 at 03:15 +1000, Jon Seymour wrote:
> > David, I have nothing whatsoever to do with the Eclipse implementation
> > of SSH, so what exactly is your point?
>
> That all programmers of _any_ persuasion who want to reimplement the
> world in their own language instead of using existing tools are
> fundamentally brain-damaged.
>
> I'd say the same if the KDevelop people wanted to rewrite git and ssh in
> C++, too.
>
> I don't think that's such a childish observation, surely? Piecing
> together tools which do one thing, and do it well, is part of the UNIX
> philosophy.
This might surprise you, but everything in the world is not a unix
command line. Using tools designed for use on a unix command line in a
highly interactive environment like Eclipse would produce an
abominably clunky result.
Presumably you think this is the Unix way.
I have already explained all the pragmatic reasons for doing a GIT
implementation in Java but you are prepared to ignore all of those
reasons. You have ignored all these reasons rather than lift a finger
to compose a well-reasoned rebuttal.
Instead you cling to a dogmatic insistence that GIT respositories only
be accessed via the C toolsets.
David, you are being extremely childish and extremely dogmatic. Why bother?
jon
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Core and Not-So Core
From: David Woodhouse @ 2005-05-10 17:25 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc4032050510101553d391b2@mail.gmail.com>
On Wed, 2005-05-11 at 03:15 +1000, Jon Seymour wrote:
> David, I have nothing whatsoever to do with the Eclipse implementation
> of SSH, so what exactly is your point?
That all programmers of _any_ persuasion who want to reimplement the
world in their own language instead of using existing tools are
fundamentally brain-damaged.
I'd say the same if the KDevelop people wanted to rewrite git and ssh in
C++, too.
I don't think that's such a childish observation, surely? Piecing
together tools which do one thing, and do it well, is part of the UNIX
philosophy.
--
dwmw2
^ permalink raw reply
* Core and Not-So Core
From: Jon Seymour @ 2005-05-10 17:15 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205051010151304d88a@mail.gmail.com>
On 5/11/05, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2005-05-11 at 02:22 +1000, Jon Seymour wrote:
> > So, no, it's not a religious issue. If anything, it is being dogmatic
> > to insist that the sacred GIT repository structure only be manipulated
> > by 'C' tools blessed by the hands of Linus.
>
> Given the volatility of the structure -- at least the details if not the
> fundamentals -- it seems bizarre to want to reimplement it rather than
> just using the existing tools.
I did consider wrapping it - I really did. But after thinking about it
for a couple of weeks
I eventually came to the conclusion it would be a sub-optimal solution.
And I don't agree that the structure is volatile. The actual structure
of GIT repository has been rock-solid since Linus reversed the
compression-signature order. Yes, there has been the excellent delta
work that Nicholas has been working on, but a Java version doesn't
need to use that anymore than Linus himself does [ and last time I
checked (the mailing list), Linus was being rather conservative about
that ].
What _has_ been changing at a great rate recently is the behaviour of
the tooling layer.
So, if I want a stable foundation to build my stuff on, basing it on
the output of the C tools would be a huge mistake. No, I think it
would be far safer for me to build my tooling using assumptions that
have proven to be rock-solid over the last few weeks - the structure
of the GIT repository format itself.
>
> This is the same mentality which gives Eclipse a half-arsed SSH
> reimplementation which doesn't behave like normal SSH is configured to
> behave either, right?
>
David, I have nothing whatsoever to do with the Eclipse implementation
of SSH, so what exactly is your point? All Java programmers are
fundamentally brain-damaged? Grow up, please.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Core and Not-So Core
From: David Woodhouse @ 2005-05-10 17:03 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc4032050510092238259b63@mail.gmail.com>
On Wed, 2005-05-11 at 02:22 +1000, Jon Seymour wrote:
> So, no, it's not a religious issue. If anything, it is being dogmatic
> to insist that the sacred GIT repository structure only be manipulated
> by 'C' tools blessed by the hands of Linus.
Given the volatility of the structure -- at least the details if not the
fundamentals -- it seems bizarre to want to reimplement it rather than
just using the existing tools.
This is the same mentality which gives Eclipse a half-arsed SSH
reimplementation which doesn't behave like normal SSH is configured to
behave either, right?
--
dwmw2
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-10 16:22 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <1115739511.16187.432.camel@hades.cambridge.redhat.com>
On 5/11/05, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:
> > I have been experimenting with pure-Java implementation of GIT
> > concepts with a goal of eventually providing plugins to Eclipse to
> > allow the Eclipse GUI to interact with GIT repositories.
>
> It's not April 1st. Why would you want to reimplement it in Java instead
> of just using the existing implementation? Is this a religious issue?
>
Not really - in the Java world, things are simpler if you don't have
to carry around a JNI library - that way, you can just run it wherever
a Java interpreter exists and not worry about
having someone recompiling the JNI part.
A pure-Java implementation will perform better than a
Java-invokes-C-executable approach [ though not, of course, a C-only
approach ].
Another benefit of playing around with a Java abstraction is that I
can more easily experiment with abstractions than I can in C since the
abstraction-facilities of Java more directly support such playing than
does C. So, for example, I can easily create a virtual repository
which layers a local repository over a remote repository and
transparently populates the local repository from the remote
repository "on-demand". Of course, this sort of thing can be done in
C, but it requires much more "work" to set up the abstractions.
You could perhaps argue that the existing 'C' tools in some way
encapsulate access to the repository format. Maybe, but the fact is
the rapid adoption of GIT has already effectively fixed the GIT
repository format in practice so any change in repository format will
require considerable planning anyway - planning that will allow
sufficient time for implementations in other languages to catch up.
So, no, it's not a religious issue. If anything, it is being dogmatic
to insist that the sacred GIT repository structure only be manipulated
by 'C' tools blessed by the hands of Linus.
The concepts in GIT are bigger than the programming language its
toolsets are implemented in.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Core and Not-So Core
From: Eduardo Teixeira Dias @ 2005-05-10 16:19 UTC (permalink / raw)
To: dwmw2; +Cc: eduardo, jon, git
In-Reply-To: <1115740844.16187.445.camel@hades.cambridge.redhat.com>
> On Tue, 2005-05-10 at 12:50 -0300, Eduardo Teixeira Dias wrote:
>> He want's to make an eclipce plugin...
>
> And there's no way for him to call execve()?
>
> Hell, even the lisp nutters manage to make emacs invoke external
> programs occasionally. What makes Java programmers so much less sane?
>
> --
> dwmw2
Good point!
It can be done using execxxx().
But a Java version is better for this particular use (Eclipce Plugin):
- Just a .jar download
- Installation without external dependencies
^ permalink raw reply
* Re: Core and Not-So Core
From: David Woodhouse @ 2005-05-10 16:00 UTC (permalink / raw)
To: eduardo; +Cc: jon, git
In-Reply-To: <17115.200.158.14.67.1115740220.squirrel@www.tendencies.com.br>
On Tue, 2005-05-10 at 12:50 -0300, Eduardo Teixeira Dias wrote:
> He want's to make an eclipce plugin...
And there's no way for him to call execve()?
Hell, even the lisp nutters manage to make emacs invoke external
programs occasionally. What makes Java programmers so much less sane?
--
dwmw2
^ permalink raw reply
* Re: Core and Not-So Core
From: Eduardo Teixeira Dias @ 2005-05-10 15:50 UTC (permalink / raw)
To: dwmw2; +Cc: jon, git, torvalds
In-Reply-To: <1115739511.16187.432.camel@hades.cambridge.redhat.com>
He want's to make an eclipce plugin...
This must be done in Java.
> On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:
>> I have been experimenting with pure-Java implementation of GIT
>> concepts with a goal of eventually providing plugins to Eclipse to
>> allow the Eclipse GUI to interact with GIT repositories.
>
> It's not April 1st. Why would you want to reimplement it in Java instead
> of just using the existing implementation? Is this a religious issue?
>
> --
> dwmw2
>
> -
> 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
--
----------------------------
Eduardo Teixeira Dias
Tendencies Consultoria
Tel/Fax: +55 11 3828-1281
http://www.tendencies.com.br
^ permalink raw reply
* Re: Core and Not-So Core
From: David Woodhouse @ 2005-05-10 15:38 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <2cfc40320505100800426d38ca@mail.gmail.com>
On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:
> I have been experimenting with pure-Java implementation of GIT
> concepts with a goal of eventually providing plugins to Eclipse to
> allow the Eclipse GUI to interact with GIT repositories.
It's not April 1st. Why would you want to reimplement it in Java instead
of just using the existing implementation? Is this a religious issue?
--
dwmw2
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: H. Peter Anvin @ 2005-05-10 15:14 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Matthias Urlichs, Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510094538.GE8176@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Tue, 2005-05-10 11:39:24 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
>
>>Jan-Benedict Glaw:
>>
>>>Ever thought about keeping some important files (of your $HOME) in some
>>>SCM? For sure, some of those are dot files:-)
>>
>>Yeah, but so are various local temporary files.
>>
>>Please don't change that without talking to Linus.
>
>
> I won't. You haven't seen a patch from me "fixing" this, too. *I*
> consider this as a defect, but that doesn't mean that I'll force others
> to take this view, too. But maybe I'll talk Linus into this when he's
> back from his trip.
>
Another vote for fixing this!
-hpa
^ permalink raw reply
* Core and Not-So Core
From: Jon Seymour @ 2005-05-10 15:00 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds
I have been experimenting with pure-Java implementation of GIT
concepts with a goal of eventually providing plugins to Eclipse to
allow the Eclipse GUI to interact with GIT repositories.
One thing I noticed when doing this is that the present index/cache
structure is rather arbitrary and the optimum index structure is
determined by the structure of the tools that use a GIT repository
rather than the structure of the GIT repository itself.
To give a concrete example: the cache currently contains most of the
posix stat structure primarily to allow quick change detection. In the
Java world, most of the posix stat structure is not directly
accessible via the pure-Java file system abstractions. However, for
most purposes detecting changes to files modification time and file
size would be enough. Given this is the case, a Java-GIT client
doesn't need to bother getting access to a posix stat structure and
could therefore get away with a simpler index structure, provided it
doesn't need to interoperate with a 'C'-GIT client that shared the
same workspace. A Java-GIT client might also choose to represent an
index cache as a complex serialized Java object graph or (perhaps) an
XML document.
Another example: I can imagine a variant of the index file structure
that recorded all the parents which have been merged into the cache
and automatically include this information when performing the commit.
The point is that many different index file structures are possible
and will be determined in part by the tooling created in the porcelain
layer - there really is no one true index file format as there is a
one true repository format. Different tools can use different index
file formats and still interoperate at the repository level because
only the repository format needs to have a solid, unchanging
definition.
Currently the GIT stack is structured as follows:
cogito
git-core
I think it would be worthwhile if care was taken to draw a distinction
between the repository and the cache aspects of the git core, perhaps
even going to the extreme of moving all knowledge of the cache into
cogito itself. By clearly drawing this distinction, we will more
easily enable the creation of different kind of tools sets atop the
foundation of the GIT repository format.
e.g., either:
cogito
git-cache
git-respository
or:
cogito-tools
cogito-cache
git-repository
Anyway, I offer this as food for thought - chew or flame away as appropriate!
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: H. Peter Anvin @ 2005-05-10 14:52 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Mark Allen, git
In-Reply-To: <4280C883.6080209@zytor.com>
H. Peter Anvin wrote:
> Junio C Hamano wrote:
>
>>
>> HPA> This is just plain WRONG. st.st_size is longer than long on many
>> HPA> architectures, including Linux/i386.
>>
>> HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
>> HPA> and cast it to (intmax_t). That is, however, a C99-ism.
>>
>> Actually the easiest way is to stop reporting the size. Nobody
>> else in core GIT reports st.st_size in their error messages.
>>
>> Although I agree with you that what you say about the size of
>> st.st_size is correct, in GIT world view, apparently "unsigned
>> long" is big enough to hold st.st_size all over the code. Would
>> you recommend tackling that assumption as well?
>
> Probably. It's an off_t.
>
That being said, there are also a whole bunch of assumptions that any
object can be memory-mapped *plus* fit uncompressed in memory... that's
obviously not going to be the case for large files.
On the other hand, one has to start cleaning up somewhere...
-hpa
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: H. Peter Anvin @ 2005-05-10 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Allen, git
In-Reply-To: <7vpsvzpolp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> HPA> This is just plain WRONG. st.st_size is longer than long on many
> HPA> architectures, including Linux/i386.
>
> HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
> HPA> and cast it to (intmax_t). That is, however, a C99-ism.
>
> Actually the easiest way is to stop reporting the size. Nobody
> else in core GIT reports st.st_size in their error messages.
>
> Although I agree with you that what you say about the size of
> st.st_size is correct, in GIT world view, apparently "unsigned
> long" is big enough to hold st.st_size all over the code. Would
> you recommend tackling that assumption as well?
Probably. It's an off_t.
-hpa
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Brad Roberts @ 2005-05-10 12:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: Juliusz Chroboczek, Git Mailing List, darcs-devel
In-Reply-To: <Pine.LNX.4.44.0505091549210.2136-100000@bellevue.puremagic.com>
On Mon, 9 May 2005, Brad Roberts wrote:
> Date: Mon, 9 May 2005 15:50:33 -0700 (PDT)
> From: Brad Roberts <braddr@puremagic.com>
> To: Petr Baudis <pasky@ucw.cz>
> Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
> Git Mailing List <git@vger.kernel.org>, darcs-devel@abridgegame.org
> Subject: Re: Darcs-git: a few notes for Git hackers
>
> > > - there's no way to have multiple simultaneous caches, short of
> > > hacking at the values of Git's global variables by hand.
> >
> > See the Brad Robert's patches of Apr 21. I've decided not to apply them
> > since it appears a lot has changed since then and it would be some pain;
> > but they may be a worthy starting point for a more up-to-date patch.
> >
> > --
> > Petr "Pasky" Baudis
>
> Since there's interest, I'll pull tip of your tree and re-do them. I
> haven't bothered todate since no one seemed interested. Do you want them
> piece meal like I did last time or just one big diff?
>
> Later,
> Brad
I wasn't able to finish redoing these against linus tip, but I got most of
it done (patches 1-14 of the original 19):
http://gameboy2.puremagic.com:8090/
rsync://gameboy2.puremagic.com/git/
The second, third, and forth to last changes need a careful review,
they're direct applications of the original patches which were lightly
tested during the first round and nothing other than compile tested in
this round.
I suspect the remaining parts of the original patch series will go in
fairly smoothly. If no one gets to them before tonight I'll finish
it up after work.
Later,
Brad
The commit comments:
Signed-off-by: Brad Roberts <braddr@puremagic.com>
!-------------------------------------------------------------flip-
- remove the no-longer-true comment about the cache being in native byte order
- move the cache_header struct into read-cache.c since it's in internal detail
of the cache, not a publicly accessed element
!-------------------------------------------------------------flip-
Drop the active_cache and active_nr parameters to write_cache
!-------------------------------------------------------------flip-
- Introduce set_cache_entry(ce, pos)
- Migrate update-cache.c, the only place that does a active_cache[pos] = ce to use it
- Migrate all the same style code in read-cache.c to use it also, except for
read_cache itself which is setting up the initial active_cache entries
TODO: rewrite the code that deal with pointers into the active_cache array such as
read-tree.c's merging code.
!-------------------------------------------------------------flip-
Introduce get_cache_entry(int pos) and use it for all trivial calls like:
ce = active_cache[pos]
TODO: rework the non-trivial active_cache manipulations
!-------------------------------------------------------------flip-
remove active_cache_changed from cache.h
!-------------------------------------------------------------flip-
Introduce get_num_cache_entries() and migrate all the trivial callers to it
!-------------------------------------------------------------flip-
Remove active_alloc from cache.h
!-------------------------------------------------------------flip-
Restructure the diff algorythm to use indexes rather than pointer math.
The resulting code is probably a little less efficient but abstracts
the data structure.
!-------------------------------------------------------------flip-
Restructure the write tree algorythm to use indexes rather than moving
the base pointer and reducing the num entries and start using the
cache abstraction apis.
!-------------------------------------------------------------flip-
Move from pointer math to indexes and use the abstractions
!-------------------------------------------------------------flip-
- convert the last caller from touching active_cache directly
- drop active_cache and active_nr from cache.h
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: [RFD] Overlapping projects
From: Sean @ 2005-05-10 12:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0505100040320.30848-100000@iabervon.org>
On Tue, May 10, 2005 12:56 am, Daniel Barkalow said:
> It seems to me like projects like cogito which are based on a core which
> is itself a project and which is also part of other projects would benefit
> from some sort of support.
>
> In particular, it would be nice if Linus could pull the changes to the
> core without getting the wrapper programs at all.
>
> I'm thinking something like having a head for cogito and a head for git in
> the same repository, where the trees for git only have the core files, and
> the commits for cogito have, in addition to a tree with only the
> cogito-specific files, a reference to a git commit that they include.
>
> It seems to me like this area contains a brilliant idea that I haven't
> had so far, and maybe someone can come up with it.
>
That sounds like a great idea and shouldn't need any brilliant ideas to
implement. Just need to push a little more multi-head handling down into
git. The Cogito build process could then include a checkout of the
git-core branch. Would be much cleaner than the way it is handled now.
Sean
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 9:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510094538.GE8176@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi,
Jan-Benedict Glaw:
> > Please don't change that without talking to Linus.
>
> I won't. You haven't seen a patch from me "fixing" this, too. *I*
> consider this as a defect, but that doesn't mean that I'll force others
> to take this view, too. But maybe I'll talk Linus into this when he's
> back from his trip.
That would be a good idea; I do support dropping (or at least relaxing)
that rule. For excluding unwanted files, I'd suggest using a .git/ignore
file with nice shiny patterns (*.a *.o *.swp ...) inside -- git already
supports that anyway.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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