* 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
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: David Greaves @ 2005-05-10 9:47 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Matthias Urlichs, Brian Gerst, git
In-Reply-To: <20050510085626.GC8176@lug-owl.de>
Jan-Benedict Glaw wrote:
>On Tue, 2005-05-10 10:36:09 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
>
>
>>Jan-Benedict Glaw:
>>
>>
>>>> find * \( -type f -o tyle l \) -print0 | ...
>>>>
>>>>
>>>Btw, this won't find dot files, so using "." as the path list (instead
>>>of "*") might be wise...
>>>
>>>
>>>
>>git doesn't want to handle dot files anyway.
>>
>>
>
>...which I actually consider to be a bug. Why should git care about the
>filename, as long as it doesn't clash with ".git"? After all, it's just
>a plumbing mechanism designed to locate file contents by SHA-1 hashes.
>It shouldn't deal with file names at all, really:-)
>
>
I tend to agree that a generic 'content tracking system' shouldn't
impose this kind of rule.
Requiring well formed filenames (eg no //, no trailing /s) is fine - but
dot-file-discrimination?
When I first saw it, I expected this kind of rule to (eventually) be
lifted from the plumbing to the porcelain. The minor problem is that
Linus seems to like getting his hands dirty and keeps using the plumbing ;)
(eek - these analogies...)
David
--
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 9:45 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510093924.GH11221@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
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.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 9:39 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510093212.GD8176@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi,
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.
FWIW, I keep important files backed up (backuppc is your friend).
No need to bother with an SCM for that.
--
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
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gerst, Matthias Urlichs, git
In-Reply-To: <7vis1rpi8a.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Tue, 2005-05-10 02:01:41 -0700, Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "JBG" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>
> >> find * \( -type f -o tyle l \) -print0 | ...
>
> JBG> Btw, this won't find dot files, so using "." as the path list (instead
> JBG> of "*") might be wise...
>
> Huh? Since when GIT started managing paths whose _any_ of their
> path component starts with a dot?
The Catholic Church never ever had female priests, so how could this
be a good thing?
Ever thought about keeping some important files (of your $HOME) in some
SCM? For sure, some of those are dot files:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Junio C Hamano @ 2005-05-10 9:01 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Brian Gerst, Matthias Urlichs, git
In-Reply-To: <20050510080445.GB8176@lug-owl.de>
>>>>> "JBG" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>> find * \( -type f -o tyle l \) -print0 | ...
JBG> Btw, this won't find dot files, so using "." as the path list (instead
JBG> of "*") might be wise...
Huh? Since when GIT started managing paths whose _any_ of their
path component starts with a dot?
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 8:56 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Brian Gerst, git
In-Reply-To: <20050510083609.GF11221@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Tue, 2005-05-10 10:36:09 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Jan-Benedict Glaw:
> > > find * \( -type f -o tyle l \) -print0 | ...
> >
> > Btw, this won't find dot files, so using "." as the path list (instead
> > of "*") might be wise...
> >
> git doesn't want to handle dot files anyway.
...which I actually consider to be a bug. Why should git care about the
filename, as long as it doesn't clash with ".git"? After all, it's just
a plumbing mechanism designed to locate file contents by SHA-1 hashes.
It shouldn't deal with file names at all, really:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- 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