* [PATCH] Rewrite builtin-fetch option parsing to use parse_options().
From: Kristian Høgsberg @ 2007-12-04 7:25 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
In-Reply-To: <1196753147-20073-1-git-send-email-krh@redhat.com>
This gets a little tricky because of the way --tags and --no-tags
are handled, and the "tag <name>" syntax needs a little hand-holding too.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-fetch.c | 123 ++++++++++++++++++++----------------------------------
1 files changed, 46 insertions(+), 77 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index f6d16fe..320e235 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -9,14 +9,45 @@
#include "remote.h"
#include "transport.h"
#include "run-command.h"
+#include "parse-options.h"
-static const char fetch_usage[] = "git-fetch [-a | --append] [--upload-pack <upload-pack>] [-f | --force] [--no-tags] [-t | --tags] [-k | --keep] [-u | --update-head-ok] [--depth <depth>] [-v | --verbose] [<repository> <refspec>...]";
+static const char * const builtin_fetch_usage[] = {
+ "git-fetch [options] [<repository> <refspec>...]",
+ NULL
+};
-static int append, force, tags, no_tags, update_head_ok, verbose, quiet;
+enum {
+ TAGS_UNSET = 0,
+ TAGS_DEFAULT = 1,
+ TAGS_SET = 2
+};
+
+static int append, force, keep, update_head_ok, verbose, quiet;
+static int tags = TAGS_DEFAULT;
static const char *depth;
+static const char *upload_pack;
static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
+static struct option builtin_fetch_options[] = {
+ OPT__QUIET(&quiet),
+ OPT__VERBOSE(&verbose),
+ OPT_BOOLEAN('a', "append", &append,
+ "append to .git/FETCH_HEAD instead of overwriting"),
+ OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
+ "path to upload pack on remote end"),
+ OPT_BOOLEAN('f', "force", &force,
+ "force overwrite of local branch"),
+ OPT_SET_INT('t', "tags", &tags,
+ "fetch all tags and associated objects", TAGS_SET),
+ OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"),
+ OPT_BOOLEAN('u', "update-head-ok", &update_head_ok,
+ "allow updating of HEAD ref"),
+ OPT_STRING(0, "depth", &depth, "DEPTH",
+ "deepen history of shallow clone"),
+ OPT_END()
+};
+
static void unlock_pack(void)
{
if (transport)
@@ -81,7 +112,7 @@ static struct ref *get_ref_map(struct transport *transport,
const struct ref *remote_refs = transport_get_remote_refs(transport);
- if (ref_count || tags) {
+ if (ref_count || tags == TAGS_SET) {
for (i = 0; i < ref_count; i++) {
get_fetch_map(remote_refs, &refs[i], &tail, 0);
if (refs[i].dst && refs[i].dst[0])
@@ -90,7 +121,7 @@ static struct ref *get_ref_map(struct transport *transport,
/* Merge everything on the command line, but not --tags */
for (rm = ref_map; rm; rm = rm->next)
rm->merge = 1;
- if (tags) {
+ if (tags == TAGS_SET) {
struct refspec refspec;
refspec.src = "refs/tags/";
refspec.dst = "refs/tags/";
@@ -482,10 +513,10 @@ static int do_fetch(struct transport *transport,
struct ref *ref_map, *fetch_map;
struct ref *rm;
int autotags = (transport->remote->fetch_tags == 1);
- if (transport->remote->fetch_tags == 2 && !no_tags)
- tags = 1;
+ if (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)
+ tags = TAGS_SET;
if (transport->remote->fetch_tags == -1)
- no_tags = 1;
+ tags = TAGS_UNSET;
if (!transport->get_refs_list || !transport->fetch)
die("Don't know how to fetch from %s", transport->url);
@@ -515,7 +546,7 @@ static int do_fetch(struct transport *transport,
/* if neither --no-tags nor --tags was specified, do automated tag
* following ... */
- if (!(tags || no_tags) && autotags) {
+ if (tags == TAGS_DEFAULT && autotags) {
ref_map = find_non_local_tags(transport, fetch_map);
if (ref_map) {
transport_set_option(transport, TRANS_OPT_DEPTH, "0");
@@ -546,80 +577,19 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
int i;
static const char **refs = NULL;
int ref_nr = 0;
- const char *upload_pack = NULL;
- int keep = 0;
/* Record the command line for the reflog */
strbuf_addstr(&default_rla, "fetch");
for (i = 1; i < argc; i++)
strbuf_addf(&default_rla, " %s", argv[i]);
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (arg[0] != '-')
- break;
- if (!strcmp(arg, "--append") || !strcmp(arg, "-a")) {
- append = 1;
- continue;
- }
- if (!prefixcmp(arg, "--upload-pack=")) {
- upload_pack = arg + 14;
- continue;
- }
- if (!strcmp(arg, "--upload-pack")) {
- i++;
- if (i == argc)
- usage(fetch_usage);
- upload_pack = argv[i];
- continue;
- }
- if (!strcmp(arg, "--force") || !strcmp(arg, "-f")) {
- force = 1;
- continue;
- }
- if (!strcmp(arg, "--no-tags")) {
- no_tags = 1;
- continue;
- }
- if (!strcmp(arg, "--tags") || !strcmp(arg, "-t")) {
- tags = 1;
- continue;
- }
- if (!strcmp(arg, "--keep") || !strcmp(arg, "-k")) {
- keep = 1;
- continue;
- }
- if (!strcmp(arg, "--update-head-ok") || !strcmp(arg, "-u")) {
- update_head_ok = 1;
- continue;
- }
- if (!prefixcmp(arg, "--depth=")) {
- depth = arg + 8;
- continue;
- }
- if (!strcmp(arg, "--depth")) {
- i++;
- if (i == argc)
- usage(fetch_usage);
- depth = argv[i];
- continue;
- }
- if (!strcmp(arg, "--quiet") || !strcmp(arg, "-q")) {
- quiet = 1;
- continue;
- }
- if (!strcmp(arg, "--verbose") || !strcmp(arg, "-v")) {
- verbose++;
- continue;
- }
- usage(fetch_usage);
- }
+ argc = parse_options(argc, argv,
+ builtin_fetch_options, builtin_fetch_usage, 0);
- if (i == argc)
+ if (argc == 0)
remote = remote_get(NULL);
else
- remote = remote_get(argv[i++]);
+ remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
if (verbose >= 2)
@@ -636,10 +606,10 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
if (!transport->url)
die("Where do you want to fetch from today?");
- if (i < argc) {
+ if (argc > 1) {
int j = 0;
- refs = xcalloc(argc - i + 1, sizeof(const char *));
- while (i < argc) {
+ refs = xcalloc(argc + 1, sizeof(const char *));
+ for (i = 1; i < argc; i++) {
if (!strcmp(argv[i], "tag")) {
char *ref;
i++;
@@ -651,7 +621,6 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
refs[j++] = ref;
} else
refs[j++] = argv[i];
- i++;
}
refs[j] = NULL;
ref_nr = j;
--
1.5.3.4
^ permalink raw reply related
* [PATCH] Use a strbuf for copying the command line for the reflog.
From: Kristian Høgsberg @ 2007-12-04 7:25 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-fetch.c | 24 ++++++++----------------
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index de9947e..f6d16fe 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -14,7 +14,7 @@ static const char fetch_usage[] = "git-fetch [-a | --append] [--upload-pack <upl
static int append, force, tags, no_tags, update_head_ok, verbose, quiet;
static const char *depth;
-static char *default_rla = NULL;
+static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
static void unlock_pack(void)
@@ -142,7 +142,7 @@ static int s_update_ref(const char *action,
static struct ref_lock *lock;
if (!rla)
- rla = default_rla;
+ rla = default_rla.buf;
snprintf(msg, sizeof(msg), "%s: %s", rla, action);
lock = lock_any_ref_for_update(ref->name,
check_old ? ref->old_sha1 : NULL, 0);
@@ -543,16 +543,19 @@ static void set_option(const char *name, const char *value)
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
- int i, j, rla_offset;
+ int i;
static const char **refs = NULL;
int ref_nr = 0;
- int cmd_len = 0;
const char *upload_pack = NULL;
int keep = 0;
+ /* Record the command line for the reflog */
+ strbuf_addstr(&default_rla, "fetch");
+ for (i = 1; i < argc; i++)
+ strbuf_addf(&default_rla, " %s", argv[i]);
+
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- cmd_len += strlen(arg);
if (arg[0] != '-')
break;
@@ -613,17 +616,6 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
usage(fetch_usage);
}
- for (j = i; j < argc; j++)
- cmd_len += strlen(argv[j]);
-
- default_rla = xmalloc(cmd_len + 5 + argc + 1);
- sprintf(default_rla, "fetch");
- rla_offset = strlen(default_rla);
- for (j = 1; j < argc; j++) {
- sprintf(default_rla + rla_offset, " %s", argv[j]);
- rla_offset += strlen(argv[j]) + 1;
- }
-
if (i == argc)
remote = remote_get(NULL);
else
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-12-04 6:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Anatol Pomozov, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0712040216220.27959@racer.site>
tisdag 04 december 2007 skrev Johannes Schindelin:
> Hi,
>
> On Mon, 3 Dec 2007, Jeff King wrote:
>
> > On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
> >
> > > code did not pass). Like Linus, this code does not resolve symlinks,
> > > but I forgot to state that it is by design. It solves my problem and
> >
> > By design meaning "I didn't feel like implemening it because I do not
> > personally care" or "I have some reason not to resolve symlinks"?
>
> IMHO those symlinks would be a nice thing in some corner cases, but
> penalise the common case. So I tend to believe the latter. (See also
> Linus' message why he talks about his preference for the die() code path.)
Actually the forme.... I don't mind it being fixed if it doesn't cost too much.
-- robin
^ permalink raw reply
* Re: git-add--interactive works only in top level
From: Junio C Hamano @ 2007-12-04 6:22 UTC (permalink / raw)
To: Reid Barton; +Cc: git
In-Reply-To: <4BC1648E-3059-4373-B388-65AD739796D8@MIT.EDU>
Reid Barton <rwbarton@MIT.EDU> writes:
> I understand that programs such as git-add--interactive will be moved
> out of the executable path not too long from now, which will also
> ameliorate the situation.
Honestly, there is nothing to ameliorate. We do not even document
git-add--interactive on purpose.
Once I saw somebody who somehow got a root account on a shared UNIX box
and tryed running everything he found under /sbin one after another
without understanding what he was doing. Needless to say, the box did
not last too long. Somehow that "tab completion" comment reminds of
him.
^ permalink raw reply
* Re: git-add--interactive works only in top level
From: Reid Barton @ 2007-12-04 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsrv9fos.fsf@gitster.siamese.dyndns.org>
On Dec 4, 2007, at 12:44 AM, Junio C Hamano wrote:
> Sheesh, you got me worried.
>
> This is a non issue; git-add--interactive is not for direct end user
> consumption. It relies on being run from git-add wrapper, which does
> cdup to the top of the work tree before launching add--interactive
> helper.
Ah, OK. Would it not be easy then to add a check to the beginning of
git-add--interactive to verify that it is indeed being run from the
top of the work tree? A user may well discover git-add--interactive
before git-add --interactive (e.g. by shell completion) and if git-
add--interactive is going to fail, it should do so right away so as
to not confuse the user.
I understand that programs such as git-add--interactive will be moved
out of the executable path not too long from now, which will also
ameliorate the situation.
Regards,
Reid Barton
^ permalink raw reply
* Re: [PATCH 1/3] git-help: add -i|--info option to display info page.
From: Christian Couder @ 2007-12-04 5:54 UTC (permalink / raw)
To: Pascal Obry
Cc: Junio C Hamano, git, Theodore Tso, Jakub Narebski, Alex Riesen,
Andreas Ericsson, Matthieu Moy, Eric Wong
In-Reply-To: <47544EE5.1050707@obry.net>
Le lundi 3 décembre 2007, Pascal Obry a écrit :
> Ok about woman. Woman is an Emacs mode to display man pages. To send man
> page to display in Emacs from the command line one can use emacsclient
> for example. I'm already doing this for standard man pages with a bash
> function. This function does something like this:
>
> $ emacsclient -e '(woman "git")'
>
> -e is for eval and the argument is the Emacs Lisp string to evaluate.
>
> Let me know if you need more information about woman.
Thanks Pascal, I will indeed tell you if I have questions about woman.
(Given the name, I wouldn't be surprised if it's hard to deal with.)
Christian.
^ permalink raw reply
* Re: git-add--interactive works only in top level
From: Junio C Hamano @ 2007-12-04 5:44 UTC (permalink / raw)
To: Reid Barton; +Cc: git
In-Reply-To: <058EB5A2-1EFE-43B9-9886-7272A955CE51@mit.edu>
Reid Barton <rwbarton@MIT.EDU> writes:
> When the working directory is not the top of the working tree, git-
> add--interactive fails silently and confusingly.
Sheesh, you got me worried.
This is a non issue; git-add--interactive is not for direct end user
consumption. It relies on being run from git-add wrapper, which does
cdup to the top of the work tree before launching add--interactive
helper.
^ permalink raw reply
* [PATCH] Documentation: add a new man page for "git-help" and -i|--info option.
From: Christian Couder @ 2007-12-04 5:44 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Option -i|--info for "git-help" is documented only in the new
"git-help.txt" man page, but this new man page is referenced
from the "--help" option documentation in the "git.txt" man page.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-help.txt | 53 ++++++++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 11 ++++++--
2 files changed, 61 insertions(+), 3 deletions(-)
create mode 100644 Documentation/git-help.txt
This is a first documentation patch in my git-help
improvement series.
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
new file mode 100644
index 0000000..232daae
--- /dev/null
+++ b/Documentation/git-help.txt
@@ -0,0 +1,53 @@
+git-help(1)
+======
+
+NAME
+----
+git-help - display help information about git
+
+SYNOPSIS
+--------
+'git help' [-a|--all|-i|--info] [COMMAND]
+
+DESCRIPTION
+-----------
+
+With no options and no COMMAND given, the synopsis of the 'git'
+command and a list of the most commonly used git commands are printed
+on the standard output.
+
+If the option '--all' or '-a' is given, then all available commands are
+printed on the standard output.
+
+If a git command is named, a manual page for that command is brought
+up. The 'man' program is used by default for this purpose, but this
+can be overriden by other options.
+
+Note that 'git --help ...' is identical as 'git help ...' because the
+former is internally converted into the latter.
+
+OPTIONS
+-------
+-a|--all::
+
+ Prints all the available commands on the standard output. This
+ option superseeds any other option.
+
+-i|--info::
+ Use the 'info' program to display the manual page, instead of
+ the 'man' program that is used by default.
+
+Author
+------
+Written by Junio C Hamano <gitster@pobox.com> and the git-list
+<git@vger.kernel.org>.
+
+Documentation
+-------------
+Initial documentation was part of the gitlink:git[7] man page.
+Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
+little. Maintenance is done by the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5460201..f8d1eef 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -100,9 +100,14 @@ OPTIONS
--help::
Prints the synopsis and a list of the most commonly used
- commands. If a git command is named this option will bring up
- the man-page for that command. If the option '--all' or '-a' is
- given then all available commands are printed.
+ commands. If the option '--all' or '-a' is given then all
+ available commands are printed. If a git command is named this
+ option will bring up the manual page for that command.
+
+ Other options are available to control how the manual page is
+ displayed. See gitlink:git-help[1] for more information,
+ because 'git --help ...' is converted internally into 'git
+ help ...'.
--exec-path::
Path to wherever your core git programs are installed.
--
1.5.3.6.1993.g154f-dirty
^ permalink raw reply related
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-04 5:37 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071204014145.GA20145@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> +cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
> +case "$cvsps_version" in
> +2.1)
> + ;;
> +'')
> + say 'skipping cvsimport tests, cvsps not found'
> + test_done
> + exit
> + ;;
> +*)
> + say 'skipping cvsimport tests, cvsps too old'
> + test_done
> + exit
> + ;;
> +esac
> +
I wonder if it is better to grep for ' [-A] ' instead, like:
cvsps_supports_A=$(cvsps -h 2>&1 | sed -ne '/\[-A\]/p')
case "$cvsps_supports_A" in
'')
say 'skipping cvsimport tests, lacking cvsps that supports -A option'
test_done
exit
esac
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Ismail Dönmez @ 2007-12-04 4:12 UTC (permalink / raw)
To: Jakub Narebski
Cc: Benjamin Close, Martin Koegler, Junio C Hamano,
Alexandre Julliard, git
In-Reply-To: <200712040037.37204.jnareb@gmail.com>
Tuesday 04 December 2007 Tarihinde 01:37:35 yazmıştı:
> On Tue, 4 Dec 2007, Benjamin Close wrote:
> > On Tue, Dec 04, 2007 at 12:20:26AM +0200, Ismail Donmez wrote:
> > > Can you try the attached patch?
> >
> > I confirm that the patch corrects the problem.
> >
> > Without it I get the Cannot decode string error. With it gitweb
> > displays correctly.
>
> But the patch _avoids_ issue (des not convert owner to utf8), rather
> than solving it, if I understand it correctly. What if gecos is in
> utf-8?
Indeed its a workaround but UTF-8 username is correctly displayed in gitweb so
my understanding was gecos field is already UTF-8.
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* git-add--interactive works only in top level
From: Reid Barton @ 2007-12-04 3:19 UTC (permalink / raw)
To: git
When the working directory is not the top of the working tree, git-
add--interactive fails silently and confusingly. In this example,
the working tree is rooted at ~/sandbox/foo and ~/sandbox/foo/bar/x
is a file that's been edited.
rwbarton@homothety:~/sandbox/foo/bar$ git-add--interactive
staged unstaged path
1: unchanged +1/-0 bar/x
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 5
staged unstaged path
1: unchanged +1/-0 bar/x
Patch update> 1
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now>
Rather than returning to the main menu, git-add--interactive should
have showed me a list of chunks. It seems that the list of files is
relative to the working tree root (which is sensible) but when git-
add--interactive invokes git-diff-files it does not take this into
account. Perhaps git-diff-files should also complain when invoked as
git-diff-files -- non-existent-file-name
so it wouldn't have taken me half an hour to track this down.
Regards,
Reid Barton
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 2:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040224080.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > Actually <n> wouldn't be so bad. We could do something like:
> >
> > GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
>
> I am somewhat wary of using environment variables in that context, since
> the variables could leak to subprocesses, or (even worse), they could be
> set inadvertently by the user or other scripts.
Sure. But as bad as it is, its still more secure than the
"repository of record" that my day-job uses for its source code
tree (no, it doesn't use Git, and I wish it was as good as Visual
Source Suck). </bad-joke>
I'd suggest also using something like getppid() to check the pid
against a pid in the env, and *gasp* maybe do a SHA-1 hash in there
or something to make it challening enough to fake that the average
user won't set it unless they really understand what they are doing.
--
Shawn.
^ permalink raw reply
* Re: [BUG] Pulling tags no longer works in 1.5.3.4...
From: Jeff King @ 2007-12-04 2:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4754B4AF.8070408@garzik.org>
On Mon, Dec 03, 2007 at 09:00:15PM -0500, Jeff Garzik wrote:
> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git
> trees:
>
> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
>
> 2) time passes (days or weeks)
>
> 3) cd tmp-2.6
> git pull ../linux-2.6
> git pull --tags ../linux-2.6
>
> Result: works as expected.
Hrm, when I try to reproduce using v1.5.3.3, I get the "Warning: No
merge candidate found..." message. Between 1.5.3.3 and 1.5.3.4, this
message got a bit longer and the exit code was fixed to indicate an
error. Were you perhaps just missing the warning message, since no error
was signaled?
At any rate, I think what you really want in step 3 is
git fetch --tags ../linux-2.6
since you just want to grab the tags, and not merge anything (remember
that pull is fetch+merge -- you are only interesting in the fetching
side effect). You could also do this:
git pull --tags ../linux-2.6 master
In general, "git pull --tags" without a branch to pull doesn't make much
sense. What happens is that the "--tags" tells the fetch part of the
pull operation to just grab the tags. Then the merge part of the pull
operation looks in what has just been fetched for something merge-able.
And of course there isn't anything, since all you fetched were tags.
-Peff
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Steven Grimm @ 2007-12-04 2:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040224080.27959@racer.site>
On Dec 3, 2007, at 6:25 PM, Johannes Schindelin wrote:
> I am somewhat wary of using environment variables in that context,
> since
> the variables could leak to subprocesses, or (even worse), they
> could be
> set inadvertently by the user or other scripts.
Agreed on the inadvertent setting, but isn't leaking to subprocesses
the whole point of the exercise here?
-Steve
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Johannes Schindelin @ 2007-12-04 2:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <20071204022020.GA14735@spearce.org>
Hi,
On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > > You failed to quote the part of my email where I talked about how
> > > we set an evironment variable to pass a hint to lockfile.c running
> > > within the git-update-ref subprocess to instruct it to perform a
> > > different style of locking, one that would work as a "recursive"
> > > lock.
> > >
> > > Such a recursive lock could be useful for a whole lot more than just
> > > the update hook. But it would at least allow the update hook to
> > > use git-update-ref to safely change the ref, without receive-pack
> > > losing its own lock on the ref.
> >
> > Indeed, I even failed to read it fully ;-)
> >
> > What do you propose, though? <filename>.lock.<n>?
>
> Sure. :-)
>
> I was also hand-waving. Hoping someone else would fill in the
> magic details.
>
> Actually <n> wouldn't be so bad. We could do something like:
>
> GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
I am somewhat wary of using environment variables in that context, since
the variables could leak to subprocesses, or (even worse), they could be
set inadvertently by the user or other scripts.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] Pulling tags no longer works in 1.5.3.4...
From: Johannes Schindelin @ 2007-12-04 2:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4754B4AF.8070408@garzik.org>
Hi,
On Mon, 3 Dec 2007, Jeff Garzik wrote:
> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git
> trees:
>
> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
>
> 2) time passes (days or weeks)
>
> 3) cd tmp-2.6
> git pull ../linux-2.6
> git pull --tags ../linux-2.6
>
> Result: works as expected.
>
>
>
> Using package git-core-1.5.3.4-1.fc8, step #3 breaks:
>
> [jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
Oops.
As a workaround, please do "git fetch --tags ../linux-2.6 && git pull
../linux-2.6/" until it is fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 2:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040211270.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > You failed to quote the part of my email where I talked about how
> > we set an evironment variable to pass a hint to lockfile.c running
> > within the git-update-ref subprocess to instruct it to perform a
> > different style of locking, one that would work as a "recursive"
> > lock.
> >
> > Such a recursive lock could be useful for a whole lot more than just
> > the update hook. But it would at least allow the update hook to
> > use git-update-ref to safely change the ref, without receive-pack
> > losing its own lock on the ref.
>
> Indeed, I even failed to read it fully ;-)
>
> What do you propose, though? <filename>.lock.<n>?
Sure. :-)
I was also hand-waving. Hoping someone else would fill in the
magic details.
Actually <n> wouldn't be so bad. We could do something like:
GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
where <ref> is a ref name (which cannot contain spaces, even though
some people seem to forget that rule) and <depth> is the number
of times it has been locked already. <depth> of 0 is the current
".lock" file. So the first lock taken out by receive-pack would
be setting:
GIT_INHERITED_LOCKS="refs/heads/master 0"
and another lock on the same ref by a subprocess would then update
it to:
GIT_INHERITED_LOCKS="refs/heads/master 1"
etc...
</hand-waving>
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Johannes Schindelin @ 2007-12-04 2:17 UTC (permalink / raw)
To: Jeff King
Cc: Robin Rosenberg, Junio C Hamano, Anatol Pomozov, git,
Linus Torvalds
In-Reply-To: <20071204014326.GA21358@coredump.intra.peff.net>
Hi,
On Mon, 3 Dec 2007, Jeff King wrote:
> On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
>
> > code did not pass). Like Linus, this code does not resolve symlinks,
> > but I forgot to state that it is by design. It solves my problem and
>
> By design meaning "I didn't feel like implemening it because I do not
> personally care" or "I have some reason not to resolve symlinks"?
IMHO those symlinks would be a nice thing in some corner cases, but
penalise the common case. So I tend to believe the latter. (See also
Linus' message why he talks about his preference for the die() code path.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Johannes Schindelin @ 2007-12-04 2:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <20071204015108.GV14735@spearce.org>
Hi,
On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
> >
> > > Steven Grimm <koreth@midwinter.com> wrote:
> > > > This is useful in cases where a hook needs to modify an incoming commit
> > > > in some way, e.g., fixing whitespace errors, adding an annotation to
> > > > the commit message, noting the location of output from a profiling tool,
> > > > or committing to an svn repository using git-svn.
> > > ...
> > > > +/* Update hook exit code: hook has updated ref on its own */
> > > > +#define EXIT_CODE_REF_UPDATED 100
> > >
> > > Hmm. I would actually rather move the ref locking to before we run
> > > the update hook, so the ref is locked *while* the hook executes.
> >
> > Would that not mean that you cannot use update-ref to update the ref,
> > since that wants to use the same lock?
>
> You failed to quote the part of my email where I talked about how
> we set an evironment variable to pass a hint to lockfile.c running
> within the git-update-ref subprocess to instruct it to perform a
> different style of locking, one that would work as a "recursive"
> lock.
>
> Such a recursive lock could be useful for a whole lot more than just
> the update hook. But it would at least allow the update hook to
> use git-update-ref to safely change the ref, without receive-pack
> losing its own lock on the ref.
Indeed, I even failed to read it fully ;-)
What do you propose, though? <filename>.lock.<n>?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Reorder msgfmt command-line arguments.
From: Shawn O. Pearce @ 2007-12-04 2:07 UTC (permalink / raw)
To: brian m. carlson; +Cc: Johannes Schindelin, git
In-Reply-To: <20071203170402.GA13712@crustytoothpaste.ath.cx>
"brian m. carlson" <sandals@crustytoothpaste.ath.cx> wrote:
> On Mon, Dec 03, 2007 at 10:35:33AM +0000, Johannes Schindelin wrote:
> >On Mon, 3 Dec 2007, brian m. carlson wrote:
> >
> >>Any program using getopt or getopt_long will stop processing options
> >>once a non-option argument has been encountered, if POSIXLY_CORRECT is
> >>set.
...
> >Besides, you probably want to send this as a git-gui patch: based on
> >git-gui.git, not git.git, and Cc'ed to Shawn Pearce.
>
> Thanks. Will do.
Don't bother. I already did the necesary work to apply this patch
to the git-gui.git tree. It was small, obviously correct, and easy
to fix up to make it apply to git-gui.git. Its already pushed out
in my master branch and will be in gitgui-0.9.1.
--
Shawn.
^ permalink raw reply
* [BUG] Pulling tags no longer works in 1.5.3.4...
From: Jeff Garzik @ 2007-12-04 2:00 UTC (permalink / raw)
To: Git Mailing List
Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel
git trees:
1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
2) time passes (days or weeks)
3) cd tmp-2.6
git pull ../linux-2.6
git pull --tags ../linux-2.6
Result: works as expected.
Using package git-core-1.5.3.4-1.fc8, step #3 breaks:
[jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
In-Reply-To: <7vmyssqrhk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > This probably requires exporting the name of the ref we currently
> > have locked in an environment variable (and teach lockfile.c it)
> > so we can effectively do recursive locking. That way the update
> > hook can still use git-update-ref to change the ref safely.
>
> Heh, I like that, although I suspect getting this right would mean the
> topic should be post 1.5.4 (which I do not mind).
Yea, most likely.
Also I won't have any time in the near future to work on this
implementation myself. I threw the idea out there in case someone
else can find the time. I'm willing to do the work myself as I think
its the right approach to use here for this update hook change, but
I just don't see myself getting to it anytime before say Christmas...
Its slightly more involved then what Steven originally proposed,
but I think it solves the problem better and gives us more room
for future improvements where we may want/need something such as
a recursive ref locking.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712031146520.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
>
> > Steven Grimm <koreth@midwinter.com> wrote:
> > > This is useful in cases where a hook needs to modify an incoming commit
> > > in some way, e.g., fixing whitespace errors, adding an annotation to
> > > the commit message, noting the location of output from a profiling tool,
> > > or committing to an svn repository using git-svn.
> > ...
> > > +/* Update hook exit code: hook has updated ref on its own */
> > > +#define EXIT_CODE_REF_UPDATED 100
> >
> > Hmm. I would actually rather move the ref locking to before we run
> > the update hook, so the ref is locked *while* the hook executes.
>
> Would that not mean that you cannot use update-ref to update the ref,
> since that wants to use the same lock?
You failed to quote the part of my email where I talked about how
we set an evironment variable to pass a hint to lockfile.c running
within the git-update-ref subprocess to instruct it to perform a
different style of locking, one that would work as a "recursive"
lock.
Such a recursive lock could be useful for a whole lot more than just
the update hook. But it would at least allow the update hook to
use git-update-ref to safely change the ref, without receive-pack
losing its own lock on the ref.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] install-sh from automake does not like -m without delimiting space
From: Shawn O. Pearce @ 2007-12-04 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7v1wa3e0h9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Robert Schiele <rschiele@gmail.com> writes:
> > The install-sh script as shipped with automake requires a space between
> > the -m switch and its argument. Since this is also the regular way of
> > doing it with other install implementations this change inserts the
> > missing space in all makefiles.
...
> I'll ask Shawn to do that part separately.
The git-gui portion is already in my master branch. See the
"What's in git-gui.git" I sent out last evening.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Jeff King @ 2007-12-04 1:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Anatol Pomozov, git, Linus Torvalds
In-Reply-To: <200712032153.31322.robin.rosenberg.lists@dewire.com>
On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
> code did not pass). Like Linus, this code does not resolve symlinks,
> but I forgot to state that it is by design. It solves my problem and
By design meaning "I didn't feel like implemening it because I do not
personally care" or "I have some reason not to resolve symlinks"?
-Peff
^ 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