* [PATCH v3 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
From: Ramsay Jones @ 2009-11-09 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marius Storm-Olsen, Johannes Sixt, GIT Mailing-list
Since commit 435bdf8c ("Make usage of windows.h lean and mean",
16-9-2009), the amount of code potentially including the WIN32
API header files has greatly increased. In particular, the Cygwin
build is at greater risk of inadvertently including WIN32 code
within preprocessor sections protected by the WIN32 or _WIN32
macros.
The previous commit message, along with comments elsewhere, assert
that the WIN32 macro is not defined on Cygwin. Currently, this is
true for the cygwin build. However, the cygwin platform can be
used to develop WIN32 GUI, WIN32 console, and POSIX applications.
Indeed it is possible to create applications which use a mix of
the WIN32 API and POSIX code (eg git!).
Unlike native WIN32 compilers, gcc on cygwin does not automatically
define the _WIN32 macro. However, as soon as you include the
<windows.h> header file, the _WIN32 and WIN32 macros are defined.
In order to reduce the risk of problems in the future, we protect
the inclusion of the windows header with an explicit check for
__CYGWIN__. Also, we move the other use of the <windows.h> header
from compat/win32.h to compat/cygwin.c
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Changes since v2:
- removed indentation from the #if-#endif block
I hope you don't mind, but I've only sent this patch, rather than
re-send the whole series. If you would like a complete re-send, just
let me know.
ATB,
Ramsay Jones
compat/cygwin.c | 1 +
compat/win32.h | 3 ---
git-compat-util.h | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/compat/cygwin.c b/compat/cygwin.c
index b4a51b9..6695515 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,5 +1,6 @@
#define WIN32_LEAN_AND_MEAN
#include "../git-compat-util.h"
+#include <windows.h>
#include "win32.h"
#include "../cache.h" /* to read configuration */
diff --git a/compat/win32.h b/compat/win32.h
index 8ce9104..a7ed72b 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -2,9 +2,6 @@
#define WIN32_H
/* common Win32 functions for MinGW and Cygwin */
-#ifndef WIN32 /* Not defined by Cygwin */
-#include <windows.h>
-#endif
static inline int file_attr_to_st_mode (DWORD attr)
{
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..0cd2693 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -65,7 +65,7 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
+#if defined(_WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
--
1.6.5
^ permalink raw reply related
* Re: [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
From: Ramsay Jones @ 2009-11-09 19:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramsay Jones, Marius Storm-Olsen, Johannes Sixt, GIT Mailing-list
In-Reply-To: <4AF5D6F8.40608@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index ef60803..c4b9e5a 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -65,10 +65,10 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include <winsock2.h>
> -#include <windows.h>
> +#if defined(_WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
> +# define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> +# include <winsock2.h>
> +# include <windows.h>
Arrgghhh.
Sorry, Junio, I meant to change this before sending it out. :(
I had intended to remove the added indentation (which I don't even remember
doing!), since it obscures the "real change", which simply consists of the
new expression in the #if preprocessor line.
I'll send a new version of this patch.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] git_odb_open ckeck for valid path to database
From: Ramsay Jones @ 2009-11-09 19:16 UTC (permalink / raw)
To: Esben Mose Hansen; +Cc: ae, git
In-Reply-To: <1257510729-6803-1-git-send-email-kde@mosehansen.dk>
Esben Mose Hansen wrote:
> diff --git a/src/odb.c b/src/odb.c
> index 6d646a4..89d6d03 100644
> --- a/src/odb.c
> +++ b/src/odb.c
> @@ -30,6 +30,10 @@
> #include "hash.h"
> #include "odb.h"
>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <unistd.h>
> +
None of these #includes should be necessary (they are not for me).
Also, "#include <unistd.h>" breaks on windows ;-)
> #define GIT_PACK_NAME_MAX (5 + 40 + 1)
> struct git_pack {
> git_odb *db;
> @@ -1023,6 +1027,15 @@ int git_odb_open(git_odb **out, const char *objects_dir)
> free(db);
> return GIT_ERROR;
> }
> + struct stat objects_dir_stat;
This should be declared at the head of the function (or generally at the start of
a block/scope); ie we don't use this C99 facility. This breaks MSVC, which does
not understand C99.
> + if (stat(db->objects_dir, &objects_dir_stat)) {
> + free(db);
> + return GIT_EOSERR;
> + }
> + if (!S_ISDIR(objects_dir_stat.st_mode)) {
This breaks on MSVC, since the MS headers do not define S_ISDIR. It's not difficult
to add; it's on my TODO list. (Andreas, I can add this later if you like)
However, I suspect it may be useful to add an gitfo_is_directory() function, or
something like it. Maybe. Andreas?
Thank you for the patch.
(I think Andreas would prefer to see libgit2 somewhere in the subject, perhaps
like [LIBGIT2 PATCH], otherwise he may miss you email)
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH] http-backend: Protect GIT_PROJECT_ROOT from /../ requests
From: Shawn O. Pearce @ 2009-11-09 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Eons ago HPA taught git-daemon how to protect itself from /../
attacks, which Junio brought back into service in d79374c7b58d
("daemon.c and path.enter_repo(): revamp path validation").
I did not carry this into git-http-backend as originally we relied
only upon PATH_TRANSLATED, and assumed the HTTP server had done
its access control checks to validate the resolved path was within
a directory permitting access from the remote client. This would
usually be sufficient to protect a server from requests for its
/etc/passwd file by http://host/smart/../etc/passwd sorts of URLs.
However in 917adc036086 Mark Lodato added GIT_PROJECT_ROOT as an
additional method of configuring the CGI. When this environment
variable is used the web server does not generate the final access
path and therefore may blindly pass through "/../etc/passwd"
in PATH_INFO under the assumption that "/../" might have special
meaning to the invoked CGI.
Instead of permitting these sorts of malformed path requests, we
now reject them back at the client, with an error message for the
server log. This matches git-daemon behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
cache.h | 1 +
daemon.c | 49 +----------------------------------------------
http-backend.c | 6 +++++
path.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
t/t5560-http-backend.sh | 31 +++++++++++++++++++++++++++++
5 files changed, 86 insertions(+), 48 deletions(-)
diff --git a/cache.h b/cache.h
index 4e283be..ecbd88a 100644
--- a/cache.h
+++ b/cache.h
@@ -656,6 +656,7 @@ const char *make_relative_path(const char *abs, const char *base);
int normalize_path_copy(char *dst, const char *src);
int longest_ancestor_length(const char *path, const char *prefix_list);
char *strip_path_suffix(const char *path, const char *suffix);
+int daemon_avoid_alias(const char *path);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/daemon.c b/daemon.c
index 1b5ada6..ce48006 100644
--- a/daemon.c
+++ b/daemon.c
@@ -101,53 +101,6 @@ static void NORETURN daemon_die(const char *err, va_list params)
exit(1);
}
-static int avoid_alias(char *p)
-{
- int sl, ndot;
-
- /*
- * This resurrects the belts and suspenders paranoia check by HPA
- * done in <435560F7.4080006@zytor.com> thread, now enter_repo()
- * does not do getcwd() based path canonicalizations.
- *
- * sl becomes true immediately after seeing '/' and continues to
- * be true as long as dots continue after that without intervening
- * non-dot character.
- */
- if (!p || (*p != '/' && *p != '~'))
- return -1;
- sl = 1; ndot = 0;
- p++;
-
- while (1) {
- char ch = *p++;
- if (sl) {
- if (ch == '.')
- ndot++;
- else if (ch == '/') {
- if (ndot < 3)
- /* reject //, /./ and /../ */
- return -1;
- ndot = 0;
- }
- else if (ch == 0) {
- if (0 < ndot && ndot < 3)
- /* reject /.$ and /..$ */
- return -1;
- return 0;
- }
- else
- sl = ndot = 0;
- }
- else if (ch == 0)
- return 0;
- else if (ch == '/') {
- sl = 1;
- ndot = 0;
- }
- }
-}
-
static char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
@@ -157,7 +110,7 @@ static char *path_ok(char *directory)
dir = directory;
- if (avoid_alias(dir)) {
+ if (daemon_avoid_alias(dir)) {
logerror("'%s': aliased", dir);
return NULL;
}
diff --git a/http-backend.c b/http-backend.c
index 646e910..f8ea9d7 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -559,7 +559,13 @@ static char* getdir(void)
if (root && *root) {
if (!pathinfo || !*pathinfo)
die("GIT_PROJECT_ROOT is set but PATH_INFO is not");
+ if (daemon_avoid_alias(pathinfo))
+ die("'%s': aliased", pathinfo);
strbuf_addstr(&buf, root);
+ if (buf.buf[buf.len - 1] != '/')
+ strbuf_addch(&buf, '/');
+ if (pathinfo[0] == '/')
+ pathinfo++;
strbuf_addstr(&buf, pathinfo);
return strbuf_detach(&buf, NULL);
} else if (path && *path) {
diff --git a/path.c b/path.c
index 047fdb0..c7679be 100644
--- a/path.c
+++ b/path.c
@@ -564,3 +564,50 @@ char *strip_path_suffix(const char *path, const char *suffix)
return NULL;
return xstrndup(path, chomp_trailing_dir_sep(path, path_len));
}
+
+int daemon_avoid_alias(const char *p)
+{
+ int sl, ndot;
+
+ /*
+ * This resurrects the belts and suspenders paranoia check by HPA
+ * done in <435560F7.4080006@zytor.com> thread, now enter_repo()
+ * does not do getcwd() based path canonicalizations.
+ *
+ * sl becomes true immediately after seeing '/' and continues to
+ * be true as long as dots continue after that without intervening
+ * non-dot character.
+ */
+ if (!p || (*p != '/' && *p != '~'))
+ return -1;
+ sl = 1; ndot = 0;
+ p++;
+
+ while (1) {
+ char ch = *p++;
+ if (sl) {
+ if (ch == '.')
+ ndot++;
+ else if (ch == '/') {
+ if (ndot < 3)
+ /* reject //, /./ and /../ */
+ return -1;
+ ndot = 0;
+ }
+ else if (ch == 0) {
+ if (0 < ndot && ndot < 3)
+ /* reject /.$ and /..$ */
+ return -1;
+ return 0;
+ }
+ else
+ sl = ndot = 0;
+ }
+ else if (ch == 0)
+ return 0;
+ else if (ch == '/') {
+ sl = 1;
+ ndot = 0;
+ }
+ }
+}
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index 908ba07..ed034bc 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -146,6 +146,37 @@ test_expect_success 'http.receivepack false' '
POST git-receive-pack 0000 "403 Forbidden"
'
+run_backend() {
+ REQUEST_METHOD=GET \
+ GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
+ PATH_INFO="$2" \
+ git http-backend >act.out 2>act.err
+}
+
+path_info() {
+ if test $1 = 0; then
+ run_backend "$2"
+ else
+ test_must_fail run_backend "$2" &&
+ echo "fatal: '$2': aliased" >exp.err &&
+ test_cmp exp.err act.err
+ fi
+}
+
+test_expect_success 'http-backend blocks bad PATH_INFO' '
+ config http.getanyfile true &&
+
+ run_backend 0 /repo.git/HEAD &&
+
+ run_backend 1 /repo.git/../HEAD &&
+ run_backend 1 /../etc/passwd &&
+ run_backend 1 ../etc/passwd &&
+ run_backend 1 /etc//passwd &&
+ run_backend 1 /etc/./passwd &&
+ run_backend 1 /etc/.../passwd &&
+ run_backend 1 //domain/data.txt
+'
+
cat >exp <<EOF
### refs/heads/master
--
1.6.5.2.351.g09432
^ permalink raw reply related
* Re: pulling git -- version confusion
From: Sverre Rabbelier @ 2009-11-09 19:16 UTC (permalink / raw)
To: Rustom Mody; +Cc: git
In-Reply-To: <f46c52560911090524l51140858sdde29d76e2cfed49@mail.gmail.com>
Heya,
On Mon, Nov 9, 2009 at 14:24, Rustom Mody <rustompmody@gmail.com> wrote:
> So theres no remote?
> But .git/remotes/origin has
Ick, how about switching to:
$ git remote add origin"git://git.kernel.org/pub/scm/git/git.git"
And then you can do what I said earlier?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git drawbacks?
From: B Smith-Mannschott @ 2009-11-09 18:47 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T170054-451@post.gmane.org>
On Mon, Nov 9, 2009 at 17:11, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
>
>> Actually, in most use cases, there is no reason to have more than one
>> working tree. Git is designed to work well with plenty branches and one
>> working tree. So, switching between two branches and recompiling a few
>> changed files is much faster then going to another directory and try to
>> work there, because when you go to another directory, you may hit cold
>> cache and disk is *slow*... Another thing is that you can do a lot of
>> things without checking out some branch. You can grep any revision in
>> your repository, you can insect any file from it, etc and you do not
>> have to checkout this revision in your working tree.
>
> Shouldn't I even worry about my not yet commited changes before switching the
> branch?
commit them before you switch. you could:
- commit them to the current branch before you switch the branch.
- commit them to a new branch before you switch
- use git stash to move your changes aside.
> I would say that this approach does not work if the build and test could take
> significant time. While in CR fix I don't want to wait for a build to complete
> before I countinue with another bug/fix. That is why I'm curious about
> few working trees...
You don't have to wait to comitting to your own branches, but do make
sure to run your usual builds and tests before pushing or asking
another to pull changes from you.
// Ben
^ permalink raw reply
* Re: question: connecting to multiple remote svn projects
From: Avery Pennarun @ 2009-11-09 18:43 UTC (permalink / raw)
To: Dave Rodgman; +Cc: git
In-Reply-To: <hd8smd$79e$2@ger.gmane.org>
On Mon, Nov 9, 2009 at 5:59 AM, Dave Rodgman <dav1dr@eml.cc> wrote:
> As far as I can understand, git-submodule pulls in a specific commit,
> as does git subtree? I've experimented a little but with not much success.
Well, they both pull in a specific commit *and* all the history
leading up to it, although the two of them do it in slightly different
ways.
> I want "git svn rebase" (or some equivalent command, or series of
> commands) to update the contents of module1/work to the latest commit
> into this branch, and similarly "git svn dcommit" should also commit into
> module1, module2, etc. Basically, I want my working copy to have the same
> functionality as if moduleX/work was the actual layout in subversion. I'm
> using git as a client for a svn repository, rather than doing a one-time
> import. Is this possible?
Yes. Both tools will work for two-way svn import/export, although
submodules will probably be a bit more convenient.
Essentially, you create one branch (and one git-svn remote entry) for
each svn subproject, and one branch for the combined project. In the
combined project, your .gitmodules should use '.' as the submodule
repository path (since all your submodule objects are in the same
local repo).
Then you 'git svn fetch' to retrieve the latest from each svn project.
Then, in each submodule, you can 'git pull .. git-svn-branchname' to
get the latest stuff from git-svn for that branch.
Then, in the combined project, you 'git commit' to lock in those commits.
It's a little screwy, but it works :)
Avery
^ permalink raw reply
* Re: [RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl
From: Tarmigan @ 2009-11-09 18:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1257790237-30850-3-git-send-email-spearce@spearce.org>
On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Unfortunately at least one version of libcurl has a bug causing
> it to include "Accept: */*" in the same POST request where we have
> already asked for "Accept: application/x-git-upload-pack-response".
>
> This is a bug in libcurl, not Git, or our test vector. The
> application has explicitly asked the server for a single content
> type, but libcurl has mistakenly also told the server the client
> application will accept */*, which is any content type.
>
> Based on the libcurl change log, this "Accept: */*" header bug
> may have been fixed in version 7.18.1 released March 30, 2008:
>
> http://curl.haxx.se/changes.html#7_18_1
>
> Rather than require users to upgrade libcurl we change the test
> vector to trim this line out of the 2nd request.
>
> Reported-by: Tarmigan <tarmigan+git@gmail.com>
Tested-by: Tarmigan <tarmigan+git@gmail.com>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
^ permalink raw reply
* Re: [PATCH 2/3] t5551-http-fetch: Work around some libcurl versions
From: Tarmigan @ 2009-11-09 18:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1257790237-30850-2-git-send-email-spearce@spearce.org>
On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Some versions of libcurl report their output when GIT_CURL_VERBOSE
> is set differently than other versions do. At least one variant
> (version unknown but likely pre-7.18.1) reports the POST payload to
> stderr, and omits the blank line after each HTTP request/response.
Yes, my curl is 7.15.5.
> @@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
> sed -e "
> s/Q\$//
> /^[*] /d
> + /^$/d
> + /^< $/d
>
> /^[^><]/{
> s/^/> /
> @@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
> /^> User-Agent: /d
> /^> Host: /d
> s/^> Content-Length: .*/> Content-Length: xxx/
> + /^00..want /d
> + /^00.*done/d
Almost. This still needs a
'> '
before both of the 00 additions. Changing this and applying 3/3 makes
the test pass for me.
Tested-with-modifications-by: Tarmigan <tarmigan+git@gmail.com>
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-09 18:34 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T170054-451@post.gmane.org>
On Mon, Nov 09, 2009 at 04:11:48PM +0000, Dmitry Smirnov wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
>
> > Actually, in most use cases, there is no reason to have more than one
> > working tree. Git is designed to work well with plenty branches and one
> > working tree. So, switching between two branches and recompiling a few
> > changed files is much faster then going to another directory and try to
> > work there, because when you go to another directory, you may hit cold
> > cache and disk is *slow*... Another thing is that you can do a lot of
> > things without checking out some branch. You can grep any revision in
> > your repository, you can insect any file from it, etc and you do not
> > have to checkout this revision in your working tree.
>
> Shouldn't I even worry about my not yet commited changes before switching the
> branch?
You probably want to use 'git stash save' and when you return back you
just do 'git stash pop'. Also, keep in mind that you can amend any
previous commit using 'git commit --amend'.
>
> I would say that this approach does not work if the build and test could take
> significant time.
Yes, but then I do not see any reason to do any time consuming building
and testing in the working tree. I create a snapshot of the interesting
version using 'git archive' and then run build&test on it... In this
way, I can make sure that the archive I deliver is tested properly. If
you do your testing in the working tree, sometimes uncommitted or some
other files that are left over from previous builds may affect result.
So, if it takes considerable time anyhow, why do not do clean build and
test? And if you worry about compilation time, you can use ccache.
Dmitry
^ permalink raw reply
* [PATCH RFC v2] builtin-push: add --delete as syntactic sugar for :foo
From: Jan Krüger @ 2009-11-09 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Sverre Rabbelier
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line, and will refuse to accept refspecs with
colons to prevent undue confusion.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
All good points, and I actually remembered to catch the colon-refspec
case a few minutes after sending the patch, but didn't have time to fix
it up. (Sorry for not considering the old thread; I had gotten
unsubscribed from the list back then).
I think with this change it becomes much saner. And no, I'm not
proposing to add --rename and --copy, too. ;)
The new error message is not completely technically correct since it's
still a refspec we're taking, we just force it to be without a colon.
On the other hand, this error message will hopefully make much more
sense to people who don't know all the background, and it's not too
horribly wrong either.
(Sverre added to Cc list from subthread)
builtin-push.c | 16 ++++++++++++++++
t/t5516-fetch-push.sh | 6 ++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 8631c06..e40bfe8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -15,6 +15,7 @@ static const char * const push_usage[] = {
};
static int thin;
+static int deleterefs;
static const char *receivepack;
static const char **refspec;
@@ -44,6 +45,15 @@ static void set_refspecs(const char **refs, int nr)
strcat(tag, refs[i]);
ref = tag;
}
+ if (deleterefs && !strchr(ref, ':')) {
+ char *delref;
+ int len = strlen(refs[i] + 1);
+ delref = xmalloc(len);
+ strcpy(delref, ":");
+ strcat(delref, refs[i]);
+ ref = delref;
+ } else if (deleterefs)
+ die("--delete only accepts plain target ref names");
add_refspec(ref);
}
}
@@ -181,6 +191,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+ OPT_BOOLEAN( 0, "delete", &deleterefs, "delete refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
@@ -193,6 +204,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
+ die("--delete is incompatible with --all, --mirror and --tags");
+ if (deleterefs && argc < 2)
+ die("--delete doesn't make sense without any refs");
+
if (tags)
add_refspec("refs/tags/*");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6889a53..aa1450a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -546,6 +546,12 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'allow deleting a ref using --delete' '
+ mk_test heads/master &&
+ git push testrepo --delete master &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/heads/master)
+'
+
test_expect_success 'warn on push to HEAD of non-bare repository' '
mk_test heads/master
(cd testrepo &&
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* [RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Tarmigan
In-Reply-To: <1257790237-30850-1-git-send-email-spearce@spearce.org>
Unfortunately at least one version of libcurl has a bug causing
it to include "Accept: */*" in the same POST request where we have
already asked for "Accept: application/x-git-upload-pack-response".
This is a bug in libcurl, not Git, or our test vector. The
application has explicitly asked the server for a single content
type, but libcurl has mistakenly also told the server the client
application will accept */*, which is any content type.
Based on the libcurl change log, this "Accept: */*" header bug
may have been fixed in version 7.18.1 released March 30, 2008:
http://curl.haxx.se/changes.html#7_18_1
Rather than require users to upgrade libcurl we change the test
vector to trim this line out of the 2nd request.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Actually, I don't want to apply this.
Tarmigan, your libcurl is broken, it looks like a newer version
fixes the problem, so I would suggest upgrading it.
t/t5551-http-fetch.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 6b0165c..9d59065 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -61,6 +61,9 @@ test_expect_success 'clone http repository' '
/^> User-Agent: /d
/^> Host: /d
+ /^> POST /,$ {
+ /^> Accept: [*]\\/[*]/d
+ }
s/^> Content-Length: .*/> Content-Length: xxx/
/^00..want /d
/^00.*done/d
--
1.6.5.2.351.g09432
^ permalink raw reply related
* [PATCH 2/3] t5551-http-fetch: Work around some libcurl versions
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Tarmigan
In-Reply-To: <1257790237-30850-1-git-send-email-spearce@spearce.org>
Some versions of libcurl report their output when GIT_CURL_VERBOSE
is set differently than other versions do. At least one variant
(version unknown but likely pre-7.18.1) reports the POST payload to
stderr, and omits the blank line after each HTTP request/response.
We clip these lines out of the stderr output now before doing the
compare, so we aren't surprised by this trivial difference.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t5551-http-fetch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index eb0c039..6b0165c 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -31,23 +31,19 @@ cat >exp <<EOF
> GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
> Accept: */*
> Pragma: no-cache
-
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-advertisement
-<
> POST /smart/repo.git/git-upload-pack HTTP/1.1
> Accept-Encoding: deflate, gzip
> Content-Type: application/x-git-upload-pack-request
> Accept: application/x-git-upload-pack-response
> Content-Length: xxx
-
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-result
-<
EOF
test_expect_success 'clone http repository' '
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
@@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
sed -e "
s/Q\$//
/^[*] /d
+ /^$/d
+ /^< $/d
/^[^><]/{
s/^/> /
@@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
+ /^00..want /d
+ /^00.*done/d
/^< Server: /d
/^< Expires: /d
--
1.6.5.2.351.g09432
^ permalink raw reply related
* [PATCH 1/3] http-backend: Fix symbol clash on AIX 5.3
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Mike Ralphson
Mike says:
> > +static void send_file(const char *the_type, const char *name)
> > +{
>
> I think a symbol clash here is responsible for a build breakage in
> next on AIX 5.3:
>
> CC http-backend.o
> http-backend.c:213: error: conflicting types for `send_file'
> /usr/include/sys/socket.h:676: error: previous declaration of `send_file'
> gmake: *** [http-backend.o] Error 1
So we rename the function send_local_file().
Reported-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
http-backend.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index 9021266..646e910 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -209,7 +209,7 @@ static void send_strbuf(const char *type, struct strbuf *buf)
safe_write(1, buf->buf, buf->len);
}
-static void send_file(const char *the_type, const char *name)
+static void send_local_file(const char *the_type, const char *name)
{
const char *p = git_path("%s", name);
size_t buf_alloc = 8192;
@@ -247,28 +247,28 @@ static void get_text_file(char *name)
{
select_getanyfile();
hdr_nocache();
- send_file("text/plain", name);
+ send_local_file("text/plain", name);
}
static void get_loose_object(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-loose-object", name);
+ send_local_file("application/x-git-loose-object", name);
}
static void get_pack_file(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-packed-objects", name);
+ send_local_file("application/x-git-packed-objects", name);
}
static void get_idx_file(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-packed-objects-toc", name);
+ send_local_file("application/x-git-packed-objects-toc", name);
}
static int http_config(const char *var, const char *value, void *cb)
--
1.6.5.2.351.g09432
^ permalink raw reply related
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Sverre Rabbelier @ 2009-11-09 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Krüger, Git ML
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 9, 2009 at 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> Jan Krüger <jk@jk.gs> writes:
>> Specifically, --delete will prepend a colon to all colon-less refspecs
>> given on the command line.
>
> Will it barf and error out if there is any colon-ful one? I think it
> should. I was about to write "I guess it could be argued both ways", but
> after thinking about it for 5 seconds I do not see a sane way to explain a
> command line "push origin --delete one two:three".
Did we not have this discussion not 3 months ago and decided it was a bad idea?
http://thread.gmane.org/gmane.comp.version-control.git/125894
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Sverre Rabbelier @ 2009-11-09 17:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <7vhbt3y7fb.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 9, 2009 at 17:44, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>> It's in next now, so please send follow-ups against sr/vcs-helper.
>
> Do you mean 'pu' or 'next'?
Sorry, my hands did not type what my mind intended, I meant to say
'pu', apologies!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-11-09 17:08 UTC (permalink / raw)
To: Jan Krüger; +Cc: Junio C Hamano, Git ML
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Will it barf and error out if there is any colon-ful one? I think it
> should. I was about to write "I guess it could be argued both ways", but
> after thinking about it for 5 seconds I do not see a sane way to explain a
> command line "push origin --delete one two:three".
Actually the one I had in mind was
git push origin --delete one two:three four
If it were
git push origin --tags --delete=one --delete=four two:three
it would be perfectly understandable, though.
No, I am not saying that we should make --delete take a parameter, allow
multiple of them, and make them compatible with --tags. At least not yet.
^ permalink raw reply
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-11-09 16:59 UTC (permalink / raw)
To: Jan Krüger; +Cc: Git ML
In-Reply-To: <20091109130935.2bea7771@perceptron>
Jan Krüger <jk@jk.gs> writes:
> Refspecs without a source side have been reported as confusing by many.
> As an alternative, this adds support for commands like:
>
> git push origin --delete somebranch
>
> Specifically, --delete will prepend a colon to all colon-less refspecs
> given on the command line.
Will it barf and error out if there is any colon-ful one? I think it
should. I was about to write "I guess it could be argued both ways", but
after thinking about it for 5 seconds I do not see a sane way to explain a
command line "push origin --delete one two:three".
I agree with you that it wouldn't make sense to mix this with --all and
friends.
^ permalink raw reply
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Junio C Hamano @ 2009-11-09 16:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhbt3ap3w.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I just found a way to reproduce the problem using plain SSH, and not
> Git:
>
> $ ssh localhost cat < random.bin | wc
> 249 1460 65536
> $ cat < random.bin | wc
> 796 4545 204800
>
> So, sshd is broken on this machine, and I don't think Git is the one
> to blame.
Yuck; that sounds scary.
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Junio C Hamano @ 2009-11-09 16:44 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911082242k5950d780i584a4714e384e007@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sat, Nov 7, 2009 at 00:19, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Sat, Nov 7, 2009 at 00:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
>>> At the very least, it needs documentation and memory leaks fixed (the
>>> refspec strings read from the helper, and the refspec structs and array on
>>> freeing the helper data).
>>
>> Please send follow-ups against [0] and I will include them in the next round :).
>
> It's in next now, so please send follow-ups against sr/vcs-helper.
Do you mean 'pu' or 'next'?
^ permalink raw reply
* Re: Git drawbacks?
From: Jacob Helwig @ 2009-11-09 16:21 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T165620-587@post.gmane.org>
On Mon, Nov 9, 2009 at 07:59, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Jacob Helwig <jacob.helwig <at> gmail.com> writes:
>
>> It does have a few caveats, however. If you have the same branch
>> checked out in two different working copies created using
>>...
>> place on your machine, you'll never notice, thuogh.
>
>
> So, i cannot recover from this situation by upmerging to the new head?
>
If you haven't actually made any changes in the second checkout of the
branch, then recovery is a simple reset --hard. If you have made any
changes in that working copy, then recovery is a bit more complicated,
and it's probably best if I leave that explanation up to someone else,
since I'm very careful to avoid this situation in the first place, and
have never actually had to recover from it.
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <20091109154816.GH27126@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov <at> gmail.com> writes:
> Actually, in most use cases, there is no reason to have more than one
> working tree. Git is designed to work well with plenty branches and one
> working tree. So, switching between two branches and recompiling a few
> changed files is much faster then going to another directory and try to
> work there, because when you go to another directory, you may hit cold
> cache and disk is *slow*... Another thing is that you can do a lot of
> things without checking out some branch. You can grep any revision in
> your repository, you can insect any file from it, etc and you do not
> have to checkout this revision in your working tree.
Shouldn't I even worry about my not yet commited changes before switching the
branch?
I would say that this approach does not work if the build and test could take
significant time. While in CR fix I don't want to wait for a build to complete
before I countinue with another bug/fix. That is why I'm curious about
few working trees...
^ permalink raw reply
* get git not to care about permissions
From: sconeman @ 2009-11-09 16:06 UTC (permalink / raw)
To: git
Hello,
I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
shares are configured with Windows permissions, and I forget the specifics
(which I can figure out if needed) about why this is the case, but basically
the deal is that if true UNIX permissions were to be used, Windows wouldn't
be able to read the drive. As such, and because we use the Kerberos
ticketing system, the permissions for the drive are set up such that the
owners (myself and my team members) have full permissions, but nobody else
does. Git doesn't like this and won't even create a bare repository. Is
there any way I can get git to ignore permissions and just do what it needs
to do?
Thanks in advance for the help!
-Matt
--
View this message in context: http://old.nabble.com/get-git-not-to-care-about-permissions-tp26268938p26268938.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 15:59 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060911090634p4e036208mfb3160eb4c4430e9@mail.gmail.com>
Jacob Helwig <jacob.helwig <at> gmail.com> writes:
> It does have a few caveats, however. If you have the same branch
> checked out in two different working copies created using
>...
> place on your machine, you'll never notice, thuogh.
So, i cannot recover from this situation by upmerging to the new head?
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-09 15:48 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T084539-720@post.gmane.org>
On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:
> <david <at> lang.hm> writes:
>
> > going back to the initial poster's comments. if the android repo is 1G,
> > eliminating the history will probably have significantly less impact than
> > you expect it to.
>
> Do you have 2 or more copies of the same repository at the same time?
> If yes, can I skip cloning new copy from network?
> Or even skip cloning it at all?
> Is it possible with Git to chekout into two (few) working trees?
Jacob has already mentioned git-new-workdir from Git contrib, but
there are other ways to do the same or almost the same....
First of all, you can always copy your directory and thus creating
another clone. It is very simple and straightforward solution, but
it takes extra space due an extra copy of the repository. Usually,
it is not a big issue in practice, because your working tree tends
to be larger than the repository itself...
However, if you want to save disk space, you can use local clone. When
you clone your (like: git clone old_dir new_dir), git tries to use hard
links if it is possible. So, it may save disk space. However, if you
repack your original repo then a new pack will be created, and saving
from using the hard link will be lost. To prevent that from happening,
you can tell to the garbage collector to keep the main existing pack by
create a file that has the same name as the pack file plus the .keep
suffix:
touch .git/objects/pack-<SHA-1>.keep
then all changes will be put into a separate pack.
There is one more way to save disk space is to use git clone --shared.
It does not require hard links, but it has some caveats. If you want to
use it, then read the documentation carefully and make sure you understand
all implications.
Actually, in most use cases, there is no reason to have more than one
working tree. Git is designed to work well with plenty branches and one
working tree. So, switching between two branches and recompiling a few
changed files is much faster then going to another directory and try to
work there, because when you go to another directory, you may hit cold
cache and disk is *slow*... Another thing is that you can do a lot of
things without checking out some branch. You can grep any revision in
your repository, you can insect any file from it, etc and you do not
have to checkout this revision in your working tree.
Dmitry
^ 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