* [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 10:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Update the git Makefile to put the results of config.sh into the scripts.
config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Makefile | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -51,9 +51,18 @@ PROG= git-update-cache git-diff-files
all: $(PROG)
-install: $(PROG) $(SCRIPTS)
+config: config.sh
+ ./config.sh
+
+install: $(PROG) $(SCRIPTS) config
$(INSTALL) -m755 -d $(dest)$(bin)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
+ . ./config ; \
+ cd $(dest)$(bin) ; \
+ for file in $(SCRIPTS); do \
+ sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
+ cat $$file.new > $$file; rm $$file.new; \
+ done
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
@@ -190,7 +199,7 @@ test: all
$(MAKE) -C t/ all
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) config
$(MAKE) -C Documentation/ clean
backup: clean
^ permalink raw reply
* [PATCH 4/6] cogito-gnu-progs: parameterize cogito
From: Bryan Larsen @ 2005-07-11 10:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Patch cogito so that the utilities 'cp' 'stat' 'xargs' and 'date' are configurable. Cogito requires the gnu versions of these tools, and on some BSD derived systems, the gnu versions of these tools have a different name.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 15 ++++++++++-----
cg-Xnormid | 2 +-
cg-add | 2 +-
cg-commit | 4 ++--
cg-diff | 4 ++--
cg-init | 4 ++--
cg-patch | 2 +-
cg-pull | 2 +-
8 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -6,6 +6,11 @@
# This file provides a library containing common code shared with all the
# Cogito programs.
+DATE=date
+CP=cp
+XARGS=xargs
+STAT=stat
+
_cg_cmd=${0##*/}
_git=${GIT_DIR:-.git}
@@ -70,9 +75,9 @@ showdate () {
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
[ "$format" ] || format="+%a, %d %b %Y %H:%M:%S $2"
if [ "$has_gnudate" ]; then
- LANG=C date -ud "1970-01-01 UTC + $secs sec" "$format"
+ LANG=C ${DATE} -ud "1970-01-01 UTC + $secs sec" "$format"
else
- LANG=C date -u -r $secs "$format"
+ LANG=C ${DATE} -u -r $secs "$format"
fi
}
@@ -104,7 +109,7 @@ tree_timewarp () {
[ "$no_head_update" ] || echo "$branch" > $_git/HEAD
# Kill gone files
- git-diff-tree -z -r $base $branch | xargs -0 bash -c '
+ git-diff-tree -z -r $base $branch | ${XARGS} -0 bash -c '
while [ "$1" ]; do
header="$1"; shift
file="$1"; shift
@@ -234,5 +239,5 @@ fi
export BROKEN_MKTEMP=1
del=$($(which mktemp) -t 2>/dev/null) && { rm $del; export BROKEN_MKTEMP=; }
-has_stat=$(which stat 2>/dev/null)
-has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
+has_stat=$(which ${STAT} 2>/dev/null)
+has_gnudate=$(${DATE} -Rud "1970-01-01 UTC" 2>/dev/null)
diff --git a/cg-Xnormid b/cg-Xnormid
--- a/cg-Xnormid
+++ b/cg-Xnormid
@@ -50,7 +50,7 @@ fi
valid=; [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
if ([ "$id" ] && [ "$id" != " " ]) && [ ! "$valid" ]; then
- reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
+ reqsecs=$(${DATE} --date="$id" +'%s' 2>/dev/null)
if [ "$reqsecs" ]; then
id=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -43,6 +43,6 @@ find "${ARGS[@]}" -type f -print0 > $TMP
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
+cat $TMPFILE | ${XARGS} -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -168,7 +168,7 @@ written=
if [ "$merging" ]; then
echo -n 'Merge with ' >>$LOGMSG
[ "$msgs" ] && echo -n 'Merge with '
- [ -s $_git/merging-sym ] || cp $_git/merging $_git/merging-sym
+ [ -s $_git/merging-sym ] || ${CP} $_git/merging $_git/merging-sym
for sym in $(cat $_git/merging-sym); do
uri=$(cat $_git/branches/$sym)
[ "$uri" ] || uri="$sym"
@@ -229,7 +229,7 @@ fi
echo "CG: -----------------------------------------------------------------------" >>$LOGMSG
echo "CG: vim: textwidth=75" >>$LOGMSG
-cp $LOGMSG $LOGMSG2
+${CP} $LOGMSG $LOGMSG2
if tty -s; then
if ! [ "$msgs" ] || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
diff --git a/cg-diff b/cg-diff
--- a/cg-diff
+++ b/cg-diff
@@ -155,7 +155,7 @@ if [ "$id2" = " " ]; then
# FIXME: Update ret based on what did we match. And take "$@"
# to account after all.
ret=
- cat $filter | xargs git-diff-cache -r -p $tree | colorize | pager
+ cat $filter | ${XARGS} git-diff-cache -r -p $tree | colorize | pager
rm $filter
@@ -169,7 +169,7 @@ id2=$(tree-id "$id2") || exit 1
[ "$id1" = "$id2" ] && die "trying to diff $id1 against itself"
-cat $filter | xargs git-diff-tree -r -p $id1 $id2 | colorize | pager
+cat $filter | ${XARGS} git-diff-tree -r -p $id1 $id2 | colorize | pager
rm $filter
exit 0
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -47,7 +47,7 @@ if [ "$uri" ]; then
echo "$uri" >$_git/branches/origin
cg-pull origin || die "pull failed"
- cp $_git/refs/heads/origin $_git/refs/heads/master
+ ${CP} $_git/refs/heads/origin $_git/refs/heads/master
git-read-tree HEAD
git-checkout-cache -a
git-update-cache --refresh
@@ -55,7 +55,7 @@ if [ "$uri" ]; then
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
+ find * \( -type f -o -type l \) -print0 | ${XARGS} -0r cg-add ${infoonly}
cg-commit -C -m"Initial commit" -E ${infoonly}
fi
diff --git a/cg-patch b/cg-patch
--- a/cg-patch
+++ b/cg-patch
@@ -129,7 +129,7 @@ wait
touchfiles="$(git-ls-files --deleted | join -v 2 $gonefile -)"
[ "$touchfiles" ] && touch $touchfiles
-cat $todo | xargs -0 bash -c '
+cat $todo | ${XARGS} -0 bash -c '
while [ "$1" ]; do
op="$1"; shift;
case "$op" in
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -233,7 +233,7 @@ fetch_local () {
dest="$2"
[ "$cut_last" ] && dest=${dest%/*}
- cp $cp_flags_l "$src" "$dest"
+ ${CP} $cp_flags_l "$src" "$dest"
}
pull_local () {
^ permalink raw reply
* [PATCH 5/6] cogito-gnu-progs-Makefile: cogito Makefile update
From: Bryan Larsen @ 2005-07-11 10:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Update the cogito Makefile to put the results of config.sh into the scripts. config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Makefile | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -195,11 +195,20 @@ sedlibdir=$(shell echo $(libdir) | sed '
.PHONY: install install-git install-cogito
install: install-git install-cogito
-install-git: $(PROG) $(SCRIPTS)
+config: config.sh
+ ./config.sh
+
+install-git: $(PROG) $(SCRIPTS) config
$(INSTALL) -m755 -d $(DESTDIR)$(bindir)
$(INSTALL) $(PROG) $(SCRIPTS) $(DESTDIR)$(bindir)
+ . ./config ; \
+ cd $(DESTDIR)$(bindir) ;\
+ for file in $(SCRIPTS); do \
+ sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
+ cat $$file.new > $$file; rm $$file.new; \
+ done
-install-cogito: $(SCRIPT) $(LIB_SCRIPT) $(GEN_SCRIPT)
+install-cogito: $(SCRIPT) $(LIB_SCRIPT) $(GEN_SCRIPT) config
$(INSTALL) -m755 -d $(DESTDIR)$(bindir)
$(INSTALL) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
rm -f $(DESTDIR)$(bindir)/cg-cancel
@@ -211,9 +220,10 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' $$file > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
+ . ./config ; \
cd $(DESTDIR)$(libdir); \
for file in $(LIB_SCRIPT); do \
- sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' $$file > $$file.new; \
+ sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
@@ -232,7 +242,7 @@ dist: cogito.spec
gzip -9 $(tarname).tar
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE) config
$(MAKE) -C Documentation/ clean
backup: clean
^ permalink raw reply
* [PATCH 6/6] darwinports-Portfile: Portfile for cogito
From: Bryan Larsen @ 2005-07-11 10:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
A Portfile for darwinports.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Makefile | 2 ++
Portfile.in | 25 +++++++++++++++++++++++++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -240,6 +240,8 @@ dist: cogito.spec
@rm $(tarname)/cogito.spec
@rmdir $(tarname)
gzip -9 $(tarname).tar
+ sed -e 's/@@VERSION@@/$(shell cat $(VERSION) | cut -d"-" -f2)/g' < Portfile.in > Portfile
+ echo "checksums md5 " `md5sum $(tarname).tar.gz | cut -d ' ' -f 1` >> Portfile
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE) config
diff --git a/Portfile.in b/Portfile.in
new file mode 100644
--- /dev/null
+++ b/Portfile.in
@@ -0,0 +1,25 @@
+# $Id: $
+PortSystem 1.0
+name cogito
+version @@VERSION@@
+categories devel
+maintainers bryan.larsen@gmail.com
+description Git core + cogito tools to provide a full distributed SCM.
+long_description The git core, developed by Linus Torvalds provides \
+ an extremely fast and flexible filesystem-based \
+ database designed to store directory trees with \
+ regard to their history. The cogito tools, \
+ developed by Petr Baudis, provide full distributed \
+ SCM (software change management) functionality.
+homepage http://kernel.org/pub/software/scm/cogito/
+master_sites http://kernel.org/pub/software/scm/cogito/
+configure {}
+depends_lib bin:gcp:coreutils
+depends_lib bin:gnuxargs:findutils
+build.type gnu
+destroot.type gnu
+destroot.destdir prefix=${prefix} DESTDIR=${destroot}
+test.run yes
+test.cmd make
+test.target test
+test.dir ${worksrcpath}
^ permalink raw reply
* Re: Trial git RPM's..
From: Eric W. Biederman @ 2005-07-11 15:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507101814210.17536@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
> RPM's of it: src, ppc64 and x86. They're build on whatever random machines
> I had, and on the ppc64 I chose to do it on my FC4 machine that has newer
> libraries than my YDL one. The x86 thing is FC3, I do believe.
>
> I haven't really verified the RPM's in any other way than a trial
> installation on one machine, and "gitk" seemed to work. Whoop. The idea
> being that this is a good way to check whether the rpm target works, _and_
> cogito can have something to build against.
A couple of pieces. The dist target has assumes git-tar-tree is in the
path. Making it so you have to have git installed to build the rpm.
The man pages are not built. The build dependencies do not call out
the tools necessary to build the man pages.
And it does not pass my torture test of building rpm's on debian,
but that is not a huge problem.
Are you still up for a patch that records who and when made a tag?
I sent one but it seems to have been lost.
Eric
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Eric W. Biederman @ 2005-07-11 15:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507101517370.17536@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>>
>> The current intelligent fetch currently has a problem that it cannot
>> be used to bootstrap a repository. If you don't have an ancestor
>> of what you are fetching you can't fetch it.
>
> Sure you can.
>
> See the current "git clone". It's actually quite good, it's a pleasure to
> use now that it gives updates on how much it has done.
>
> Just do
>
> git clone src dest
Sorry, somehow I just missed that, and then I noticed just a little
before you sent out your email.
I'm having the worst time putting together a mental model of how git
works, and the documentation is spotty enough that it hasn't been
helpful. So I am wading through the code. It seems every time I turn
a corner there is another rough spot.
I guess I was expecting to pull from one tree into another unrelated
tree. Getting a tree with two heads and then be able to merge them
together.
A couple of questions.
1) Does git-clone-script when packed copy the entire repository
or just take a couple of slices of the tree where you have
references?
2) Is there a way for a pack to create deltas against objects
that are not in the tree? For a dumb repository making incremental
changes this is ideal.
Eric
^ permalink raw reply
* Re: [RFC] Design for http-pull on repo with packs
From: Dan Holmsand @ 2005-07-11 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, torvalds, git
In-Reply-To: <7v4qb2ni73.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> One very minor problem I have with Holmsand approach [*1*] is
> that the original Barkalow puller allowed a really dumb http
> server by not requiring directory index at all. For somebody
> like me with a cheap ISP account [*2*], it was great that I did
> not have to update 256 index.html files for objects/??/
> directories. Admittedly, it would be just one directory
> object/pack/, but still...
I totally agree that you shouldn't have to do any special kind of
prepping to serve a repository thru http. Which was why I thought it was
a good thing to use the default directory listing of the web-server,
assuming that this feature would be available on most servers...
Apparently not yours, though :-(
And Cogito already relies on directory listings (to find tags to download).
But if git-repack-script generates a "pack index file" automagically,
then of course everything is fine.
> On the other hand, picking an optimum set of packs from
> overlapping set of packs is indeed a very interesting (and hard
> combinatorial) problem to solve. I am hoping that in practice
> people would not force clients to do it with "interesting" set
> of packs. I would hope them to have just a full pack and
> incrementals, never having ovelaps, like Linus plans to do on
> his kernel repo.
>
> On the other hand, for somebody like Jeff Garzik with 50 heads,
> it might make some sense to have a handful different overlapping
> packs, optimized for different sets of people wanting to pull
> some but not all of his heads.
Well, it is an interresting problem... But I don't think that the
solution is to create more pack files. In fact, you'd want as few pack
files as possible, for maximum overall efficiency.
I did a little experiment. I cloned Linus' current tree, and git
repacked everything (that's 63M + 3.3M worth of pack files). Then I got
something like 25 or so of Jeff's branches. That's 6.9M of object files,
and 1.4M packed. Total size: 70M for the entire .git/objects/pack directory.
Repacking all of that to a single pack file gives, somewhat
surprisingly, a pack size of 62M (+ 1.3M index). In other words, the
cost of getting all those branches, and all of the new stuff from Linus,
turns out to be *negative* (probably due to some strange deltification
coincidence).
I think that this shows that (at least in this case), having many
branches isn't particularly wasteful (1.4M in this case with one
incremental pack).
And that fewer packs beats many packs quite handily.
The big problem, however, comes when Jeff (or anyone else) decides to
repack. Then, if you fetch both his repo and Linus', you might end up
with several really big pack files, that mostly overlap. That could
easily mean storing most objects many times, if you don't do some smart
selective un/repacking when fetching.
/dan
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Linus Torvalds @ 2005-07-11 16:38 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1irzh74m0.fsf@ebiederm.dsl.xmission.com>
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I guess I was expecting to pull from one tree into another unrelated
> tree. Getting a tree with two heads and then be able to merge them
> together.
You can do it, but you have to do it by hand. It's a valid operation, but
it's not an operation I want people to do by mistake, so it's not
something the trivial helper scripts help with.
The way to do it by hand is to just use something stupid that doesn't
understand what it's doing anyway, and just copy the files over. "cp -a"
or "rsync" works fine. Then just do "git resolve" by hand. It's not very
hard at all, but it's definitely something that should be a special case.
> A couple of questions.
>
> 1) Does git-clone-script when packed copy the entire repository
> or just take a couple of slices of the tree where you have
> references?
It only gets the objects needed for the references, nothing more.
So if you only get one branch, it will leave the objects that are specific
to other branches alone.
> 2) Is there a way for a pack to create deltas against objects
> that are not in the tree? For a dumb repository making incremental
> changes this is ideal.
A pack can only have deltas against objects in that pack. It caan't even
have deltas to other objects in the same tree, it literally is only
_within_ a pack. This is so that each pack is totally independent: you can
always unpack (and verify) the objects in a pack _without_ having anything
else (of course, the end result is often not a full project, and you won't
have any references, but at least the _objects_ are valid).
I don't want to have deltas to outside the pack, because while it's
obviously very nice from a size packing standpoint, it's totally horrid
from an infrastructure standpoint. It would make it possible to have
circular dependencies (ie deltas against each other) that could only be
resolved by having a third pack (or the unpacked object).
It would also means that you may have to have two packs mapped at the same
time to unpack them, which was very much against what I was aiming for: I
think that in the long run, for truly huge projects, you'd want to have a
history of packs, each maybe a gigabyte in size, and you may be in the
situation that you simply cannot have two packs mapped at the same time
because you don't have enough virtual memory for it.
So then inter-pack deltas would mean that you'd have to have "partial pack
mapping" etc horrid special case logic. Right now, because a pack is
always self-sufficient, you know that in order to unpack an object, if you
find it in the index file, you will be able to unpack it by just mapping
that pack and going off..
So the rule is: don't pack too often. The unpacked objects are actually
working really really well as long as you don't have tens of thousands of
them. Having a few hundred (or even a few thousand) unpacked objects is
not a problem at all. Then you do a "git repack" when it starts getting
uncomfortable, and you you continue.
Linus
^ permalink raw reply
* Re: Trial git RPM's..
From: Linus Torvalds @ 2005-07-11 17:06 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Git Mailing List
In-Reply-To: <m1eka574c8.fsf@ebiederm.dsl.xmission.com>
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> A couple of pieces. The dist target has assumes git-tar-tree is in the
> path. Making it so you have to have git installed to build the rpm.
Yes. Maybe we could relax that requirement by using "./git-tar-tree" or
something? That still requires that you have _built_ git to do the rpm,
but at least you won't have had to install it.
Does that fit the rpm build process? Or does an rpm build make something
like that really inconvenient? I don't know, patches welcome.
> The man pages are not built. The build dependencies do not call out
> the tools necessary to build the man pages.
Most people don't have asciidoc, and I'm not sure we want to require it.
Maybe we could have a separate "make man-rpm" target for that?
> And it does not pass my torture test of building rpm's on debian,
> but that is not a huge problem.
Ok, why is debian problematic? Is there some missing dependency or
something? I really haven't ever done an rpm, and the git rpm target was
all done by Chris Wright, so I don't have any clue at all. Again, patches
welcome.
> Are you still up for a patch that records who and when made a tag?
> I sent one but it seems to have been lost.
I'd really actually prefer for the code to be shared with the commit code,
so that the user info (name, email, date) would not just be exactly the
same, but would share the same code so that we don't end up having them
ever get out of sync.
That would imply moving parts of "git-tag-script" into mktag.c.
Linus
^ permalink raw reply
* Re: [RFC] Design for http-pull on repo with packs
From: Tony Luck @ 2005-07-11 17:08 UTC (permalink / raw)
To: Dan Holmsand; +Cc: Junio C Hamano, Daniel Barkalow, torvalds, git
In-Reply-To: <42D2960E.3050008@gmail.com>
> The big problem, however, comes when Jeff (or anyone else) decides to
> repack. Then, if you fetch both his repo and Linus', you might end up
> with several really big pack files, that mostly overlap. That could
> easily mean storing most objects many times, if you don't do some smart
> selective un/repacking when fetching.
So although it is possible to pack and re-pack at any time, perhaps we
need some guidelines? Maybe Linus should just do a re-pack as each
2.6.x release is made (or perhaps just every 2.6.even release if that is
too often). It has already been noted offlist that repositories hosted on
kernel.org can just copy pack files from Linus (or even better hardlink them).
-Tony
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Linus Torvalds @ 2005-07-11 17:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0507102337160.30848-100000@iabervon.org>
On Mon, 11 Jul 2005, Daniel Barkalow wrote:
> On Sun, 10 Jul 2005, Linus Torvalds wrote:
>
> >
> > You really _mustn't_ try to create the pack directly to the
> > $GIT_DIR/objects/pack subdirectory - that would make git itself start
> > possibly using that pack before the index is all done, and that would be
> > just wrong and nasty.
> >
> > So you really should _always_ generate the pack somewhere else, and then
> > move it (pack file first, index file second).
>
> It's currently fine ignoring index files without corresponding
> pack files (sha1_file.c, line 470).
That doesn't help.
Redgardless of which order you write them (and you _will_ write the
pack-file first), you'll find that at some point you have both files, but
one or the other isn't fully written, ie they are unusable.
And yes, you can handle that by always checking the SHA1 of the files when
you open them, but the fact is, you shouldn't need to, just to use it.
Checking the SHA1 of the pack-file in particular is very expensive (since
it's potentially a huge file, and you don't even want to read all of it).
So you could have rules like: pack-file must get populated first, and
index file must be SHA1-checked by all users.
Or, you could just have a saner rule: create the pack-files somewhere
else, and move them atomically to the right place. Problem solved.
So that's what I decided the rule is: never ever have a partial file, and
thus you can by definition use them immediately when you see both files.
But that requires that you write them under another name than the final
one. And since you want that _anyway_ for other uses, you don't hide that
inside "git-pack-objects", but you make it an exported interface.
Linus
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Linus Torvalds @ 2005-07-11 17:53 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1irzh74m0.fsf@ebiederm.dsl.xmission.com>
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I'm having the worst time putting together a mental model of how git
> works, and the documentation is spotty enough that it hasn't been
> helpful. So I am wading through the code. It seems every time I turn
> a corner there is another rough spot.
Btw, I know I'm bad at writing docs, but what I _do_ enjoy doing is
answering reasonably specific technical questions, and maybe somebody else
can write docs by taking advantage of me that way.
I tried to write the tutorial in a way that it also tries to explain how
git works (not just a "do this", but a "you update the index file and then
write the result out as a tree object"), but it obviously covers a fairly
limited part of what git actually can do, and at the same time it doesn't
go into a lot of detail.
And part of that is not just my inability to write documentation, it's
also that I just have the wrong "view" of the project, ie I probably just
take a lot of things for granted and consider them obvious, even though
they aren't, and then I probably occasionally explain things that aren't
worth explaining, because either they _are_ obvious, or people just don't
care and they are irrelevant.
I'd love to see somebody write up more of a "this is how you use git" kind
of tutorial, _and_ on the other hand more of a low-level explanation of
the notion of an object store where objects refer to each other by their
SHA1 names, and how that is represented in the filesystem and/or in packs.
Something with a few pictures would be great (ie screenshots of gitk, but
also something that tries to just visually show hot tags point to commits
that point to parents and trees, and trees pointing to other trees and
then blobs).
All things that I'm a complete idiot at, but that would help users
visualize what the heck git is actually _doing_, so that they don't just
parrot some magic command line that they don't understand, but can
actually reason about what they are doing.
I think a lot of people do understand this, but yes, the docs are kind of
lacking.
Linus
^ permalink raw reply
* [PATCH] git-cvsimport-script: add "import only" option
From: Sven Verdoolaege @ 2005-07-11 14:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, git
git-cvsimport-script: add "import only" option.
Acked-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
commit 1be6fbebb010083a083d8e2ee69fced7b6ae1261
tree a69017b2d10fd0a2655070d177f7cf59ab21882f
parent a3eb250f996bf5e12376ec88622c4ccaabf20ea8
author Sven Verdoolaege <skimo@kotnet.org> Mon, 11 Jul 2005 16:17:25 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Mon, 11 Jul 2005 16:17:25 +0200
Documentation/git-cvsimport-script.txt | 7 ++++++-
git-cvsimport-script | 18 +++++++++++-------
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
'git-cvsimport-script' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ <CVS_module> ]
DESCRIPTION
@@ -29,6 +29,11 @@ OPTIONS
currently, only the :local:, :ext: and :pserver: access methods
are supported.
+-i::
+ Import-only: don't perform a checkout after importing. This option
+ ensures the working directory and cache remain untouched and will
+ not create them if they do not exist.
+
-o <branch-for-HEAD>::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z);
+our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ CVS_module ]
+ [ -i ] [ CVS_module ]
END
exit(1);
}
-getopts("hvo:d:p:C:z:") or usage();
+getopts("hivo:d:p:C:z:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -723,8 +723,10 @@ if($orig_branch) {
print "DONE\n" if $opt_v;
system("cp","$git_dir/refs/heads/$opt_o","$git_dir/refs/heads/master")
if $forward_master;
- system('git-read-tree', '-m', '-u', 'CVS2GIT_HEAD', 'HEAD');
- die "read-tree failed: $?\n" if $?;
+ unless ($opt_i) {
+ system('git-read-tree', '-m', '-u', 'CVS2GIT_HEAD', 'HEAD');
+ die "read-tree failed: $?\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
@@ -732,7 +734,9 @@ if($orig_branch) {
unless -f "$git_dir/refs/heads/master";
unlink("$git_dir/HEAD");
symlink("refs/heads/$orig_branch","$git_dir/HEAD");
- system('git checkout');
- die "checkout failed: $?\n" if $?;
+ unless ($opt_i) {
+ system('git checkout');
+ die "checkout failed: $?\n" if $?;
+ }
}
unlink("$git_dir/CVS2GIT_HEAD");
^ permalink raw reply
* Re: [PATCH] Dereference tag repeatedly until we get a non-tag.
From: Jon Seymour @ 2005-07-11 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y0dx24j.fsf@assigned-by-dhcp.cox.net>
This seems reasonable to me. I have thought this would be useful on
several occasions and haven't yet conceived of a counterexample where
it would break something.
On 7/11/05, Junio C Hamano <junkio@cox.net> wrote:
> When we allow a tag object in place of a commit object, we only
> dereferenced the given tag once, which causes a tag that points
> at a tag that points at a commit to be rejected. Instead,
> dereference tag repeatedly until we get a non-tag.
>
> This patch makes change to two functions:
>
> - commit.c::lookup_commit_reference() is used by merge-base,
> rev-tree and rev-parse to convert user supplied SHA1 to that of
> a commit.
> - rev-list uses its own get_commit_reference() to do the same.
>
> Dereferencing tags this way helps both of these uses.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> *** Whether having a tag pointing at another tag is a separate
> *** issue, but I do not see a reason to forbid it. Maybe it
> *** is used to represent a chain of trust.
>
> commit.c | 5 +++--
> rev-list.c | 4 ++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> 0dc9377363ee73c5e3f3711d6f82e49886ce8c6a
> diff --git a/commit.c b/commit.c
> --- a/commit.c
> +++ b/commit.c
> @@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
>
> if (!obj)
> return NULL;
> - if (obj->type == tag_type)
> - obj = ((struct tag *)obj)->tagged;
> + while (obj->type == tag_type)
> + obj = parse_object(((struct tag *)obj)->tagged->sha1);
> +
> return check_commit(obj, sha1);
> }
>
> diff --git a/rev-list.c b/rev-list.c
> --- a/rev-list.c
> +++ b/rev-list.c
> @@ -367,12 +367,12 @@ static struct commit *get_commit_referen
> /*
> * Tag object? Look what it points to..
> */
> - if (object->type == tag_type) {
> + while (object->type == tag_type) {
> struct tag *tag = (struct tag *) object;
> object->flags |= flags;
> if (tag_objects && !(object->flags & UNINTERESTING))
> add_pending_object(object, tag->tag);
> - object = tag->tagged;
> + object = parse_object(tag->tagged->sha1);
> }
>
> /*
>
> -
> 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
>
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Linus Torvalds @ 2005-07-11 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan Larsen, bryan.larsen, pasky, git
In-Reply-To: <7vk6jxupxs.fsf@assigned-by-dhcp.cox.net>
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> I am not yet convinced "one variable per GNU program" is the
> right way to do (I do agree it is a problem and I appreciate
> your trying to solving it; an obvious alternative cop-out would
> be to fix this in the user's environment, but there might be a
> saner solution)
Yes. As you say, if we do this (and I think it's so ugly that I'm not
convinced we want to), it should be done in git-sh-setup-script _once_
instead of editing every single script.
Most everything includes git-sh-setup-script anyway by now.
However, what are the features that break the default apple tools anyway?
Maybe we should avoid using them? OSX clearly comes with "cp" and "xargs"
regardless, what are the flags that don't work with their cruddy versions?
[ Rant mode on: ..and who the hell is the idiot at Apple who includes the
old crappy BSD stuff? They already use gcc, so it's totally pointless to
have a NIH thing, when the GNU utilities are just _better_. Maybe
somebody can ask Apple to get with the program and not live in the dark
ages any more. ]
Linus
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 19:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bryan.larsen, torvalds, pasky, git
In-Reply-To: <7vk6jxupxs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Bryan Larsen <bryanlarsen@yahoo.com> writes:
>>+ for file in $(SCRIPTS); do \
>>+ sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
>>+ cat $$file.new > $$file; rm $$file.new; \
>>+ done
>
>
> I am not yet convinced "one variable per GNU program" is the
> right way to do
My first thought was to have some type of "prefix" argument that could
either be "g" or "". But xargs is called "gnuxargs" instead of
"gxargs". I'm not sure where that braindamage comes from, but I have to
deal with it.
To me, one variable per program makes sense: we do it in Makefiles all
the time $(CC), $(LD), et cetera.
> (I do agree it is a problem and I appreciate
> your trying to solving it; an obvious alternative cop-out would
> be to fix this in the user's environment, but there might be a
> saner solution).
If we can move the solution into the Portfile somehow, it probably
wouldn't bother me.
> Assuming that this is the way to go, wouldn't
> it be saner if this sed munging is done in only one place, say
> git-sh-setup-script, and have everybody include that? If we
> want to have some scripts usable not at the top-level GIT
> directory, then git-sh-setup-script may not be a good place; in
> which case introduce git-sh-compat-script and have everybody
> include _that_ instead?
>
That's the way it's done in cogito: it's in cg-Xlib and nowhere else.
This isn't obvious from the Makefile: perhaps I should have made it so.
I was very tempted to put it in git-sh-setup-script, but realized that
was inappropriate. Introducing a gid-sh-compat-script seems more sane.
Bryan
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Junio C Hamano @ 2005-07-11 19:02 UTC (permalink / raw)
To: Bryan Larsen; +Cc: bryan.larsen, junkio, torvalds, pasky, git
In-Reply-To: <20050711101454.10318.70399.sendpatchset@bryan-larsens-ibook-g4.local>
Bryan Larsen <bryanlarsen@yahoo.com> writes:
> Update the git Makefile to put the results of config.sh into the scripts.
> config.sh searches for gnu utilities cp, stat, date and xargs.
>
> Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
> +install: $(PROG) $(SCRIPTS) config
> $(INSTALL) -m755 -d $(dest)$(bin)
> $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
> + . ./config ; \
> + cd $(dest)$(bin) ; \
> + for file in $(SCRIPTS); do \
> + sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
> + cat $$file.new > $$file; rm $$file.new; \
> + done
I am not yet convinced "one variable per GNU program" is the
right way to do (I do agree it is a problem and I appreciate
your trying to solving it; an obvious alternative cop-out would
be to fix this in the user's environment, but there might be a
saner solution). Assuming that this is the way to go, wouldn't
it be saner if this sed munging is done in only one place, say
git-sh-setup-script, and have everybody include that? If we
want to have some scripts usable not at the top-level GIT
directory, then git-sh-setup-script may not be a good place; in
which case introduce git-sh-compat-script and have everybody
include _that_ instead?
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Petr Baudis @ 2005-07-11 19:39 UTC (permalink / raw)
To: Thomas Lord; +Cc: git
In-Reply-To: <1120918813.4901.27.camel@dev1.seyza.com>
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> The prereq graph is, indeed, an improvement.
..snip..
But object retrieval can be potentially as much as linear to the depth
of the prereq graph, right? I don't think any of the benefits you listed
are worth the complication, and you can still do the reachability
analysis pretty easily. (And I think it takes the same number of
roundtrips when downloading from remote server?)
> Other advantageous (imo) changes from `git' not mentioned in the
> original message:
>
> * blobs do not have header lines
>
> Git blobs all begin with a line of text declaring the "type"
> and size of the blob. That doesn't increase database
> verifiability significantly and I found no use for the headers.
> Having the headers makes it needlessly complicated to translate
> a file to or from a blob.
>
> `revc' does not have blob headers.
In git, this is crucial at least for distinguishing commits and tags.
I personally consider the verifiability boost useful.
> * `revc' uses portable file formats
>
> In working dirs, `git' stores binary files which are
> endian, word-size, and compiler-environment specific.
>
> `revc' stores some binary files too (for performance
> and simplicity reasons) but uses only portable formats.
I think they are only word-size specific, and that should be no big
matter to resolve, shall anyone want to.
> * `revc' is shaping up into much cleaner and more portable code
>
> (at least compared to the last version of `git' I saw --
> which was extremely *lucid* code but not terribly
> clean and not even attempting to be portable.)
All right, the portability could be better. ;-)
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 19:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, bryan.larsen, pasky, git
In-Reply-To: <Pine.LNX.4.58.0507111206240.17536@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
>>I am not yet convinced "one variable per GNU program" is the
>>right way to do (I do agree it is a problem and I appreciate
>>your trying to solving it; an obvious alternative cop-out would
>>be to fix this in the user's environment, but there might be a
>>saner solution)
>
>
> Yes. As you say, if we do this (and I think it's so ugly that I'm not
> convinced we want to), it should be done in git-sh-setup-script _once_
> instead of editing every single script.
Agreed: I was much happier with my cogito implementation where I just
put it in cg-Xlib. Is git-sh-setup-script appropriate? At first glance
it had a specific purpose and was not included in a large number of files.
>
> Most everything includes git-sh-setup-script anyway by now.
>
> However, what are the features that break the default apple tools anyway?
> Maybe we should avoid using them? OSX clearly comes with "cp" and "xargs"
> regardless, what are the flags that don't work with their cruddy versions?
xargs -r, cp -l, cp -u, cp -a. Git uses the first 2, cogito uses all 4.
Last night, I couldn't think of alternatives to these, but I obviously
didn't try very hard. xargs -r can probably happen via a temporary file
and cp -u can probably be simulated using rsync.
>
> [ Rant mode on: ..and who the hell is the idiot at Apple who includes the
> old crappy BSD stuff? They already use gcc, so it's totally pointless to
> have a NIH thing, when the GNU utilities are just _better_. Maybe
> somebody can ask Apple to get with the program and not live in the dark
> ages any more. ]
>
It wasn't long ago that the BSD's and Solaris had the same problems. If
only Apple is in the dark ages, shame on them.
Bryan
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Chris Wright @ 2005-07-11 20:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Russell King, git
In-Reply-To: <20050710145954.GB24249@pasky.ji.cz>
* Petr Baudis (pasky@suse.cz) wrote:
> Ok, cg-pull didn't quite handle this. I've fixed it so that it should
> reasonably handle it now. Hopefully.
Is this plus the zero-sized fix worth making cogito-0.12-2 rpm release?
IOW, these two patches...
diff-tree 291ec0f2d2ce65e5ccb876b46d6468af49ddb82e (from 72347a233e6f3c176059a28f0817de6654ef29c7)
tree a1d3a4e01516f1d924c407a9e42a6df0d13b43b6
parent 72347a233e6f3c176059a28f0817de6654ef29c7
author Linus Torvalds <torvalds@g5.osdl.org> 1120608369 -0700
committer Linus Torvalds <torvalds@g5.osdl.org> 1120608369 -0700
Don't special-case a zero-sized compression.
zlib actually writes a header for that case, and while ignoring that
header will get us the right data, it will also end up messing up our
stream position. So we actually want zlib to "uncompress" even an empty
object.
diff --git a/unpack-objects.c b/unpack-objects.c
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -55,8 +55,6 @@ static void *get_data(unsigned long size
z_stream stream;
void *buf = xmalloc(size);
- if (!size)
- return buf;
memset(&stream, 0, sizeof(stream));
stream.next_out = buf;
diff-tree 7b754d7f0800117cd97afa5e806e50c7fd16d8c1 (from a2503fd85e6bb7f25d134a5634a1d8efc93fee5f)
Author: Petr Baudis <pasky@suse.cz>
Date: Sun Jul 10 16:59:28 2005 +0200
Fix cg-pull to handle packed tags properly
If the objects referenced by refs/tags/ are packed, it wouldn't detect
them properly and instead try to refetch them, but they are likely to
be packed on the other side as well and that makes them impossible to
be fetched explicitly (which isn't a problem as long as they are the
same branch).
Also, the fetch failure message was confusing.
Reported by Russel King.
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -294,13 +294,14 @@ $fetch -i -s -u -d "$uri/refs/tags" "$_g
for tag in *; do
[ "$tag" = "*" ] && break
tagid=$(cat $tag)
- tagfile=objects/${tagid:0:2}/${tagid:2}
- [ -s "../../$tagfile" ] && continue
+ GIT_DIR=../../../$_git git-cat-file -t "$tagid" >/dev/null 2>&1 && continue
echo -n "Missing object of tag $tag... "
+ # In case it's not in a packfile...
+ tagfile=objects/${tagid:0:2}/${tagid:2}
if $fetch -i -s "$uri/$tagfile" "../../$tagfile" 2>/dev/null >&2; then
echo "retrieved"
else
- echo "different source (obsolete tag?)"
+ echo "unable to retrieve"
fi
done
)
^ permalink raw reply
* Re: Trial git RPM's..
From: Chris Wright @ 2005-07-11 20:34 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <m1eka574c8.fsf@ebiederm.dsl.xmission.com>
* Eric W. Biederman (ebiederm@xmission.com) wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
> > RPM's of it: src, ppc64 and x86. They're build on whatever random machines
> > I had, and on the ppc64 I chose to do it on my FC4 machine that has newer
> > libraries than my YDL one. The x86 thing is FC3, I do believe.
> >
> > I haven't really verified the RPM's in any other way than a trial
> > installation on one machine, and "gitk" seemed to work. Whoop. The idea
> > being that this is a good way to check whether the rpm target works, _and_
> > cogito can have something to build against.
>
> A couple of pieces. The dist target has assumes git-tar-tree is in the
> path. Making it so you have to have git installed to build the rpm.
Known, and was a reasonable assumption in my environment. It's simple
bootstrapping issue.
> The man pages are not built. The build dependencies do not call out
> the tools necessary to build the man pages.
That was rather intentional, because the asciidoc package is not common.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Junio C Hamano @ 2005-07-11 20:30 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Linus Torvalds, bryan.larsen, pasky, git
In-Reply-To: <7virzhrtfy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The only user of "cp -l" in the Linus GIT is git-clone-script
> local optimization. I could revert it to the version that I
> originally sent to the list, which uses cpio -pld, if your cpio
> groks that flag.
Bryan, does this work for you?
------------
Two changes to git-clone-script local optimization.
- When local optimization is used, the variable repo has
already been passed through get_repo_base so there is no need
to check for .git subdirectory in there.
- Use cpio -l instead of "cp -l".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -48,11 +48,8 @@ test -d "$D" || usage
case "$local,$use_local" in
yes,yes)
( cd "$repo/objects" ) || {
- repo="$repo/.git"
- ( cd "$repo/objects" ) || {
- echo >&2 "-l flag seen but $repo is not local."
- exit 1
- }
+ echo >&2 "-l flag seen but $repo is not local."
+ exit 1
}
# See if we can hardlink and drop "l" if not.
@@ -68,7 +65,9 @@ yes,yes)
l=l
fi &&
rm -f "$D/.git/objects/sample" &&
- cp -r$l "$repo/objects" "$D/.git/" || exit 1
+ cd "$repo" &&
+ find objects -type f -print |
+ cpio -puamd$l "$D/.git/" || exit 1
# Make a duplicate of refs and HEAD pointer
HEAD=
^ permalink raw reply
* git clone rsync:... ?
From: Marc Singer @ 2005-07-11 21:30 UTC (permalink / raw)
To: git
elf@florence /git > git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
defaulting to local storage area
ssh: rsync: Name or service not known
fatal: unexpected EOF
I've read several messages that this is changing, but it still isn't
clear where we should be starting. Moreover, I'd like to be able to
keep one repo that is just pulling from the net and then clone it for
different working directories. Why? Sometimes, in my ignorance, I
break my working repo. It's handy to have one that I know is OK
without pulling from the net each time.
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, bryan.larsen, pasky, git
In-Reply-To: <7vy88dqe4h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
>>The only user of "cp -l" in the Linus GIT is git-clone-script
>>local optimization. I could revert it to the version that I
>>originally sent to the list, which uses cpio -pld, if your cpio
>>groks that flag.
>
>
> Bryan, does this work for you?
>
Yes, it appears to work fine.
For the record, "${XARGS} -0r" may be uglier than "xargs -0r", but
replacing it with several lines of shell magic is a loss. OTOH shell
magic can be wrapped up into nice little functions. Certainly I'll
appreciate being able to remove my coreutils and findutils dependency,
but I think that assuming the user has gnu tools available somewhere is
a reasonable assumption for tools of this type.
The tradeoff might be different for git and cogito. Cogito uses shell
scripts more heavily and requires bash instead of Bourne. Certainly
you've demonstrated that git can be made portable relatively cleanly. I
doubt cogito will fall as easily.
But if you prefer to go this route, I'm happy with it.
Bryan
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Thomas Lord @ 2005-07-11 21:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050711193944.GA5981@pasky.ji.cz>
On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > The prereq graph is, indeed, an improvement.
> ..snip..
> But object retrieval can be potentially as much as linear to the depth
> of the prereq graph, right?
Potentially but not, by far, in the common case.
Moreover, that depth is an arbitrary parameter which user's can
freely vary -- that's part of the point.
> I don't think any of the benefits you listed
> are worth the complication, and you can still do the reachability
> analysis pretty easily. (And I think it takes the same number of
> roundtrips when downloading from remote server?)
>
I don't agree that any complication is added. I know that
some complications are avoided with this approach.
-t
^ 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