* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Shawn Pearce @ 2006-05-24 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7wr3tc3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >> I've swallowed all 10 and pushed them out in "pu", but could you
> >> add tests to check the Porcelainish commands you touched with
> >> this series to make sure they all log correctly?
> >
> > Sure. I've been putting it off as I've been busy the past few days
> > and have also been thinking about trying to rebuild reflog using a
> > tag/annotation branch style, which might be more generally useful
> > to others.
>
> It appears that there is more serious breakage caused by the
> lock_ref change. http-fetch in "next" fails to clone, because
> the call to lock-ref-sha1 in fetch.c::pull() forgets that the
> program might be creating a new ref.
The breakage is because of current_ref always being null. The old
code would allow locking a non-existant ref in this case while the
new code was failing. A simple change such as the following should
fix it:
-->8--
Fix fetch when using reflog.
Previously fetch was permitted to create refs if they did not exist;
this only worked as current_ref was always NULL and thus never
would get compared against the existing ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
2dad4178db978c01257fde949d808361589ee003
fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
2dad4178db978c01257fde949d808361589ee003
diff --git a/fetch.c b/fetch.c
index fd57684..15110b8 100644
--- a/fetch.c
+++ b/fetch.c
@@ -213,7 +213,7 @@ int pull(char *target)
save_commit_buffer = 0;
track_object_refs = 0;
if (write_ref) {
- lock = lock_ref_sha1(write_ref, current_ref, 1);
+ lock = lock_ref_sha1(write_ref, current_ref, 0);
if (!lock) {
error("Can't lock ref %s", write_ref);
return -1;
--
1.3.3.gfad60
^ permalink raw reply related
* Re: Slow fetches of tags
From: Linus Torvalds @ 2006-05-24 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Baechle, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605241200110.5623@g5.osdl.org>
On Wed, 24 May 2006, Linus Torvalds wrote:
>
> IOW, I think there's something more fundamentally wrong with the tag
> following. We _should_ have figured out much more quickly that we have it
> all.
Actually, maybe the problem is that Ralf's tree has two roots, because of
the old CVS history. It might be following the other root down for the
"have" part, since that one doesn't exist at all in the target and the
other side will never acknowledge any of it.
I'll play with it.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Junio C Hamano @ 2006-05-25 0:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605241631340.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 24 May 2006, Junio C Hamano wrote:
>>
>> It was very pleasant to read the changes that way, especially around
>> write_sha1_to_fd() vs repack_object(). xxdiff is my new friend.
>
> I think "kompare" (the KDE diff tool) is nicer.
I'd love to give it a whirl, but aptitude says it will consume
73.5MB diskspace to install it, with download size 22.4MB, which
makes me go ... hmmmm (my machines are currently KDE free so the
above counts slurping in the kdelibs essentials).
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Sean @ 2006-05-25 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7virnv3qi6.fsf@assigned-by-dhcp.cox.net>
On Wed, 24 May 2006 17:19:29 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Wed, 24 May 2006, Junio C Hamano wrote:
> >>
> >> It was very pleasant to read the changes that way, especially around
> >> write_sha1_to_fd() vs repack_object(). xxdiff is my new friend.
> >
> > I think "kompare" (the KDE diff tool) is nicer.
>
> I'd love to give it a whirl, but aptitude says it will consume
> 73.5MB diskspace to install it, with download size 22.4MB, which
> makes me go ... hmmmm (my machines are currently KDE free so the
> above counts slurping in the kdelibs essentials).
>
"meld" works great too, and lets you do hunk-level merging etc; very
handy. The bash <( ... ) feature is quite handy too, it will create
a temp file for you and clean it up afterward.
$ meld sha1_file.c <(git cat-file -p c2f493a4ae:sha1_file.c)
Sean
^ permalink raw reply
* [PATCH] cat-file: document -p option
From: Jeff King @ 2006-05-25 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060524203108.70b6c596.seanlkml@sympatico.ca>
---
On Wed, May 24, 2006 at 08:31:08PM -0400, Sean wrote:
> $ meld sha1_file.c <(git cat-file -p c2f493a4ae:sha1_file.c)
I had never seen the -p option, and it wasn't in the Documentation. Let
me know if I've gotten its function completely wrong. :)
-Peff
Documentation/git-cat-file.txt | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 504eb1b..5e9cbf8 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -8,12 +8,12 @@ git-cat-file - Provide content or type i
SYNOPSIS
--------
-'git-cat-file' [-t | -s | -e | <type>] <object>
+'git-cat-file' [-t | -s | -e | -p | <type>] <object>
DESCRIPTION
-----------
Provides content or type of objects in the repository. The type
-is required unless '-t' is used to find the object type,
+is required unless '-t' or '-p' is used to find the object type,
or '-s' is used to find the object size.
OPTIONS
@@ -33,6 +33,9 @@ OPTIONS
Suppress all output; instead exit with zero status if <object>
exists and is a valid object.
+-p::
+ Pretty-print the contents of <object> based on its type.
+
<type>::
Typically this matches the real type of <object> but asking
for a type that can trivially be dereferenced from the given
@@ -49,6 +52,8 @@ If '-s' is specified, the size of the <o
If '-e' is specified, no output.
+If '-p' is specified, the contents of <object> are pretty-printed.
+
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
--
1.3.3.g4d548
^ permalink raw reply related
* Re: Slow fetches of tags
From: Junio C Hamano @ 2006-05-25 1:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605241641250.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 24 May 2006, Linus Torvalds wrote:
>>
>> IOW, I think there's something more fundamentally wrong with the tag
>> following. We _should_ have figured out much more quickly that we have it
>> all.
>
> Actually, maybe the problem is that Ralf's tree has two roots, because of
> the old CVS history. It might be following the other root down for the
> "have" part, since that one doesn't exist at all in the target and the
> other side will never acknowledge any of it.
>
> I'll play with it.
I think I know what is going on. You are exactly right -- the
two-root ness is what is causing this.
We used to stop sending "have" immediately after we get an ACK.
This was troublesome for trees with many long branches, so we
introduced multi_ack protocol extension to let the server side
(upload-pack) say "Ok, enough on this branch -- I know this
object so do not tell me any more about objects reachable from
it, but do tell me about other development tracks if you have
one". If you run "fetch-pack -v" after priming a repository
with Ralf's tree and Chris's tree, you will see many "have" with
occasional "got ack 2 [0-9a-f]{40}". The latter is upload-pack
acking this way.
This was done to prevent already-known-to-be-common objects
filling up the list of known common commits on the server side.
The remaining slots can be used to discover common commits on
other branches, so that we can minimize the transfer. It was an
important optimization when dealing with sets of branches that
are long.
This unfortunately breaks down quite badly in this case, since
the remaining "branch" it keeps following is the other history
Chris's tree has never heard of down to its root in vain.
It might be worth changing fetch-pack to note that it has sent
many "have"s after it got an "continue" ACK, and give up early,
say using a heuristic between the age of the commit that did got
an ACK and the one we are about to send out as a "have".
^ permalink raw reply
* [PATCH 1/2] Fix cg-patch hanging on terminals with TOSTOP flag
From: Pavel Roskin @ 2006-05-25 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Pavel Roskin <proski@gnu.org>
Terminals with TOSTOP flag don't allow background processes to write to
the terminal. This flag is used e.g. by the subshell in GNU Midnight
Commander. It can also be set by "stty tostop".
Redirect stdout and strerr of the "patch" command to a temporary file
and show it once "patch" terminates.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
cg-patch | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/cg-patch b/cg-patch
index 9ea7de4..115869e 100755
--- a/cg-patch
+++ b/cg-patch
@@ -337,6 +337,7 @@ # parts of the tree from inadverent poll
[ "$unidiff" ] && newsfile="$(mktemp -t gitapply.XXXXXX)"
gonefile="$(mktemp -t gitapply.XXXXXX)"
todo="$(mktemp -t gitapply.XXXXXX)"
+patchout="$(mktemp -t gitapply.XXXXXX)"
patchfifo="$(mktemp -t gitapply.XXXXXX)"
rm "$patchfifo" && mkfifo -m 600 "$patchfifo"
@@ -347,7 +348,7 @@ # patch file removal behaviour cannot be
# just handle it all ourselves.
patch_args="-p$strip -N"
[ "$reverse" ] && patch_args="$patch_args -R"
-patch $patch_args <"$patchfifo" &
+patch $patch_args <"$patchfifo" >"$patchout" 2>&1 &
tee "$patchfifo" | {
redzone_reset
@@ -407,6 +408,7 @@ tee "$patchfifo" | {
} >$todo
wait %1; ret=$?
+cat "$patchout"
IFS=$'\n' emptyfiles=($(git-ls-files --deleted | join -v 2 "$gonefile" -))
if [ "$unidiff" ]; then
@@ -441,7 +443,7 @@ while [ "$1" ]; do
done
' padding
-rm "$patchfifo" "$todo" "$gonefile"
+rm "$patchfifo" "$todo" "$gonefile" "$patchout"
[ "$unidiff" ] && rm "$newsfile"
exit $ret
^ permalink raw reply related
* [PATCH 2/2] Improve the tutorial script
From: Pavel Roskin @ 2006-05-25 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060525014001.27814.23082.stgit@dv.roinet.com>
From: Pavel Roskin <proski@gnu.org>
Use a function to imitate differern users. Set environment variables so
the the names of the users are actually used in the commits.
Further limit direct use of git. Stop using git for patch transmission.
Use cg-mkpatch and cg-patch instead. Don't even attempt octopus merge
to avoid confusing users.
Don't use obsolete "-d" flag for cg-tag.
Rewrite many comments to make the tutorial more coherent. Group
commands in a more logical way.
Suppress "ed" output. Strip trailing spaces.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
Documentation/tutorial-script/0000-playground.sh | 6 -
Documentation/tutorial-script/script.sh | 237 ++++++++++++----------
2 files changed, 129 insertions(+), 114 deletions(-)
diff --git a/Documentation/tutorial-script/0000-playground.sh b/Documentation/tutorial-script/0000-playground.sh
deleted file mode 100755
index cdfb442..0000000
--- a/Documentation/tutorial-script/0000-playground.sh
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/sh
-
-rm -rf Playground
-mkdir Playground
-cd Playground
-mkdir Alice Bob Charlie
diff --git a/Documentation/tutorial-script/script.sh b/Documentation/tutorial-script/script.sh
index 5b7fc6d..b99e3c9 100755
--- a/Documentation/tutorial-script/script.sh
+++ b/Documentation/tutorial-script/script.sh
@@ -1,15 +1,14 @@
#!/bin/bash
#
-# FIXME: This script has some GITisms. They stem from missing Cogito
-# features, such as exporting patches to mbox format, applying patches
-# from e-mail, merging multiple tags at once, verifying signed tags and
-# repacking the repository.
+# This script serves both as a tutorial explaining how to use Cogito and
+# as a test for Cogito. It's uses as part of the testsuite.
#
-# Not that there would be anything wrong per se with this; GIT and Cogito
-# can interoperate fine (except few quite special situations; see the README
-# for details) and you can mix the commands; Cogito might never provide
-# wrappers for some of the GIT features which are nevertheless awesomely
-# useful, like `git bisect`.
+# This script has a few direct calls to git. They are used when Cogito
+# doesn't provide needed functionality, such as verifying signed tags
+# and repacking the repository.
+#
+# There is anything wrong with this; git and Cogito can interoperate
+# just fine, especially if you don't use git for things Cogito can do.
# This function is appended as "&& should_fail" to commands which should
@@ -28,100 +27,132 @@ set -e
trap 'echo >&2 "Unexpected error $? on line $LINENO"; exit 1' exit
-### Set up playground
-sh 0000-playground.sh
-export PATH=$(pwd)/../..:$PATH # Use the local Cogito version
+# Since this script doubles as a test, prefer the local Cogito version
+# so it can be tested before installation
TOP=$(pwd)
+export PATH=$TOP/../..:$PATH
+
+### Set up the playground
+rm -rf Playground
+mkdir Playground
+cd Playground
+
+# Suppose we have three users: Alice, Bob and Charlie
+mkdir Alice Bob Charlie
ALICE=$TOP/Playground/Alice
BOB=$TOP/Playground/Bob
CHARLIE=$TOP/Playground/Charlie
-cd Playground
-### Alice's first version
-cd $ALICE
+# This function imitates becoming one of the users
+switch_user () {
+ case $1 in
+ Alice) cd "$ALICE";;
+ Bob) cd "$BOB";;
+ Charlie) cd "$CHARLIE";;
+ *) echo "I don't know you, $1"; exit 1;;
+ esac
+ HOME=$(pwd)
+ GIT_AUTHOR_NAME="$1"
+ GIT_AUTHOR_EMAIL="$1@example.com"
+ GIT_COMMITTER_NAME="$1"
+ GIT_COMMITTER_EMAIL="$1@example.com"
+}
+
+
+### Let's start. Pretend you are Alice
+switch_user Alice
+
+# Alice has written an RPN calculator program
tar xf $TOP/0001-alice.tar
cd rpn
# Being a tidy girl, she places it under Cogito
echo "Alice's first version" | cg-init
-cg-tag -d "First ever version of RPN" rpn-0.1
-
-# Alice decides on OSL-2.1
-cd $ALICE/rpn
+# Let it be known as version 0.1
+cg-tag -m "First ever version of RPN" rpn-0.1
+
+# Alice decides to add the license file to the code
cp $TOP/0002-alice-license.txt osl-2.1.txt
-# The new file has to be added
+# Cogito should know that it's a new file to be added
cg-add osl-2.1.txt
-# Fix up the files
+# Notices should be added to the existing files
patch -p1 -i $TOP/0003-alice-osl.patch
-# Now save all, and tag it for later reference
+# Alice commits the changes and tags the result as version 0.2
cg-commit -m "Place under OSL-2.1"
-cg-tag -d "Place under OSL-2.1" rpn-0.2
+cg-tag -m "Place under OSL-2.1" rpn-0.2
-# Alice creates a public repository for the new toy
+# Now Alice creates a public repository for the new toy
cg-admin-setuprepo $ALICE/rpn.git
-cg-branch-add public "$ALICE/rpn.git" # Shortcut for the public repository
-# Alice pushes her master _and_ the two tags to the public repository
+
+# Alice will refer to it as the "public" branch
+cg-branch-add public "$ALICE/rpn.git"
+
+# Alice pushes her master branch and both tags to the public repository
cg-push public -t rpn-0.1 -t rpn-0.2
-### Bob hears about this exciting new program, gets a copy from Alice
-cd $BOB
+### Bob hears about this exciting new program and gets a copy from Alice
+switch_user Bob
cg-clone $ALICE/rpn.git
-
cd rpn
-# Bob thinks the declarations for the stack should go in a header file
+# Bob thinks the declarations for the stack belong to a header file
cp $TOP/0004-bob-stack_h stack.h
patch -p1 -i $TOP/0005-bob-stack_h.patch
-
cg-add stack.h
cg-commit -m "Place stack declarations in header file" \
-m "Create stack.h, move declarations of stack manipulation into it" \
- -m "Include stack.h in rpn.c and stack.h"
+ -m "Include stack.h in rpn.c and stack.h"
-# Later, he remembers he didn't fix the Makefile
+# Just after commit, Bob realizes he didn't fix the Makefile
patch -p1 -i $TOP/0006-bob-Makefile.patch
-
cg-commit -m "Update dependencies for stack.h in Makefile"
### Alice has been busy too...
-cd $ALICE/rpn
+switch_user Alice
+cd rpn
# She adds the 'd'rop operation
patch -p1 -i $TOP/0007-alice-drop.patch
-
cg-commit -m "Add drop command" \
-m "Change rpn.c to add handling for 'd'rop"
# Then she adds 'C'lear, and a first stab at documentation
patch -p1 -i $TOP/0008-alice-clear.patch
cp $TOP/0009-alice-README.txt README
-
cg-add README
cg-commit -m "Add clear stack command" \
-m "Change rpn.c to add handling for 'C'lear" \
-m "Add README file with fist stab at documentation"
# The result works fine, so she prepares to release it
-cg-tag -d "First public release" rpn-0.3
+cg-tag -m "First public release" rpn-0.3
cg-push public -t rpn-0.3
cg-export ../rpn-0.3.tar.bz2
### Bob tells Alice of his changes, Alice prepares to get them.
-cd $ALICE/rpn
+switch_user Alice
+cd rpn
+# Alice creates local branch "bob" to integrate Bob's changes.
cg-switch -r master bob
+
+# Now Alice has branches "master", "public" and "bob" ("bob" is active).
cg-status -g
-# Alice needs to register his remote branch
+# Remote branch "bobswork" is a shortcut to the Bob's master branch
cg-branch-add bobswork $BOB/rpn
-# Now try to merge Bob's work to the bob branch
+
+# Remote branches are "public" and "bobswork".
+cg-branch-ls
+
+# Alice tries to merge Bob's work to the "bob" branch
cg-update bobswork && should_fail
# There are conflicts in rpn.c. Looking at the file, Alice sees the
@@ -132,98 +163,82 @@ #: <<<<<<< bob
#: extern double pop(void);
#: extern void push(double);
#: extern void clear(void);
-#:
+#:
#: =======
#: >>>>>>> bobswork
#: extern int getsym(void);
#: ...
-
-# Alice keeps Bob's version
-ed rpn.c < $TOP/0010-alice-bob-fixup.ed
+
+# Alice keeps Bob's version, i.e. the one from the "bobswork" branch
+ed -s rpn.c < $TOP/0010-alice-bob-fixup.ed
# cg-commit after resolving conflicts from failed merge will autogenerate
# the commit message.
cg-commit </dev/null
-# She fixes up Makefile and stack.h a bit
+# While still on the "bob" branch, Alice fixes up Makefile and stack.h
patch -p1 -i $TOP/0011-alice-cleanup.patch
cg-commit -m "Fix Makefile and stack.h"
-## Charlie heard of RPN, and wants to hack too.
-cd $CHARLIE
-
+### Charlie heard of RPN, and wants to hack too
+switch_user Charlie
cg-clone $ALICE/rpn.git rpn
cd rpn
-# He hacks around, and messes up rpn.c. To restore the saved version:
-rm rpn.c
-cg-restore rpn.c
+# He hacks around, and messes up rpn.c
+echo "Oops!" > rpn.c
-# Finally, he has the changes he wants
+# Fortunately, cg-restore can take care of it
+cg-restore -f rpn.c
+
+# Finally, Charlie has the changes he wants
cp $TOP/0012-charlie-lexer_h lexer.h
patch -p1 -i $TOP/0013-charlie-lexer.patch
-
cg-add lexer.h
cg-commit -m "Add proper header file for lexer" \
-m "Create lexer.h, move lexer declarations into it." \
-m "Include lexer.h in rpn.c and lexer.c" \
-m "Update dependencies in Makefile"
-# Charlie emails the patch to Alice:
-# cg-mkpatch -d .. -r rpn-0.3..master
-git format-patch -o .. --mbox --signoff -r rpn-0.3
-# Only git can create mbox formatted output
-# Compare the result to 0014-charlie-email
+# Charlie prepares the patch and sends it to Alice
+cg-mkpatch -d ../patches -r rpn-0.3..master
+
+# Well, in real life Charlie is more likely to use e-mail than "cp"
+cp -r $CHARLIE/patches $ALICE/patches
### Alice is busy meanwhile...
-cd $ALICE/rpn
+switch_user Alice
+cd rpn
+# She returns to master branch, leaving "bob" for later merging
cg-switch master
+# The calculator gets a new operator
patch -p1 -i $TOP/0015-alice-mod.patch
-
cg-commit -m "Add mod operator" \
-m "Add handling for '%' (fmod(3)) in rpn.c"
+# And then another one
patch -p1 -i $TOP/0016-alice-dup.patch
-
cg-commit -m "Add duplication operator" \
-m "Add handling for 'D'up in rpn.c"
-
+
# Alice publishes her work-in-progress
cg-push public
-
-### Alice gets Charlie's fix, creates a new branch for his changes
-cd $ALICE/rpn
-
+# Alice gets Charlie's fix and creates a new branch for his changes.
+# This time, she starts the branch off the rpn-0.3 tag, which was
+# the base version for Charlie's changes.
cg-switch -r rpn-0.3 charlie
-cg-status -g
-
-# Check what's inside the patch. There is no Cogito equivalent yet.
-git apply --stat $TOP/0014-charlie-email
-git apply --summary $TOP/0014-charlie-email
-git apply --check $TOP/0014-charlie-email
-
-# Everything looks OK
-git applymbox $TOP/0014-charlie-email
-# This doesn't work well yet
-# cg-patch < $TOP/0014-charlie-email
-
-### Alice integrates the changes in the branches for the next release
-cd $ALICE/rpn
+cg-patch -d $ALICE/patches
+# Alice is going to integrate the changes in the "bob" and "charlie"
+# branches into "master" for the next release
cg-switch master
-# Alice tries "git merge" instead of "cg-merge" since she wanted to
-# merge both branches at once, which "cg-merge" cannot do.
-git merge "Integrate changes from Bob and Charlie" master bob charlie \
- && should_fail
-# Automatic 3-way merge fails! Have to do it step by step
-
-cg-reset
+# First, Alice tries to integrate Bob's changes
cg-merge bob && should_fail
# Merge fails:
@@ -239,34 +254,38 @@ #: stack.o: stack.h
#: lexer.o:
#: >>>>>>> bob
-ed Makefile < $TOP/0017-alice-bob-fixup.ed
-
+# Alice fixes Makefile and commits the changes
+ed -s Makefile < $TOP/0017-alice-bob-fixup.ed
cg-commit -m "Integrate Bob's changes"
+# Now it's time to integrate Charlie's changes
cg-merge charlie && should_fail
-# Merge conflicts!
+# Merge fails again! Makefile needs tweaking
#: ...
#: <<<<<<< master
#: $(CC) $(CFLAGS) $^ -lm -o $@
-#:
+#:
#: rpn.o: stack.h
#: stack.o: stack.h
#: lexer.o:
#: =======
#: $(CC) $(CFLAGS) $^ -o $@
-#:
+#:
#: rpn.o lexer.o: lexer.h
-#:
+#:
#: >>>>>>> charlie
-ed Makefile < $TOP/0018-alice-charlie-fixup1.ed
+# Alice fixes Makefile
+ed -s Makefile < $TOP/0018-alice-charlie-fixup1.ed
+
+# rpn.c needs fixing too
#: ...
#: <<<<<<< master
#: extern int getsym(void);
-#:
+#:
#: =======
#: extern double pop(void);
#: extern void push(double);
@@ -275,36 +294,37 @@ #:
#: >>>>>> charlie
#: ...
-ed rpn.c < $TOP/0019-alice-charlie-fixup2.ed
+ed -s rpn.c < $TOP/0019-alice-charlie-fixup2.ed
+# Finally, Charlie's changes can be committed
cg-commit -m "Integrate Charlie's changes"
-# Give proper credits
+# Alice gives proper credits to the contributors
cp $TOP/0020-alice-CONTRIBUTORS.txt CONTRIBUTORS
-
cg-add CONTRIBUTORS
cg-commit -m "Add CONTRIBUTORS"
-# Wrong file name...
+# But maybe it's better to call that file CREDITS?
cg-mv CONTRIBUTORS CREDITS
cg-commit -m "Rename CONTRIBUTORS to CREDITS"
-
-# Pack it so it uses less space
+# Alice packs the repository so it uses less space
git repack
git prune-packed
-# Second public release
-cg-tag -d "New public release" rpn-0.4
+# Now it's time for another public release
+cg-tag -m "Public release of version 0.4" rpn-0.4
cg-push public -t rpn-0.4
cg-export ../rpn-0.4.tar.bz2
-# Also pack public repository
+# The public repository needs packing too
GIT_DIR=$ALICE/rpn.git git repack
GIT_DIR=$ALICE/rpn.git git prune-packed
+
### Bob updates his version to Alice's
-cd $BOB/rpn
+switch_user Bob
+cd rpn
cg-fetch
@@ -314,9 +334,10 @@ # to set up a GPG key before running the
# scripts does not make much sense.)
git verify-tag rpn-0.4 && should_fail
-# Everything's OK, integrate the changes
+# Everything's OK, Bob integrate the changes
cg-merge
-# Great, we are done.
+
+### Great, we are done.
trap - exit
echo "Script completed successfully!"
^ permalink raw reply related
* [PATCH] Built git-upload-tar should be ignored.
From: Shawn Pearce @ 2006-05-25 2:48 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 18a7295..afd0876 100644
--- a/.gitignore
+++ b/.gitignore
@@ -116,6 +116,7 @@ git-update-index
git-update-ref
git-update-server-info
git-upload-pack
+git-upload-tar
git-var
git-verify-pack
git-verify-tag
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Verify git-commit provides a reflog message.
From: Shawn Pearce @ 2006-05-25 3:33 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
The reflog message from git-commit should include the first line
of the commit message as supplied by the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t1400-update-ref.sh | 38 ++++++++++++++++++++++++++------------
1 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f6b076b..2b1f4c8 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -178,22 +178,36 @@ rm -f .git/$m .git/logs/$m expect
test_expect_success \
'creating initial files' \
- 'cp ../../COPYING COPYING &&
- git-add COPYING &&
+ 'echo TEST >F &&
+ git-add F &&
+ GIT_AUTHOR_DATE="2005-05-26 23:30" \
GIT_COMMITTER_DATE="2005-05-26 23:30" git-commit -m add -a &&
- cp ../../Makefile COPYING &&
- GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -m change -a'
+ h_TEST=$(git-rev-parse --verify HEAD)
+ echo The other day this did not work. >M &&
+ echo And then Bob told me how to fix it. >>M &&
+ echo OTHER >F &&
+ GIT_AUTHOR_DATE="2005-05-26 23:41" \
+ GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F m -a &&
+ h_OTHER=$(git-rev-parse --verify HEAD)
+ rm -f m'
+
+cat >expect <<EOF
+$Z $h_TEST $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 commit: add
+$h_TEST $h_OTHER $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150860 +0000 commit: The other day this did not work.
+EOF
+test_expect_success \
+ 'git-commit logged updates' \
+ 'diff expect .git/logs/$m'
+unset h_TEST h_OTHER
test_expect_success \
- 'git-cat-file blob master:COPYING (expect Makefile)' \
- 'git-cat-file blob master:COPYING | diff - ../../Makefile'
+ 'git-cat-file blob master:F (expect OTHER)' \
+ 'test OTHER = $(git-cat-file blob master:F)'
test_expect_success \
- 'git-cat-file blob master@{2005-05-26 23:30}:COPYING (expect COPYING)' \
- 'git-cat-file blob "master@{2005-05-26 23:30}:COPYING" \
- | diff - ../../COPYING'
+ 'git-cat-file blob master@{2005-05-26 23:30}:F (expect TEST)' \
+ 'test TEST = $(git-cat-file blob "master@{2005-05-26 23:30}:F")'
test_expect_success \
- 'git-cat-file blob master@{2005-05-26 23:42}:COPYING (expect Makefile)' \
- 'git-cat-file blob "master@{2005-05-26 23:42}:COPYING" \
- | diff - ../../Makefile'
+ 'git-cat-file blob master@{2005-05-26 23:42}:F (expect OTHER)' \
+ 'test OTHER = $(git-cat-file blob "master@{2005-05-26 23:42}:F")'
test_done
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Test that git-branch -l works.
From: Shawn Pearce @ 2006-05-25 3:34 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
If the user supplies -l to git-branch when creating a new branch
then the new branch's log should be created automatically and the
branch creation should be logged in that log.
Further if a branch is being deleted and it had a log then also
verify that the log was deleted.
Test git-checkout -b foo -l for creating a new branch foo with a
log and checking out that branch.
Fixed git-checkout -b foo -l as the branch variable name was
incorrect in the script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-checkout.sh | 4 ++--
t/t3200-branch.sh | 31 ++++++++++++++++++++++++++++++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 360aabf..564117f 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -197,8 +197,8 @@ #
if [ "$?" -eq 0 ]; then
if [ "$newbranch" ]; then
if [ "$newbranch_log" ]; then
- mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
- touch "$GIT_DIR/logs/refs/heads/$branchname"
+ mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$newbranch")
+ touch "$GIT_DIR/logs/refs/heads/$newbranch"
fi
git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
branch="$newbranch"
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index c3de151..5b04efc 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -14,7 +14,8 @@ test_expect_success \
'prepare an trivial repository' \
'echo Hello > A &&
git-update-index --add A &&
- git-commit -m "Initial commit."'
+ git-commit -m "Initial commit." &&
+ HEAD=$(git-rev-parse --verify HEAD)'
test_expect_success \
'git branch --help should return success now.' \
@@ -32,4 +33,32 @@ test_expect_success \
'git branch a/b/c should create a branch' \
'git-branch a/b/c && test -f .git/refs/heads/a/b/c'
+cat >expect <<EOF
+0000000000000000000000000000000000000000 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from HEAD
+EOF
+test_expect_success \
+ 'git branch -l d/e/f should create a branch and a log' \
+ 'GIT_COMMITTER_DATE="2005-05-26 23:30" \
+ git-branch -l d/e/f &&
+ test -f .git/refs/heads/d/e/f &&
+ test -f .git/logs/refs/heads/d/e/f &&
+ diff expect .git/logs/refs/heads/d/e/f'
+
+test_expect_success \
+ 'git branch -d d/e/f should delete a branch and a log' \
+ 'git-branch -d d/e/f &&
+ test ! -f .git/refs/heads/d/e/f &&
+ test ! -f .git/logs/refs/heads/d/e/f'
+
+cat >expect <<EOF
+0000000000000000000000000000000000000000 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 checkout: Created from master^0
+EOF
+test_expect_success \
+ 'git checkout -b g/h/i -l should create a branch and a log' \
+ 'GIT_COMMITTER_DATE="2005-05-26 23:30" \
+ git-checkout -b g/h/i -l master &&
+ test -f .git/refs/heads/g/h/i &&
+ test -f .git/logs/refs/heads/g/h/i &&
+ diff expect .git/logs/refs/heads/g/h/i'
+
test_done
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] ls-remote fix for rsync:// transport
From: Junio C Hamano @ 2006-05-25 4:22 UTC (permalink / raw)
To: git
I think this would fix the "cloning rsync:// clones repository fine but
does not check out the working tree" problem.
---
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index b6882a9..6b21879 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -58,7 +58,8 @@ http://* | https://* )
;;
rsync://* )
- mkdir $tmpdir
+ mkdir $tmpdir &&
+ rsync -rlq "$peek_repo/HEAD" $tmpdir &&
rsync -rq "$peek_repo/refs" $tmpdir || {
echo "failed slurping"
exit
@@ -69,6 +70,13 @@ rsync://* )
cat "$tmpdir/$path" | tr -d '\012'
echo " $path"
done &&
+ head=$(cat "$tmpdir/HEAD") &&
+ case "$head" in
+ ref:' '*)
+ head=$(expr "z$head" : 'zref: \(.*\)') &&
+ head=$(cat "$tmpdir/$head") || exit
+ esac &&
+ echo "$head HEAD"
rm -fr $tmpdir
;;
^ permalink raw reply related
* importing cvs logical modules
From: Geoff Russell @ 2006-05-25 4:48 UTC (permalink / raw)
To: git
Hi,
Firstly, the code to automagically
repack a git repository on-the-fly during a big load has solved one of
my problems - thanks, it is great. Unfortunately it has bought me to
showstopper number 2.
- cvs modules.
cvs allows you to define modules which rearrange the physical repository into
a different logical structure. This sounds great and we use it, but it gives
us other headaches because "cvs update" doesn't always do the right
thing with these modules.
Furthermore cvsps doesn't appear to handle this module feature at all and
is tricked into thinking that rearranged directories come from somewhere
else and issues its "file xxx doesn't match strip_path" message.
I have tried to hack cvsps to go around the problem, but without success.
Another alternative that I thought might be easier would be to unload the cvs
repository in clean pieces - each being a git repository. Then to join the
git repositories together in the desired way. I think this would be
generally useful and not just solve my problem.
e.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy
Progs/.git
xxxx/.git
yyyy/.git
I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
Progs/.git
Progs/xxxx
Progs/yyyy
Does this sound useful to anyone else, or is it already possible?
Cheers,
Geoff Russell.
^ permalink raw reply
* Re: Slow fetches of tags
From: Junio C Hamano @ 2006-05-25 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vd5e23n5a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It might be worth changing fetch-pack to note that it has sent
> many "have"s after it got an "continue" ACK, and give up early,
> say using a heuristic between the age of the commit that did got
> an ACK and the one we are about to send out as a "have".
I think the right fix for this is to change upload-pack to
traverse reachability chain from the "want" heads as it gets
"have" from the downloader, and stop responding "continue" when
all "want" heads can reach some "have" commits. This would not
prevent it from going down all the way to the root commit if
what is wanted does not have anything to do with what the other
end has (e.g. if you have only my main project branches, and you
ask for html head for the first time), but it would have
prevented Ralf's tree from getting "continue" after he asked
only for v2.6.16.18 tag and said he has 2.6.16.18 commit and its
ancestors. It should not be too difficult to do this, but here
is an alternative, client-side workaround.
-- >8 --
[PATCH] fetch-pack: give up after getting too many "ack continue"
If your repository have more roots than the remote repository
you ask an object for, the remote upload-pack keeps responding
"ack continue" until it fills up its received-have buffer
(currently 256 entries). Usually this is not a problem because
the requester stops traversing the ancestry chain from the commit
it gets "ack continue" for, but this mechanism does not work as
a roadblock when it traverses down the path to the root the
other side does not have.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 8daa93d..8371348 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -18,6 +18,12 @@ #define COMMON_REF (1U << 2)
#define SEEN (1U << 3)
#define POPPED (1U << 4)
+/*
+ * After sending this many "have"s if we do not get any new ACK , we
+ * give up traversing our history.
+ */
+#define MAX_IN_VAIN 256
+
static struct commit_list *rev_list = NULL;
static int non_common_revs = 0, multi_ack = 0, use_thin_pack = 0;
@@ -134,6 +140,8 @@ static int find_common(int fd[2], unsign
int fetching;
int count = 0, flushes = 0, retval;
const unsigned char *sha1;
+ unsigned in_vain = 0;
+ int got_continue = 0;
for_each_ref(rev_list_insert_ref);
@@ -172,6 +180,7 @@ static int find_common(int fd[2], unsign
packet_write(fd[1], "have %s\n", sha1_to_hex(sha1));
if (verbose)
fprintf(stderr, "have %s\n", sha1_to_hex(sha1));
+ in_vain++;
if (!(31 & ++count)) {
int ack;
@@ -200,9 +209,16 @@ static int find_common(int fd[2], unsign
lookup_commit(result_sha1);
mark_common(commit, 0, 1);
retval = 0;
+ in_vain = 0;
+ got_continue = 1;
}
} while (ack);
flushes--;
+ if (got_continue && MAX_IN_VAIN < in_vain) {
+ if (verbose)
+ fprintf(stderr, "giving up\n");
+ break; /* give up */
+ }
}
}
done:
^ permalink raw reply related
* Re: importing cvs logical modules
From: Jakub Narebski @ 2006-05-25 4:56 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com>
Geoff Russell wrote:
> Then to join the git repositories together in the desired way. I think
> this would be generally useful and not just solve my problem.
>
> e.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy
>
> Progs/.git
> xxxx/.git
> yyyy/.git
>
> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
>
> Progs/.git
> Progs/xxxx
> Progs/yyyy
>
> Does this sound useful to anyone else, or is it already possible?
It is done. TODO branch in git.git repository on kernel.org is pushed to
from *separate* git-todo.git repository. BTW. working are of repositories
can be joined (although it needs entry in .gitignore):
Progs/.git
Progs/TODO/.git
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: importing cvs logical modules
From: Junio C Hamano @ 2006-05-25 5:01 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com>
"Geoff Russell" <geoffrey.russell@gmail.com> writes:
> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
>
> Progs/.git
> Progs/xxxx
> Progs/yyyy
>
> Does this sound useful to anyone else, or is it already possible?
I would do it like this:
Progs/.git
Progs/xxxx/.git
Progs/yyyy/.git
I do not know what you have in Progs/ hierarchy -- if it is just
scaffolding to house subdirectories and nothing else you may not
even need Progs/.git repository.
This is a very useful and handy structure, and you do not need
any tool support once you have these as separate repositories.
If you want a single distribution point, you can push from these
separate repositories into separate branches of a single
distribution point repository [*1*].
One potential disadvantage is that you would not get revision
linkage between these "modules", but not having tight linkage is
the point of modular structure, so depending on your workflow it
probably may not matter.
[Footnote]
*1* In fact, my git working area has the "master", "next" or
"pu" branch checked out in /path/to/work/area/git (and the
repository is in /path/to/work/area/git/.git directory), and I
check out the "todo" branch in /path/to/work/area/git/Meta
directory, with /path/to/work/area/git/Meta/.git directory as
its repository.
^ permalink raw reply
* Re: [PATCH] ls-remote fix for rsync:// transport
From: Sean @ 2006-05-25 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4a3f9i.fsf@assigned-by-dhcp.cox.net>
On Wed, 24 May 2006 21:22:17 -0700
Junio C Hamano <junkio@cox.net> wrote:
> I think this would fix the "cloning rsync:// clones repository fine but
> does not check out the working tree" problem.
Nice find, works here.
Sean
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyjpz9a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Can we fix the check in upload-pack.c something like my
>> patch below does? Are there any security implications for
>> doing that?
>
>> Could we just make the final check before dying if (!o) ?
>
> The primary implication is about correctness, so I am reluctant
> to break it without a careful alternative check in place.
>
> The issue is that having a single object in the repository does
> not guarantee that you have everything reachable from it, and we
> need that guarantee. Reachability from the refs is what
> guarantees that.
I don't see why having something reachable from a ref guarantees
that everything is reachable. Given the recent patch that added
a check to make certain a ref actually existed I believe there
is some evidence that trees may become corrupted, and have the
problems you describe.
> We are careful to update the ref at the very end of the transfer
> (fetch/clone or push); so if an object is reachable from a ref,
> then all the objects reachable from that object are available in
> the repository.
In the normal case I agree.
> Imagine http commit walker started fetching tip of upstream into
> your repository and you interrupted the transfer. Objects near
> the tip of the upstream history are available after such an
> interrupted transfer. But a bit older history (but still later
> than what we had before we started the transfer) are not.
>
> We do not update the ref with the downloaded tip object, so that
> we would not break the guarantee. This guarantee is needed for
> feeding clients from the repository later. If you tell your
> clients, after such an interrupted transfer, that you are
> willing to serve the objects near the (new) tip, the clients may
> rightfully request objects that are reachable from these
> objects, some of them you do _not_ have!
I clearly would not advertise it. My problem is that I have
evidence that someone pulled a given sha1 at some point from
some branch on a given repository. But I don't have that branch.
Actually trees mirrored with rsync have similar problems all of
the time when the catch a tree in the middle of an update.
> So this "on demand SHA1" stuff needs to be solved by checking if
> the given object is reachable from our refs in upload-pack,
> instead of the current check to see if the given object is
> pointed by our refs. When upload-pack can prove that the object
> is reachable from one of the refs, it is OK to use it; otherwise
> you should not.
I have a problem with that approach. Suppose the branch I have
evidence something came from is like your pu branch. If I want
a copy of your pu branch at some point in the past, but you have
rebased it since that sha1 was published then there will clearly not
be a path from any current head to that branch. But if I still have a
copy of the sha1 I should actually be able to recover the old copy of
the pu branch from your tree.
> Now, proving that a given SHA1 is the name of an object that
> exists in the repository is cheap (has_sha1_file()), but proving
> that the object is reachable from some of our refs can become
> quite expensive. That gives this issue a security implication
> as well -- you can easily DoS the git-daemon that way, for
> example.
Exactly, which is why I aimed for the cheap test.
There is a reasonable argument that can be made that the branches
represent the policy that you are willing to serve. If you have a
tree and share a common object store with a much lager tree, like
David Woodhouse has set up, I can see such a policy being desirable.
That is an argument I have a much harder time shooting down.
At the same time if it is just a policy question the policy it should
be modifiable with an appropriate configuration directive, or
command line option.
Eric
^ permalink raw reply
* Re: importing cvs logical modules
From: Geoff Russell @ 2006-05-25 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslmyzoit.fsf@assigned-by-dhcp.cox.net>
On 5/25/06, Junio C Hamano <junkio@cox.net> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
> > I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
> >
> > Progs/.git
> > Progs/xxxx
> > Progs/yyyy
> >
> > Does this sound useful to anyone else, or is it already possible?
>
> I would do it like this:
>
> Progs/.git
> Progs/xxxx/.git
> Progs/yyyy/.git
>
> I do not know what you have in Progs/ hierarchy -- if it is just
> scaffolding to house subdirectories and nothing else you may not
> even need Progs/.git repository.
>
> This is a very useful and handy structure, and you do not need
> any tool support once you have these as separate repositories.
> If you want a single distribution point, you can push from these
> separate repositories into separate branches of a single
> distribution point repository [*1*].
>
> One potential disadvantage is that you would not get revision
> linkage between these "modules", but not having tight linkage is
> the point of modular structure, so depending on your workflow it
> probably may not matter.
The tight linkage is absolutely essential.
When we tag the system, we
want to tag everything (not individually tag all 300 programs)
so that later we can to branch at that tag. Very few of our
programs are self contained, they generally make heavy use
of one or more libraries --- which must also be part of the
tree. The full structure should end up looking like:
Top/.git
Libraries/libx
Libraries/liby
Libraries/boost
Libraries/...
Programs/xxx
Programs/yyy
Programs/...
...etc.
When we build a full system, we want to tag that point so
we can know exactly what went into that build.
We used to do it the "other" way.
cvsroot/xxx
cvsroot/yyy
cvsroot/liby
cvsroot/libx
etc
But then when we did a system build, someone always forgot
to tag something. So we got cvs to build a build logical tree
and then cvs was quite happy to tag the lot with one go and
nothing got forgotten. So now we are trying to pull the
lot into git as one big tree.
Cheers,
Geoff.
>
>
> [Footnote]
>
> *1* In fact, my git working area has the "master", "next" or
> "pu" branch checked out in /path/to/work/area/git (and the
> repository is in /path/to/work/area/git/.git directory), and I
> check out the "todo" branch in /path/to/work/area/git/Meta
> directory, with /path/to/work/area/git/Meta/.git directory as
> its repository.
>
>
^ permalink raw reply
* Re: importing cvs logical modules
From: Martin Langhoff @ 2006-05-25 6:16 UTC (permalink / raw)
To: geoff; +Cc: Junio C Hamano, git
In-Reply-To: <93c3eada0605242302x24ca1272xd7bfc3a677b32845@mail.gmail.com>
On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> The tight linkage is absolutely essential.
>
> When we tag the system, we
> want to tag everything (not individually tag all 300 programs)
> so that later we can to branch at that tag. Very few of our
Then you want a single git repo/tree/project. The thing is how to work
through your mangled CVS history.
Two options there...
- Don't. Import from after the last directory reorg or from your last
interesting release. Keep the cvs tree for people who really want to
dig into the past. this has several advantages, as initial checkouts
will be faster, import times shorter, less pain overall.
- Mangle import to match your reorganizations:
- Generate the cvsps output file
- Duplicate/copy files in the cvs repo so that files are in both
places if you've been mving them around.
- Mangle the cvsps output file from each reorg onwards. This is
nasty, but it will define the history that cvsimport sees.
cheers,
martin
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-25 6:36 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m13beysnb2.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> I clearly would not advertise it. My problem is that I have
> evidence that someone pulled a given sha1 at some point from
> some branch on a given repository. But I don't have that branch.
If that was over rsync (as you mention later), then I would
consider that is an unfortunate unfixable issue. rsync mirrors
are fundamentally unsafe for git -- Linus and I do not keep
saying rsync should be deprecated without good reasons.
There still might be bugs that breaks this guarantee outside
rsync, but if that is the case we should fix it.
I do not want to rehash the thread around Sep 29th 2005 here.
The entry point of that thread is this message:
http://marc.theaimsgroup.com/?l=git&m=112795140820665
and the punch line are these two messages:
http://marc.theaimsgroup.com/?l=git&m=112801874021223
http://marc.theaimsgroup.com/?l=git&m=112802808030710
I did not realize what I was breaking initially. I am not
ashamed of having been wrong, but it was embarrassing ;-).
> If I want
> a copy of your pu branch at some point in the past, but you have
> rebased it since that sha1 was published then there will clearly not
> be a path from any current head to that branch. But if I still have a
> copy of the sha1 I should actually be able to recover the old copy of
> the pu branch from your tree.
Not necessarily. I occasionally prune after rewinding. When my
"pu" branch head does not point at the lost commit, the
repository may or may not have that object you happen to know I
used to have anymore.
>> Now, proving that a given SHA1 is the name of an object that
>> exists in the repository is cheap (has_sha1_file()), but proving
>> that the object is reachable from some of our refs can become
>> quite expensive. That gives this issue a security implication
>> as well -- you can easily DoS the git-daemon that way, for
>> example.
>
> Exactly, which is why I aimed for the cheap test.
But the thing is the cheap test is broken, eh, rather,
propagates brokenness downstream (which is perhaps worse).
^ permalink raw reply
* Re: importing cvs logical modules
From: Geoff Russell @ 2006-05-25 6:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605242316l4b0a0963m638f7a2e47936000@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> > The tight linkage is absolutely essential.
> >
> > When we tag the system, we
> > want to tag everything (not individually tag all 300 programs)
> > so that later we can to branch at that tag. Very few of our
>
> Then you want a single git repo/tree/project. The thing is how to work
> through your mangled CVS history.
>
> Two options there...
>
> - Don't. Import from after the last directory reorg or from your last
> interesting release. Keep the cvs tree for people who really want to
> dig into the past. this has several advantages, as initial checkouts
> will be faster, import times shorter, less pain overall.
Yes, this is definitely on the shortlist of options.
If we can't keep all the history, we may as well make
a clean start. Thanks for the advice.
Cheers,
Geoff.
^ permalink raw reply
* Re: importing cvs logical modules
From: Jakub Narebski @ 2006-05-25 7:02 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0605242359k204bfe79vabc323eddfafa5f@mail.gmail.com>
Geoff Russell wrote:
> On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>>> The tight linkage is absolutely essential.
>>>
>>> When we tag the system, we
>>> want to tag everything (not individually tag all 300 programs)
>>> so that later we can to branch at that tag. Very few of our
>>
>> Then you want a single git repo/tree/project. The thing is how to work
>> through your mangled CVS history.
>>
>> Two options there...
>>
>> - Don't. Import from after the last directory reorg or from your last
>> interesting release. Keep the cvs tree for people who really want to
>> dig into the past. this has several advantages, as initial checkouts
>> will be faster, import times shorter, less pain overall.
>
> Yes, this is definitely on the shortlist of options.
> If we can't keep all the history, we may as well make
> a clean start. Thanks for the advice.
Well, you can always copy history and graft old CVS history later. Perhaps
when "bind" (or Cogito "bind lite") mature enough...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* parsecvs fails
From: Aneesh Kumar @ 2006-05-25 11:32 UTC (permalink / raw)
To: Git Mailing List
The tagging used by the repository given below is quiet complex.
But it can be used as a test case for all the cvs to git converter.
Even ViewVC and ViewCVS doesn't work with this repository.
Any help in converting it to git ?
rsync -av rsync://ci-linux.cvs.sourceforge.net/cvsroot/ci-linux/ci/ ci-linux/ci/
-aneesh
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Björn Engelmann @ 2006-05-25 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wuj6wln.fsf@assigned-by-dhcp.cox.net>
> Sorry, I forgot all about hash-objects X-<. It was a convenient
> way to try out new things such as 'gitlink'. Thanks for the
> clarification.
>
> As to unification, I am not sure if there are a lot to unify.
> Everybody starts with type, length and a LF, but after that each
> type has its own format constraints. A grand unified command
> that knows about format constraints of every type under the sun
> does not sound like a good approach. While we have only handful
> types (and I expect things will stay that way) it is not a big
> deal either way, though.
>
Oops, sorry, I forgot that "modular" in C means something else than in
the OO-World...
You are right. Probably it is best to have one tool handle each type.
Actually what I am aiming for is not the internal structure. I am more
concerned about cleaning up the user-interface. When I started learning
git I found it very annoying and inconsistent that there are commands
for creating a tag and a tree in a validated fashion, but the command
for creating blobs was named "git-hash-object -w" and also could create
all other objects without validating them at all. Also, AFAIK there is
currently no way of creating a commit object with validating.
I am well aware that all functionality neccessary already exists. I just
want to prevent people learning git in future to have the same
frustrating experience as I did.
Obviously renaming / moving code around like that would break nearly all
tools build ontop of git. Therefore I would prefer to use aliasing. If
you feel like this would introduce too many unneccessary commands, I
would instead focus on improving the documentation.
Bj
^ 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