* Re: [PATCH 4/4] clone: use --progress to force progress reporting
From: Miklos Vajna @ 2009-12-27 1:20 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-5-git-send-email-rctay89@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On Sat, Dec 26, 2009 at 01:12:06AM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
> -v/--verbose now does not force progress reporting. Make git-clone.txt
> say so.
>
> This should cover all the bases in 21188b1 (Implement git clone -v),
> which implemented the option to force progress reporting.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
> Documentation/git-clone.txt | 3 +++
> builtin-clone.c | 8 ++++++--
> t/t5702-clone-options.sh | 3 ++-
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index e722e6c..f43c8b2 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -102,6 +102,9 @@ objects from the source repository into a pack in the cloned repository.
>
> --verbose::
> -v::
> + Run verbosely.
What about mentioning this "does not force progress reporting" behaviour
in documentation of the "new" -v option?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tay Ray Chuan @ 2009-12-27 3:19 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <1261847255-13970-1-git-send-email-tarmigan+git@gmail.com>
Hi,
On Sun, Dec 27, 2009 at 1:07 AM, Tarmigan Casebolt
<tarmigan+git@gmail.com> wrote:
> @@ -60,8 +60,8 @@ automatically by the web server.
>
> EXAMPLES
> --------
> -All of the following examples map 'http://$hostname/git/foo/bar.git'
> -to '/var/www/git/foo/bar.git'.
> +Unless otherwise noted, the following examples map
> +'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
This rephrase seems to be unrelated (to providing an example of
serving smart http).
> @@ -144,6 +144,42 @@ ScriptAliasMatch \
> ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
> ----------------------------------------------------------------
>
> +In the following example, a repository at
> +'/home/$username/devel/foo/bar.git' will be accessible at
> +'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
> +
> +From UserDir on Apache 2.x::
> + One way to configure 'git-http-backend' to execute and serve
> + from a user directory (for example, on a shared hosting
> + provider), is to have a symbolic link that points from the cgi
> + directory to the 'git-http-backend' executable in libexec. The
> + advantage of the symblic link is that any updates to the
s/symblic/symbolic/.
> + installed version of 'git-http-backend' also update the version
s/update/updates/.
> + that is run in the userdir. Depending on the configuration of
> + the server, the symbolic link may be able to point to a global
> + installation of git. If, for security reasons, the server is
At this point, the user dealing with the "easy" case (ie. the user
just symlinks the shared git installation and doesn't have to create
symlinks in his own home directory) should have enough configuration
details without having to read any further. So, you could tell the
user about the symlinks to create and the configuration lines in
.htaccess.
It might also be a good idea to start a new paragraph for the "hard"
case, for better readability.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 4/4] clone: use --progress to force progress reporting
From: Tay Ray Chuan @ 2009-12-27 3:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <20091227012032.GE25474@genesis.frugalware.org>
Hi,
On Sun, Dec 27, 2009 at 9:20 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sat, Dec 26, 2009 at 01:12:06AM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> -v/--verbose now does not force progress reporting. Make git-clone.txt
>> say so.
>>
>> This should cover all the bases in 21188b1 (Implement git clone -v),
>> which implemented the option to force progress reporting.
>>
>> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>> ---
>> Documentation/git-clone.txt | 3 +++
>> builtin-clone.c | 8 ++++++--
>> t/t5702-clone-options.sh | 3 ++-
>> 3 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
>> index e722e6c..f43c8b2 100644
>> --- a/Documentation/git-clone.txt
>> +++ b/Documentation/git-clone.txt
>> @@ -102,6 +102,9 @@ objects from the source repository into a pack in the cloned repository.
>>
>> --verbose::
>> -v::
>> + Run verbosely.
>
> What about mentioning this "does not force progress reporting" behaviour
> in documentation of the "new" -v option?
Ok.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Tay Ray Chuan @ 2009-12-27 3:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Miklos Vajna, Nicolas Pitre, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0912260952020.4985@pacific.mpi-cbg.de>
Hi,
On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>
>> This series makes git-clone follow the "argument convention" of
>> git-pack-objects, where the option --progress is used to force reporting
>> of reporting. This was previously done with -v/--verbose.
>
> No objections from my side, although you might want to advertise more that
> this is a change in behavior. (Meaning in the release notes)
Indeed, -v/--verbose to force reporting of progress was done sometime
last year (Thu Oct 9 2008) so there may be scripts/applications
dependent on this option.
Junio, do you have any advice on this front?
>> PS. If someone can enlighten me on the proper noun for the git
>> executable (I said "main git"), I would be very thankful.
>
> I call it the "Git wrapper", although less polite words exist, too.
I see. Thanks!
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH] Don't pass CFLAGS to the linker
From: Tomas Carnecky @ 2009-12-27 6:55 UTC (permalink / raw)
To: git
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
---
I don't remember exactly which tool had problems with CFLAGS being passed
to the linker. Maybe it was the clang static analyzer, or some other
tool that I let run on git.git. Anyway, I don't think there's any
reason to pass CFLAGS to the linker.
Makefile | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index c11719c..d9cd189 100644
--- a/Makefile
+++ b/Makefile
@@ -1473,8 +1473,7 @@ git.o: git.c common-cmds.h GIT-CFLAGS
$(ALL_CFLAGS) -o $@ -c $(filter %.c,$^)
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
- $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ git.o $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
@@ -1660,10 +1659,10 @@ http-walker.o: http-walker.c http.h GIT-CFLAGS
endif
git-%$X: %.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
git-imap-send$X: imap-send.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
http.o http-walker.o http-push.o: http.h
@@ -1671,14 +1670,14 @@ http.o http-walker.o http-push.o: http.h
http.o http-walker.o: $(LIB_H)
git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL)
git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
@@ -1798,7 +1797,7 @@ test-parse-options.o: parse-options.h
.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
test-%$X: test-%.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
--
1.6.6
^ permalink raw reply related
* [RESEND] [PATCH] Endianness bug in index cache logic
From: Nathaniel W Filardo @ 2009-12-27 6:11 UTC (permalink / raw)
To: git
In-Reply-To: <20091204202928.GW17192@gradx.cs.jhu.edu>
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
On Fri, Dec 04, 2009 at 03:29:28PM -0500, Nathaniel W Filardo wrote:
> On Fri, Dec 04, 2009 at 09:16:40PM +0100, Andreas Schwab wrote:
> > Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> >
> > > On this machine,
> > >
> > > mirrors hydra:/tank0/mirrors/misc% uname -a
> > > FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #13: Sat Nov 14 19:40:25 EST 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64
> > >
> > > attempting to fetch from an svn source yields the following error:
> > >
> > > rs hydra:/tank0/mirrors/misc% git svn init -s https://joshua.svn.sourceforge.net/svnroot/joshua test-joshua
> > > Initialized empty Git repository in /tank0/mirrors/misc/test-joshua/.git/
> > > mirrors hydra:/tank0/mirrors/misc% cd test-joshua
> > > mirrors hydra:/tank0/mirrors/misc/test-joshua% git svn fetch
> > > A scripts/distributedLM/config.template
> > > [...]
> > > A build.xml
> > > r1 = fe84a7d821ec6d92da75133ac7ad1deb476b6484 (refs/remotes/trunk)
> > > error: index uses extension, which we do not understand
> > > fatal: index file corrupt
> > > write-tree: command returned error: 128
> >
> > I could not reproduce that on powerpc (both 32bit and 64bit).
> >
> > Andreas.
I got some free time and tracked it down. The following one-line delta
fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
the wrong endianness for the memcpy trick to work as written? I could be
sligntly off in my assessment of the problem, tho'.
index 1bbaf1c..9033dd3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
* extension name (4-byte) and section length
* in 4-byte network byte order.
*/
- unsigned long extsize;
+ uint32_t extsize;
memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
extsize = ntohl(extsize);
if (read_index_extension(istate,
--nwf;
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Erik Faye-Lund @ 2009-12-27 12:39 UTC (permalink / raw)
To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>
On Sun, Dec 27, 2009 at 7:11 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> I got some free time and tracked it down. The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
You mean 8 bytes, right?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Nguyễn Thái Ngọc Duy @ 2009-12-27 13:28 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <200912071115.48085.robin.rosenberg.lists@dewire.com>
According to config.txt:
> core.worktree::
> Set the path to the working tree. The value will not be
> used in combination with repositories found automatically in
> a .git directory (i.e. $GIT_DIR is not set).
This behavior was changed after e90fdc3 (Clean up work-tree handling -
2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
2007-12-05). If core.worktree is set, even if git_dir automatically
found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
core.worktree. This makes core.worktree effective even if GIT_DIR is
not set, in contrast to config.txt.
This patch makes sure it only checks for core.worktree if GIT_DIR is set.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
setup.c | 19 +++++++++++++------
t/t1501-worktree.sh | 4 ++++
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/setup.c b/setup.c
index 2cf0f19..35b7915 100644
--- a/setup.c
+++ b/setup.c
@@ -283,6 +283,18 @@ const char *read_gitfile_gently(const char *path)
return path;
}
+static int check_repository_work_tree(const char *var, const char *value, void *cb)
+{
+ if (strcmp(var, "core.worktree") == 0) {
+ if (!value)
+ return config_error_nonbool(var);
+ free(git_work_tree_cfg);
+ git_work_tree_cfg = xstrdup(value);
+ inside_work_tree = -1;
+ }
+ return 0;
+}
+
/*
* We cannot decide in this function whether we are in the work tree or
* not, since the config can only be read _after_ this function was called.
@@ -320,6 +332,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env) {
retval = set_work_tree(gitdirenv);
/* config may override worktree */
+ git_config(check_repository_work_tree, NULL);
if (check_repository_format_gently(nongit_ok))
return NULL;
return retval;
@@ -474,12 +487,6 @@ int check_repository_format_version(const char *var, const char *value, void *cb
is_bare_repository_cfg = git_config_bool(var, value);
if (is_bare_repository_cfg == 1)
inside_work_tree = -1;
- } else if (strcmp(var, "core.worktree") == 0) {
- if (!value)
- return config_error_nonbool(var);
- free(git_work_tree_cfg);
- git_work_tree_cfg = xstrdup(value);
- inside_work_tree = -1;
}
return 0;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 74e6443..9756f35 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -30,6 +30,10 @@ test_rev_parse() {
EMPTY_TREE=$(git write-tree)
mkdir -p work/sub/dir || exit 1
+
+git config core.worktree work
+test_rev_parse 'core.worktree without GIT_DIR' false false true ''
+
mv .git repo.git || exit 1
say "core.worktree = relative path"
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Nathaniel W Filardo @ 2009-12-27 16:12 UTC (permalink / raw)
To: kusmabite; +Cc: Nathaniel W Filardo, git
In-Reply-To: <40aa078e0912270439i3948a38fw9784e23e7cdc4407@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Sun, Dec 27, 2009 at 01:39:24PM +0100, Erik Faye-Lund wrote:
> On Sun, Dec 27, 2009 at 7:11 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> > I got some free time and tracked it down. The following one-line delta
> > fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
>
> You mean 8 bytes, right?
Yes, sorry. How embarrassing. :)
--nwf;
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Newbie to git
From: Jorge Bastos @ 2009-12-27 16:42 UTC (permalink / raw)
To: git
Howdy people,
I'm a using of git for several time, but now I have the need to a git server.
My question, where can get a howto for reallyyyy newbies on git server?
I have part of it setup but still not working.
Thanks in advanced,
Jorge,
^ permalink raw reply
* Re: [PATCH RESEND] gitk: add "--no-replace-objects" option
From: Christian Couder @ 2009-12-27 17:26 UTC (permalink / raw)
To: Paul Mackerras
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Junio C Hamano
In-Reply-To: <20091213230923.GB8135@brick.ozlabs.ibm.com>
On lundi 14 décembre 2009, Paul Mackerras wrote:
> On Sat, Dec 12, 2009 at 05:52:39AM +0100, Christian Couder wrote:
> > Replace refs are useful to change some git objects after they
> > have started to be shared between different repositories. One
> > might want to ignore them to see the original state, and
> > "--no-replace-objects" option can be used from the command
> > line to do so.
> >
> > This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> > variable, and that is enough to make gitk ignore replace refs.
> >
> > The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> > safer on some platforms, thanks to Johannes Sixt and Michael J
> > Gruber.
> >
> > Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>
> Thanks, applied.
Thanks, but it looks like the patch is not in v1.6.6.
Could you ask Junio to pull from you?
Best regards,
Christian.
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 17:45 UTC (permalink / raw)
To: git
In-Reply-To: <1435.87.196.47.196.1261932152.squirrel@webmail.decimal.pt>
> I'm a using of git for several time, but now I have the need to a git
> server.
> My question, where can get a howto for reallyyyy newbies on git server?
One question:
I've created a project on the server with:
mkdir project.git
cd project.git
git init
-and now locally, created a directory, and cloned this, it said that i was
cloning an empty repo, fine about that.
-now i added something locally, i get: (locally this is on a windows
machine with tortoiso git)
--
git.exe push --tags "origin" master:git://192.168.1.206/projects.git
error: src refspec master:git does not match any.
error: failed to push some refs to 'git://192.168.1.206/projects.git'
--
I've read somewhere that i have to init both repos, remote and local to
the same branch, is it correct?
My idea is:
- clone remote repo
- add projects locally and commit them to remote
how can this be done easylly?
^ permalink raw reply
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Junio C Hamano @ 2009-12-27 18:24 UTC (permalink / raw)
To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>
Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> I got some free time and tracked it down. The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
> the wrong endianness for the memcpy trick to work as written? I could be
> sligntly off in my assessment of the problem, tho'.
>
> index 1bbaf1c..9033dd3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
> * extension name (4-byte) and section length
> * in 4-byte network byte order.
> */
> - unsigned long extsize;
> + uint32_t extsize;
> memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
> extsize = ntohl(extsize);
> if (read_index_extension(istate,
Good catch.
The original is broken on big endian 64-bit platforms, and your sparc64
indeed is one. The code expects to see a signature (4-byte) at src_offset
followed by length (4-byte int in network byte order) and it is trying to
read read the latter in extsize.
Thanks for the fix. The bug dates back to late April 2006, and I am kind
of surprised that nobody reported this since then (perhaps nobody runs git
on big endian 64-bit boxes?).
^ permalink raw reply
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Tomas Carnecky @ 2009-12-27 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathaniel W Filardo, git
In-Reply-To: <7veimgxolb.fsf@alter.siamese.dyndns.org>
On 12/27/09 7:24 PM, Junio C Hamano wrote:
> Nathaniel W Filardo<nwf@cs.jhu.edu> writes:
>
>> I got some free time and tracked it down. The following one-line delta
>> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
>> the wrong endianness for the memcpy trick to work as written? I could be
>> sligntly off in my assessment of the problem, tho'.
>>
>> index 1bbaf1c..9033dd3 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
>> * extension name (4-byte) and section length
>> * in 4-byte network byte order.
>> */
>> - unsigned long extsize;
>> + uint32_t extsize;
>> memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
>> extsize = ntohl(extsize);
>> if (read_index_extension(istate,
>
> Good catch.
>
> The original is broken on big endian 64-bit platforms, and your sparc64
> indeed is one. The code expects to see a signature (4-byte) at src_offset
> followed by length (4-byte int in network byte order) and it is trying to
> read read the latter in extsize.
>
> Thanks for the fix. The bug dates back to late April 2006, and I am kind
> of surprised that nobody reported this since then (perhaps nobody runs git
> on big endian 64-bit boxes?).
Both the native Sun compiler as well as GCC default to 32bit binaries,
even if the system is capable of running 64bit binaries (unlike for
example Linux where x86_64-pc-linux-gnu-gcc produces 64bit binaries by
default). And the git makefile doesn't use -m64, so my guess is that
nobody bothered changing CFLAGS on sparc64 systems (I have access to a
couple such systems and I never changed CFLAGS because git always worked
out of the box). Though I don't know what the default is on other big
endian systems.
tom
^ permalink raw reply
* Re: Newbie to git
From: Howard Miller @ 2009-12-27 20:12 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <3a9710ae6b01fabf3b462da607af2534@192.168.1.222>
2009/12/27 <mysql.jorge@decimal.pt>:
>> I'm a using of git for several time, but now I have the need to a git
>> server.
>> My question, where can get a howto for reallyyyy newbies on git server?
>
> One question:
>
> I've created a project on the server with:
>
> mkdir project.git
> cd project.git
> git init
>
> -and now locally, created a directory, and cloned this, it said that i was
> cloning an empty repo, fine about that.
> -now i added something locally, i get: (locally this is on a windows
> machine with tortoiso git)
>
> --
> git.exe push --tags "origin" master:git://192.168.1.206/projects.git
>
> error: src refspec master:git does not match any.
> error: failed to push some refs to 'git://192.168.1.206/projects.git'
Firstly, I would have a serious look at 'gitosis' for the server end
(there are other similar projects I believe).
Secondly, the push command is wrong. You don't need to supply the
remote URL again... that's what 'origin' is telling the push command,
which remote to use. This would have been established by the original
clone.
Also, again, be careful with 'empty' repositories. (again AFAIK) an
empty repository is just that, it doesn't even have a master branch so
you really need to check out a branch and commit something before
pushing makes much sense. I'm sure this is not 100% correct but you'll
be safe that way!
Howard
^ permalink raw reply
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Junio C Hamano @ 2009-12-27 20:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1261920513-25189-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> According to config.txt:
>> core.worktree::
>> Set the path to the working tree. The value will not be
>> used in combination with repositories found automatically in
>> a .git directory (i.e. $GIT_DIR is not set).
>
> This behavior was changed after e90fdc3 (Clean up work-tree handling -
> 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> 2007-12-05). If core.worktree is set, even if git_dir automatically
> found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> core.worktree. This makes core.worktree effective even if GIT_DIR is
> not set, in contrast to config.txt.
>
> This patch makes sure it only checks for core.worktree if GIT_DIR is set.
The work-tree area got too complicated over time for a small Panda brain
to grasp, so let me think aloud here.
The command line option --git-dir= has the same impact on the semantics as
the $GIT_DIR environment variable has. The only difference is that the
option has higher precedence over environment. Therefore, I won't talk
about the command line options in the following description.
In the beginning, there was GIT_DIR environment variable. We had a very
simple semantics:
- When there is no GIT_DIR environment variable:
- if "." is a "git directory", i.e. it has the set of git things like
refs/, objects/ and HEAD, then you are working in a bare repository.
- if ./.git exists and it is a "git directory", then "." is the top of
the work tree;
- otherwise, try the parent directory of "." for the second rule
repeatedly to find the git directory and the top of the work tree.
- When there is GIT_DIR environment variable:
- $GIT_DIR is (and must be) the "git directory" and "." is the top of
the work tree.
People wanted to have a work tree that is at a location totally unrelated
to where the "git directory" and setting $GIT_DIR at runtime was the only
way to do so, but that restricted them to work only at the top of the work
tree. $GIT_WORK_TREE was invented as a way to say "this is the top of the
work tree". So that people can do something like:
$ GIT_DIR=/srv/git/proj.git GIT_WORK_TREE=/scratch/proj
$ export GIT_DIR GIT_WORK_TREE
$ cd $GIT_WORK_TREE/Documentation
$ edit; git diff; git commit -a; ...
Because the facility was meant to allow separation of "git directory" and
its associated work tree, and not meant to allow more than one work trees
sharing the same "git directory" (which does not make any sense, as there
is only one index in "git directory" that describes the state of the work
tree), it was an unnecessary nuisanse that you had to set two environment
variables. core.worktree was invented---by recording the location of the
work tree in the config file in the "git directory", the above can be made
into this:
$ GIT_DIR=/srv/git/proj.git
$ cd /scratch/proj/Documentation
$ edit; git diff; git commit -a; ...
Given these background, I am not sure the "fix" is addressing the right
issue. What does it mean to have "core.worktree" in a configuration file,
but that configuration file was found in a "git directory" that was found
thorough the repository discovery process due to lack of $GIT_DIR? There
are only two cases I can see:
- The user is in the "git directory" itself, which is bare (iow,
/srv/git/proj.git in the above example). This is not the case the
documentation snippet you quoted is about, and I don't think your patch
changes (nor should change) the behaviour for;
- The "git directory" is a ".git/" subdirectory of some work tree, and
the value of core.worktree may or may not match that work tree. This
is the case the documentation talks about, and your patch addresses.
For the former case, while I don't see much point, we do seem to support
this use case (continuing the example scenario):
$ unset GIT_DIR GIT_WORK_TREE
$ cd /srv/git/proj.git
$ git checkout -b newbranch master
We find that "." is our "git directory", and through its config file, we
know core.worktree points at /scratch/proj/, and the checkout updates
files over there, not in /srv/git/proj.git/. While it is not obvious why
anybody finds this useful to me, I think the behaviour makes _some_ sense,
and I don't think your patch breaks it by changing the behaviour for this
case [*1*].
The latter, unless core.worktree matches the parent directory of the "git
directory" in question, seems to me a misconfiguration and nothing else.
Shouldn't it be diagnosed as an error, instead of matching the
documentation to the letter?
[Footnote]
*1* I said "makes _some_ sense" for a reason. While operations like
switching branches that is inherently whole-tree makes sense, it is
totally unclear what operations that work relative to the work tree,
i.e. "git add", in such a set-up.
^ permalink raw reply
* Re: Does smart-http need git-daemon-export-ok?
From: Shawn O. Pearce @ 2009-12-27 21:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Tarmigan, Git Mailing List, Tay Ray Chuan, Clemens Buchacher,
J.H.
In-Reply-To: <7vk4w963np.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
> > Should the git-http-backend check something like git-daemon-export-ok
> > before serving a repository?
>
> I'd agree that it would make sense to have a way to mark individual
> repository for (or not for) export.
Just for some background... early drafts of git-http-backend actually
did check for, and require, this file before it exported a repository.
I took the check out because I was relying on the HTTP server's
document root translation to provide the mapping into the local
filesystem. That meant the HTTP repository was already exported via
dumb-http, and the git-daemon-export-ok flag wasn't being checked.
Later in the series development we got the patch to allow a
different filesystem root via an environment variable, which means
its possible to hide repositories and make them available only
through git-http-backend. In that configuration, checking the
git-daemon-export-ok flag makes sense again.
> In "native" case, the chain of events are: client talks to the daemon, the
> daemon checks and decides to (or not to) export, and it runs upload-pack.
>
> In "smart http" case, http-backend is one half of what corresponds to the
> daemon (the other half being your http server configuration), and it is
> more flexible and git specific half, so I'd say it would make sense to
> implement the check that honors the same git-daemon-export-ok flag file in
> it.
Yea, I'd agree.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Shawn O. Pearce @ 2009-12-27 21:10 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <1261870153-57572-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> Similar to how git-daemon checks whether a repository is OK to be
> exported, smart-http should also check. This check can be satisfied
> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> may be set to export all repositories, or the individual repository
> may have the file git-daemon-export-ok.
>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
I really think this and 1/2 should be squashed together, in which
case you can apply my ACK to the entire thing.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Shawn O. Pearce @ 2009-12-27 21:15 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git
In-Reply-To: <1261847255-13970-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> Smart-http may be an attactive and easy way for people to setup git
> hosting on shared servers whose primary web server configuration they
> do not control. To facilite this, provide an example of how it may be
> done.
...
> + \~/public_html/cgi-bin/.htaccess:
> ++
> +----------------------------------------------------------------
> +SetHandler cgi-script
> +Options +SymLinksIfOwnerMatch
> +SetEnv GIT_PROJECT_ROOT /home/$username/devel
> +----------------------------------------------------------------
At this point, isn't this just easier?
mkdir ~/public_html/git
vi ~/public_html/git/.htaccess
SetEnv GIT_PROJECT_ROOT /home/$username/devel
ScriptAlias / /usr/libexec/git-core/git-http-backend/
No need to mess around with SymlinksIfOwnerMatch and all of that fun.
If you have .htaccess override allows, you should be able to setup
a ScriptAlias without needing to use a cgi-bin directory.
--
Shawn.
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <26ae428a0912271212j70857e29m6248f6ec653f7551@mail.gmail.com>
Hi Howard,
> Firstly, I would have a serious look at 'gitosis' for the server end
> (there are other similar projects I believe).
>
> Secondly, the push command is wrong. You don't need to supply the
> remote URL again... that's what 'origin' is telling the push command,
> which remote to use. This would have been established by the original
> clone.
>
> Also, again, be careful with 'empty' repositories. (again AFAIK) an
> empty repository is just that, it doesn't even have a master branch so
> you really need to check out a branch and commit something before
> pushing makes much sense. I'm sure this is not 100% correct but you'll
> be safe that way!
Well, gitosis even made me more confused :P
Let me reask:
I'm running git deamon under supervisor with:
/usr/lib/git-core/git-daemon --syslog --export-all --enable=receive-pack
--verbose --base-path=/home/apache/gitprojects
then i went to /home/apache/gitprojects and runned:
git init
git add .
but for example, CGIT web interface says:
--
Not a git repository: '/home/apache/gitprojects'
generated by cgit at 2009-12-27 21:54:47 (GMT)
--
what could i be missing here?
I've been reading howto's i find on the web, but all lead me to the same
point, what i did and non work.. (with me).
Jorge,
^ permalink raw reply
* Git reproducible corruption errors on merge/checkout not detected by git fsck --full --strict
From: Denis Rosset @ 2009-12-27 21:59 UTC (permalink / raw)
To: git
Hi all !
I use git regularly since twelve months; on one specific repository, I
had repetitive "inflate: data stream error (incorrect data check)"
errors. These errors appear when checking out from one branch to
another or when merging; however doing a "git fsck --full --strict" on
either the local repository or the remote repository before the
operation does not show anything wrong.
The bare repository is located on a Mac OS X 10.5 PPC server with Git
1.5.X.Y (X, Y not known), the local client is Git 1.6.6 installed
through MacPorts. I am stuck with Git 1.6.6 due to the MacPorts
architecture. Local zlib is 1.2.3_3.
I created a new local repository, reimported the files manually (only
the files, losing all the history in the process), and errors happen
again. The errors seems to appear when Git creates a local pack to
store the object files.
I am now installing Macports git 1.6.6 on the server to do further
testing.
My questions :
1) is "git fsck --full --strict" the most comprehensive check I can do
on a repository ?
2) are there known bugs leading to data corruption in the git 1.6.6
prerelease and/or zlib 1.2.3_3 ?
3) is there a verbose flag or a log I can consult (and eventually send
to this list) ?
Kind regards,
Denis Rosset
^ permalink raw reply
* Re: Newbie to git
From: Andreas Schwab @ 2009-12-27 22:34 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <0a78ff1d3ae5d236fa45c31f7bb8bd54@192.168.1.222>
<mysql.jorge@decimal.pt> writes:
> then i went to /home/apache/gitprojects and runned:
>
> git init
You probably want to create a bare repository in this directory:
$ git init --bare foo.git
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 23:00 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <m27hs8t5b7.fsf@whitebox.home>
Hi Andreas,
> You probably want to create a bare repository in this directory:
>
> $ git init --bare foo.git
>
Ok one more point, seams to be that!
Forgive my really newbie question:
not i have:
/home/apache/gitprojects/mydir.git
created with: git init --base mydir.git
Now, inside here, what should i do to create my projects:
mkdir myproject1
cd myproject1
git init
touch a.txt
git add .
git commit -m "1st commit"
am i correct or not really?
^ permalink raw reply
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Robin Rosenberg @ 2009-12-28 0:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Robin Rosenberg
In-Reply-To: <7viqbsw2vn.fsf@alter.siamese.dyndns.org>
söndagen den 27 december 2009 21.58.20 skrev Junio C Hamano:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> > According to config.txt:
> >> core.worktree::
> >> Set the path to the working tree. The value will not be
> >> used in combination with repositories found automatically in
> >> a .git directory (i.e. $GIT_DIR is not set).
> >
> > This behavior was changed after e90fdc3 (Clean up work-tree handling -
> > 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> > 2007-12-05). If core.worktree is set, even if git_dir automatically
> > found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> > core.worktree. This makes core.worktree effective even if GIT_DIR is
> > not set, in contrast to config.txt.
> >
> > This patch makes sure it only checks for core.worktree if GIT_DIR is set.
...
>
> Given these background, I am not sure the "fix" is addressing the right
> issue. What does it mean to have "core.worktree" in a configuration file,
> but that configuration file was found in a "git directory" that was found
> thorough the repository discovery process due to lack of $GIT_DIR? There
> are only two cases I can see:
I'm inclined towards fixing the docs. Overriding a config setting in non-
intuitive and nobody has complained.
-- robin
^ permalink raw reply
* Re: Newbie to git
From: Junio C Hamano @ 2009-12-28 2:18 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <ecddd9ed719d3d854b2248970cdb9cdf@192.168.1.222>
<mysql.jorge@decimal.pt> writes:
> Hi Andreas,
If you are addressing Andreas, why does your mail have:
To: <git@vger.kernel.org>
Cc: <git@vger.kernel.org>
and no other addressee???
> not i have:
> /home/apache/gitprojects/mydir.git
>
> created with: git init --base mydir.git
>
> Now, inside here, what should i do to create my projects:
>
> mkdir myproject1
> cd myproject1
> git init
> touch a.txt
> git add .
> git commit -m "1st commit"
>
> am i correct or not really?
You created "myproject1" somewhere you started "mkdir" in (perhaps in
$HOME?) [*1*] and that project tracks a single file "a.txt"; you are
correct if that was what you wanted to do.
The new repository "myproject1" doesn't have any relation to the bare
repository at /home/apache/gitprojects/mydir.git/ you created earlier.
The next steps I recommend new people are:
(1) push into the public repository, by doing:
cd myproject1
git push /home/apache/gitprojects/mydir.git/ master
(2) make sure push went correctly by trying to clone from there:
cd ..
mv myproject1 myproject1.old
git clone /home/apache/gitprojects/mydir.git/ myproject1
(3) check if the clone is what you expect
diff myproject1.old/a.txt myproject1/a.txt
(4) once satisfied, remove the old one
rm -fr myproject1.old
And keep working in the myproject1 repository from there on.
[Footnote]
*1* If you started that "mkdir" somewhere else you may want to remove it
and redo that step, especially if you did so inside that bare repository
you created earlier, i.e. /home/apache/gitprojects/mydir.git directory.
You don't want to have it there.
^ 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