* [PATCH] Fix cg-commit to handle files with leading '-'
From: Jonas Fonseca @ 2005-05-11 0:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
Hi Pasky,
cg-commit dies with "update-cache failed" message when adding files
beginning with a '-' because the '--' arg is missing.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--
Jonas Fonseca
[-- Attachment #2: fix-cg-commit.patch --]
[-- Type: text/plain, Size: 728 bytes --]
Index: cg-commit
===================================================================
--- 673ad20e23591a8e5bdf18a755a5dea1755b7bf6/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -140,13 +140,13 @@
if [ ! "$ignorecache" ]; then
if [ "$customfiles" ]; then
- git-update-cache --add --remove "${commitfiles[@]}" \
+ git-update-cache --add --remove -- "${commitfiles[@]}" \
|| die "update-cache failed"
export GIT_INDEX_FILE=$(mktemp -t gitci.XXXXXX)
git-read-tree HEAD
fi
# TODO: Do the proper separation of adds, removes, and changes.
- git-update-cache --add --remove "${commitfiles[@]}" \
+ git-update-cache --add --remove -- "${commitfiles[@]}" \
|| die "update-cache failed"
fi
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-11 0:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <20050510225235.GD26384@pasky.ji.cz>
On 5/11/05, Petr Baudis <pasky@ucw.cz> wrote:
> Dear diary, on Tue, May 10, 2005 at 05:00:33PM CEST, I got a letter
> where Jon Seymour <jon.seymour@gmail.com> told me that...
>
> Yes. And that's how it should be - the directory cache is just that - a
> _cache_.
No argument there.
> So unlike the objects database which has well-defined format and is
> supposed to be "public", you should view the directory cache as internal
> git tools' structure. If you want to mess with it too, either use the
> proper level of abstraction and call the git tools, or don't mess with
> it at all. And you need to care about it only if you want the git tools
> working on the same tree properly too - so in that case use the git
> tools too.
I agree in principle, though I'd like users to be able to easily
switch between the Eclipse and git tools view of the workspace if they
want to - who am I to say how a user should work? Eclipse does this
kind of thing quite well with CVS precisely because it shares the
workspace structures with the CVS command line tools rather than
"re-inventing" the wheel. Yes, separation of concerns has been lost
(two implementations of a CVS client), but the big win is that the
tools behave like the user wants them to behave.
The trickiest case here is when the user switches between toolsets
mid-merge. I guess what I can do is this:
user switch from eclipse -> to git-tools:
1. blow away existing git tools index
2. use git-read-tree to repeat the merge executed in eclipse (my
workspace will track parents)
3. use git-update-cache --add/--remove to reflect merge actions
that have occurred since the workspace deviated from the HEAD.
Alternatively, I can just make Eclipse reflect cache changing actions
out onto the git-tools, via an exec of those tools, as and when they
occur.
Making use of the git tools index going the other way isn't so easy to
achieve because the git tools workspace as it stands doesn't track the
merges that have occurred (i.e. which parents were used to form the
current cache). However, that's not necessarily a big problem. I just
rebuild my "cache" from scratch based on the merges I know about and
treat every other difference from the HEAD as a user edit to the
workspace.
>
> From your arguments, it's not clear to me what really is the big
> problem with the git tools. They are _designed_ for automatic use
> instead of human interaction - you can perceive them just as methods
> with funny (but actually friendly to your programs) calling convention.
>
I am not really arguing that there is a big problem with the existing
git tools. However, what I am arguing is that the existing workspace
tools are just one way to manage the workspace (Eclipse might be
another, as an example) and it would be helpful to keep this in mind,
particularly when/if libification ever happens.
jon.
^ permalink raw reply
* Re: Introducing GIT_DIR environment variable.
From: Alex Riesen @ 2005-05-10 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Daniel Barkalow, git
In-Reply-To: <7v8y2nr411.fsf_-_@assigned-by-dhcp.cox.net>
On 5/10/05, Junio C Hamano <junkio@cox.net> wrote:
> Ok, following the mailing list discussion, I've done GIT_DIR and
> pushed it out to the usual git-jc repository, at:
>
> http://members.cox.net/junkio/git-jc.git/
>
> Author: Junio C Hamano <junkio@cox.net>
> Date: Mon May 9 22:57:58 2005 -0700
>
> Introduce GIT_DIR environment variable.
>
Just in case I missed it: was it already considered to use
the extended attributes (EAs) for saving pointer to GIT cache?
So I don't have to exclude anything from "grep -rn <pattern> ."
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-10 23:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050510230844.GG26384@pasky.ji.cz>
On 5/11/05, Petr Baudis <pasky@ucw.cz> wrote:
> Dear diary, on Wed, May 11, 2005 at 01:05:55AM CEST, I got a letter
> where Jon Seymour <jon.seymour@gmail.com> told me that...
> >
> > I guess I agree it is somewhat nonsensical if one considers the
> > current git toolset as a collection of programs - the exercise now
> > might simply reduce to classifying git tools as
> > index-using/non-index-using and nothing more. However, it might be
> > worth keeping in mind when/if the "libification" of git happens so
> > that there is a clean separation of layers in the API between the
> > repository API and index/cache/workspace API.
>
> In that case the repository API's input/output is data structure
> equivalent to the index, and workspace API's input/output is the index
> too. That is what it really is - and it is kept on the disk only since
> the commands are invoked separately so it needs to keep the state around
> somewhere.
>
Not sure I agree...
The repository API would contain functionality equivalent to cat-file,
ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of
the transport code - things that don't involve use of the index.
The workspace API would contain read-tree, write-tree, commit-tree,
etc - things that do involve use of the the index.
jon.
^ permalink raw reply
* Re: Core and Not-So Core
From: Horst von Brand @ 2005-05-10 23:11 UTC (permalink / raw)
To: Diego Calleja; +Cc: eduardo, git
In-Reply-To: <20050511010302.3ab47c74.diegocg@gmail.com>
Diego Calleja <diegocg@gmail.com> said:
> El Tue, 10 May 2005 19:33:14 -0300 (BRT),
> "Eduardo Teixeira Dias" <eduardo@tendencies.com.br> escribió:
> > Write Once Run Everywhere that GCJ Runs (Sounds Good).
> GCJ in fact supports more architectures than Sun's java VM so with GCJ
> you _really_ can run your java code everywhere.
But then again, a half decent C implementation is even more ubicuous, so...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Core and Not-So Core
From: Petr Baudis @ 2005-05-10 23:08 UTC (permalink / raw)
To: Jon Seymour; +Cc: Git Mailing List
In-Reply-To: <2cfc4032050510160578b81fa7@mail.gmail.com>
Dear diary, on Wed, May 11, 2005 at 01:05:55AM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> >
> > > 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.
> >
> > I think this is nonsensical. The cache format is tied to the way in which
> > the repository accessing code is written, so a git-core separate from the
> > cache wouldn't have a useful set of code.
> >
>
> I guess I agree it is somewhat nonsensical if one considers the
> current git toolset as a collection of programs - the exercise now
> might simply reduce to classifying git tools as
> index-using/non-index-using and nothing more. However, it might be
> worth keeping in mind when/if the "libification" of git happens so
> that there is a clean separation of layers in the API between the
> repository API and index/cache/workspace API.
In that case the repository API's input/output is data structure
equivalent to the index, and workspace API's input/output is the index
too. That is what it really is - and it is kept on the disk only since
the commands are invoked separately so it needs to keep the state around
somewhere.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-10 23:05 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc40320505101605721420@mail.gmail.com>
>
> > 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.
>
> I think this is nonsensical. The cache format is tied to the way in which
> the repository accessing code is written, so a git-core separate from the
> cache wouldn't have a useful set of code.
>
I guess I agree it is somewhat nonsensical if one considers the
current git toolset as a collection of programs - the exercise now
might simply reduce to classifying git tools as
index-using/non-index-using and nothing more. However, it might be
worth keeping in mind when/if the "libification" of git happens so
that there is a clean separation of layers in the API between the
repository API and index/cache/workspace API.
> It might be worthwhile to produce a separate document describing the
> repository format, such that it could be accessed by different code,
> however. Of course, the index file wouldn't be part of this documentation,
> for the same reason that the public git repositories don't include index
> files.
>
And thanks for your constructive criticism.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Petr Baudis @ 2005-05-10 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, GIT Mailing List, Linus Torvalds
In-Reply-To: <7vr7gewuxt.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, May 11, 2005 at 12:57:34AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "MW" == Morten Welinder <mwelinder@gmail.com> writes:
>
> MW> git-checkout-cache is having problems when files change from directories to
> MW> plain files or vice versa. cg-seek seems to be similarly affected.
>
> Could you give this patch a try? It lets checkout-cache remove
> a file where you want to have a directory (because you want to
> create something underneath) or remove a whole subdirectory
> where you want to have a non-directory, when '-f' parameter is
> specified.
>
> If things test well, I'll put this in the git-jc repository and
> ask Linus to pull from it alongside with other accumulated
> patches when he returns.
Chilling.
What if you have some files not tracked by git in the subdirectory?
Either you need to check for this and deal with it (Cogito's approach
would be to remove the git-tracked files and rename the subdirectory),
or not do it at all. Or at least please use -F or something if you
really want this and like to gamble.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Core and Not-So Core
From: Diego Calleja @ 2005-05-10 23:03 UTC (permalink / raw)
To: eduardo; +Cc: git
In-Reply-To: <58433.200.158.14.67.1115764394.squirrel@www.tendencies.com.br>
[somewhat OT]
El Tue, 10 May 2005 19:33:14 -0300 (BRT),
"Eduardo Teixeira Dias" <eduardo@tendencies.com.br> escribió:
> Write Once Run Everywhere that GCJ Runs (Sounds Good).
GCJ in fact supports more architectures than Sun's java VM so with GCJ you _really_
can run your java code everywhere.
^ permalink raw reply
* Re: Core and Not-So Core
From: James Purser @ 2005-05-10 23:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Diego Calleja, eduardo, dwmw2, jon, git
In-Reply-To: <20050510224433.GC26384@pasky.ji.cz>
On Wed, 2005-05-11 at 08:44, Petr Baudis wrote:
> Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter
> where Diego Calleja <diegocg@gmail.com> told me that...
> > 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.
>
> It's not like everything git is ever going to be used for is kernel and
> only the kernel.
So does this mean I can keep working on my wxWidgets implementation? :)
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-10 22:57 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List, Linus Torvalds
In-Reply-To: <118833cc05050911255e601fc@mail.gmail.com>
>>>>> "MW" == Morten Welinder <mwelinder@gmail.com> writes:
MW> git-checkout-cache is having problems when files change from directories to
MW> plain files or vice versa. cg-seek seems to be similarly affected.
Could you give this patch a try? It lets checkout-cache remove
a file where you want to have a directory (because you want to
create something underneath) or remove a whole subdirectory
where you want to have a non-directory, when '-f' parameter is
specified.
If things test well, I'll put this in the git-jc repository and
ask Linus to pull from it alongside with other accumulated
patches when he returns.
Thanks.
Signed-off-by: Junio C Hamano <junkio@cox.net>
------------
# - HEAD: Adjust quoting styles for some environment variables in the documentation.
# + 7: Let checkout-cache stomp on existing file/directory with -f.
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -32,6 +32,8 @@
* of "-a" causing problems (not possible in the above example,
* but get used to it in scripting!).
*/
+#include <sys/types.h>
+#include <dirent.h>
#include "cache.h"
static int force = 0, quiet = 0, not_new = 0;
@@ -46,11 +48,51 @@ static void create_directories(const cha
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
- mkdir(buf, 0755);
+ if (mkdir(buf, 0755)) {
+ if (errno == EEXIST) {
+ struct stat st;
+ if (!lstat(buf, &st) && S_ISDIR(st.st_mode))
+ continue; /* ok */
+ if (force && !unlink(buf) && !mkdir(buf, 0755))
+ continue;
+ }
+ die("cannot create directory at %s", buf);
+ }
}
free(buf);
}
+static void remove_subtree(const char *path)
+{
+ DIR *dir = opendir(path);
+ struct dirent *de;
+ char pathbuf[PATH_MAX];
+ char *name;
+
+ if (!dir)
+ die("cannot opendir %s", path);
+ strcpy(pathbuf, path);
+ name = pathbuf + strlen(path);
+ *name++ = '/';
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st;
+ if (de->d_name[0] == '.')
+ continue; /* we mean . and .. but verify_path would
+ * have rejected any dotfiles earlier.
+ */
+ strcpy(name, de->d_name);
+ if (lstat(pathbuf, &st))
+ die("cannot lstat %s", pathbuf);
+ if (S_ISDIR(st.st_mode))
+ remove_subtree(pathbuf);
+ else if (unlink(pathbuf))
+ die("cannot unlink %s", pathbuf);
+ }
+ closedir(dir);
+ if (rmdir(path))
+ die("cannot rmdir %s", path);
+}
+
static int create_file(const char *path, unsigned int mode)
{
int fd;
@@ -62,6 +104,14 @@ static int create_file(const char *path,
create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
}
+ else if (errno == EISDIR && force) {
+ remove_subtree(path);
+ fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
+ }
+ else if (errno == ENOTDIR && force) {
+ create_directories(path);
+ fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
+ }
}
return fd;
}
^ permalink raw reply
* Re: Core and Not-So Core
From: Andreas Gal @ 2005-05-10 22:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: Diego Calleja, eduardo, dwmw2, jon, git
In-Reply-To: <20050510224433.GC26384@pasky.ji.cz>
Btw, I rewrote about 90% of git in python, just out of curiousity.
Performance is pretty competitive, and I can optimize certain operations
by keeping the index in memory temporarily. It also saves a lot of output
parsing, simplifies error-handling (if the frontend is written in python
too, which bit now is), and the best of all: its about 600 lines of python
code. I am all for a Java implementation. After its done we will see
whether it works and how well it works. We can still throw it away if it
sucks.
Andreas
On Wed, 11 May 2005, Petr Baudis wrote:
> Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter
> where Diego Calleja <diegocg@gmail.com> told me that...
> > 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.
>
> It's not like everything git is ever going to be used for is kernel and
> only the kernel.
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Core and Not-So Core
From: Petr Baudis @ 2005-05-10 22:52 UTC (permalink / raw)
To: Jon Seymour; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <2cfc40320505100800426d38ca@mail.gmail.com>
Dear diary, on Tue, May 10, 2005 at 05:00:33PM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> 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.
Yes. And that's how it should be - the directory cache is just that - a
_cache_. It does not hold any permanent information, merely serves to
record git tools' working state relative to the given working tree. So
unlike the objects database which has well-defined format and is
supposed to be "public", you should view the directory cache as internal
git tools' structure. If you want to mess with it too, either use the
proper level of abstraction and call the git tools, or don't mess with
it at all. And you need to care about it only if you want the git tools
working on the same tree properly too - so in that case use the git
tools too.
From your arguments, it's not clear to me what really is the big
problem with the git tools. They are _designed_ for automatic use
instead of human interaction - you can perceive them just as methods
with funny (but actually friendly to your programs) calling convention.
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Core and Not-So Core
From: Petr Baudis @ 2005-05-10 22:44 UTC (permalink / raw)
To: Diego Calleja; +Cc: eduardo, dwmw2, jon, git
In-Reply-To: <20050510234501.79eea7a4.diegocg@gmail.com>
Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter
where Diego Calleja <diegocg@gmail.com> told me that...
> 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.
It's not like everything git is ever going to be used for is kernel and
only the kernel.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Core and Not-So Core
From: Eduardo Teixeira Dias @ 2005-05-10 22:34 UTC (permalink / raw)
To: diegocg; +Cc: eduardo, dwmw2, jon, git
In-Reply-To: <20050510234501.79eea7a4.diegocg@gmail.com>
I'm a Java programmer and I was thinking like one (Culture thing).
The reuse argument is very Strong.
The git-core are ready and it's a very good idea to reuse it. Any change
in the core or in the internal representation of git repository will
benefit the Git-Java implementation...
I think that a growing utilization of GCJ and ClassPath will contribute to
a Gradual Culture Change in the Java Land and promote a beter
reutilization among all GCC languages...
Write Once Run Everywhere that GCJ Runs (Sounds Good).
Eclipse will be compiled with GCJ in Fedora 4. Let's see how it works...
Cheers!
> 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
* Re: Core and Not-So Core
From: Eduardo Teixeira Dias @ 2005-05-10 22:33 UTC (permalink / raw)
To: diegocg; +Cc: eduardo, dwmw2, jon, git
In-Reply-To: <20050510234501.79eea7a4.diegocg@gmail.com>
I'm a Java programmer and I was thinking like one (Culture thing).
The reuse argument is very Strong.
The git-core are ready and it's a very good idea to reuse it. Any change
in the core or in the internal representation of git repository will
benefit the Git-Java implementation...
I think that a growing utilization of GCJ and ClassPath will contribute to
a Gradual Culture Change in the Java Land and promote a beter
reutilization among all GCC languages...
Write Once Run Everywhere that GCJ Runs (Sounds Good).
Eclipse will be compiled with GCJ in Fedora 4. Let's see how it works...
Cheers!
> 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
* Re: Core and Not-So Core
From: Eduardo Teixeira Dias @ 2005-05-10 22:33 UTC (permalink / raw)
To: diegocg; +Cc: eduardo, dwmw2, jon, git
In-Reply-To: <20050510234501.79eea7a4.diegocg@gmail.com>
I'm a Java programmer and I was thinking like one (Culture thing).
The reuse argument is very Strong.
The git-core are ready and it's a very good idea to reuse it. Any change
in the core or in the internal representation of git repository will
benefit the Git-Java implementation...
I think that a growing utilization of GCJ and ClassPath will contribute to
a Gradual Culture Change in the Java Land and promote a beter
reutilization among all GCC languages...
Write Once Run Everywhere that GCJ Runs (Sounds Good).
Eclipse will be compiled with GCJ in Fedora 4. Let's see how it works...
Cheers!
> 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
* Re: Core and Not-So Core
From: Daniel Barkalow @ 2005-05-10 22:18 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <2cfc40320505100800426d38ca@mail.gmail.com>
On Wed, 11 May 2005, 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.
>
> 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.
I'd guess that an Eclipse plugin wouldn't have a on-disk cache at all,
since it expects to keep the same address space through a whole day's
work.
> 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.
The two clients should be able to interoperate trivially; the C version
would just treat the Java one as a text editor whose modifications happen
to match commits going into the same head; as soon as the C user does
either read-tree or update-cache, everything will be seen to be consistent
again.
> 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.
I think this is nonsensical. The cache format is tied to the way in which
the repository accessing code is written, so a git-core separate from the
cache wouldn't have a useful set of code.
It might be worthwhile to produce a separate document describing the
repository format, such that it could be accessed by different code,
however. Of course, the index file wouldn't be part of this documentation,
for the same reason that the public git repositories don't include index
files.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/4] split core-git.txt and update
From: Junio C Hamano @ 2005-05-10 22:09 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <42812866.2040208@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
DG> Here are some more doc patches.
Thanks. Applied and pushed out.
^ permalink raw reply
* [PATCH 2/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
Rearrange commands in git.txt
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit ce5e04ff2f337c625ab070315b4f4f9d309f635e
tree 879e10daf0b047f9457cf6ba1d4183bbe1ba370c
parent 63ee9d429cd688ad364969b9f73aebc2377e6a05
author David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:19:30 +0100
committer David Greaves <david@dgreaves.com> Tue, 10 May 2005 22:19:30 +0100
Documentation/git.txt | 84 ++++++++++++++++++++++++++++----------------------
1 files changed, 48 insertions(+), 36 deletions(-)
Index: Documentation/git.txt
===================================================================
--- b5f4b1411f20986abae0d2ff57cb15caa35fe947/Documentation/git.txt (mode:100644)
+++ 879e10daf0b047f9457cf6ba1d4183bbe1ba370c/Documentation/git.txt (mode:100644)
@@ -32,56 +32,30 @@
the repository, the cache and the working fileset and those that
interrogate and compare them.
+There are also some ancilliary programs that can be viewed as useful
+aids for using the core commands but which are unlikely to be used by
+SCMs layered over git.
+
Manipulation commands
~~~~~~~~~~~~~~~~~~~~~
-link:git-apply-patch-script.html[git-apply-patch-script]::
- Sample script to apply the diffs from git-diff-*
-
link:git-checkout-cache.html[git-checkout-cache]::
Copy files from the cache to the working directory
link:git-commit-tree.html[git-commit-tree]::
Creates a new commit object
-link:git-convert-cache.html[git-convert-cache]::
- Converts old-style GIT repository
-
-link:git-http-pull.html[git-http-pull]::
- Downloads a remote GIT repository via HTTP
-
link:git-init-db.html[git-init-db]::
Creates an empty git object database
-link:git-local-pull.html[git-local-pull]::
- Duplicates another GIT repository on a local system
-
link:git-merge-base.html[git-merge-base]::
Finds as good a common ancestor as possible for a merge
-link:git-merge-one-file-script.html[git-merge-one-file-script]::
- The standard helper program to use with "git-merge-cache"
-
link:git-mktag.html[git-mktag]::
Creates a tag object
-link:git-prune-script.html[git-prune-script]::
- Prunes all unreachable objects from the object database
-
-link:git-pull-script.html[git-pull-script]::
- Script used by Linus to pull and merge a remote repository
-
link:git-read-tree.html[git-read-tree]::
Reads tree information into the directory cache
-link:git-resolve-script.html[git-resolve-script]::
- Script used to merge two trees
-
-link:git-rpull.html[git-rpull]::
- Pulls from a remote repository over ssh connection
-
-link:git-tag-script.html[git-tag-script]::
- An example script to create a tag object signed with GPG
-
link:git-update-cache.html[git-update-cache]::
Modifies the index or directory cache
@@ -108,9 +82,6 @@
link:git-diff-tree.html[git-diff-tree]::
Compares the content and mode of blobs found via two tree objects
-link:git-diff-tree-helper.html[git-diff-tree-helper]::
- Generates patch format output for git-diff-*
-
link:git-export.html[git-export]::
Exports each commit and a diff against each of its parents
@@ -132,9 +103,6 @@
link:git-rev-tree.html[git-rev-tree]::
Provides the revision tree for one or more commits
-link:git-rpush.html[git-rpush]::
- Helper "server-side" program used by git-rpull
-
link:git-tar-tree.html[git-tar-tree]::
Creates a tar archive of the files in the named tree
@@ -145,6 +113,50 @@
touch the working file set - but in general they don't
+Ancilliary Commands
+-------------------
+Manipulators:
+
+link:git-apply-patch-script.html[git-apply-patch-script]::
+ Sample script to apply the diffs from git-diff-*
+
+link:git-convert-cache.html[git-convert-cache]::
+ Converts old-style GIT repository
+
+link:git-http-pull.html[git-http-pull]::
+ Downloads a remote GIT repository via HTTP
+
+link:git-local-pull.html[git-local-pull]::
+ Duplicates another GIT repository on a local system
+
+link:git-merge-one-file-script.html[git-merge-one-file-script]::
+ The standard helper program to use with "git-merge-cache"
+
+link:git-pull-script.html[git-pull-script]::
+ Script used by Linus to pull and merge a remote repository
+
+link:git-prune-script.html[git-prune-script]::
+ Prunes all unreachable objects from the object database
+
+link:git-resolve-script.html[git-resolve-script]::
+ Script used to merge two trees
+
+link:git-tag-script.html[git-tag-script]::
+ An example script to create a tag object signed with GPG
+
+link:git-rpull.html[git-rpull]::
+ Pulls from a remote repository over ssh connection
+
+Interogators:
+
+link:git-diff-tree-helper.html[git-diff-tree-helper]::
+ Generates patch format output for git-diff-*
+
+link:git-rpush.html[git-rpush]::
+ Helper "server-side" program used by git-rpull
+
+
+
Terminology
-----------
see README for description
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* [PATCH 0/4] split core-git.txt and update
From: David Greaves @ 2005-05-10 21:32 UTC (permalink / raw)
To: Junio C Hamano, GIT Mailing Lists
Hi Junio
Here are some more doc patches.
I've :
* split up core-git.txt
* restructured the git.txt page
* described the environment variable usage and symbolic identifiers
* verified the docs for the first section of commands
* created a Makefile
All against your repository.
David
--
^ permalink raw reply
* 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
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