* 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: 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-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
* [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: Peter Williams @ 2005-05-11 1:17 UTC (permalink / raw)
To: jon; +Cc: Petr Baudis, Git Mailing List, Linus Torvalds
In-Reply-To: <2cfc403205051017505b57da72@mail.gmail.com>
Jon Seymour wrote:
> 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.
I disagree here. My experience is that Eclipse does not work well with
command line use of CVS within one of its workspaces. This is because
Eclipse keeps too much "state" information internally instead of relying
on CVS for all information about the state of the CVS playground. This
is one of the reasons that you can't attach Eclipse to an already
checked out CVS playground. The problem should be easily avoidable.
In spite of the above, Eclipse's SCM interface is the best that I've
stumbled across and is the main reason that I use Eclipse. I
particularly like the ability to compare a file in the workspace with
those in different versions, branches, etc.
So I'm looking forward to a git plug-in.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* gitweb wishlist
From: Petr Baudis @ 2005-05-11 1:26 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
Hello,
I would be very happy if you could extend the gitweb scripts a little.
Basically, what I need is to have ability to create a permanent link to
a given file in the repository, which stays same across revisions (as
long as the file stays with the given name, obviously).
E.g. I would like to have something like
http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib/ciabot.pl
for file contrib/ciabot.pl in the latest Cogito tree, and
http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib
for the list of the contrib/ directory in the latest Cogito tree.
I think I would prefer the link from the repository index to go not to
the log page, but some "summary" page, which would have some short
information about the repository (owner, description, list of branches
if gitweb supports that, list of tags, link to the latest tree and link
to the log).
BTW, why are people using ';' in the URIs for separators instead of
good old '&'s? Hmm, actually it just occurred to me that it might be to
workaround entity string problems?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [RFC] Embedding asciidoc manpages in the cg scripts
From: Jonas Fonseca @ 2005-05-11 1:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hi Pasky,
I am still a bit unsure how you want to embed asciidoc in the cg scripts
so I hope you will comment on this patch probe.
The Makefile stuff is pretty much ripped off from the recent Makefile by
David Greaves. I don't know if it should also live in
Documentation/Makefile.
You mentioned that you wanted the usage info in the USAGE variable. The
variable is initialized so that the usage info can be sed'ed out and
become part of the manpage. I assume the reason for this is to add a
usage function to cg-Xlib and use it as I have done in cg-add. This
should of course be done in a separate patch.
Finally, the embedded asciidoc markup. I still don't understand why you
dislike the cg-CMD strings in the NAME section. Asciidoc expects them
there and it will be so much harder to add them to the output of
$(cg-help cg-CMD).
---
Makefile | 28 +++++++++++++++++++++++++
cg-Xlib | 7 +++++-
cg-add | 28 ++++++++++++++++++++++---
cg-commit | 4 +--
cg-log | 68 ++++++++++++++++++++++++++++++++++++++++++++------------------
5 files changed, 110 insertions(+), 25 deletions(-)
Index: Makefile
===================================================================
--- 1cfa9d5a4f751f8ddd8b9a40758b8d6d0141264e/Makefile (mode:100644)
+++ uncommitted/Makefile (mode:100644)
@@ -29,6 +29,7 @@
bindir?=$(prefix)/bin
libdir?=$(prefix)/lib/cogito
+mandir?=$(prefix)/man/man1
CC?=gcc
AR?=ar
@@ -136,6 +137,8 @@
$(INSTALL) $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
$(INSTALL) -m755 -d $(DESTDIR)$(libdir)
$(INSTALL) $(LIB_SCRIPT) $(DESTDIR)$(libdir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(mandir)
+ $(INSTALL) $(MANDOC) $(DESTDIR)$(mandir)
cd $(DESTDIR)$(bindir); \
for file in $(SCRIPT); do \
sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' $$file > $$file.new; \
@@ -157,3 +160,31 @@
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
+
+
+DOCSRC = cg-log cg-add
+HTMLDIR = Documentation/html
+MANDIR = Documentation/man/man1
+HTMLDOC = $(patsubst %,$(HTMLDIR)/%.html,$(DOCSRC))
+MANDOC = $(patsubst %,$(MANDIR)/%.1,$(DOCSRC))
+
+doc-clean:
+ $(RM) $(HTMLDOC) $(MANDOC)
+
+html: $(HTMLDOC)
+man: $(MANDOC)
+
+$(HTMLDIR):
+ $(INSTALL) -m755 -d $@
+
+$(MANDIR)/%.1: %.xml
+ xmlto man $< -o $(@D)
+
+%.xml: %.txt
+ asciidoc -b docbook -d manpage -o $@ $<
+
+$(HTMLDIR)/%.html: %.txt $(HTMLDIR)
+ asciidoc -b css-embedded -d manpage -o $@ $<
+
+%.txt: %
+ cg-help $< > $@
Index: cg-Xlib
===================================================================
--- 1cfa9d5a4f751f8ddd8b9a40758b8d6d0141264e/cg-Xlib (mode:100755)
+++ uncommitted/cg-Xlib (mode:100755)
@@ -17,6 +17,11 @@
exit 1
}
+usage () {
+ echo "usage: $USAGE" >&2
+ exit 1
+}
+
mktemp () {
if [ ! "$BROKEN_MKTEMP" ]; then
@@ -52,7 +57,7 @@
print_help () {
which "cg-$1" >/dev/null 2>&1 || exit 1
- cat $(which cg-$1) | sed -n '3,/^$/s/^# *//p'
+ cat $(which cg-$1) | sed 's/^USAGE="\(.*\)"/# \1/' | sed -n '3,/^$/s/^# *//p'
exit
}
Index: cg-add
===================================================================
--- 1cfa9d5a4f751f8ddd8b9a40758b8d6d0141264e/cg-add (mode:100755)
+++ uncommitted/cg-add (mode:100755)
@@ -1,14 +1,36 @@
#!/usr/bin/env bash
#
-# Add new file to a GIT repository.
-# Copyright (c) Petr Baudis, 2005
+# CG-ADD(1)
+# =========
#
+# NAME
+# ----
+# cg-add - add files to a GIT repository
+#
+# SYNOPSIS
+# --------
+USAGE="cg-add FILE..."
+#
+# DESCRIPTION
+# -----------
# Takes a list of file names at the command line, and schedules them
# for addition to the GIT repository at the next commit.
+#
+# The command will fail if one of the given files does not exist.
+#
+# cg-add is part of Cogito, an SCM-like toolkit for managing GIT trees.
+#
+# OPTIONS
+# -------
+# No options.
+#
+# COPYING
+# -------
+# Copyright (c) Petr Baudis, 2005.
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || die "usage: cg-add FILE..."
+[ "$1" ] || usage
for file in "$@"; do
if [ -f "$file" ]; then
Index: cg-log
===================================================================
--- 1cfa9d5a4f751f8ddd8b9a40758b8d6d0141264e/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -1,26 +1,56 @@
#!/usr/bin/env bash
#
-# Make a log of changes in a GIT branch.
-# Copyright (c) Petr Baudis, 2005.
-# Copyright (c) David Woodhouse, 2005.
-#
-# Takes a -c option to add color to the output.
-# Currently, the colors are:
+# CG-LOG(1)
+# =========
#
-# header Green
-# author Cyan
-# committer Magenta
-# files Blue
-# signoff Yellow
-#
-# Takes an -f option to list which files was changed.
-#
-# Takes an -r followed with id resolving to a commit to start from
-# (HEAD by default), or id1:id2 representing an (id1;id2] range
-# of commits to show.
+# NAME
+# ----
+# cg-log - show log information for files or a range of commits
+#
+# SYNOPSIS
+# --------
+USAGE="cg-log [ -c ] [ -f ] [ --help | -h ] [-r FROM_ID[:TO_ID]]... [FILE]..."
+#
+# DESCRIPTION
+# -----------
+# Display log information for files or a range of commits. The output
+# will automatically be displayed in pager unless it is piped.
+#
+# cg-log is part of Cogito, an SCM-like toolkit for managing GIT trees.
+#
+# OPTIONS
+# -------
+# Arguments not interpreted as options will be interpreted as filenames;
+# cg-log then displays only changes in those files.
+#
+# --help, -h::
+# Print this documentation
+#
+# -c::
+# Add color to the output. Currently, the colors are:
+#
+# header Green
+# author Cyan
+# committer Magenta
+# files Blue
+# signoff Yellow
+#
+# -f::
+# List which files were changed.
+#
+# -r FROM_ID[:TO_ID]::
+# Limit the log information to a range of commits. The range of
+# included commits can be specified either as -r FROM_ID[:TO_ID]
+# or as -r FROM_ID -r TO_ID. In both situations the -r option
+# expects ID arguments which resolve to commits. For ranges, the
+# log for both the specified IDs will be included. If TO_ID is
+# left out all commits older than FROM_ID will not be shown. If no
+# -r option is given commits starting from HEAD will be shown.
#
-# The rest of arguments are took as filenames; cg-log then displays
-# only changes in those files.
+# COPYING
+# -------
+# Copyright (c) Petr Baudis, 2005.
+# Copyright (c) David Woodhouse, 2005.
. ${COGITO_LIB}cg-Xlib
# Try to fix the annoying "Broken pipe" output. May not help, but apparently
--
Jonas Fonseca
^ permalink raw reply
* Re: gitweb wishlist
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-11 1:49 UTC (permalink / raw)
To: pasky; +Cc: kay.sievers, git, yoshfuji
In-Reply-To: <20050511012626.GL26384@pasky.ji.cz>
In article <20050511012626.GL26384@pasky.ji.cz> (at Wed, 11 May 2005 03:26:26 +0200), Petr Baudis <pasky@ucw.cz> says:
> E.g. I would like to have something like
>
> http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib/ciabot.pl
~~~ why not /?
--yoshfuji
^ permalink raw reply
* Re: Core and Not-So Core
From: Rik van Riel @ 2005-05-11 1:59 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc4032050510101553d391b2@mail.gmail.com>
On Wed, 11 May 2005, Jon Seymour wrote:
> 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.
> 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.
Can Java use a library that's implemented in C, like Python
and Perl can? If that is the case, the C implementation of
git simply needs the ability to be called as a library and
you can implement Java bindings for it.
That should also make it easier to create front-ends in
other languages...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
^ permalink raw reply
* Re: gitweb wishlist
From: Petr Baudis @ 2005-05-11 2:04 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: kay.sievers, git
In-Reply-To: <20050511.104907.57995840.yoshfuji@linux-ipv6.org>
Dear diary, on Wed, May 11, 2005 at 03:49:07AM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> In article <20050511012626.GL26384@pasky.ji.cz> (at Wed, 11 May 2005 03:26:26 +0200), Petr Baudis <pasky@ucw.cz> says:
>
> > E.g. I would like to have something like
> >
> > http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib/ciabot.pl
> ~~~ why not /?
This was a simple cut'n'paste. I don't care either way personally, but I
think it's better to be conservative when generating links and escape
this. OTOH it should obviously also accept a URL containing a slash
instead.
--
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-11 2:09 UTC (permalink / raw)
To: Rik van Riel; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.61.0505102158140.17216@chimarrao.boston.redhat.com>
On 5/11/05, Rik van Riel <riel@redhat.com> wrote:
> On Wed, 11 May 2005, Jon Seymour wrote:
>
> > 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.
>
> > 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.
>
> Can Java use a library that's implemented in C, like Python
> and Perl can? If that is the case, the C implementation of
> git simply needs the ability to be called as a library and
> you can implement Java bindings for it.
>
It can in principle, yes. This is the so-called Java-Native-Interface (JNI).
I think in the longer term it would make sense to write a JNI layer
but the GIT source code is probably a little too unstable for that
now. What needs to happen first, I think, is that a solid and stable C
API (e.g. a libgit) be proposed and developed.
One outcome of the work I am doing (a long time away, probably will
never happen) might eventually be to propose an C API for GIT based,
in part, on the prototyping work I do in Java. However, I suspect its
Java-tainted heritage would mean instant death to it for purely
dogmatic reasons so I think it I'll leave it to others to propose a
C-API and then write a JNI wrapper for that when/if it ever happens.
> That should also make it easier to create front-ends in
> other languages...
>
Agreed.
jon.
^ permalink raw reply
* Re: Core and Not-So Core
From: Petr Baudis @ 2005-05-11 2:14 UTC (permalink / raw)
To: Jon Seymour; +Cc: Rik van Riel, Git Mailing List
In-Reply-To: <2cfc4032050510190950bba995@mail.gmail.com>
Dear diary, on Wed, May 11, 2005 at 04:09:49AM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> On 5/11/05, Rik van Riel <riel@redhat.com> wrote:
> > On Wed, 11 May 2005, Jon Seymour wrote:
> >
> > > 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.
> >
> > > 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.
> >
> > Can Java use a library that's implemented in C, like Python
> > and Perl can? If that is the case, the C implementation of
> > git simply needs the ability to be called as a library and
> > you can implement Java bindings for it.
> >
>
> It can in principle, yes. This is the so-called Java-Native-Interface (JNI).
>
> I think in the longer term it would make sense to write a JNI layer
> but the GIT source code is probably a little too unstable for that
> now. What needs to happen first, I think, is that a solid and stable C
> API (e.g. a libgit) be proposed and developed.
FWIW, this is actually happening now (see Brad Roberts' posts in nearby
thread).
--
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: Nicolas Pitre @ 2005-05-11 2:30 UTC (permalink / raw)
To: Jon Seymour; +Cc: Petr Baudis, Git Mailing List, Linus Torvalds
In-Reply-To: <2cfc403205051017505b57da72@mail.gmail.com>
On Wed, 11 May 2005, Jon Seymour wrote:
> On 5/11/05, Petr Baudis <pasky@ucw.cz> wrote:
> > 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.
In this case you just need to manage to use the current index format
somehow.
Honestly I don't think Linus might be interested into changing the index
format just to make a Java implementation happier. So your best bet is
probably to use it as is or ignore it entirely.
Nicolas
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-11 2:53 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List, Linus Torvalds
In-Reply-To: <7vr7gewuxt.fsf@assigned-by-dhcp.cox.net>
Please forget about the previous one which was buggy when you
had ".something" file under the directory being replaced.
Could you give this patch a try?
---
Running git-checkout-cache -f -a to check out a file in a
directory fails when the work tree has a non-directory with the
same name as the directory being checked out. Similarly it
fails to check out a file when the work tree has a directory
with the same name as the file being checked out.
When '-f' is specified, the user is telling us that "I really
want to match the work tree with what is in the cache." So
removing the offending file or directory from the work tree to
make room when necessary and possible in order to make the
checkout succeed is the right thing to do.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- 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] == '.') &&
+ ((de->d_name[1] == 0) ||
+ (de->d_name[1] == '.') && de->d_name[2] == 0))
+ continue;
+ 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;
@@ -58,10 +100,14 @@ static int create_file(const char *path,
mode = (mode & 0100) ? 0777 : 0666;
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
if (fd < 0) {
- if (errno == ENOENT) {
+ if ((errno == ENOENT) || (errno == ENOTDIR && force)) {
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);
+ }
}
return fd;
}
------------------------------------------------
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-11 3:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Petr Baudis, Git Mailing List, Linus Torvalds
In-Reply-To: <Pine.LNX.4.62.0505102226020.5426@localhost.localdomain>
On 5/11/05, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 11 May 2005, Jon Seymour wrote:
> > 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.
>
> In this case you just need to manage to use the current index format
> somehow.
>
> Honestly I don't think Linus might be interested into changing the index
> format just to make a Java implementation happier. So your best bet is
> probably to use it as is or ignore it entirely.
>
Agreed - I am not proposing a change to the index format, merely
highlighting that the index format is closely bound to the
workspace-oriented toolset and that the workspace-oriented toolset is
distinct from the repository-oriented toolset; different
workspace-oriented toolsets will have different requirements for their
index files and so their index files might quite rightly differ in
both form and substance.
That said, their is no harm making my set of tools interoperable with
the git tools, where that is possible so that the user can decide to
use which ever toolset fits the job immediately at hand. With this in
mind, a published specification of the index format would help, but I
am not going insist on that. I am certainly not going to ask for
changes to it! Life is too short :-)
jon.
^ permalink raw reply
* [ANNOUNCE] git-pb git tree
From: Petr Baudis @ 2005-05-11 3:16 UTC (permalink / raw)
To: git
Hello,
I've published the git-pb git tree. This is a purely "core GIT" tree,
with no traces of Cogito itself inside, and intended to be safe-to-pull
for Linus. It will hopefully be soon fully synchronized by the GIT part
of the Cogito tree (it already has all the important bits), and will
stay so - any GIT stuff will go to the Cogito tree through the git-pb
tree.
I plan to integrate the well-looking core git patches flying through
the mailing list to the git-pb tree, as well as various own stuff
(related or not related to what Cogito needs for operating well). I
will be pulling from Linus on regular basis, and from git-jc too if I
feel comfortable with what's inside.
I'm also thinking about git-pbc for the possibly controversial stuff
(taking care of hidden files, perhaps librarifications).
You get it as a Git tree at
rsync://rsync.kernel.org/pub/scm/cogito/git-pb.git
http://www.kernel.org/pub/scm/cogito/git-pb.git
On related note, I've set up a Git->CIA gateway. CIA is a commit
aggregator, tracking large number of open source projects. Cogito's and
git-pb's corner is at http://cia.navi.cx/stats/project/Cogito, the
commits are also broadcasted to the #git OPN channel (which is the point
of the whole thing, after all ;-).
Have fun,
--
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: [ANNOUNCE] git-pb git tree
From: Junio C Hamano @ 2005-05-11 4:11 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20050511031613.GO26384@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Hello,
PB> I've published the git-pb git tree. This is a purely "core GIT" tree,
PB> ...
PB> You get it as a Git tree at
PB> rsync://rsync.kernel.org/pub/scm/cogito/git-pb.git
PB> http://www.kernel.org/pub/scm/cogito/git-pb.git
Good, this is what I was waiting for.
Just in case people are wondering, all of what's there in the
current git-jc tree, except for one two liner documentation fix,
is already included in the git-pb tree, so there is no reason
for people other than Petr to pull from git-jc at this moment.
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-11 5:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Morten Welinder, git, Linus Torvalds
In-Reply-To: <20050510230357.GF26384@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> What if you have some files not tracked by git in the subdirectory?
PB> Either you need to check for this and deal with it (Cogito's approach
PB> would be to remove the git-tracked files and rename the subdirectory),
PB> or not do it at all.
Let me understand you correctly. You "rename the subdirectory"
because the cache you want to check out records a non-directory
there. Is this correct? When do you "remove the git-tracked
files"? Do you mean "if a file that is not tracked (in the
user's mind) is there in the filesystem, and the cache to be
checked out has a file there, the file on the filesystem is
removed"? What happens if an existing non-directory interferes
with a directory to be checked out from the cache?
I think the right thing for the core GIT layer to do, when the
end user is using the Plumbing tools directly and says "really
please" by specifying an '-f', is to make the checkout succeed
by removing conflicting stuff, as my fixed patch does.
If the Porcelain runs checkout-cache on the user's behalf, the
story is a bit different. Porcelain would have some idea of
what GIT tree the files in the working directory originated from
("the last commit", or "my head before the read-tree -m merge")
before the user started working in it. When the user wants to
update the work tree to match a cache (which may be quite
different from "the last commit", if it is coming from cg-seek
or result of a merge), the Porcelain knows:
- the set of non git-tracked (from the point of view from "the
last commit") files that are in the work tree;
- among those, the set of files that would be overwritten by
this checkout. This includes, but not limited to, the files
that would otherwise interfere because of file-directory
conflicts.
And then you can set aside those "to-be-overwritten" files,
remove them from the filesystem, and run your checkout.
The determination of which files to set aside should not be done
based on whether they cause file-directory conflicts. If the
user has a non-tracked file which happens to be registered as a
tracked file in the cache to be checked out (e.g. after a
three-way merge), that file is as valuable as a non-tracked file
that is in a subdirectory that the new cache happens to have as
a non-directory. Losing the former is as harmful as losing the
latter. From what you say above, it sounds like you are saving
the latter but not the former, but my readins of what you wrote
above may be mistaken.
^ permalink raw reply
* [PATCH Cogito] match pathnames in exclude handling
From: Matthias Urlichs @ 2005-05-11 5:25 UTC (permalink / raw)
To: David Mansfield; +Cc: Jan-Benedict Glaw, Junio C Hamano, Brian Gerst, git
In-Reply-To: <4281281F.6000101@cobite.com>
[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]
Hi,
David Mansfield:
> 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.
>
I already did, last week. (I do need to cleanup my changes...)
The idea is that "foo" matches anywhere, "foo/bar" the exact pathname.
As a special case, "./foo" matches in the root directory only.
NB: "*" can cross subdirectory paths, so "*/foo/bar" does match
"a/b/c/foo/bar".
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
---
Index: ls-files.c
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/ls-files.c (mode:100644)
+++ 12deb13b12cdb338fe3fdc2e77a024490d6c39ea/ls-files.c (mode:100644)
@@ -80,9 +80,17 @@
if (nr_excludes) {
const char *basename = strrchr(pathname, '/');
basename = (basename) ? basename+1 : pathname;
- for (i = 0; i < nr_excludes; i++)
- if (fnmatch(excludes[i], basename, 0) == 0)
- return 1;
+ for (i = 0; i < nr_excludes; i++) {
+ if (excludes[i][0] != '.' || excludes[i][1] != '/') {
+ if (fnmatch(excludes[i], pathname, 0) == 0)
+ return 1;
+ if (basename != pathname && fnmatch(excludes[i], pathname, 0) == 0)
+ return 1;
+ } else {
+ if (fnmatch(excludes[i]+2, pathname, 0) == 0)
+ return 1;
+ }
+ }
}
return 0;
}
@@ -129,10 +137,10 @@
if (de->d_name[0] == '.')
continue;
- if (excluded(de->d_name) != show_ignored)
- continue;
len = strlen(de->d_name);
memcpy(fullname + baselen, de->d_name, len+1);
+ if (excluded(fullname) != show_ignored)
+ continue;
switch (DTYPE(de)) {
struct stat st;
--
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
* [ANNOUNCE] git tracker online
From: Thomas Gleixner @ 2005-05-11 7:01 UTC (permalink / raw)
To: git
Hi,
git tracker is online in a beta version:
http://www.tglx.de/gittracker
It does:
- multi repository tracking
- Tree browsing
- File revision history
- File diffs
- File annotation
- commit viewer with filtering (e.g. all commits in a tree which are not
in another tree)
The file histories and annotations are partially messed due to the
missing information about head forward merges. Its a pity that there
seems to be no interest to solve this problem really. It might be not
important for some of you, but it is often quite helpful to have
consistent information across multiple trees available.
The simplest solution would be a head order list per repository, which
is updated every time when the head is changed. Thats a non intrusive
feature, which could be simply added to the current tools.
tglx
^ permalink raw reply
* Re: Core and Not-So Core
From: Christoph Hellwig @ 2005-05-11 7:17 UTC (permalink / raw)
To: Diego Calleja; +Cc: eduardo, dwmw2, jon, git
In-Reply-To: <20050510234501.79eea7a4.diegocg@gmail.com>
On Tue, May 10, 2005 at 11:45:01PM +0200, Diego Calleja wrote:
> ...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...
Note that it's also not true. At least if you use the gcj-specific CNI
mechanisms instead of Sun's braindead JNI.
^ permalink raw reply
* GIT compile error on Sun Sparc SB2000
From: Alexey Nezhdanov @ 2005-05-11 7:41 UTC (permalink / raw)
To: Git Mailing List
Hello. GIT refuses to compile on Debian sarge on sparc64.
Probably some compile flag is incompartible but can't figure out which.
=============================
webmaster@www:/tmp/cogito-0.10$ make
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o read-cache.o
read-cache.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o sha1_file.o
sha1_file.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o usage.o usage.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o object.o object.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o commit.o commit.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o tree.o tree.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o blob.o blob.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o tag.o tag.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o date.o date.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o strbuf.o strbuf.c
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o diff.o diff.c
ar rcs libgit.a read-cache.o sha1_file.o usage.o object.o commit.o tree.o
blob.o tag.o date.o strbuf.o diff.o
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-update-cache
update-cache.c libgit.a -lz -lssl
/usr/bin/ld: skipping
incompatible /usr/lib/gcc-lib/sparc-linux/3.3.3/../../../libz.so when
searching for -lz
/usr/bin/ld: skipping
incompatible /usr/lib/gcc-lib/sparc-linux/3.3.3/../../../libz.a when
searching for -lz
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libz.so when searching for
-lz
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libz.a when searching for
-lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
make: *** [git-update-cache] Error 1
webmaster@www:/tmp/cogito-0.10$
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-11 7:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Diego Calleja, eduardo, dwmw2, git
In-Reply-To: <20050511071717.GB23090@infradead.org>
On 5/11/05, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, May 10, 2005 at 11:45:01PM +0200, Diego Calleja wrote:
> > ...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...
>
> Note that it's also not true. At least if you use the gcj-specific CNI
> mechanisms instead of Sun's braindead JNI.
>
>
What I actually claimed (contrary to Diego's misquote) is that
"Java-invokes-C-executable" would be slower than pure-Java. I didn't
make a claim one way or the other about the performance of a Java
implementation invoking some form of native interface.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: David Greaves @ 2005-05-11 8:01 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: Git Mailing List
In-Reply-To: <200505111141.27725.snake@penza-gsm.ru>
Alexey Nezhdanov wrote:
>Hello. GIT refuses to compile on Debian sarge on sparc64.
>Probably some compile flag is incompartible but can't figure out which.
>
>
read the error message:
>/usr/bin/ld: skipping
>incompatible /usr/lib/gcc-lib/sparc-linux/3.3.3/../../../libz.so when
>
>
hmm...
libz.so
>/usr/bin/ld: cannot find -lz
>
>
Can't find often equals "not installed"
So go to aptitude, search for zlib
You'll find libz-dev
Install it
Or just run
apt-get install libz-dev
And try again
David
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-11 8:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050511012626.GL26384@pasky.ji.cz>
On Wed, 2005-05-11 at 03:26 +0200, Petr Baudis wrote:
> Hello,
>
> I would be very happy if you could extend the gitweb scripts a little.
> Basically, what I need is to have ability to create a permanent link to
> a given file in the repository, which stays same across revisions (as
> long as the file stays with the given name, obviously).
>
> E.g. I would like to have something like
>
> http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib/ciabot.pl
>
> for file contrib/ciabot.pl in the latest Cogito tree, and
>
> http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib
>
> for the list of the contrib/ directory in the latest Cogito tree.
With the next round I will try to introduce a real browser through the
tree instead of the current damn simple tree-object list. It would be
nice if it can show the the current path and provide a "up to parent"
way. Along with that it should be easy to add the stuff you asked for.
> I think I would prefer the link from the repository index to go not to
> the log page, but some "summary" page, which would have some short
> information about the repository (owner, description, list of branches
> if gitweb supports that, list of tags, link to the latest tree and link
> to the log).
>
> BTW, why are people using ';' in the URIs for separators instead of
> good old '&'s? Hmm, actually it just occurred to me that it might be to
> workaround entity string problems?
Yes, but it's "bad old" not "good". :)
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
Thanks,
Kay
^ 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