* [PATCH 02/24] Show usage string for 'git grep -h'
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Junio C Hamano
In-Reply-To: <20091109150235.GA23871@progeny.tock>
Clarification: the following description only talks about "git
grep -h" without any other options and arguments.
Such a change cannot be breaking backward compatibility. "grep
-h" cannot be asking for suppressing filenames, as there is no
match pattern specified.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-grep.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 1df25b0..01be9bf 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -788,6 +788,13 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_END()
};
+ /*
+ * 'git grep -h', unlike 'git grep -h <pattern>', is a request
+ * to show usage information and exit.
+ */
+ if (argc == 2 && !strcmp(argv[1], "-h"))
+ usage_with_options(grep_usage, options);
+
memset(&opt, 0, sizeof(opt));
opt.prefix = prefix;
opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
--
1.6.5.2
^ permalink raw reply related
* [PATCH 01/24] Retire fetch--tool helper to contrib/examples
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
When git-fetch was builtin-ized, the previous script was moved to
contrib/examples. Now, it is the sole remaining user for
'git fetch--tool'.
The fetch--tool code is still worth keeping around so people can
try out the old git-fetch.sh, for example when investigating
regressions from the builtinifaction.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
See also <http://thread.gmane.org/gmane.comp.version-control.git/65122/focus=65191>.
Makefile | 1 -
builtin.h | 1 -
.../examples/builtin-fetch--tool.c | 0
git.c | 1 -
4 files changed, 0 insertions(+), 3 deletions(-)
rename builtin-fetch--tool.c => contrib/examples/builtin-fetch--tool.c (100%)
diff --git a/Makefile b/Makefile
index 5d5976f..c0ba479 100644
--- a/Makefile
+++ b/Makefile
@@ -601,7 +601,6 @@ BUILTIN_OBJS += builtin-diff-index.o
BUILTIN_OBJS += builtin-diff-tree.o
BUILTIN_OBJS += builtin-diff.o
BUILTIN_OBJS += builtin-fast-export.o
-BUILTIN_OBJS += builtin-fetch--tool.o
BUILTIN_OBJS += builtin-fetch-pack.o
BUILTIN_OBJS += builtin-fetch.o
BUILTIN_OBJS += builtin-fmt-merge-msg.o
diff --git a/builtin.h b/builtin.h
index a2174dc..c3f83c0 100644
--- a/builtin.h
+++ b/builtin.h
@@ -48,7 +48,6 @@ extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);
extern int cmd_fast_export(int argc, const char **argv, const char *prefix);
extern int cmd_fetch(int argc, const char **argv, const char *prefix);
extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);
-extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);
extern int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix);
extern int cmd_for_each_ref(int argc, const char **argv, const char *prefix);
extern int cmd_format_patch(int argc, const char **argv, const char *prefix);
diff --git a/builtin-fetch--tool.c b/contrib/examples/builtin-fetch--tool.c
similarity index 100%
rename from builtin-fetch--tool.c
rename to contrib/examples/builtin-fetch--tool.c
diff --git a/git.c b/git.c
index bd2c5fe..f295561 100644
--- a/git.c
+++ b/git.c
@@ -304,7 +304,6 @@ static void handle_internal_command(int argc, const char **argv)
{ "fast-export", cmd_fast_export, RUN_SETUP },
{ "fetch", cmd_fetch, RUN_SETUP },
{ "fetch-pack", cmd_fetch_pack, RUN_SETUP },
- { "fetch--tool", cmd_fetch__tool, RUN_SETUP },
{ "fmt-merge-msg", cmd_fmt_merge_msg, RUN_SETUP },
{ "for-each-ref", cmd_for_each_ref, RUN_SETUP },
{ "format-patch", cmd_format_patch, RUN_SETUP },
--
1.6.5.2
^ permalink raw reply related
* [PATCH 00/24] Let 'git <command> -h' show usage without a git dir
From: Jonathan Nieder @ 2009-11-09 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091108110341.GA23737@progeny.tock>
Junio C Hamano wrote:
> So I think the right approach is something like how you handled http-push;
> namely, check if the sole argument is "-h", and if so show help and exit.
I took a more aggressive approach with some commands. As long as it
was obviously safe and not too complicated to implement, I let -h work
wherever other options work.
Tested with
git_home=$(pwd)
while read a b
do
cmd=${a#git-}
test "$cmd" = "$a" && continue
echo "$cmd"
( cd /tmp && "$git_home/git" "$cmd" -h 2>&1 | head -1 )
done |
less
and the test suite.
Thoughts?
Jonathan Nieder (24):
Retire fetch--tool helper to contrib/examples
Show usage string for 'git grep -h'
Show usage string for 'git cherry -h'
Show usage string for 'git commit-tree -h'
Show usage string for 'git merge-ours -h'
Show usage string for 'git show-ref -h'
check-ref-format: update usage string
Show usage string for 'git check-ref-format -h'
Show usage string for 'git fast-import -h'
Show usage string for 'git get-tar-commit-id -h'
Show usage string for 'git imap-send -h'
Show usage string for 'git mailsplit -h'
Show usage string for 'git merge-one-file -h'
Show usage string for 'git rev-parse -h'
Show usage string for 'git show-index -h'
Show usage string for 'git unpack-file -h'
Show usage string for 'git stripspace -h'
merge: do not setup worktree twice
Let 'git http-fetch -h' show usage outside any git repository
http-fetch: add missing initialization of argv0_path
Let 'git <command> -h' show usage without a git dir
Let usage() take a printf-style format
merge-{recursive,subtree}: use usage() to print usage
diff --no-index: make the usage string less scary
Documentation/git-show-ref.txt | 3 +-
Makefile | 1 -
builtin-check-ref-format.c | 9 +++++++-
builtin-commit-tree.c | 2 +-
builtin-grep.c | 7 ++++++
builtin-log.c | 9 ++++++++
builtin-mailsplit.c | 2 +
builtin-merge-ours.c | 6 +++++
builtin-merge-recursive.c | 2 +-
builtin-merge.c | 1 -
builtin-mv.c | 8 +++---
builtin-read-tree.c | 4 +-
builtin-reflog.c | 3 ++
builtin-rerere.c | 3 ++
builtin-rev-parse.c | 10 +++++++++
builtin-show-ref.c | 10 +++++++-
builtin-stripspace.c | 4 ++-
builtin-tar-tree.c | 6 +++++
builtin.h | 1 -
.../examples/builtin-fetch--tool.c | 0
diff-no-index.c | 2 +-
fast-import.c | 3 ++
git-compat-util.h | 2 +-
git-merge-one-file.sh | 12 ++++++++++
git.c | 22 ++++++++++---------
http-fetch.c | 21 ++++++++++++------
imap-send.c | 5 ++++
index-pack.c | 3 ++
pack-redundant.c | 3 ++
show-index.c | 5 ++++
unpack-file.c | 2 +-
usage.c | 14 ++++++++----
32 files changed, 143 insertions(+), 42 deletions(-)
rename builtin-fetch--tool.c => contrib/examples/builtin-fetch--tool.c (100%)
^ permalink raw reply
* Re: Git drawbacks?
From: Jacob Helwig @ 2009-11-09 14:34 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T084539-720@post.gmane.org>
On Sun, Nov 8, 2009 at 23:53, Dmitry Smirnov <divis1969@gmail.com> 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?
>
Take a look at git-new-workdir. It's in the contrib directory of
git.git. This lets you skip re-cloning the same repository over
again, if you want a new working copy of it. It'll also give you some
space savings, by sharing certain key things in the .git directory
between working copies, by using symlinks.
It does have a few caveats, however. If you have the same branch
checked out in two different working copies created using
git-new-workdir, and update the branch in one of them, then the other
will appear to have a bunch of staged changes, even though you haven't
done anything in it. The branch pointer will have been updated out
from underneath it, and it will be "confused". As long as you
remember not to update a branch that is checked out in more than one
place on your machine, you'll never notice, thuogh.
^ permalink raw reply
* Re: [PATCH v2] Show usage string for 'git http-push -h'
From: Tay Ray Chuan @ 2009-11-09 13:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20091109104732.GA15519@progeny.tock>
Hi,
On Mon, Nov 9, 2009 at 6:47 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (I was making sure "git http-push -h" would work without a git
> directory by putting the check for -h before setup_git_directory().
> But nothing in the argv loop requires a git repository, so it is
> better and simpler to move the setup_git_directory() call to after the
> loop. Thanks for the catch.)
Actually, I didn't notice the removal of the "is in a git directory
for -h" requirement; I was only looking at the argument mix.
Thanks.
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: pulling git -- version confusion
From: Rustom Mody @ 2009-11-09 13:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911082351o326b205aic205552faae4e4da@mail.gmail.com>
On Mon, Nov 9, 2009 at 1:21 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 08:45, Rustom Mody <rustompmody@gmail.com> wrote:
>> Gives me
>> fatal: ambiguous argument 'origin/master': unknown revision or path
>> not in the working tree.
>> Use '--' to separate paths from revisions
>
> Well, as what remote do you have upstream configured?
>
> What is the output of
> $ git config -l
gives me
core.safecrlf=true
user.email=<my email>
user.name=<my name>
core.repositoryformatversion=0
core.filemode=true
gui.geometry=885x450+0+27 207 192
So theres no remote?
But .git/remotes/origin has
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/maint:refs/heads/maint
Pull: refs/heads/next:refs/heads/next
Pull: refs/heads/html:refs/heads/html
Pull: refs/heads/pu:refs/heads/pu
Pull: refs/heads/todo:refs/heads/todo
Pull: refs/heads/man:refs/heads/man
Also [I just tried this] if I make a fresh repo directly and then do a git pull
it gives a fatal: where do you want to fetch from
But with the git repo pull (seems to be) pulling all sorts of stuff
and not erroring out.
^ permalink raw reply
* [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Jan Krüger @ 2009-11-09 12:09 UTC (permalink / raw)
To: Git ML
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.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Since I consider this extension pure syntactic sugar, it doesn't change
the underlying transport code. As such it's a relatively non-invasive
change.
One might imagine a different implementation that supports combining
--delete with --all and/or --tags, but perhaps it's better if people
are forced to do that kind of thing manually.
builtin-push.c | 15 +++++++++++++++
t/t5516-fetch-push.sh | 6 ++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 8631c06..4ae9166 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,14 @@ 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;
+ }
add_refspec(ref);
}
}
@@ -181,6 +190,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 +203,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
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Matthieu Moy @ 2009-11-09 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <vpqeio8eou4.fsf@bauges.imag.fr>
Hi again,
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.
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Hi,
>
> I'm hitting a bug when git-push-ing to a Linux PPC machine. In
> general, pushing works well, but pushing some particular commits
> breaks reproducibly with :
>
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To ssh://localhost//home/perms/moy/prive/dest
> ! [remote rejected] master -> master (n/a (unpacker error))
>
> I've put the guilty files on my website and wrote a reproduction
> script:
>
> #!/bin/sh
>
> rm -fr source dest
> git init source
> git init --bare dest
> dest=$PWD/dest
> cd source
> echo foo > bar.txt
> git add .
> git commit -m init
> git push ssh://localhost/$dest master
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Conception Manual.docx'
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Extreme Programming.doc'
> git add .
> git commit -m "bug"
> git push ssh://localhost/$dest master
>
> The full output is attached (the error message for the last push is
> given above). The machine on which I get this (let's call it "A")
> says :
>
> $ ssh -Version
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
> $ uname -a
> Linux A 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> (it's a 32-bit distribution although the machine is 64bits)
> $ git --version
> git version 1.6.5.2
> (compiled myself, "make test" passes)
>
> According to my experiments, the problem is on the receiver side. If I
> do the same as above, with source/ and dest/ directories on two
> different machines, then if source/ in on A and dest/ anywhere else,
> it works, and if dest/ is on machine A, I get the same error.
>
> If I push using "file://" instead of "ssh://", then everything works
> well.
>
> If instead of push-ing, I go to dest/ and do a fetch, then it works
> well too.
>
> Does anyone have any idea on what's going on?
>
> If anyone has a machine similar to mine (ppc64), can he/she run my
> reproduction script and tell me if the bug happens?
>
> Thanks a lot,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: question: connecting to multiple remote svn projects
From: Dave Rodgman @ 2009-11-09 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911061151q68ddcc58w209acf28c5eec2f@mail.gmail.com>
>> Given a layout in a single subversion repository like this:
>>
>> module1/branches/1.0/work
>> module2/branches/1.0/work
>>
>> I would like achieve the following layout locally, in git:
>>
>> module1/work
>> module2/work
>>
>> Obviously I can create multiple git repositories in separate
>> directories, but I would like them to be in a single repository. I can
>> also get the same layout as subversion, but this breaks various bits of
>> build infrastructure.
>
> Can you just create the file structure you want using symlinks? That
> would be the easiest way.
It would, and this is what I do on Linux. On Windows, obviously, this
doesn't work.
>> I don't care about tracking the subversion branches in git, or being
>> able to switch between subversion branches.
>
> Don't care about tracking *any* subversion history, or just the history
> of branches other than the 1.0 branch you've listed above? I assume the
> latter, because otherwise the problem is easy (just copy the latest
> revision of the files into a git repo and commit).
Indeed. I want history, but only for a given branch.
> Other options that might work for you: create a "superproject" branch
> and import the two modules using git-submodule, or else import them
> using git-subtree (http://github.com/apenwarr/git-subtree). Or import
> the svn history and then use git-filter-branch to move stuff around.
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.
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?
thanks for your help
Dave
^ permalink raw reply
* [PATCH v2] Show usage string for 'git http-push -h'
From: Jonathan Nieder @ 2009-11-09 10:47 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <be6fef0d0911090052s158ac720ha1fac70da748106d@mail.gmail.com>
http-push already knows how to dump usage if it is given no
options, but it interprets '-h' as the URL to a remote
repository:
$ git http-push -h
error: Cannot access URL -h/, return code 6
Dump usage instead. Humans wanting to pass the URL -h/ to curl
for some reason can use 'git http-push -h/' explicitly. Scripts
expecting to access an HTTP repository at URL '-h' will break,
though.
Also delay finding a git directory until after option parsing, so
"http-push -h" can be used outside any git repository.
Cc: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Tay Ray Chuan wrote:
> just curious, I'm wondering why isn't the check for "-h" done in the
> argv loop later on? I see this being done already in the builtins
> diff, log, ls-remote and update-index.
Good question. :)
(I was making sure "git http-push -h" would work without a git
directory by putting the check for -h before setup_git_directory().
But nothing in the argv loop requires a git repository, so it is
better and simpler to move the setup_git_directory() call to after the
loop. Thanks for the catch.)
> Also, unlike grep, -h <arg> is not an option we're looking out for, so
> I'm not sure if we should allow the user to mix -h with a valid set of
> arguments (which is what Johnathan's patch would allow).
Makes sense.
http-push.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index 00e83dc..ad1a6c9 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1792,8 +1792,6 @@ int main(int argc, char **argv)
git_extract_argv0_path(argv[0]);
- setup_git_directory();
-
repo = xcalloc(sizeof(*repo), 1);
argv++;
@@ -1827,6 +1825,8 @@ int main(int argc, char **argv)
force_delete = 1;
continue;
}
+ if (!strcmp(arg, "-h"))
+ usage(http_push_usage);
}
if (!repo->url) {
char *path = strstr(arg, "//");
@@ -1854,6 +1854,8 @@ int main(int argc, char **argv)
if (delete_branch && nr_refspec != 1)
die("You must specify only one branch name when deleting a remote branch");
+ setup_git_directory();
+
memset(remote_dir_exists, -1, 256);
/*
--
1.6.5.2
^ permalink raw reply related
* Re: [OT] Re: gitk : french translation
From: Maximilien Noal @ 2009-11-09 9:24 UTC (permalink / raw)
To: Matthieu Moy
Cc: Nicolas Pitre, Nicolas Sebrecht, Emmanuel Trillaud,
Thomas Moulard, Git Mailing List
In-Reply-To: <vpqocncay8m.fsf_-_@bauges.imag.fr>
Matthieu Moy a écrit :
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>> It's like those stu**d people who decided that "email" was too hard to
>> translate. So they declared that "email" was "imél" in French.
>
> This one is not _as_ stupid as it seems to be. It's not "imél", it's
> "mél.", and it's a shortcut for "messagerie électronique", like "tél."
> is a shortcut for "téléphone" (the kind of things to put on your visit
> card or on the header of a letter).
>
> http://www.culture.gouv.fr/culture/dglf/mel.htm
>
mél is ugly as hell to the ear.
Courriel sounds way better!
^ permalink raw reply
* Re: [PATCH] Show usage string for 'git http-push -h'
From: Tay Ray Chuan @ 2009-11-09 8:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20091108072604.GA21367@progeny.tock>
Hi,
On Sun, Nov 8, 2009 at 3:26 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> @@ -1792,6 +1792,11 @@ int main(int argc, char **argv)
>
> git_extract_argv0_path(argv[0]);
>
> + if (argc == 2 && !strcmp(argv[1], "-h")) {
> + fprintf(stderr, "usage: %s\n", http_push_usage);
> + return 0;
> + }
> +
> setup_git_directory();
>
> repo = xcalloc(sizeof(*repo), 1);
just curious, I'm wondering why isn't the check for "-h" done in the
argv loop later on? I see this being done already in the builtins
diff, log, ls-remote and update-index.
Also, unlike grep, -h <arg> is not an option we're looking out for, so
I'm not sure if we should allow the user to mix -h with a valid set of
arguments (which is what Johnathan's patch would allow).
--
Cheers,
Ray Chuan
^ permalink raw reply
* [OT] Re: gitk : french translation
From: Matthieu Moy @ 2009-11-09 8:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Nicolas Sebrecht, Emmanuel Trillaud, Thomas Moulard,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0911082010590.16711@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> It's like those stu**d people who decided that "email" was too hard to
> translate. So they declared that "email" was "imél" in French.
This one is not _as_ stupid as it seems to be. It's not "imél", it's
"mél.", and it's a shortcut for "messagerie électronique", like "tél."
is a shortcut for "téléphone" (the kind of things to put on your visit
card or on the header of a letter).
http://www.culture.gouv.fr/culture/dglf/mel.htm
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #02; Sun, 08)
From: Tarmigan @ 2009-11-09 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <7vzl6wz36r.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]
On Sun, Nov 8, 2009 at 9:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * sp/smart-http (2009-11-04) 30 commits
> + test smart http fetch and push
I am trying to test smart http, and have had to set
DEFAULT_HTTPD_PATH='/usr/sbin/httpd'
DEFAULT_HTTPD_MODULE_PATH='/usr/lib64/httpd/modules' on Centos.
Perhaps this failing test is just a difference in the default Apache
and curl configurations.
Testing with 7f640b7 ("http-backend: Test configuration options")
gives me errors with the third test in t5551-http-fetch. I don't
really know the point of the sed lines, but I am attaching my "err"
file in case some of the problem is with the CR/LF stuff.
Thanks,
Tarmigan
* expecting success:
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
test_cmp file clone/file &&
tr '\015' Q <err |
sed -e "
s/Q\$//
/^[*] /d
/^[^><]/{
s/^/> /
}
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
/^< Server: /d
/^< Expires: /d
/^< Date: /d
/^< Content-Length: /d
/^< Transfer-Encoding: /d
" >act &&
test_cmp exp act
--- exp 2009-11-09 07:33:19.000000000 +0000
+++ act 2009-11-09 07:33:19.000000000 +0000
@@ -6,15 +6,16 @@
< 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: */*
> Accept-Encoding: deflate, gzip
> Content-Type: application/x-git-upload-pack-request
> Accept: application/x-git-upload-pack-response
> Content-Length: xxx
+> 0073want 1937bb05802e1973cc2e437c13e9f1845941b785
multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
+> 00000009done
< 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
-<
* FAIL 3: clone http repository
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
test_cmp file clone/file &&
tr '\015' Q <err |
sed -e "
s/Q\$//
/^[*] /d
/^[^><]/{
s/^/> /
}
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
/^< Server: /d
/^< Expires: /d
/^< Date: /d
/^< Content-Length: /d
/^< Transfer-Encoding: /d
" >act &&
test_cmp exp act
[-- Attachment #2: err --]
[-- Type: application/octet-stream, Size: 1601 bytes --]
* Couldn't find host 127.0.0.1 in the .netrc file, using defaults
* About to connect() to 127.0.0.1 port 5551
* Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 5551
> GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.6.5.45.g7f640
Host: 127.0.0.1:5551
Accept: */*
Pragma: no-cache
< HTTP/1.1 200 OK
< Date: Mon, 09 Nov 2009 07:29:09 GMT
< Server: Apache/2.2.3 (CentOS)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Transfer-Encoding: chunked
< Content-Type: application/x-git-upload-pack-advertisement
* Connection #0 to host 127.0.0.1 left intact
* Couldn't find host 127.0.0.1 in the .netrc file, using defaults
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 5551
> POST /smart/repo.git/git-upload-pack HTTP/1.1
User-Agent: git/1.6.5.45.g7f640
Host: 127.0.0.1:5551
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-response
Content-Length: 128
0073want 016a872ce97795d991a9c5014a0bbc8aa4ecca39 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
00000009done
< HTTP/1.1 200 OK
< Date: Mon, 09 Nov 2009 07:29:09 GMT
< Server: Apache/2.2.3 (CentOS)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Transfer-Encoding: chunked
< Content-Type: application/x-git-upload-pack-result
* Connection #0 to host 127.0.0.1 left intact
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Mike Hommey @ 2009-11-09 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx8obz2o.fsf@alter.siamese.dyndns.org>
On Sun, Nov 08, 2009 at 11:23:27AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > Usually, when I run git push --dry-run, it's to check that what follows
> > (usually the refspec part) does what I want it to do, such as not pushing
> > tags I didn't intend to push(*), and stuff like that.
>
> Ahh, that one.
>
> That reminds me of a topic that we discussed but went away without
> reaching the conclusion on adding a "confirmation: are you sure this
> pushes what you want?" to the command. I had a doubt about the patch back
> then which was that it hardcoded a tty interaction and it would be hard to
> retrofit it to help GUI frontends (so my suggestion was to use something
> like hooks mechanism, perhaps --confirm=this-script and allow it to do its
> GUI thing), but thinking about it again, they can always use "expect" to
> drive the interaction with the confirmation prompt, so it may not a big
> deal after all---we might want to resurrect the topic.
How about an option to have the confirmation asked, quite like
cp/mv/rm's -i option ?
> That was an unrelated, independent thought on your comment, but if we did
> so, you might not even have to try to use --dry-run on git:// transport.
Sounds like a good trade-off.
Cheers
Mike
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 7:53 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm>
<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?
^ permalink raw reply
* Re: pulling git -- version confusion
From: Rustom Mody @ 2009-11-09 7:45 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911082237x462b1203v724b51e309a2d89@mail.gmail.com>
On Mon, Nov 9, 2009 at 12:07 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Mon, Nov 9, 2009 at 07:14, Rustom Mody <rustompmody@gmail.com> wrote:
>> When I checkout branch next
>> git version becomes 1.6.0.rc1.194.g9e4e
>
> Try either:
> $ git checkout master
> $ git reset --hard origin/master
Gives me
fatal: ambiguous argument 'origin/master': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
>
> or:
> $ git checkout next
> $ git reset --hard origin/next
Likewise here
>
> Followed by:
> $ make
> $ ./git --version
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: pulling git -- version confusion
From: Sverre Rabbelier @ 2009-11-09 7:51 UTC (permalink / raw)
To: Rustom Mody; +Cc: git
In-Reply-To: <f46c52560911082345y71eb12c9w114b799d70720dc6@mail.gmail.com>
Heya,
On Mon, Nov 9, 2009 at 08:45, Rustom Mody <rustompmody@gmail.com> wrote:
> Gives me
> fatal: ambiguous argument 'origin/master': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions
Well, as what remote do you have upstream configured?
What is the output of
$ git config -l
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
> There are three methods I know of to manage this:
>
> 1) Just commit whatever version of a subproject you want as a subtree
> of your current project, and if you want to replace/delete/upgrade it,
> just do that. (You rarely want to track the actual *history* of the
> third party tool, just the history of versions *you* used, which is
> easy to do.)
Ok. Does that mean that new component2 and common component1 should leave on the
new branch (having in mind that old component2 and component1 are still living
on previous branch)? So, how many efforts will I need to get both component1
versions in sync (it is supposed that most of the changes in this component are
common for both)? Is is supposed that having 2 branches for this component is
cheaper (from development cycle POW)?
> 2) Use git-submodule to link repositories together. (Arguably, one
> major reason 'repo' was written is that git-submodule is too
> complicated, though.)
> 3) Try my git-subtree tool, which basically makes it easier to
> split/join repositories (similar to #1) without losing the history
> (similar to #2).
I'll try to learn it.
I suppose, both these tools (repo and git-subtree) are the indication of some
contradiction between the tool and SCM practice (especially, for big projects).
>
> Basically, performance is linear with the number of files in your
> repo. If you can check out just a "slice" of your repo (say 10% of
> the whole), you'll have faster performance (eg. 10x) from any VCS.
Yes, I just wish to see this feature in some VCS. Why not Git? ;-)
> So I can see an argument that Windows users would want arbitrary
> "slices" much more often than Linux+git users, but I think this is
> largely due to performance, not because people really *want* to be
> stuck with a restricted view of the repo.
How offten do you use this info? I mean the whole stuff?
^ permalink raw reply
* Re: [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
From: Johannes Sixt @ 2009-11-09 7:20 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Marius Storm-Olsen, GIT Mailing-list
In-Reply-To: <4AF5D6F8.40608@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> 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.
Thanks, this makes the problem pretty clear that you want to solve.
> 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!).
In this paragraph, you are only saying that cygwin comes with headers and
libraries that can be used to write code using the Windows API in addition
to the POSIX headers and libraries. (I'm just asking, not complaining;
perhaps this could be stated differently.)
> 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
But I sense a contradiction here. Above you are arguing that much more
WIN32 code is included, but here you are saying that the explicit check
for __CYGWIN__ is just a safety measure to protect us from failures in
future changes. Indeed, looking at the code it seems that this extra check
is *currently* not necessary:
- Cygwin does not define WIN32, hence, in the original code of this hunk,
> 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>
> #endif
>
> #include <unistd.h>
windows.h is not included in cygwin. (Nor is it in the changed version.)
- The other files that include windows.h are compat/win32.h and nedmalloc.
The latter isn't used on cygwin.
- win32.h is included only from cygwin.c, mingw.c, and msvc.c. Only the
first one is used by cygwin, and since it is a .c file, pulling in
windows.h can only concern code in cygwin.c, but not code.
IOW, I disagree with your analysis that a lot of code suffers from
windows.h pollution. What am I missing?
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Sverre Rabbelier @ 2009-11-09 6:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911061519j6d64ff50v9b0cefe61965fbbc@mail.gmail.com>
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.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Björn Gustavsson @ 2009-11-09 6:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490911081643w46e34858kd82270be0482f8b9@mail.gmail.com>
2009/11/9 Jay Soffian <jaysoffian@gmail.com>:
> 2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
>> In order to not duplicate functionality, re-implement 'git remote
>> update' in terms of 'git fetch'.
>
> Junio, I guess I'll wait for this to hit pu and then rebase my fetch
> --prune changes on top of it?
It has hit pu now.
If you'll rebase and finish your patch series, I can base my final
patch in my series on your changes, because that patch will need a
fetch that supports --prune in order to support 'git remote update --prune'.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: pulling git -- version confusion
From: Sverre Rabbelier @ 2009-11-09 6:37 UTC (permalink / raw)
To: Rustom Mody; +Cc: git
In-Reply-To: <f46c52560911082214x81ae8beya139a8bcb3cbcf2a@mail.gmail.com>
Heya,
On Mon, Nov 9, 2009 at 07:14, Rustom Mody <rustompmody@gmail.com> wrote:
> When I checkout branch next
> git version becomes 1.6.0.rc1.194.g9e4e
Try either:
$ git checkout master
$ git reset --hard origin/master
or:
$ git checkout next
$ git reset --hard origin/next
Followed by:
$ make
$ ./git --version
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Björn Gustavsson @ 2009-11-09 6:25 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, Junio C Hamano
In-Reply-To: <20091109010824.GA17414@coredump.intra.peff.net>
2009/11/9 Jeff King <peff@peff.net>:
> Isn't the colon optional, indicating that the ref should be fetched into
> FETCH_HEAD?
Yes, that's why I was forced to invent a new option.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH 4/4] format-patch: Add "--no-stat" as a synonym for "-p"
From: Björn Gustavsson @ 2009-11-09 6:22 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1257721866.1734.47.camel@swboyd-laptop>
2009/11/9 Stephen Boyd <bebarino@gmail.com>:
>> - OPT_BOOLEAN('p', NULL, &use_patch_format,
>> + OPT_BOOLEAN('p', "no-stat", &use_patch_format,
>
> I think this needs to have the OPT_NO_NEG flag so users can't say
> --no-no-stat.
Thanks! I didn't know about that.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ 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