* Re: [ANNOUNCE] GIT 1.2.1
From: Michael Fischer @ 2006-02-18 4:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmkrizuw.fsf@assigned-by-dhcp.cox.net>
*sigh*
I got confused about git pull origin and git pull master.
Tutorial seems to tell me I should have said git pull origin
and left well enough alone.
Now I get:
fatal: you need to resolve your current index first
How do I do that?
TIA.
Michael
--
Michael Fischer Happiness is a config option.
michael@visv.net Recompile and be happy.
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Andreas Ericsson @ 2006-02-18 2:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim O'Callaghan, git
In-Reply-To: <Pine.LNX.4.63.0602180109480.525@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 17 Feb 2006, Tim O'Callaghan wrote:
>
>
>>On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
>>
>>>On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>
>>>>I just got git to work on an Irix box. These are the changes I needed
>>>>to apply. Maybe some of them are of use for other ancient systems... You
>>>>know, I like ancient systems. And if I could get my hands on a VMS, I
>>>>would try to get git to work on it, too ;-)
>>>
>>>You can get free VMS accounts at the Deathrow Cluster:
>>>http://deathrow.vistech.net/
>>>
>>>If you're serious about using your account, you'll find that the admin
>>>team is pretty supportive and friendly.
>>
>>You should check out polarhome.com if you want a variety of platforms
>>to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
>>etc.
>>
>>I work on VMS systems at the moment and i thought of attempting to
>>port git for the hell of it. I decided not to bother for a variety of
>>reasons, but mostly because it looked like too much work :)
>
>
> Well, I did not remember that VMS does not have a proper fork() call.
It doesn't. It's got vfork() though.
> BTW, my remark about VMS was more tongue-in-cheek than not...
>
Thanks anyway. I would never have gotten that link to polarhome if you'd
kept your tongue straight.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Junio, you are a genius.
From: Johannes Schindelin @ 2006-02-18 2:12 UTC (permalink / raw)
To: git
Hi,
Earlier, I avoided to repack too often, since "repack -a -d" was too
expensive, and small incremental packs were inefficient.
Now, with the reusing delta patch, "repack -a -d" is marginally less
efficient than incremental packs. No longer worry about when to repack:
Just do it! No need for incremental packs!
Hero!
Ciao,
Dscho
^ permalink raw reply
* Re: stGIT: commit vs export vs mail
From: Jesse Brandeburg @ 2006-02-18 2:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jesse Brandeburg, git
In-Reply-To: <43F64A51.10607@gmail.com>
On Fri, 17 Feb 2006, Catalin Marinas wrote:
> Jesse Brandeburg wrote:
>> So I am using stgit .8 right now, and I'm having a hard time figuring
>> out what the correct workflow should be for using stg and then
>> committing a change
>>
>> Here is what I've been doing:
>> stg new test
>> enter my short description on first line
>> enter my long description on next lines.
>> vi file
>> stg refresh
>> stg mail <blah blah blah>
>> or
>> stg commit
>
> There is no "or" above but only "and maybe". The 'commit' command is
> only used to permanently store a set of patches into the repository.
> After that, you should not be able to change them anymore (well, someone
> just sent me a patch for an uncommit command). I only use this command
> when I work in the "maintainer" mode on StGIT. For contributing patches,
> you shouldn't need it since the base of the stack should usually be
> identical to the HEAD of the remote repository.
I'm trying to commit changes to a local repository so that the maintainer
can do a "pull" off of my repository.
>> Problem that I'm having right now is that the templates do the right
>> thing for mail, but, the commit only puts in the "enter my..." text.
>
> I don't fully understand this. Where does commit put the "enter my..." text?
so I used stgit to commit this change. It puts it in the git log of
checkins for the repository.
[jbrandeb@lindenhurst-2 e1000]$ git log | head -n 20
commit fb16b7111dae51b9a928aa7706d1cc022df8741d
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Fri Feb 17 11:29:19 2006 -0800
e1000: update readme
Update the e1000 text to the latest version
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> Is there a template based way to automatically append the author in the
>> Signed-off-by: line when i do stg commit?
>
> This can only be done when creating a patch. Commit doesn't modify the
> patches. I think you slightly misunderstood the commit command.
the stgit command stg commit freezes patches that I've made into my
repository. I think I get that, but I've been wrong before. Its just
that I can template the Signed-off-by: line for emails, but when I do a
stg commit I want the thing to have the Signed-off-by: line in the commit
text (like above where I added it by hand)
I guess I'll just change my templates to not auto add the Signed-off-by
line and then things will work okay, as I'll just add the line during stg
new ...
Thanks for your reply, and the cool tool!
Jesse
^ permalink raw reply
* [PATCH] Document --short and --git-dir in git-rev-parse(1)
From: Jonas Fonseca @ 2006-02-18 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 013b99654ee464856d266a72f0203d0fee2b0d11
tree 3c961d6ebb8b9805ee3950ec081679de15f5a9ba
parent 16e2efc524d181cf46dcb252532139a0aff4a28f
author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:05:11 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:05:11 +0100
Documentation/git-rev-parse.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index d638bfc..1662e06 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -77,6 +77,14 @@ OPTIONS
path of the top-level directory relative to the current
directory (typically a sequence of "../", or an empty string).
+--git-dir::
+ Show `$GIT_DIR` if defined else show the path to the .git directory.
+
+--short, short=number::
+ Instead of outputting the full SHA1 values of object names try to
+ abbriviate them to a shorter unique name. When no length is specified
+ 7 is used. The minimum length is 4.
+
--since=datestring, --after=datestring::
Parses the date string, and outputs corresponding
--max-age= parameter for git-rev-list command.
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] git-rev-parse: Fix --short= option parsing
From: Jonas Fonseca @ 2006-02-18 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 16e2efc524d181cf46dcb252532139a0aff4a28f
tree c57ea8bf09b25fb643aadd224e7e73673187cc60
parent b867c7c23a42fbe9f261153a9814a5efbc071a29
author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:04:26 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:04:26 +0100
rev-parse.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/rev-parse.c b/rev-parse.c
index b82f294..70a8271 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -225,12 +225,12 @@ int main(int argc, char **argv)
continue;
}
if (!strcmp(arg, "--short") ||
- !strncmp(arg, "--short=", 9)) {
+ !strncmp(arg, "--short=", 8)) {
filter &= ~(DO_FLAGS|DO_NOREV);
verify = 1;
abbrev = DEFAULT_ABBREV;
- if (arg[8] == '=')
- abbrev = strtoul(arg + 9, NULL, 10);
+ if (arg[7] == '=')
+ abbrev = strtoul(arg + 8, NULL, 10);
if (abbrev < MINIMUM_ABBREV)
abbrev = MINIMUM_ABBREV;
else if (40 <= abbrev)
--
Jonas Fonseca
^ permalink raw reply related
* Re: diffstat wierdness with 'git format-patch' output
From: Greg KH @ 2006-02-18 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd72v2jp.fsf@assigned-by-dhcp.cox.net>
On Mon, Feb 13, 2006 at 11:10:18PM -0800, Junio C Hamano wrote:
> Greg KH <greg@kroah.com> writes:
>
> > Hm, git-send-email doesn't see this, so it doesn't get sent out if you
> > use that tool.
>
> And people are very likely to remove it by hand.
>
> Another possibility would be to use "git apply --numstat" and
> add numbers up in your script, but that would not give you a
> nice graph output either X-<.
>
> I'd say if you really care we should just remove those two
> lines, and remember I am _very_ receptive from such suggestion
> from prominent kernel people.
Hm, in thinking about this some more, I realized that it only requires
me to change my script to generate the emails for Linus to pull from a
tiny bit, making this whole thing not a bit deal at all.
Thanks a lot for being so receptive, if I have further problems with it,
I'll let you know.
greg k-h
^ permalink raw reply
* [PATCH] Prevent git-upload-pack segfault if object cannot be found
From: Carl Worth @ 2006-02-18 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
Signed-off-by: Carl Worth <cworth@cworth.org>
---
It's probably a just-don't-do-that situation, but I did-it by moving a
directory that had already been cached in objects/info/alternates by
clone -l -s. Here's a fix for the segfault that that turned up.
Probably trivial enough to not bother the list with, but I'm still
learning about formatting patches and mails and things, so I'm open to
any feedback if I'm getting anything wrong.
sha1_file.c | 4 +++-
upload-pack.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 64cf245..1d799f7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -551,8 +551,10 @@ static void prepare_packed_git_one(char
sprintf(path, "%s/pack", objdir);
len = strlen(path);
dir = opendir(path);
- if (!dir)
+ if (!dir) {
+ fprintf(stderr, "unable to open object pack directory: %s: %s\n", path, strerror(errno));
return;
+ }
path[len++] = '/';
while ((de = readdir(dir)) != NULL) {
int namelen = strlen(de->d_name);
diff --git a/upload-pack.c b/upload-pack.c
index d198055..3606529 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -216,6 +216,9 @@ static int send_ref(const char *refname,
static char *capabilities = "multi_ack";
struct object *o = parse_object(sha1);
+ if (!o)
+ die("git-upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+
if (capabilities)
packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname,
0, capabilities);
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 0/5] Support ancient systems
From: Johannes Schindelin @ 2006-02-18 0:14 UTC (permalink / raw)
To: Tim O'Callaghan; +Cc: git
In-Reply-To: <20060217170345.GB3468@ELSAMSW37164>
Hi,
On Fri, 17 Feb 2006, Tim O'Callaghan wrote:
> On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
> > On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > I just got git to work on an Irix box. These are the changes I needed
> > > to apply. Maybe some of them are of use for other ancient systems... You
> > > know, I like ancient systems. And if I could get my hands on a VMS, I
> > > would try to get git to work on it, too ;-)
> >
> > You can get free VMS accounts at the Deathrow Cluster:
> > http://deathrow.vistech.net/
> >
> > If you're serious about using your account, you'll find that the admin
> > team is pretty supportive and friendly.
>
> You should check out polarhome.com if you want a variety of platforms
> to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
> etc.
>
> I work on VMS systems at the moment and i thought of attempting to
> port git for the hell of it. I decided not to bother for a variety of
> reasons, but mostly because it looked like too much work :)
Well, I did not remember that VMS does not have a proper fork() call. So
maybe it would be easier to port git to MinGW32 first...
BTW, my remark about VMS was more tongue-in-cheek than not...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Johannes Schindelin @ 2006-02-17 23:29 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <11491.1140196527@lotus.CS.Berkeley.EDU>
Hi,
On Fri, 17 Feb 2006, Jason Riedy wrote:
> And Johannes Schindelin writes:
> -
> - Some version of GNU make do not understand $(call), and have
> - problems to interpret rules like this:
>
> Is building a newer version of GNU make impossible on Irix?
No. But it is annoying to be forced to upgrade every second package. If
there'd be some real benefit, then okay, I'd do it. But there is really no
point in not supporting the old version.
Besides, in some environments you are just not allowed to go wild
installing programs. And in some environments, you just don't have the
quota.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] git-repack question
From: Linus Torvalds @ 2006-02-17 22:20 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20060217213824.5848.qmail@science.horizon.com>
On Fri, 17 Feb 2006, linux@horizon.com wrote:
>
> I'm trying to imagine when you'd want to run git-repack without the -d
> option, or without running git-prune-packed afterwards.
> (Isn't the idea behind packs to save space?)
Normally you'd always run git-prune-packed.
The reason it doesn't do that is simply being anally careful, and because
conceptually the pruning phase is totally independent.
For example, in an environment that mirrors out git repositories by rsync,
it can make sense to wait with pruning until the mirror cycle has
finished, so that all mirrors always have all the objects.
(I don't do it for the kernel, because (a) I'm a lazy bastard, (b) I'm so
confused that I sometimes forget my own name, much less to prune things a
day after I've repacked them and (c) I don't care that much about rsync
anyway, since you can't avoid some of the _other_ races).
As to whether you'd normally run "-d" - usually you'd run it whenever you
pair it up with "-a". When you do an incremental re-pack, "-d" won't do
anything anyway.
Again, it might make sense to not delete the old packs when repacking
everything in a rsync'ing environment - or even in a shared repository,
where removing a pack-file could race with somebody else working on it.
Basically, the default ends up being to never remove any objects at all,
simply because that's the _safe_ thing to do.
In practice, I personally always do
git repack -a -d
git prune-packed
together, because the full repack isn't _that_ expensive for me (I tend to
have lots of cpu power), and because I can't be bothered to worry too much
about rsync and there are never any other users working on my git trees.
Linus
^ permalink raw reply
* Re: stGIT: commit vs export vs mail
From: Catalin Marinas @ 2006-02-17 22:12 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: git
In-Reply-To: <Pine.WNT.4.63.0602171139020.3052@jbrandeb-desk.amr.corp.intel.com>
Jesse Brandeburg wrote:
> So I am using stgit .8 right now, and I'm having a hard time figuring
> out what the correct workflow should be for using stg and then
> committing a change
>
> Here is what I've been doing:
> stg new test
> enter my short description on first line
> enter my long description on next lines.
> vi file
> stg refresh
> stg mail <blah blah blah>
> or
> stg commit
There is no "or" above but only "and maybe". The 'commit' command is
only used to permanently store a set of patches into the repository.
After that, you should not be able to change them anymore (well, someone
just sent me a patch for an uncommit command). I only use this command
when I work in the "maintainer" mode on StGIT. For contributing patches,
you shouldn't need it since the base of the stack should usually be
identical to the HEAD of the remote repository.
> Problem that I'm having right now is that the templates do the right
> thing for mail, but, the commit only puts in the "enter my..." text.
I don't fully understand this. Where does commit put the "enter my..." text?
> Is there a template based way to automatically append the author in the
> Signed-off-by: line when i do stg commit?
This can only be done when creating a patch. Commit doesn't modify the
patches. I think you slightly misunderstood the commit command.
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-17 21:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060213210001.GA31278@pasky.or.cz>
Petr Baudis wrote:
> * I can't just get the patch in its "canonical ready-to-mail
> form" on stdout so that I could easily review it. Why is
> pg-export insisting to dump it to a file?
I pushed tonight 2 patches for this. One of them adds a --stdout option
to 'export' so that you can see the patches. The other patch adds a
--mbox option to 'mail' that generates an mbox file on the stdout. This
is useful not only for reviewing patches.
--
Catalin
^ permalink raw reply
* [PATCH] git-repack question
From: linux @ 2006-02-17 21:38 UTC (permalink / raw)
To: git; +Cc: junkio
I'm trying to imagine when you'd want to run git-repack without the -d
option, or without running git-prune-packed afterwards.
(Isn't the idea behind packs to save space?)
I'll leave changing the default to wiser heads, but this trivial patch
will at least allow the normal operations to be performed with one
command.
Oh, and is the failure to support getopt-style concatenated
single-letter options (git-repack -dp) a deliberate design feature
of git, or just laziness?
(Legalese: Patch placed in the public domain; copyright abandoned.)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9060fe8..1b1f50d 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -47,6 +47,10 @@ OPTIONS
Do not update the server information with
`git update-server-info`.
+-p::
+ After packing, run gitlink:git-prune-packed[1] to delete
+ redundant unpacked objects.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/git-repack.sh b/git-repack.sh
index 1fafb6e..361c7e9 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,10 +3,10 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-l] [-n]'
+USAGE='[-a] [-d] [-l] [-n] [-p]'
. git-sh-setup
-no_update_info= all_into_one= remove_redundant= local=
+no_update_info= all_into_one= remove_redundant= local= prune=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -14,6 +14,7 @@ do
-a) all_into_one=t ;;
-d) remove_redundant=t ;;
-l) local=t ;;
+ -p) prune=t ;;
*) usage ;;
esac
shift
@@ -76,6 +77,10 @@ then
fi
fi
+case "$prune" in
+t) git-prune-packed ;;
+esac
+
case "$no_update_info" in
t) : ;;
*) git-update-server-info ;;
^ permalink raw reply related
* [PATCH 3/3] New test to verify that when git-clone fails it cleans up the new directory.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <1140212006127-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
t/t5600-clone-fail-cleanup.sh | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100755 t/t5600-clone-fail-cleanup.sh
0d8852c105e5f910ba53fc974a5d929a2136aecd
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
new file mode 100755
index 0000000..0c6a363
--- /dev/null
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Copyright (C) 2006 Carl D. Worth <cworth@cworth.org>
+#
+
+test_description='test git-clone to cleanup after failure
+
+This test covers the fact that if git-clone fails, it should remove
+the directory it created, to avoid the user having to manually
+remove the directory before attempting a clone again.'
+
+. ./test-lib.sh
+
+test_expect_failure \
+ 'clone of non-existent source should fail' \
+ 'git-clone foo bar'
+
+test_expect_failure \
+ 'failed clone should not leave a directory' \
+ 'cd bar'
+
+# Need a repo to clone
+test_create_repo foo
+
+# clone doesn't like it if there is no HEAD. Is that a bug?
+(cd foo && touch file && git add file && git commit -m 'add file' >/dev/null 2>&1)
+
+test_expect_success \
+ 'clone should work now that source exists' \
+ 'git-clone foo bar'
+
+test_expect_success \
+ 'successfull clone must leave the directory' \
+ 'cd bar'
+
+test_done
--
1.2.0.gf6e8
^ permalink raw reply related
* [PATCH 2/3] Abstract test_create_repo out for use in tests.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <11402120042011-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
t/test-lib.sh | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
6110a439c2b1962c6f128cdaac3a2ee8450ac22c
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7a58a86..66f62b9 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -149,6 +149,21 @@ test_expect_code () {
fi
}
+# Most tests can use the created repository, but some amy need to create more.
+# Usage: test_create_repo <directory>
+test_create_repo () {
+ test "$#" = 1 ||
+ error "bug in the test script: not 1 parameter to test-create-repo"
+ owd=`pwd`
+ repo="$1"
+ mkdir "$repo"
+ cd "$repo" || error "Cannot setup test environment"
+ "$GIT_EXEC_PATH/git" init-db --template=$GIT_EXEC_PATH/templates/blt/ 2>/dev/null ||
+ error "cannot run git init-db -- have you built things yet?"
+ mv .git/hooks .git/hooks-disabled
+ cd "$owd"
+}
+
test_done () {
trap - exit
case "$test_failure" in
@@ -196,9 +211,5 @@ test -d ../templates/blt || {
# Test repository
test=trash
rm -fr "$test"
-mkdir "$test"
-cd "$test" || error "Cannot setup test environment"
-"$GIT_EXEC_PATH/git" init-db --template=../../templates/blt/ 2>/dev/null ||
-error "cannot run git init-db -- have you built things yet?"
-
-mv .git/hooks .git/hooks-disabled
+test_create_repo $test
+cd "$test"
--
1.2.0.gf6e8
^ permalink raw reply related
* Making git-clone clean up when it fails
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git
So instead of just making noise, I'll start actually contributing to
git. The first patch here is designed to fix the annoying bug that
when git-clone fails it still leaves the created directory around, (so
that a subsequent git-clone will be guaranteed to fail since the
directory already exists).
The second and third patches provide a new test case for the new
behavior. I had to guess at the number for the new test, since the
distinction of the various numbers in t/README was too vague for me to
know where a git-clone test should go. Feel free to adjust that as
you might see fit.
-Carl
--
cworth@redhat.com
^ permalink raw reply
* [PATCH 1/3] Trap exit to clean up created directory if clone fails.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <11402120031687-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
git-clone.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
589b68168e3dad89238b879b06680c662a99ad8d
diff --git a/git-clone.sh b/git-clone.sh
index e192b08..d184ceb 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -118,6 +118,7 @@ dir="$2"
[ -e "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(cd "$dir" && pwd) &&
+trap 'err=$?; rm -r $D; exit $err' exit
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
@@ -255,3 +256,6 @@ Pull: $head_points_at:$origin" &&
git checkout
esac
fi
+
+trap - exit
+
--
1.2.0.gf6e8
^ permalink raw reply related
* stGIT: commit vs export vs mail
From: Jesse Brandeburg @ 2006-02-17 21:09 UTC (permalink / raw)
To: git
So I am using stgit .8 right now, and I'm having a hard time figuring out
what the correct workflow should be for using stg and then committing a
change
Here is what I've been doing:
stg new test
enter my short description on first line
enter my long description on next lines.
vi file
stg refresh
stg mail <blah blah blah>
or
stg commit
Problem that I'm having right now is that the templates do the right thing
for mail, but, the commit only puts in the "enter my..." text.
Is there a template based way to automatically append the author in the
Signed-off-by: line when i do stg commit?
I realize that I could put Signed-off-by in the log by hand (or even in
.git/patchdescr.tmpl which i just found) but it would be cool if the
commit just had something like patchmail.tmpl (maybe call it
commitdescr.tmpl or something?)
thanks for any opinions or instruction.
Jesse
^ permalink raw reply
* Re: [PATCH 5/5] Optionally work without python
From: Radoslaw Szkodzinski @ 2006-02-17 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0602171523510.24274@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
Johannes Schindelin wrote:
> In some setups (notably server setups) you do not need that dependency.
> Gracefully handle the absence of python when NO_PYTHON is defined.
>
> +# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
lose
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -11,7 +11,11 @@ LF='
> '
>
> all_strategies='recursive octopus resolve stupid ours'
Maybe use this:
default_strategies='recursive'
if test -n "@@NO_PYTHON@@"; then
default_strategies='resolve'
fi
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-cvs-import and branches
From: David Mansfield @ 2006-02-17 20:35 UTC (permalink / raw)
To: Martin Mares; +Cc: git, CVSps
In-Reply-To: <mj+md-20060217.193815.10412.albireo@ucw.cz>
On Fri, 2006-02-17 at 20:55 +0100, Martin Mares wrote:
> Hello!
>
> I'm git-importing a rather large CVS repository with lots of branches and
> although the mainline is imported correctly, the branches aren't. They
> usually contain some changes introduced to the ancestor branch after
> the point the new branch has been tagged.
>
> I haven't studied git-cvsimport and cvsps in much detail yet, but it seems
> that git-cvsimport forks off the branch at the first patchset reported by
> cvsps which mentions the branch and copies the current state of the ancestor
> branch at that time.
>
> This doesn't seem to be correct, since many changes might have happened
> to the ancestor branch since the real branching point. However, since
> cvsps doesn't report the branching points (and they aren't exact points anyway
> since tagging is not atomic in CVS), I don't see how to make cvsimport
> find the right starting revision.
Ugh. I understand the problem but really don't have any solutions
off-hand. Unfortunately, I dying under a 'real work' load at the
moment, so I have to apologize and say, 'good luck.'
David
^ permalink raw reply
* git-cvs-import and branches
From: Martin Mares @ 2006-02-17 19:55 UTC (permalink / raw)
To: git; +Cc: CVSps
Hello!
I'm git-importing a rather large CVS repository with lots of branches and
although the mainline is imported correctly, the branches aren't. They
usually contain some changes introduced to the ancestor branch after
the point the new branch has been tagged.
I haven't studied git-cvsimport and cvsps in much detail yet, but it seems
that git-cvsimport forks off the branch at the first patchset reported by
cvsps which mentions the branch and copies the current state of the ancestor
branch at that time.
This doesn't seem to be correct, since many changes might have happened
to the ancestor branch since the real branching point. However, since
cvsps doesn't report the branching points (and they aren't exact points anyway
since tagging is not atomic in CVS), I don't see how to make cvsimport
find the right starting revision.
Does anybody have an idea how to solve this?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Completely Outdated, Badly Overused Language
^ permalink raw reply
* git-cvs-import retries
From: Martin Mares @ 2006-02-17 19:38 UTC (permalink / raw)
To: git
Hello!
I am trying git-cvsimport on a rather huge repository and the CVS server
sometimes drops the connection and the whole importing aborts, although
it contains some retrying logic. I've noticed that in the connection closes
I experience, $res ends up being empty instead of undefined. This is tested
by the `server went again' check, but not by the retry check a couple of
lines before.
This patch extends the retry check and makes the symptoms go away.
However, take it with a grain of salt as I don't understand yet why the
connection is aborted.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A jury consists of 12 persons chosen to decide who has the better lawyer.
Signed-Off-By: Martin Mares <mj@ucw.cz>
--- old/git-cvsimport 2006-02-17 13:02:24.000000000 +0100
+++ new/git-cvsimport 2006-02-17 18:13:06.000000000 +0100
@@ -371,7 +371,7 @@
$self->_file($fn,$rev) and $res = $self->_line($fh);
- if (!defined $res) {
+ if (!defined $res || $res eq '') {
# retry
$self->conn();
$self->_file($fn,$rev)
^ permalink raw reply
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Junio C Hamano @ 2006-02-17 18:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602170738390.916@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 16 Feb 2006, Junio C Hamano wrote:
>>
>> This one has one nasty data corruption bug, which fortunately I
>> think I have figured out how to fix.
>
> Circular deltas? What else can go wrong?
Circular deltas are prevented by not using deltified objects
check_object() decides to keep in find_deltas(), so I do not
think it is an issue.
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Jason Riedy @ 2006-02-17 17:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171522020.24274@wbgn013.biozentrum.uni-wuerzburg.de>
And Johannes Schindelin writes:
-
- Some version of GNU make do not understand $(call), and have
- problems to interpret rules like this:
Is building a newer version of GNU make impossible on Irix?
Thankfully, I haven't had to deal with that OS in quite some
time.
Jason
^ 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