* Re: problem with http clone/pull
From: Junio C Hamano @ 2006-09-12 23:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17671.16741.995661.664789@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Getting alternates list for http://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/
> Also look at http://git.kernel.or
> error: Couldn't resolve host 'git.kernel.orobjects' (curl_result = 6, http_code = 0, sha1 = c336923b668fdcf0312efbec3b44895d713f4d81)
> Getting pack list for http://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/
> Getting pack list for http://git.kernel.or
I've seen this "last character of hostname dropped" symptom
mentioned on the #git channel long time ago, but I do not
remember if somebody figured out what the problem was. I know
that nobody did a patch to specifically fix it.
Among the changes since v1.3.0 that touches http-fetch.c the
only thing I can see that touches anything related to alternates
handling is this one, but I do not see anything obviously wrong
with it X-<.
commit bfbd0bb6ecbbbf75a5caaff6afaf5a6af8fa518e
Date: Sun Jun 11 14:03:28 2006 +0200
Implement safe_strncpy() as strlcpy() and use it more.
diff --git a/http-fetch.c b/http-fetch.c
index d3602b7..da1a7f5 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -584,10 +584,8 @@ static void process_alternates_response(
// skip 'objects' at end
if (okay) {
target = xmalloc(serverlen + posn - i - 6);
- strncpy(target, base, serverlen);
- strncpy(target + serverlen, data + i,
- posn - i - 7);
- target[serverlen + posn - i - 7] = '\0';
+ safe_strncpy(target, base, serverlen);
+ safe_strncpy(target + serverlen, data + i, posn - i - 6);
if (get_verbosely)
fprintf(stderr,
"Also look at %s\n", target);
^ permalink raw reply related
* Re: [PATCH 3/3] Add sideband status report to git-archive protocol
From: Junio C Hamano @ 2006-09-12 23:44 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <45066CFD.5040202@innova-card.com>
Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
>> I was uncomfortable letting waitpid() there to wait forever.
>> When does poll() return? (1) we have data ready in which case
>> we process; (2) the child somehow closed the pipe but without
>> dying, which is an error in the child. In the latter case even
>> not hanging in waitpid() and retrying the poll would not give
>> any useful input so that would not help either.
>
> your case (2) is not totaly right. If you look a the trace above,
> for the normal case, you can see that the child close the pipe then
> _after_ a while die. So there's a time when the child is not died
> but the pipe is closed.
>
> I think it's safe to assume that if the child closes the pipe, either
> because it has finished to write or something wrong going on, then
> it's going to die pretty soon.
I am essentially saying the same thing (and perhaps one more).
Something is wrong with the child, and either it's going to die
pretty soon in which case waitpid() to wait forever is fine, or
even if it is not going to die soon, going back to poll() would
not give us any useful information anyway, so WNOHANG was
pointless.
So we are in agreement.
> I think calling send_sideband() with sz = 0 should be fine,
I just coded it defensively -- no point calling send() when you
already know there is nothing to be sent.
^ permalink raw reply
* Re: problem with http clone/pull
From: Junio C Hamano @ 2006-09-13 0:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vodtkejm9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I've seen this "last character of hostname dropped" symptom
> mentioned on the #git channel long time ago, but I do not
> remember if somebody figured out what the problem was. I know
> that nobody did a patch to specifically fix it.
Perhaps this would fix it?
I am at work now and I haven't looked at the logic aruond it
too deeply (e.g. I do not know if this breaks the relative
alternate or http specific cases, nor the same or similar
breakages were there in these other cases in the original code
to begin with)
---
diff --git a/http-fetch.c b/http-fetch.c
index fac1760..d870390 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -559,7 +559,13 @@ static void process_alternates_response(
char *target = NULL;
char *path;
if (data[i] == '/') {
- serverlen = strchr(base + 8, '/') - base;
+ /* This counts
+ * http://git.host/pub/scm/linux.git
+ * 1234567----here^
+ * so strcpy(dst, base, serverlen) will
+ * copy up to "...git.host/"
+ */
+ serverlen = strchr(base + 7, '/') - base;
okay = 1;
} else if (!memcmp(data + i, "../", 3)) {
i += 3;
@@ -586,7 +592,7 @@ static void process_alternates_response(
/* skip 'objects' at end */
if (okay) {
target = xmalloc(serverlen + posn - i - 6);
- strlcpy(target, base, serverlen);
+ memcpy(target, base, serverlen);
strlcpy(target + serverlen, data + i, posn - i - 6);
if (get_verbosely)
fprintf(stderr,
^ permalink raw reply related
* Re: problem with http clone/pull
From: Junio C Hamano @ 2006-09-13 0:39 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j08eikw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Perhaps this would fix it?
>
> I am at work now and I haven't looked at the logic aruond it
> too deeply (e.g. I do not know if this breaks the relative
> alternate or http specific cases, nor the same or similar
> breakages were there in these other cases in the original code
> to begin with)
Side note:
> diff --git a/http-fetch.c b/http-fetch.c
> index fac1760..d870390 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -559,7 +559,13 @@ static void process_alternates_response(
> char *target = NULL;
> char *path;
> if (data[i] == '/') {
> - serverlen = strchr(base + 8, '/') - base;
> + /* This counts
> + * http://git.host/pub/scm/linux.git
> + * 1234567----here^
> + * so strcpy(dst, base, serverlen) will
> + * copy up to "...git.host/"
> + */
> + serverlen = strchr(base + 7, '/') - base;
> okay = 1;
> } else if (!memcmp(data + i, "../", 3)) {
> i += 3;
The change between 7 and 8 does not really matter, because the
hostname cannot be empty, and 8 was masking the breakage of this
code; it was (perhaps deliberately) being sloppy to allow us to
also skip over "protocol://" part for https:// case. Call it
subtle if you want ;-).
I think the right thing for this part to do would be something
like this:
diff --git a/http-fetch.c b/http-fetch.c
index fac1760..c7545f2 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -559,8 +559,18 @@ static void process_alternates_response(
char *target = NULL;
char *path;
if (data[i] == '/') {
- serverlen = strchr(base + 8, '/') - base;
- okay = 1;
+ /* This counts
+ * http://git.host/pub/scm/linux.git
+ * -----------here^
+ * so memcpy(dst, base, serverlen) will
+ * copy up to "...git.host".
+ */
+ const char *colon_ss = strstr(base,"://");
+ if (colon_ss) {
+ serverlen = (strchr(colon_ss + 3, '/')
+ - base);
+ okay = 1;
+ }
} else if (!memcmp(data + i, "../", 3)) {
i += 3;
serverlen = strlen(base);
@@ -583,11 +593,13 @@ static void process_alternates_response(
okay = 1;
}
}
- /* skip 'objects' at end */
+ /* skip "objects\n" at end */
if (okay) {
target = xmalloc(serverlen + posn - i - 6);
- strlcpy(target, base, serverlen);
- strlcpy(target + serverlen, data + i, posn - i - 6);
+ memcpy(target, base, serverlen);
+ memcpy(target + serverlen, data + i,
+ posn - i - 7);
+ target[serverlen + posn - i - 7] = 0;
if (get_verbosely)
fprintf(stderr,
"Also look at %s\n", target);
^ permalink raw reply related
* Re: problem with http clone/pull
From: Paul Mackerras @ 2006-09-13 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j08eikw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Perhaps this would fix it?
Yes, it works with that patch. Thanks.
Paul.
^ permalink raw reply
* Re: [PATCH] connect.c: finish_connect(): allow null pid parameter
From: Junio C Hamano @ 2006-09-13 4:48 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <4506771D.9040605@innova-card.com>
Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
> git_connect() can return 0 if we use git protocol for example.
> Users of this function don't know and don't care if a process
> had been created or not, and to avoid them to check it before
> calling finish_connect() this patch allows finish_connect() to
> take a null pid. And in that case return 0.
>
> Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
> ---
>
> Found it when debugging 'git archive --remote=git://...'
> command. I noticed that this command always exited with 1 as
> status.
True. This should affect existing users of finish_connect(), but
existing callers do not check its return value X-<.
I think the return type of git_connect() should be changed to
pid_t with a warning that says it returns negative on error, pid
of a process finish_connect() should wait for if the underlying
protocol driver forks, and 0 if we do not have to wait in
finish_connect(). Making finish_connect() to accept 0 as its
input is probably a good change.
^ permalink raw reply
* [PATCH] pack-objects: document --revs, --unpacked and --all.
From: Junio C Hamano @ 2006-09-13 5:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee3hac$n57$1@sea.gmane.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Clear enough?
Documentation/git-pack-objects.txt | 21 ++++++++++++++++++++-
builtin-pack-objects.c | 2 +-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 4991f88..d4661dd 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-pack-objects' [-q] [--no-reuse-delta] [--non-empty]
[--local] [--incremental] [--window=N] [--depth=N]
- {--stdout | base-name} < object-list
+ [--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
DESCRIPTION
@@ -56,6 +56,24 @@ base-name::
Write the pack contents (what would have been written to
.pack file) out to the standard output.
+--revs::
+ Read the revision arguments from the standard input, instead of
+ individual object names. The revision arguments are processed
+ the same way as gitlink:git-rev-list[1] with `--objects` flag
+ uses its `commit` arguments to build the list of objects it
+ outputs. The objects on the resulting list are packed.
+
+--unpacked::
+ This implies `--revs`. When processing the list of
+ revision arguments read from the standard input, limit
+ the objects packed to those that are not already packed.
+
+--all::
+ This implies `--revs`. In addition to the list of
+ revision arguments read from the standard input, pretend
+ as if all refs under `$GIT_DIR/refs` are specifed to be
+ included.
+
--window and --depth::
These two options affects how the objects contained in
the pack are stored using delta compression. The
@@ -103,6 +121,7 @@ Documentation by Junio C Hamano
See Also
--------
+gitlink:git-rev-list[1]
gitlink:git-repack[1]
gitlink:git-prune-packed[1]
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 753dd9a..8d7a120 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -15,7 +15,7 @@ #include "list-objects.h"
#include <sys/time.h>
#include <signal.h>
-static const char pack_usage[] = "git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} [--revs [--unpacked | --all]* <ref-list | <object-list]";
+static const char pack_usage[] = "git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] [--revs [--unpacked | --all]*] [--stdout | base-name] <ref-list | <object-list]";
struct object_entry {
unsigned char sha1[20];
--
1.4.2.g61af0
^ permalink raw reply related
* Re: [PATCH] Teach runstatus about --untracked
From: Jeff King @ 2006-09-13 6:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0609122243360.19042@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Sep 12, 2006 at 10:45:12PM +0200, Johannes Schindelin wrote:
> + if (!s->untracked)
> + dir.show_other_directories = 1;
This should also set dir.hide_empty_directories to match the original
behavior.
-Peff
^ permalink raw reply
* Re: [PATCH] contrib/vim: add syntax highlighting file for commits
From: Junio C Hamano @ 2006-09-13 6:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Tom Prince
In-Reply-To: <20060912023256.GA6596@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Sep 11, 2006 at 08:08:13PM -0600, Tom Prince wrote:
>
>> > + 1. Copy commit-syntax.vim to vim's syntax directory:
>> > + $ cp commit-syntax.vim $HOME/.vim/syntax/gitcommit.vim
>> It would be more obvious if you could do cp gitcomit.vim $HOME/.vim/syntax/
>
> It would be with only one file, but you could just as easily have a
> .vim/ftplugin/gitcommit.vim file (I think there are others, too). If you
> want to give it the "proper" name, it should probably be
> syntax/gitcommit.vim.
I am not a vim user, but my reading of Tom's comment is that he
thinks it would have been nicer if the file the patch adds were
named gitcommit.vim, not commit-syntax.vim. As you seem to
agree that the preferred name for this file when deployed is
gitcommit.vim, how about something like this on top of your
patch perhaps?
diff --git a/contrib/vim/README b/contrib/vim/README
index bad0a05..f574cc8 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -1,6 +1,6 @@
To syntax highlight git's commit messages, you need to:
- 1. Copy commit-syntax.vim to vim's syntax directory:
- $ cp commit-syntax.vim $HOME/.vim/syntax/gitcommit.vim
+ 1. Copy gitcommit.vim to vim's syntax directory:
+ $ cp gitcommit.vim $HOME/.vim/syntax/
2. Auto-detect the editing of git commit files:
$ cat >>$HOME/.vimrc <<'EOF'
autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
diff --git a/contrib/vim/commit-syntax.vim b/contrib/vim/gitcommit.vim
similarity index 100%
rename from contrib/vim/commit-syntax.vim
rename to contrib/vim/gitcommit.vim
^ permalink raw reply related
* Re: [PATCH] Teach runstatus about --untracked
From: Junio C Hamano @ 2006-09-13 6:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Schindelin
In-Reply-To: <20060913061040.GA3590@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 12, 2006 at 10:45:12PM +0200, Johannes Schindelin wrote:
>
>> + if (!s->untracked)
>> + dir.show_other_directories = 1;
>
> This should also set dir.hide_empty_directories to match the original
> behavior.
Right. Thanks for eyeballing.
^ permalink raw reply
* Re: [PATCH] contrib/vim: add syntax highlighting file for commits
From: Jeff King @ 2006-09-13 6:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tom Prince
In-Reply-To: <7vy7so9txj.fsf@assigned-by-dhcp.cox.net>
On Tue, Sep 12, 2006 at 11:12:08PM -0700, Junio C Hamano wrote:
> I am not a vim user, but my reading of Tom's comment is that he
> thinks it would have been nicer if the file the patch adds were
> named gitcommit.vim, not commit-syntax.vim. As you seem to
> agree that the preferred name for this file when deployed is
> gitcommit.vim, how about something like this on top of your
> patch perhaps?
My point was that there may be many files named gitcommit.vim; the
directory they appear in under your .vim directory has significance. If
we add another such file, they will conflict in the flattened namespace
of contrib/vim. See below (which also adds the necessary mkdir
command):
-- >8 --
contrib/vim: give commit-syntax a more sensible name
diff --git a/contrib/vim/README b/contrib/vim/README
index bad0a05..9e7881f 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -1,6 +1,7 @@
To syntax highlight git's commit messages, you need to:
- 1. Copy commit-syntax.vim to vim's syntax directory:
- $ cp commit-syntax.vim $HOME/.vim/syntax/gitcommit.vim
+ 1. Copy syntax/gitcommit.vim to vim's syntax directory:
+ $ mkdir -p $HOME/.vim/syntax
+ $ cp syntax/gitcommit.vim $HOME/.vim/syntax
2. Auto-detect the editing of git commit files:
$ cat >>$HOME/.vimrc <<'EOF'
autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
diff --git a/contrib/vim/commit-syntax.vim b/contrib/vim/syntax/gitcommit.vim
similarity index 100%
rename from contrib/vim/commit-syntax.vim
rename to contrib/vim/syntax/gitcommit.vim
^ permalink raw reply related
* Re: [PATCH] contrib/vim: add syntax highlighting file for commits
From: Tom Prince @ 2006-09-13 6:46 UTC (permalink / raw)
To: git
In-Reply-To: <20060913062557.GA4783@coredump.intra.peff.net>
On Wed, Sep 13, 2006 at 02:25:57AM -0400, Jeff King wrote:
> My point was that there may be many files named gitcommit.vim; the
> directory they appear in under your .vim directory has significance. If
> we add another such file, they will conflict in the flattened namespace
> of contrib/vim. See below (which also adds the necessary mkdir
> command):
>
Much clearer. I had glanced at the readme and did
cp commit-syntax.vim ~/.vim/syntax
and it took me a minute or so to figure what was wrong.
Tom
^ permalink raw reply
* Re: [PATCH] Teach runstatus about --untracked
From: Johannes Schindelin @ 2006-09-13 7:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, junkio
In-Reply-To: <20060913061040.GA3590@coredump.intra.peff.net>
Hi,
On Wed, 13 Sep 2006, Jeff King wrote:
> On Tue, Sep 12, 2006 at 10:45:12PM +0200, Johannes Schindelin wrote:
>
> > + if (!s->untracked)
> > + dir.show_other_directories = 1;
>
> This should also set dir.hide_empty_directories to match the original
> behavior.
But of course! Completely forgot that. Thanks.
^ permalink raw reply
* [PATCH] Test return value of finish_connect()
From: Franck Bui-Huu @ 2006-09-13 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck, git
In-Reply-To: <7vd5a0bcdf.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
fetch-pack.c | 4 ++--
peek-remote.c | 4 ++--
send-pack.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 1b2d6ee..e8708aa 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -525,7 +525,7 @@ int main(int argc, char **argv)
ret = fetch_pack(fd, nr_heads, heads);
close(fd[0]);
close(fd[1]);
- finish_connect(pid);
+ ret |= finish_connect(pid);
if (!ret && nr_heads) {
/* If the heads to pull were given, we should have
@@ -540,5 +540,5 @@ int main(int argc, char **argv)
}
}
- return ret;
+ return !!ret;
}
diff --git a/peek-remote.c b/peek-remote.c
index 87f1543..353da00 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -66,6 +66,6 @@ int main(int argc, char **argv)
ret = peek_remote(fd, flags);
close(fd[0]);
close(fd[1]);
- finish_connect(pid);
- return ret;
+ ret |= finish_connect(pid);
+ return !!ret;
}
diff --git a/send-pack.c b/send-pack.c
index 49be764..5bb123a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -443,6 +443,6 @@ int main(int argc, char **argv)
ret = send_pack(fd[0], fd[1], nr_heads, heads);
close(fd[0]);
close(fd[1]);
- finish_connect(pid);
- return ret;
+ ret |= finish_connect(pid);
+ return !!ret;
}
--
1.4.2
^ permalink raw reply related
* [PATCH] git_connect: change return type to pid_t
From: Franck Bui-Huu @ 2006-09-13 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck, git
In-Reply-To: <7vd5a0bcdf.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
For now I let this function die if an error has occured.
Current users wouldn't do anything usefull with a negative
value except exiting.
cache.h | 2 +-
connect.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index ac51ed1..57db7c9 100644
--- a/cache.h
+++ b/cache.h
@@ -359,7 +359,7 @@ #define REF_NORMAL (1u << 0)
#define REF_HEADS (1u << 1)
#define REF_TAGS (1u << 2)
-extern int git_connect(int fd[2], char *url, const char *prog);
+extern pid_t git_connect(int fd[2], char *url, const char *prog);
extern int finish_connect(pid_t pid);
extern int path_match(const char *path, int nr, char **match);
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
diff --git a/connect.c b/connect.c
index e6efff9..4bf7914 100644
--- a/connect.c
+++ b/connect.c
@@ -602,7 +602,7 @@ static void git_proxy_connect(int fd[2],
/*
* Yeah, yeah, fixme. Need to pass in the heads etc.
*/
-int git_connect(int fd[2], char *url, const char *prog)
+pid_t git_connect(int fd[2], char *url, const char *prog)
{
char command[1024];
char *host, *path = url;
--
1.4.2
^ permalink raw reply related
* Re: qgit segfaults after b237b00
From: Andreas Ericsson @ 2006-09-13 8:45 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550609121039h1ef25bc8y25186c321d555b8e@mail.gmail.com>
Marco Costalba wrote:
> Hi Andreas,
>
> On 9/12/06, Andreas Ericsson <ae@op5.se> wrote:
>> What subject says, really. Tried cold cache, hot cache, with and without
>> qgit.dat, 3 different repos and 14 different repo-tips. Same result
>> every time. A segfault before anything is drawn.
>>
>
> Sorry but I am not able to reproduce the bug here. Also from the trace I
> see
> that the segfault happens in a part of code that has not been touched
> by b237b00.
> And that _should_ not segfault in any way.
>
> The code there is the same of qgit-1.5.1 so perhaps could be some
> platform related issue,
Probably, yes. Some more digging indicates it comes from trying to fetch
the system default-font and setting it as the default application-font.
> please write me Qt and gcc versions and processor used and, in case,
> do a complete rebuild with also reconfiguration (autoreconf -i).
>
Naturally. Forgot it in the first mail *blush*. Mainly running Fedora
Core 5, except for the kernel which I compile myself.
nox!exon:~/git/qgit$ gcc --version
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
nox!exon:~/git/qgit$ rpm -q qt
qt-3.3.6-0.4.fc5
nox!exon:~/git/qgit$ uname -a
Linux nox.op5.se 2.6.18-rc6 #1 Wed Sep 6 15:41:35 CEST 2006 i686 i686
i386 GNU/Linux
nox!exon:~/git/qgit$
Rebuilding with full autoreconf -i does indeed seem to solve the
problem. I'm guessing some yum update changed the qt-version and the
configure.cache kept the old settings so that it wasn't checked.
Sorry for the noise.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git pull a subtree, embedded trees
From: Tim Shimmin @ 2006-09-13 13:05 UTC (permalink / raw)
To: git
Hi,
I'm new to git and have a couple of novice questions.
* Is it possible to only pull in a subtree from
a repository.
Moreover, is it possible to have a subtree based on another
repository.
For example, have a topdir directory with subdirs,
s1, s2, s3 and s4. And then have say, s2 linked to
a repository rs2 and s3 linked to rs3, so that
one can update s2 and s3 from these other repositories but
having the rest of the tree linked from a main repository.
* Are there any tools for dumping out the contents of the
git objects in the .git/objects directory.
By dumping out, I mean an ascii representation of the data
fields for the commit and tree objects in particular.
I've written a simple small program to dump out the index
entries (cache entries).
I just want to see what is exactly stored in the .git
binary files and how they change when I do various git
operations.
Thanks a bunch.
--Tim
^ permalink raw reply
* Re: git pull a subtree, embedded trees
From: Jakub Narebski @ 2006-09-13 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <4508020F.2050604@sgi.com>
Tim Shimmin wrote:
> I'm new to git and have a couple of novice questions.
>
> * Is it possible to only pull in a subtree from
> a repository.
I assume that by pull you mean checkout...
I think it is possible (try git-read-tree with --prefix option,
and select subtree by giving either it's sha1, or e.g.
HEAD:<path> form), but not easy to do. Git revisions are
snapshots of the whole project (the revisions are states of
the whole project).
> Moreover, is it possible to have a subtree based on another
> repository.
It is possible. For example, make empty directory <subproject>
somewhere, add this directory, or just all the files in it
either to .gitignore or .git/info/excludes file, then clone
the other project (subproject) to this place. You would have
the following directory structure
/
dir1
dir2
dir2/subdir
subproject
subproject/.git
subproject/subprojectsubdir
...
> * Are there any tools for dumping out the contents of the
> git objects in the .git/objects directory.
> By dumping out, I mean an ascii representation of the data
> fields for the commit and tree objects in particular.
> I've written a simple small program to dump out the index
> entries (cache entries).
git-cat-file -p
> I just want to see what is exactly stored in the .git
> binary files and how they change when I do various git
> operations.
Loose object are stored type+compressed contents. But usually
everything except latest work is in packs.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git pull a subtree, embedded trees
From: Shawn Pearce @ 2006-09-13 15:00 UTC (permalink / raw)
To: Tim Shimmin; +Cc: git
In-Reply-To: <4508020F.2050604@sgi.com>
Tim Shimmin <tes@sgi.com> wrote:
> I've written a simple small program to dump out the index
> entries (cache entries).
`git-ls-files --stage` also dumps a number of those details, though
it doesn't dump every available field.
> I just want to see what is exactly stored in the .git
> binary files and how they change when I do various git
> operations.
You may want to review some of the material in
Documentation/core-tutorial.txt and Documentation/technical.
These documents try to describe some of the formats but reviewing
them now it looks like there's still some additional information
that could be written down.
--
Shawn.
^ permalink raw reply
* Marking abandoned branches
From: Jon Smirl @ 2006-09-13 15:17 UTC (permalink / raw)
To: Git Mailing List
Since branch refs are being worked on it would make sense to add an
object that marks a branch as being abandoned. The visualization tools
would use this to suppress viewing of these branches in their default
display.
For example Mozilla has 100s of branches that were abandoned five or
more years ago. No point in having them impact a current gitk display.
You would add an abandoned branch marker after the last commit on the
branch and adjust the branch ref to point at it. If you want to open
the branch again point the branch ref back to the last commit and let
git prune remove the marker.
Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Marking abandoned branches
From: Petr Baudis @ 2006-09-13 15:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910609130817r39bbf8a8x2e05461816d9d2a1@mail.gmail.com>
Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> Abandoned branches are common in CVS since it is not distributed.
> People start working on something in the main repo and then decide it
> was a bad idea. In the git world these branches usually don't end up
> in the main repo.
Can't you just toss the branch away in that case? :-)
You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.
Object classes are precious things and we shouldn't get carried away.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Marking abandoned branches
From: Johannes Schindelin @ 2006-09-13 15:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20060913152451.GH23891@pasky.or.cz>
Hi,
On Wed, 13 Sep 2006, Petr Baudis wrote:
> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > Abandoned branches are common in CVS since it is not distributed.
> > People start working on something in the main repo and then decide it
> > was a bad idea. In the git world these branches usually don't end up
> > in the main repo.
>
> Can't you just toss the branch away in that case? :-)
>
> You could also stash the ref to refs/heads-abandoned/ instead of
> refs/heads/ if you want to keep the junk around for some reason. Of
> course you don't get the nice marker with explanation of why is this
> abandoned and who decided that, but you can just use an empty commit for
> the same purpose.
... or a tag (remember, you can stash a tag into refs/abandoned/, instead
of a commit) with the further benefit that you really cannot commit on top
of that.
> Object classes are precious things and we shouldn't get carried away.
Exactly.
Ciao,
Dscho
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0609131729500.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Wed, 13 Sep 2006, Petr Baudis wrote:
>
>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
>> where Jon Smirl <jonsmirl@gmail.com> said that...
>> > Abandoned branches are common in CVS since it is not distributed.
>> > People start working on something in the main repo and then decide it
>> > was a bad idea. In the git world these branches usually don't end up
>> > in the main repo.
>>
>> Can't you just toss the branch away in that case? :-)
>>
>> You could also stash the ref to refs/heads-abandoned/ instead of
>> refs/heads/ if you want to keep the junk around for some reason. Of
>> course you don't get the nice marker with explanation of why is this
>> abandoned and who decided that, but you can just use an empty commit for
>> the same purpose.
>
> ... or a tag (remember, you can stash a tag into refs/abandoned/, instead
> of a commit) with the further benefit that you really cannot commit on top
> of that.
Or refs/Attic/ ;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Marking abandoned branches
From: Jon Smirl @ 2006-09-13 15:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20060913152451.GH23891@pasky.or.cz>
On 9/13/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > Abandoned branches are common in CVS since it is not distributed.
> > People start working on something in the main repo and then decide it
> > was a bad idea. In the git world these branches usually don't end up
> > in the main repo.
>
> Can't you just toss the branch away in that case? :-)
It is a historical import. Everything that was in the initial repo
needs to be preserved otherwise they aren't going to get rid of the
old CVS repo.
> You could also stash the ref to refs/heads-abandoned/ instead of
> refs/heads/ if you want to keep the junk around for some reason. Of
> course you don't get the nice marker with explanation of why is this
> abandoned and who decided that, but you can just use an empty commit for
> the same purpose.
>
> Object classes are precious things and we shouldn't get carried away.
If this is done with an object there should probably be some way to
encode it into the existing commit object.
Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Marking abandoned branches
From: Johannes Schindelin @ 2006-09-13 16:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com>
Hi,
On Wed, 13 Sep 2006, Jon Smirl wrote:
> Moving the refs into refs/abandoned would work too. We would need new
> git commands to do this and flags on the visualization tools to
> include the abandoned branches. On the other hand doing this is
> recording state about the repository in the refs directory instead of
> writing this state into the repo itself.
Well, the refs directory is _part_ of the repository. Think about it, if
you do not know which branches are in the object database, you lack a lot
of information.
BTW the moving of a branch to a tag in refs/abandoned/ is trivial.
Ciao,
Dscho
^ 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