* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-14 17:25 UTC (permalink / raw)
To: Christian Couder; +Cc: Wincent Colaiuta, Junio Hamano, git
In-Reply-To: <200710141709.51579.chriscool@tuxfamily.org>
Hi,
On Sun, 14 Oct 2007, Christian Couder wrote:
> Le dimanche 14 octobre 2007, David Kastrup a ?crit :
> > Wincent Colaiuta <win@wincent.com> writes:
> > > El 14/10/2007, a las 14:28, Christian Couder escribi?:
> > >> Here is my bisect dunno patch series again.
> > >
> > > Good work on the series, Christian, but don't you think that
> > > "unknown" would sound a little bit better than "dunno"? For people
> > > who don't speak English as a second language "dunno" might not be
> > > immediately clear.
> >
> > "undecided"?
>
> I choosed "dunno" because that was what Dscho suggested in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
>
> It seems to me short and understandable at the same time.
>
> More meaningfull would be "untestable" or "cannottest" or "canttest" but
> it's much longer, while "good" and "bad" are short.
I guess this discussion means that nobody has anything technical to argue
about. IOW your patch series is good...
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Marius Storm-Olsen @ 2007-10-14 17:24 UTC (permalink / raw)
To: Christian Couder
Cc: Wincent Colaiuta, David Kastrup, René Scharfe, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <522E90CF-FC15-472F-B0A8-91C310CAF9BF@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
Wincent Colaiuta said the following on 14.10.2007 18:35:
> El 14/10/2007, a las 18:25, David Kastrup escribió:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Christian Couder schrieb:
>>>> I choosed "dunno" because that was what Dscho suggested in
>>>> this thread:
>>>>
>>>> http://thread.gmane.org/gmane.comp.version-control.git/53584/
>>>> focus=53595
>>>>
>>>> It seems to me short and understandable at the same time.
>>>>
>>>> More meaningfull would be "untestable" or "cannottest" or
>>>> "canttest" but it's much longer, while "good" and "bad" are
>>>> short.
>>> Ugly? Neutral?
>> "Ugly" has a certain charm to it but would probably not translate
>> well. "Limbo" would be another such candidate, probably with
>> better translatability. But while some of those have some geeky
>> appeal, I really think something reasonably plain like
>> "undecided" would be better in the long run.
>
> "undecided" sounds good to me. It should be clear to non-native
> speakers of English (at least, clearer than "dunno").
What about just "unknown"?
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] add get_sha1_with_real_ref() returning full name of ref on demand
From: Johannes Schindelin @ 2007-10-14 17:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11923520852991-git-send-email-prohaska@zib.de>
Hi,
On Sun, 14 Oct 2007, Steffen Prohaska wrote:
> Deep inside get_sha1() the name of the requested ref is matched
> according to the rules documented in git-rev-parse. This patch
> introduces a function that returns the full name of the matched
> ref to the outside.
>
> For example 'master' is typically returned as 'refs/heads/master'.
>
> The new function can be used by "git rev-parse" to print the full
> name of the matched ref and can be used by "git send-pack" to expand
> a local ref to its full name.
I have not really studies your patch, but from your description it sounds
as if dwim_ref() does what you want.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add color to git-add--interactive diffs (Take 2: now without spurious line break!)
From: Johannes Schindelin @ 2007-10-14 17:15 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Tom Tobin, Git Mailing List
In-Reply-To: <EFADE863-FC59-4A50-B165-9D30D9648B97@wincent.com>
Hi,
On Sun, 14 Oct 2007, Wincent Colaiuta wrote:
> > +sub parse_color {
>
> You could simplify the manual escape sequence construction that you're
> doing here by using Term::ANSIColor like the other patches did. I see
> that git-send-email.perl uses that module too, so I guess depending on
> that module is ok.
Wrong. Depending on that module is not correct, you always have to wrap
it into an "if (<is_color>) {...}".
I use git add -i quite often, and I _never_ use git send-email. My guess
is that I am not alone with that.
Ciao,
Dscho
^ permalink raw reply
* [PATCH amend 14/14] Use the asyncronous function infrastructure to run the content filter.
From: Johannes Sixt @ 2007-10-14 17:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710140404480.25221@racer.site>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Sunday 14 October 2007 05:07, Johannes Schindelin wrote:
> On Sat, 13 Oct 2007, Johannes Sixt wrote:
> > status = finish_command(&child_process);
> > if (status)
> > - error("external filter %s failed %d", cmd, -status);
> > + error("external filter %s failed", params->cmd);
>
> Did you mean to remove the status from the output (it should probably read
> "(exit status %d)" instead of just "%d", but an exit status can help
> identify problems, right?
I didn't mean to change the error message here.
> > + if (start_async(&async))
> > + return 0; /* error was already reported */
>
> Please write "return NULL;"
This patch now does just that.
-- Hannes
convert.c | 60 +++++++++++++++++++++++++++---------------------------------
1 files changed, 27 insertions(+), 33 deletions(-)
diff --git a/convert.c b/convert.c
index c870817..ac04157 100644
--- a/convert.c
+++ b/convert.c
@@ -201,15 +201,21 @@ static char *crlf_to_worktree(const char *path, const char *src, unsigned long *
return buffer;
}
-static int filter_buffer(int fd, const char *src,
- unsigned long size, const char *cmd)
+struct filter_params {
+ const char *src;
+ unsigned long size;
+ const char *cmd;
+};
+
+static int filter_buffer(int fd, void *data)
{
/*
* Spawn cmd and feed the buffer contents through its stdin.
*/
struct child_process child_process;
+ struct filter_params *params = (struct filter_params *)data;
int write_err, status;
- const char *argv[] = { "sh", "-c", cmd, NULL };
+ const char *argv[] = { "sh", "-c", params->cmd, NULL };
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -217,17 +223,17 @@ static int filter_buffer(int fd, const char *src,
child_process.out = fd;
if (start_command(&child_process))
- return error("cannot fork to run external filter %s", cmd);
+ return error("cannot fork to run external filter %s", params->cmd);
- write_err = (write_in_full(child_process.in, src, size) < 0);
+ write_err = (write_in_full(child_process.in, params->src, params->size) < 0);
if (close(child_process.in))
write_err = 1;
if (write_err)
- error("cannot feed the input to external filter %s", cmd);
+ error("cannot feed the input to external filter %s", params->cmd);
status = finish_command(&child_process);
if (status)
- error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", params->cmd, -status);
return (write_err || status);
}
@@ -241,42 +247,31 @@ static char *apply_filter(const char *path, const char *src,
* (child --> cmd) --> us
*/
const int SLOP = 4096;
- int pipe_feed[2];
- int status;
char *dst;
unsigned long dstsize, dstalloc;
- struct child_process child_process;
+ struct async async;
+ struct filter_params params;
if (!cmd)
return NULL;
- memset(&child_process, 0, sizeof(child_process));
-
- if (pipe(pipe_feed) < 0) {
- error("cannot create pipe to run external filter %s", cmd);
- return NULL;
- }
+ memset(&async, 0, sizeof(async));
+ async.proc = filter_buffer;
+ async.data = ¶ms;
+ params.src = src;
+ params.size = *sizep;
+ params.cmd = cmd;
fflush(NULL);
- child_process.pid = fork();
- if (child_process.pid < 0) {
- error("cannot fork to run external filter %s", cmd);
- close(pipe_feed[0]);
- close(pipe_feed[1]);
- return NULL;
- }
- if (!child_process.pid) {
- close(pipe_feed[0]);
- exit(filter_buffer(pipe_feed[1], src, *sizep, cmd));
- }
- close(pipe_feed[1]);
+ if (start_async(&async))
+ return NULL; /* error was already reported */
dstalloc = *sizep;
dst = xmalloc(dstalloc);
dstsize = 0;
while (1) {
- ssize_t numread = xread(pipe_feed[0], dst + dstsize,
+ ssize_t numread = xread(async.out, dst + dstsize,
dstalloc - dstsize);
if (numread <= 0) {
@@ -293,15 +288,14 @@ static char *apply_filter(const char *path, const char *src,
dst = xrealloc(dst, dstalloc);
}
}
- if (close(pipe_feed[0])) {
+ if (close(async.out)) {
error("read from external filter %s failed", cmd);
free(dst);
dst = NULL;
}
- status = finish_command(&child_process);
- if (status) {
- error("external filter %s failed %d", cmd, -status);
+ if (finish_async(&async)) {
+ error("external filter %s failed", cmd);
free(dst);
dst = NULL;
}
--
1.5.3.2.141.g48f10
^ permalink raw reply related
* Re: [PATCH 01/14] Change git_connect() to return a struct child_process instead of a pid_t.
From: Johannes Schindelin @ 2007-10-14 17:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <200710141140.10597.johannes.sixt@telecom.at>
Hi,
On Sun, 14 Oct 2007, Johannes Sixt wrote:
> On Sunday 14 October 2007 02:57, Johannes Schindelin wrote:
> >
> > On Sat, 13 Oct 2007, Johannes Sixt wrote:
> > > -int finish_connect(pid_t pid)
> > > +int finish_connect(struct child_process *conn)
> > > {
> > > - if (pid == 0)
> > > + if (conn == NULL)
> > > return 0;
> > >
> > > - while (waitpid(pid, NULL, 0) < 0) {
> > > + while (waitpid(conn->pid, NULL, 0) < 0) {
> > > if (errno != EINTR)
> > > return -1;
> >
> > Just for completeness' sake: could you do a free(conn); before return
> > -1;?
>
> I know. But the loop is going away with the next patch, so I didn't
> bother. Can you live with that?
It'll be hard, but I'll try ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Benoit SIGOURE @ 2007-10-14 17:10 UTC (permalink / raw)
To: git list; +Cc: Make Windows
In-Reply-To: <1192381040.4908.57.camel@homebase.localnet>
[-- Attachment #1.1: Type: text/plain, Size: 1254 bytes --]
Context: GNU make seems to be willing to switch from CVS to ...
something else.
On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
> [...] the big thing no one else seems to have addressed much in
> other discussions I've seen is portability. It LOOKS like there are
> native ports of GIT to MINGW, but I have no idea how complete and
> usable
> they are. If someone who has a Windows system could look into that it
> would be a big help.
I think the best thing to do is to ask directly on the Git ML.
Someone already pointed out that he'd like to use Git on Windows but
doesn't want to install either Cygwin or MSYS. Is this possible, or
will it be possible in the near future? Is it possible to use one of
the various GUIs (git-gui, gitk, qgit) on Windows without requiring a
POSIXish shell etc.?
When will the librarification of Git be finished? (if Git is
available as a library, and if this library works on Windows, it will
greatly help truly native Windows ports).
Not that I like Windows in any way, right, but it's legitimate for
people working on Windows ports of various software to be willing to
have a truly native port of Git for Windows.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
[-- Attachment #2: Type: text/plain, Size: 134 bytes --]
_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
^ permalink raw reply
* Re: [PATCH 0/14] fork/exec removal series
From: Johannes Schindelin @ 2007-10-14 17:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Johannes Sixt, gitster, git
In-Reply-To: <20071014071239.GB1198@artemis.corp>
Hi,
On Sun, 14 Oct 2007, Pierre Habouzit wrote:
> On Sun, Oct 14, 2007 at 02:58:57AM +0000, Shawn O. Pearce wrote:
>
> > But we most definately *must* continue to support fork() for the async
> > functions. Its the most common interface available on one of our
> > biggest platforms (UNIX).
>
> Yeah that, and the fact that many of the git modules aren't thread-safe
> (some modules have static buffers strbuf's or caching variables) and
> should be used with care.
I think that was exactly the point of Shawn: expose bugs on Unix that
would otherwise only show in msysGit.
Ciao,
Dscho
^ permalink raw reply
* [PATCH amend 08/14] Add infrastructure to run a function asynchronously.
From: Johannes Sixt @ 2007-10-14 17:08 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1192305984-22594-9-git-send-email-johannes.sixt@telecom.at>
This adds start_async() and finish_async(), which runs a function
asynchronously. Communication with the caller happens only via pipes.
For this reason, this implementation forks off a child process that runs
the function.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
This is the same as submitted previously except it uses close_pair()
to close the pipe in an error patch and improves the comments in
run-command.h.
-- Hannes
run-command.c | 52 ++++++++++++++++++++++++++++++++++++++++++++--------
run-command.h | 22 ++++++++++++++++++++++
2 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/run-command.c b/run-command.c
index d00c03b..db02f75 100644
--- a/run-command.c
+++ b/run-command.c
@@ -127,16 +127,11 @@ int start_command(struct child_process *cmd)
return 0;
}
-int finish_command(struct child_process *cmd)
+static int wait_or_whine(pid_t pid)
{
- if (cmd->close_in)
- close(cmd->in);
- if (cmd->close_out)
- close(cmd->out);
-
for (;;) {
int status, code;
- pid_t waiting = waitpid(cmd->pid, &status, 0);
+ pid_t waiting = waitpid(pid, &status, 0);
if (waiting < 0) {
if (errno == EINTR)
@@ -144,7 +139,7 @@ int finish_command(struct child_process *cmd)
error("waitpid failed (%s)", strerror(errno));
return -ERR_RUN_COMMAND_WAITPID;
}
- if (waiting != cmd->pid)
+ if (waiting != pid)
return -ERR_RUN_COMMAND_WAITPID_WRONG_PID;
if (WIFSIGNALED(status))
return -ERR_RUN_COMMAND_WAITPID_SIGNAL;
@@ -158,6 +153,15 @@ int finish_command(struct child_process *cmd)
}
}
+int finish_command(struct child_process *cmd)
+{
+ if (cmd->close_in)
+ close(cmd->in);
+ if (cmd->close_out)
+ close(cmd->out);
+ return wait_or_whine(cmd->pid);
+}
+
int run_command(struct child_process *cmd)
{
int code = start_command(cmd);
@@ -200,3 +204,35 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
cmd.env = env;
return run_command(&cmd);
}
+
+int start_async(struct async *async)
+{
+ int pipe_out[2];
+
+ if (pipe(pipe_out) < 0) {
+ return error("cannot create pipe: %s", strerror(errno));
+ }
+
+ async->pid = fork();
+ if (async->pid < 0) {
+ error("fork (async) failed: %s", strerror(errno));
+ close_pair(pipe_out);
+ return -1;
+ }
+ if (!async->pid) {
+ close(pipe_out[0]);
+ exit(!!async->proc(pipe_out[1], async->data));
+ }
+ async->out = pipe_out[0];
+ close(pipe_out[1]);
+ return 0;
+}
+
+int finish_async(struct async *async)
+{
+ int ret = 0;
+
+ if (wait_or_whine(async->pid))
+ ret = error("waitpid (async) failed");
+ return ret;
+}
diff --git a/run-command.h b/run-command.h
index 35b9fb6..94e1e9d 100644
--- a/run-command.h
+++ b/run-command.h
@@ -43,4 +43,26 @@ int run_command_v_opt_cd(const char **argv, int opt, const char *dir);
*/
int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env);
+/*
+ * The purpose of the following functions is to feed a pipe by running
+ * a function asynchronously and providing output that the caller reads.
+ *
+ * It is expected that no synchronization and mutual exclusion between
+ * the caller and the feed function is necessary so that the function
+ * can run in a thread without interfering with the caller.
+ */
+struct async {
+ /*
+ * proc writes to fd and closes it;
+ * returns 0 on success, non-zero on failure
+ */
+ int (*proc)(int fd, void *data);
+ void *data;
+ int out; /* caller reads from here and closes it */
+ pid_t pid;
+};
+
+int start_async(struct async *async);
+int finish_async(struct async *async);
+
#endif
--
1.5.3.2.141.g48f10
^ permalink raw reply related
* [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Johannes Schindelin @ 2007-10-14 16:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Eric Wong, git
In-Reply-To: <20071014095755.GF1198@artemis.corp>
When there is an option "--amend", the option parser now recognizes
"--am" for that option, provided that there is no other option beginning
with "--am".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sun, 14 Oct 2007, Pierre Habouzit wrote:
> On Sun, Oct 14, 2007 at 09:18:55AM +0000, Eric Wong wrote:
> >
> > One feature I really like is automatically handling of long
> > option abbreviations. gitopt supported this at the expense of
> > complexity and the aforementioned intrusivenes. This allows
> > automatic handling of the abbreviation style seen commonly in
> > git shell scripts:
> >
> > --a|--am|--ame|--amen|--amend) (from git-commit.sh)
>
> Yes, but if you do that, you can't order options in the order
> you want (because of first match issues), making the help dumps
> hopelessly random.
I think this patch proves that you do not need to order the options...
;-)
parse-options.c | 32 ++++++++++++++++++++++++++++++++
t/t0040-parse-options.sh | 22 ++++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 72656a8..afc6c89 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -102,6 +102,13 @@ static int parse_short_opt(struct optparse_t *p, const struct option *options)
static int parse_long_opt(struct optparse_t *p, const char *arg,
const struct option *options)
{
+ const char *arg_end = strchr(arg, '=');
+ const struct option *abbrev_option = NULL;
+ int abbrev_flags = 0;
+
+ if (!arg_end)
+ arg_end = arg + strlen(arg);
+
for (; options->type != OPTION_END; options++) {
const char *rest;
int flags = 0;
@@ -111,10 +118,33 @@ static int parse_long_opt(struct optparse_t *p, const char *arg,
rest = skip_prefix(arg, options->long_name);
if (!rest) {
+ /* abbreviated? */
+ if (!strncmp(options->long_name, arg, arg_end - arg)) {
+is_abbreviated:
+ if (abbrev_option)
+ die ("Ambiguous option: %s "
+ "(could be --%s%s or --%s%s)",
+ arg,
+ (flags & OPT_UNSET) ?
+ "no-" : "",
+ options->long_name,
+ (abbrev_flags & OPT_UNSET) ?
+ "no-" : "",
+ abbrev_option->long_name);
+ if (!(flags & OPT_UNSET) && *arg_end)
+ p->opt = arg_end + 1;
+ abbrev_option = options;
+ abbrev_flags = flags;
+ continue;
+ }
+ /* negated? */
if (strncmp(arg, "no-", 3))
continue;
flags |= OPT_UNSET;
rest = skip_prefix(arg + 3, options->long_name);
+ /* abbreviated and negated? */
+ if (!rest && !prefixcmp(options->long_name, arg + 3))
+ goto is_abbreviated;
if (!rest)
continue;
}
@@ -125,6 +155,8 @@ static int parse_long_opt(struct optparse_t *p, const char *arg,
}
return get_value(p, options, flags);
}
+ if (abbrev_option)
+ return get_value(p, abbrev_option, abbrev_flags);
return error("unknown option `%s'", arg);
}
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 09b3230..e4dd86f 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -66,4 +66,26 @@ test_expect_success 'intermingled arguments' '
git diff expect output
'
+cat > expect << EOF
+boolean: 0
+integer: 2
+string: (not set)
+EOF
+
+test_expect_success 'unambiguously abbreviated option' '
+ test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+ test ! -s output.err &&
+ git diff expect output
+'
+
+test_expect_success 'unambiguously abbreviated option with "="' '
+ test-parse-options --int=2 > output 2> output.err &&
+ test ! -s output.err &&
+ git diff expect output
+'
+
+test_expect_failure 'ambiguously abbreviated option' '
+ test-parse-options --strin 123
+'
+
test_done
--
1.5.3.4.1174.gcd0d6-dirty
^ permalink raw reply related
* Re: git blame crashes with internal error
From: Pierre Habouzit @ 2007-10-14 16:50 UTC (permalink / raw)
To: David Kastrup; +Cc: Andreas Ericsson, Björn Steinbrink, gitster, git
In-Reply-To: <85hcktn3s0.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
On Sun, Oct 14, 2007 at 02:56:31PM +0000, David Kastrup wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Björn Steinbrink wrote:
> >>
> >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
> >> master and all of them crashed. A small shell script to reproduce the
> >> problem is attached.
> >>
> >
> > Manual bisect? Ugh. This *is* the century of the competent developer
> > tools, you know... ;-)
>
> It's not a "bisect" when it crashes in all versions.
What What, git cannot bisect future versions ??? *g* what a
disappointment.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Imports without Tariffs
From: Jeff King @ 2007-10-14 16:40 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <814D00AE-B89A-45ED-A500-4643C825D0EB@mit.edu>
On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
> I can make a patch, but at the moment I'm swamped and I don't want to think
> about doing that.
>
> I'll get around to it eventually, I hope.
>
> Do I just submit the patch to this list? How do I know it will be used?
Yes, send a patch to the list and to Junio (the maintainer). See
Documentation/SubmittingPatches for details.
> Frankly, I don't know how robust my idea is either, but it's simple
> enough not to have many problems lurking in the shadows.
>
> It would certainly be more useful than not.
Then submit a patch implementing it. :)
>> all of the data that goes into the commit hash as textual comments in
>> the CVS commit (committer name/time, author name/time). And then
> I considered this too, but this exposes what we're doing. We don't
> want the old farts to wonder what all these hash thingies are.
Heh. I like the idea of git secretly infiltrating institutions,
replacing CVS unbeknownst to management. It was the same for Linux in
the mid-90's ("our mail server is running on what!?").
-Peff
^ permalink raw reply
* Re: git blame crashes with internal error
From: Alex Riesen @ 2007-10-14 16:37 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: gitster, git
In-Reply-To: <20071014143628.GA22568@atjola.homenet>
Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> Hi Junio,
>
> git blame just decided to crash on me, when I tried to use it while
> resolving a merge conflict. Interesting is probably, that it crashes
> when given the filename of a file that is not _directly_ affected by the
> merge, but contains code that originates from a file that caused
> conlicts.
>
> Error message is:
> fatal: internal error: ce_mode is 0
>
It is not crashing. It is just not handling unexpected situation
properly:
$ testcase.sh
...
Switched to branch "foo"
CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.
Automatic merge failed; fix conflicts and then commit the result.
fatal: internal error: ce_mode is 0
$ git ls-files --cached --stage
100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1 file1
100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3 file1
100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0 file2
See? There is an unresolved merge.
The question is, what's the problem...
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Wincent Colaiuta @ 2007-10-14 16:35 UTC (permalink / raw)
To: David Kastrup
Cc: René Scharfe, Christian Couder, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <85y7e5ll38.fsf@lola.goethe.zz>
El 14/10/2007, a las 18:25, David Kastrup escribió:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Christian Couder schrieb:
>>>
>>> I choosed "dunno" because that was what Dscho suggested in this
>>> thread:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/53584/
>>> focus=53595
>>>
>>> It seems to me short and understandable at the same time.
>>>
>>> More meaningfull would be "untestable" or "cannottest" or
>>> "canttest" but it's much longer, while "good" and "bad" are short.
>>
>> Ugly? Neutral?
>
> "Ugly" has a certain charm to it but would probably not translate
> well. "Limbo" would be another such candidate, probably with better
> translatability. But while some of those have some geeky appeal, I
> really think something reasonably plain like "undecided" would be
> better in the long run.
"undecided" sounds good to me. It should be clear to non-native
speakers of English (at least, clearer than "dunno").
<personal opinion>
Another problem with "dunno" is that it might come across as a bit
unprofessional due to its informality. Yes, you'll find it in most
dictionaries, but always with a qualifier of "slang", "colloquial",
"casual", "pronunciation spelling" or similar.
</personal opinion>
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Update manpages to reflect new short and long option aliases
From: Pierre Habouzit @ 2007-10-14 16:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
In-Reply-To: <20071014141042.GA21197@diku.dk>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
added and pushed.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplify usage string printing
From: Pierre Habouzit @ 2007-10-14 16:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
In-Reply-To: <20071014140116.GA20970@diku.dk>
[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]
On Sun, Oct 14, 2007 at 02:01:16PM +0000, Jonas Fonseca wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> builtin-branch.c | 1 -
> builtin-update-ref.c | 1 -
> parse-options.c | 2 +-
> 3 files changed, 1 insertions(+), 3 deletions(-)
>
> Pierre Habouzit <madcoder@debian.org> wrote Sat, Oct 13, 2007:
> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > ---
> > builtin-update-ref.c | 71 +++++++++++++++++++++-----------------------------
> > 1 files changed, 30 insertions(+), 41 deletions(-)
> >
> > diff --git a/builtin-update-ref.c b/builtin-update-ref.c
> > index fe1f74c..eafb642 100644
> > --- a/builtin-update-ref.c
> > +++ b/builtin-update-ref.c
> > @@ -1,59 +1,48 @@
> > #include "cache.h"
> > #include "refs.h"
> > #include "builtin.h"
> > +#include "parse-options.h"
> >
> > -static const char git_update_ref_usage[] =
> > -"git-update-ref [-m <reason>] (-d <refname> <value> | [--no-deref] <refname> <value> [<oldval>])";
> > +static const char * const git_update_ref_usage[] = {
> > + "",
> > + "git-update-ref [options] -d <refname> <oldval>",
> > + "git-update-ref [options] <refname> <newval> [<oldval>]",
> > + NULL
> > +};
>
> How about something like this to get rid of these empty strings
> that look strange?
>
> > ./git update-ref -h
> usage: git-update-ref [options] -d <refname> <oldval>
> or: git-update-ref [options] <refname> <newval> [<oldval>]
I like the idea, though we may want to have more text to explain some
things about the command, so I'll do something in between that uses or:
until an empty line is met, and just prefix the result with four spaces
else, this way we can have:
usage: git-foo ...
or: git-foo ...
Did you know that you can do bar with git-foo ?
but beware that it cannot do quux.
-m <reason> reason of the update
-d deletes the reference
--no-deref update <refname> not the one it points to
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-14 16:25 UTC (permalink / raw)
To: René Scharfe
Cc: Christian Couder, Wincent Colaiuta, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <4712400C.2080900@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Christian Couder schrieb:
>>
>> I choosed "dunno" because that was what Dscho suggested in this thread:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
>>
>> It seems to me short and understandable at the same time.
>>
>> More meaningfull would be "untestable" or "cannottest" or
>> "canttest" but it's much longer, while "good" and "bad" are short.
>
> Ugly? Neutral?
"Ugly" has a certain charm to it but would probably not translate
well. "Limbo" would be another such candidate, probably with better
translatability. But while some of those have some geeky appeal, I
really think something reasonably plain like "undecided" would be
better in the long run.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-14 16:16 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071014142826.8caa0a9f.chriscool@tuxfamily.org>
Hi,
On Sun, 14 Oct 2007, Christian Couder wrote:
> Here is my bisect dunno patch series again.
> The changes since last time are the following:
>
> [PATCH 1/7] rev-list: implement --bisect-all
> [PATCH 2/7] Bisect: fix some white spaces and empty lines breakages.
>
> -> No change.
>
> [PATCH 3/7] Bisect: implement "bisect dunno" to mark untestable revisions.
>
> -> Added dunno stuff in "bisect_replay" that I had forgotten.
> -> Use "bisect_write_good" and "bisect_write_bad" in "bisect_replay"
> while at it.
>
> [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
> [PATCH 5/7] Bisect: factorise some logging into "bisect_write".
> [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
>
> -> Some new factorisation and clean up work.
>
> [PATCH 7/7] Bisect: add "bisect dunno" to the documentation.
>
> -> Document "bisect dunno" and fix some short usage descriptions.
Thanks for doing this. I think that especially the factorisation adds
tremendously to the readibility.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Johannes Schindelin @ 2007-10-14 16:15 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071014143003.23ae649f.chriscool@tuxfamily.org>
Hi,
On Sun, 14 Oct 2007, Christian Couder wrote:
> -bisect_bad() {
> +bisect_state() {
> bisect_autostart
> - case "$#" in
> - 0)
> - rev=$(git rev-parse --verify HEAD) ;;
> - 1)
> - rev=$(git rev-parse --verify "$1^{commit}") ;;
> + state=$1
> + case "$#,$state" in
> + 0,*)
> + die "Please call 'bisect_state' with at least one argument." ;;
> + 1,bad|1,good|1,dunno)
> + rev=$(git rev-parse --verify HEAD) ||
> + die "Bad rev input: HEAD"
> + bisect_write "$state" "$rev" ;;
> + 2,bad)
> + rev=$(git rev-parse --verify "$2^{commit}") ||
> + die "Bad rev input: $2"
> + bisect_write "$state" "$rev" ;;
Really? As far as I see, "2,bad" is an error in the current bisect.
> @@ -404,17 +390,15 @@ bisect_run () {
> exit $res
> fi
>
> - # Use "bisect_good" or "bisect_bad"
> - # depending on run success or failure.
> + # Find current state depending on run success or failure.
> if [ $res -gt 0 ]; then
> - next_bisect='bisect_bad'
> + state='bad'
> else
> - next_bisect='bisect_good'
> + state='good'
> fi
Maybe it is time to have a special exit status for "dunno"? But this is
not something to fix in your patch, just an idea for a future patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: René Scharfe @ 2007-10-14 16:13 UTC (permalink / raw)
To: Christian Couder
Cc: David Kastrup, Wincent Colaiuta, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <200710141709.51579.chriscool@tuxfamily.org>
Christian Couder schrieb:
> Le dimanche 14 octobre 2007, David Kastrup a écrit :
>> Wincent Colaiuta <win@wincent.com> writes:
>>> El 14/10/2007, a las 14:28, Christian Couder escribió:
>>>> Here is my bisect dunno patch series again.
>>> Good work on the series, Christian, but don't you think that
>>> "unknown" would sound a little bit better than "dunno"? For people
>>> who don't speak English as a second language "dunno" might not be
>>> immediately clear.
>> "undecided"?
>
> I choosed "dunno" because that was what Dscho suggested in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
>
> It seems to me short and understandable at the same time.
>
> More meaningfull would be "untestable" or "cannottest" or "canttest" but
> it's much longer, while "good" and "bad" are short.
Ugly? Neutral?
René
^ permalink raw reply
* Re: [PATCH 5/7] Bisect: factorise some logging into "bisect_write".
From: Johannes Schindelin @ 2007-10-14 16:07 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071014142948.9f08b8ed.chriscool@tuxfamily.org>
Hi,
On Sun, 14 Oct 2007, Christian Couder wrote:
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 847250c..e12125f 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -132,6 +131,7 @@ bisect_write() {
> esac
> echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
> echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
> + test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
> }
Isn't a nolog="$3" missing from bisect_write()?
Ciao,
Dscho
^ permalink raw reply
* Re: git blame crashes with internal error
From: Björn Steinbrink @ 2007-10-14 15:23 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: gitster, git
In-Reply-To: <47122D02.9060204@op5.se>
On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> Björn Steinbrink wrote:
>> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
>> master and all of them crashed. A small shell script to reproduce the
>> problem is attached.
>
> Manual bisect? Ugh. This *is* the century of the competent developer
> tools, you know... ;-)
Then, how do I search for a good version with git bisect if I only have
the one data-point "master is bad"?
All I tried when testing those 5 versions was trying to find a good
version so that I can actually do an automatic bisect. And I stopped at
1.5.3 because I figured that my test-case is probably just pretty
uncommon and was basically always broken.
Another manual "bisect" shows that 1.5.0 also crashes and as 1.4.0
doesn't even want to read my git git repository, I don't intend to go
even further backwards in the history to find a good commit, unless
someone tells me that it is a really good idea or how to automate
finding a good commit in a sane way.
Björn
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Andreas Ericsson @ 2007-10-14 15:14 UTC (permalink / raw)
To: David Kastrup
Cc: Christian Couder, Wincent Colaiuta, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <85d4vhn35z.fsf@lola.goethe.zz>
David Kastrup wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> Le dimanche 14 octobre 2007, David Kastrup a écrit :
>>> Wincent Colaiuta <win@wincent.com> writes:
>>>> El 14/10/2007, a las 14:28, Christian Couder escribió:
>>>>> Here is my bisect dunno patch series again.
>>>> Good work on the series, Christian, but don't you think that
>>>> "unknown" would sound a little bit better than "dunno"? For people
>>>> who don't speak English as a second language "dunno" might not be
>>>> immediately clear.
>>> "undecided"?
>> I choosed "dunno" because that was what Dscho suggested in this thread:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
>
> I would think that tongue-in-cheek. In case it was serious, I'd
> consider it one of those cases where it would make good sense to
> overrule the geek penchant for quirkiness.
>
> Just think about the nuisance of finding adequate translations in
> i18n: "Woaßnet", "Eh?", "Chepas" etc.
>
Well, that won't be a problem, as commands and their subcommands and
options aren't translated.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-14 15:09 UTC (permalink / raw)
To: Christian Couder; +Cc: Wincent Colaiuta, Junio Hamano, Johannes Schindelin, git
In-Reply-To: <200710141709.51579.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Le dimanche 14 octobre 2007, David Kastrup a écrit :
>> Wincent Colaiuta <win@wincent.com> writes:
>> > El 14/10/2007, a las 14:28, Christian Couder escribió:
>> >> Here is my bisect dunno patch series again.
>> >
>> > Good work on the series, Christian, but don't you think that
>> > "unknown" would sound a little bit better than "dunno"? For people
>> > who don't speak English as a second language "dunno" might not be
>> > immediately clear.
>>
>> "undecided"?
>
> I choosed "dunno" because that was what Dscho suggested in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
I would think that tongue-in-cheek. In case it was serious, I'd
consider it one of those cases where it would make good sense to
overrule the geek penchant for quirkiness.
Just think about the nuisance of finding adequate translations in
i18n: "Woaßnet", "Eh?", "Chepas" etc.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Christian Couder @ 2007-10-14 15:09 UTC (permalink / raw)
To: David Kastrup; +Cc: Wincent Colaiuta, Junio Hamano, Johannes Schindelin, git
In-Reply-To: <854pgtonp5.fsf@lola.goethe.zz>
Le dimanche 14 octobre 2007, David Kastrup a écrit :
> Wincent Colaiuta <win@wincent.com> writes:
> > El 14/10/2007, a las 14:28, Christian Couder escribió:
> >> Here is my bisect dunno patch series again.
> >
> > Good work on the series, Christian, but don't you think that
> > "unknown" would sound a little bit better than "dunno"? For people
> > who don't speak English as a second language "dunno" might not be
> > immediately clear.
>
> "undecided"?
I choosed "dunno" because that was what Dscho suggested in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
It seems to me short and understandable at the same time.
More meaningfull would be "untestable" or "cannottest" or "canttest" but
it's much longer, while "good" and "bad" are short.
Christian.
^ 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