* Re: Need some help with git rebase
From: Sylvain Rabot @ 2009-12-31 9:02 UTC (permalink / raw)
To: git
In-Reply-To: <CB5B49CA-0C66-4384-9B47-3675E517E203@wincent.com>
On Wed, Dec 30, 2009 at 23:46, Wincent Colaiuta <win@wincent.com> wrote:
>
> Look at the "git-rebase" man page, particularly the order of the arguments, what they mean, and the usage examples of "--onto":
>
> $ git rebase --onto 12.72.1 master feature
>
> Means, "replay these changes on top of 12.72.1", where "these changes" refers to commits on branch "feature" with upstream "master", which is what "git rebase" did for you.
>
> If you actually want the "feature" branch to continue pointing at the old feature branch rather than your newly rebased one, you could just look up the old SHA1 for it and update it with:
>
> $ git branch -f feature abcd1234
>
> Where "abcd1234" is the hash of the old "feature" HEAD.
>
> But I don't really know why you'd want to do that. The purpose of "git rebase" isn't to copy or cherry-pick commits from one branch onto another, but to actually _move_ (or transplant, or replay, if you prefer) those commits.
>
> Maybe I misunderstood your intentions though.
>
> Cheers,
> Wincent
>
In fact I want to backport the commits of the feature branch into 12.72.1.
I used git rebase because the drawings of the man page looked like
that I wanted to do and it does except for the part it resets the head
of my feature branch.
But the good behavior would be to cherry pick each commit of the
feature branch and apply them into 12.72.1, right ?
Thanks for your answer.
Regards.
--
Sylvain
^ permalink raw reply
* Re: Need some help with git rebase
From: Peter Baumann @ 2009-12-31 9:32 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <7fce93be0912310102x53755120o31e42c4a7a92a709@mail.gmail.com>
On Thu, Dec 31, 2009 at 10:02:12AM +0100, Sylvain Rabot wrote:
> On Wed, Dec 30, 2009 at 23:46, Wincent Colaiuta <win@wincent.com> wrote:
> >
> > Look at the "git-rebase" man page, particularly the order of the arguments, what they mean, and the usage examples of "--onto":
> >
> > $ git rebase --onto 12.72.1 master feature
> >
> > Means, "replay these changes on top of 12.72.1", where "these changes" refers to commits on branch "feature" with upstream "master", which is what "git rebase" did for you.
> >
> > If you actually want the "feature" branch to continue pointing at the old feature branch rather than your newly rebased one, you could just look up the old SHA1 for it and update it with:
> >
> > $ git branch -f feature abcd1234
> >
> > Where "abcd1234" is the hash of the old "feature" HEAD.
> >
> > But I don't really know why you'd want to do that. The purpose of "git rebase" isn't to copy or cherry-pick commits from one branch onto another, but to actually _move_ (or transplant, or replay, if you prefer) those commits.
> >
> > Maybe I misunderstood your intentions though.
> >
> > Cheers,
> > Wincent
> >
>
> In fact I want to backport the commits of the feature branch into 12.72.1.
> I used git rebase because the drawings of the man page looked like
> that I wanted to do and it does except for the part it resets the head
> of my feature branch.
>
> But the good behavior would be to cherry pick each commit of the
> feature branch and apply them into 12.72.1, right ?
>
$ git checkout -b rebased_feature feature
$ git rebase --onto 12.72.1 master rebased_feature
will create a temporary branch named "rebased_feature" pointing to the same
commit as the branch "feature". In fact, this will rebase the commits on the
feature branch not reachable from master onto your 12.72.1 branch *and* won't
reset the feature branch. Instead the temporary branch named "rebased_feature"
will be rebased ontop of 12.72.1.
I would still prefere the rebase over doing multiple cherry picks.
-Peter
^ permalink raw reply
* [PATCH] Fix "git remote update" with remotes.defalt set
From: Björn Gustavsson @ 2009-12-31 9:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Starting from commit 8db35596, "git remote update" (with no
group name given) will fail with the following message if
remotes.default has been set in the config file:
fatal: 'default' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
The problem is that the --multiple option is not passed to
"git fetch" if no remote or group name is given on the command
line. Fix the problem by always passing the --multiple
option to "git fetch" (which actually simplifies the code).
Reported-by: YONETANI Tomokazu
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
builtin-remote.c | 10 ++++------
t/t5505-remote.sh | 14 ++++++++++++++
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index a501939..c4945b8 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -1238,13 +1238,11 @@ static int update(int argc, const char **argv)
fetch_argv[fetch_argc++] = "--prune";
if (verbose)
fetch_argv[fetch_argc++] = "-v";
- if (argc < 2) {
+ fetch_argv[fetch_argc++] = "--multiple";
+ if (argc < 2)
fetch_argv[fetch_argc++] = "default";
- } else {
- fetch_argv[fetch_argc++] = "--multiple";
- for (i = 1; i < argc; i++)
- fetch_argv[fetch_argc++] = argv[i];
- }
+ for (i = 1; i < argc; i++)
+ fetch_argv[fetch_argc++] = argv[i];
if (strcmp(fetch_argv[fetch_argc-1], "default") == 0) {
git_config(get_remote_default, &default_defined);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index fd166d9..936fe0a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -419,6 +419,20 @@ test_expect_success 'update default (overridden, with funny whitespace)' '
'
+test_expect_success 'update (with remotes.default defined)' '
+
+ (cd one &&
+ for b in $(git branch -r)
+ do
+ git branch -r -d $b || break
+ done &&
+ git config remotes.default "drosophila" &&
+ git remote update &&
+ git branch -r > output &&
+ test_cmp expect output)
+
+'
+
test_expect_success '"remote show" does not show symbolic refs' '
git clone one three &&
--
1.6.6.69.gc18d
^ permalink raw reply related
* [updated patch v2 0/2] Improve remote helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 10:48 UTC (permalink / raw)
To: git
Changes since updated patch (second round):
- Work around deadlock with pager.
- Fix exec reporting if read end of report pipe winds up to be fd #0.
- Limit number of retries in force_close for unexpected errors.
Ilari Liusvaara (2):
Report exec errors from run-command
Improve transport helper exec failure reporting
Makefile | 1 +
run-command.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++--
t/t0061-run-command.sh | 13 ++++++
test-run-command.c | 35 ++++++++++++++++
transport-helper.c | 14 +++++--
5 files changed, 158 insertions(+), 8 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
^ permalink raw reply
* [updated patch v2 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <1262256488-22985-1-git-send-email-ilari.liusvaara@elisanet.fi>
Previously transport-helper exec failure error reporting was pretty
much useless as it didn't report errors from execve, only from pipe
and fork. Now that run-command passes errno from exec, use the
improved support to actually print useful errors if execution fails.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
transport-helper.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 5078c71..0965c9b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
helper->out = -1;
helper->err = 0;
helper->argv = xcalloc(4, sizeof(*helper->argv));
- strbuf_addf(&buf, "remote-%s", data->name);
+ strbuf_addf(&buf, "git-remote-%s", data->name);
helper->argv[0] = strbuf_detach(&buf, NULL);
helper->argv[1] = transport->remote->name;
helper->argv[2] = transport->url;
- helper->git_cmd = 1;
- if (start_command(helper))
- die("Unable to run helper: git %s", helper->argv[0]);
+ helper->git_cmd = 0;
+ if (start_command(helper)) {
+ if (errno == ENOENT)
+ die("Unable to find remote helper for \"%s\"",
+ data->name);
+ else
+ die("Unable to run helper %s: %s", helper->argv[0],
+ strerror(errno));
+ }
data->helper = helper;
write_str_in_full(helper->in, "capabilities\n");
--
1.6.6.3.gaa2e1
^ permalink raw reply related
* [updated patch v2 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-31 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <1262256488-22985-1-git-send-email-ilari.liusvaara@elisanet.fi>
Previously run-command was unable to report errors happening in exec
call. Change it to pass errno from failed exec to errno value at
return.
The errno value passing can be done by opening close-on-exec pipe and
piping the error code through in case of failure. In case of success,
close-on-exec closes the pipe on successful exec and parent process
gets end of file on read.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
Makefile | 1 +
run-command.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++--
t/t0061-run-command.sh | 13 ++++++
test-run-command.c | 35 ++++++++++++++++
4 files changed, 148 insertions(+), 4 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
diff --git a/Makefile b/Makefile
index 4a1e5bc..452ad50 100644
--- a/Makefile
+++ b/Makefile
@@ -1725,6 +1725,7 @@ TEST_PROGRAMS += test-parse-options$X
TEST_PROGRAMS += test-path-utils$X
TEST_PROGRAMS += test-sha1$X
TEST_PROGRAMS += test-sigchain$X
+TEST_PROGRAMS += test-run-command$X
all:: $(TEST_PROGRAMS)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..1c5b103 100644
--- a/run-command.c
+++ b/run-command.c
@@ -15,6 +15,22 @@ static inline void dup_devnull(int to)
close(fd);
}
+static inline void force_close(int fd)
+{
+ int err = 0;
+ /*
+ * Retry EINTRs undefinitely, exit on EBADF immediately, other
+ * errors retry only up to three times (even if pipe close
+ * shouldn't cause other errors, but you never know with
+ * what broken systems may return on closed file descriptor).
+ * consequences of failure to close pipe here may include
+ * deadlocking.
+ */
+ while (close(fd) < 0 && errno != EBADF && err < 3)
+ if(errno != EINTR)
+ err++;
+}
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -76,9 +92,64 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef WIN32
+{
+ int report_pipe[2] = {-1, -1};
+
+ if (pipe(report_pipe) < 0) {
+ report_pipe[0] = -1;
+ report_pipe[1] = -1;
+ warning("Can't open pipe for exec status report: %s\n",
+ strerror(errno));
+ }
+
fflush(NULL);
cmd->pid = fork();
- if (!cmd->pid) {
+ if (cmd->pid > 0) {
+ int r = 0, ret;
+ force_close(report_pipe[1]);
+read_again:
+ if (report_pipe[0] >= 0)
+ r = read(report_pipe[0], &ret, sizeof(ret));
+ if (r < 0 && (errno == EAGAIN || errno == EINTR ||
+ errno == EWOULDBLOCK))
+ goto read_again;
+ else if (r < 0)
+ warning("Can't read exec status report: %s\n",
+ strerror(errno));
+ else if (r == 0)
+ ;
+ else if (r < sizeof(ret)) {
+ warning("Received incomplete exec status report.\n");
+ errno = EBADMSG;
+ } else {
+ failed_errno = ret;
+ /*
+ * Clean up the process that did the failed execution
+ * so no zombies remain.
+ */
+wait_again:
+ r = waitpid(cmd->pid, &ret, 0);
+ if (r < 0 && errno != ECHILD)
+ goto wait_again;
+ cmd->pid = -1;
+ }
+ } else if (!cmd->pid) {
+ int r = 0;
+ int flags;
+ force_close(report_pipe[0]);
+
+ flags = fcntl(report_pipe[1], F_GETFD);
+ if (flags < 0)
+ r = -1;
+ flags |= FD_CLOEXEC;
+ r = (r || fcntl(report_pipe[1], F_SETFD, flags));
+ if (r) {
+ warning("Can't FD_CLOEXEC pipe for exec status "
+ "report: %s\n", strerror(errno));
+ force_close(report_pipe[1]);
+ report_pipe[1] = -1;
+ }
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -119,20 +190,44 @@ fail_pipe:
unsetenv(*cmd->env);
}
}
- if (cmd->preexec_cb)
+ if (cmd->preexec_cb) {
+ /*
+ * We don't know what pre-exec callbacks do, and they
+ * may do something that causes deadlock with exec
+ * reporting. The sole user of this hook seems to
+ * be pager, and it is run through shell, so one
+ * wouldn't get useful error from exec reporting
+ * and would get useful error from shell anyway. So
+ * just disable exec reporting for such comamnds.
+ */
+ force_close(report_pipe[1]);
+ report_pipe[1] = -1;
cmd->preexec_cb();
+ }
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
+ failed_errno = errno;
+
trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
strerror(errno));
+
+ r = 0;
+write_again:
+ if (report_pipe[1] >= 0)
+ r = write(report_pipe[1], &failed_errno,
+ sizeof(failed_errno));
+ if (r < 0 && (errno == EAGAIN || errno == EINTR ||
+ errno == EWOULDBLOCK))
+ goto write_again;
+
exit(127);
- }
- if (cmd->pid < 0)
+ } else if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
+}
#else
{
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
new file mode 100755
index 0000000..1d9e82a
--- /dev/null
+++ b/t/t0061-run-command.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Ilari Liusvaara
+#
+
+test_description='Test run command'
+
+. ./test-lib.sh
+
+test_expect_success "reporting ENOENT" \
+"test-run-command 1"
+
+test_done
diff --git a/test-run-command.c b/test-run-command.c
new file mode 100644
index 0000000..6297785
--- /dev/null
+++ b/test-run-command.c
@@ -0,0 +1,35 @@
+/*
+ * test-run-command.c: test run command API.
+ *
+ * (C) 2009 Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "git-compat-util.h"
+#include "run-command.h"
+#include <string.h>
+#include <errno.h>
+
+int main(int argc, char **argv)
+{
+ char* procs[2];
+ struct child_process proc;
+ memset(&proc, 0, sizeof(proc));
+
+ if(argc < 2)
+ return 1;
+
+ if (argv[1][1] == '1')
+ procs[0] = "does-not-exist-62896869286";
+ procs[1] = NULL;
+ proc.argv = (const char **)procs;
+
+ if (!run_command(&proc))
+ return 1;
+ if (errno != ENOENT)
+ return 1;
+ return 0;
+}
--
1.6.6.3.gaa2e1
^ permalink raw reply related
* Re: [Updated PATCH 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-31 10:48 UTC (permalink / raw)
To: Tarmigan; +Cc: git
In-Reply-To: <905315640912302126n1848c99cre0f9caa644041fad@mail.gmail.com>
On Thu, Dec 31, 2009 at 12:26:48AM -0500, Tarmigan wrote:
> On Wed, Dec 30, 2009 at 5:52 AM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
>
> I was testing pu and 'git diff' and 'git log' would hang forever.
V3 just sent to list. Should fix this issue.
-Ilari
^ permalink raw reply
* Re: Need some help with git rebase
From: Wincent Colaiuta @ 2009-12-31 11:06 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <7fce93be0912301502r77152c52sbccf762fb6c44610@mail.gmail.com>
El 31/12/2009, a las 00:02, Sylvain Rabot escribió:
> In fact I want to backport the commits of the feature branch into
> 12.72.1.
>
> I used git rebase because the drawings of the man page looked like
> that I
> wanted to do and it does except for the part it resets the head of my
> feature branch.
>
> But as you said the good behavior would be to cherry pick each
> commit of the
> feature branch and apply them into 12.72.1, right ?
Well rebasing is just a convenient way of cherry-picking a bunch of
commits, so it's probably the right tool for the job.
But as you've seen, it has the effect of "moving" or "transplanting"
the feature branch (replacing the old feature HEAD). If you really
want the original feature branch HEAD to continue existing after the
rebase you'll need to take some specific action to preserve it
beforehand (creating a temporary branch before doing the rebase like
Peter Baumann suggested) or restore it afterwards (using "git branch"
like I suggested).
But before you actually do that, I'd make sure that you actually have
a valid reason for keeping that branch around. Maybe wanting to
"backport" those commits onto various different branches might be a
valid reason. But it's worth thinking through because Git gives you
various tools for supporting different workflows (merging, rebasing,
cherry-picking) and they each have their use cases.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] bash completion: factor submodules into dirty state
From: Thomas Rast @ 2009-12-31 11:48 UTC (permalink / raw)
To: git; +Cc: Johan Herland, Kevin Ballard, Shawn O. Pearce
In-Reply-To: <200912310240.07741.johan@herland.net>
In the implementation of GIT_PS1_SHOWDIRTYSTATE in 738a94a (bash:
offer to show (un)staged changes, 2009-02-03), I cut&pasted the
git-diff invocations from dirty-worktree checks elsewhere, carrying
along the --ignore-submodules option.
As pointed out by Kevin Ballard, this doesn't really make sense: to
the _user_, a changed submodule counts towards uncommitted changes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Johan Herland wrote:
> On Wednesday 30 December 2009, Kevin Ballard wrote:
> > Why does the __git_ps1 function in git-completion.bash explicitly ignore
> > submodules when showing the GIT_PS1_SHOWDIRTYSTATE status? The most
> > common issue with my current repository is not realizing when submodules
> > need to be updated because I blindly trust my prompt to tell me when I
> > have dirty state.
>
> According to git blame, it has been there since GIT_PS1_SHOWDIRTYSTATE was
> introduced in 738a94a... by Thomas Rast (CCed), but the commit message does
> not say why submodules are explicitly ignored.
>
> FWIW, I agree with Kevin, and would like changed submodules to be included
> in the status.
No good reason; I really do remember cut&pasting the checks, though
I'm not sure from where.
I don't really use submodules, so I'll just trust your judgements that
it's better to factor them into the status.
contrib/completion/git-completion.bash | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c65462c..a455fe8 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -142,11 +142,9 @@ __git_ps1 ()
elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --ignore-submodules \
- --quiet --exit-code || w="*"
+ git diff --no-ext-diff --quiet --exit-code || w="*"
if git rev-parse --quiet --verify HEAD >/dev/null; then
- git diff-index --cached --quiet \
- --ignore-submodules HEAD -- || i="+"
+ git diff-index --cached --quiet HEAD -- || i="+"
else
i="#"
fi
--
1.6.6.337.g4932e
^ permalink raw reply related
* Re: [msysGit] Problem with apply
From: Erik Faye-Lund @ 2009-12-31 12:49 UTC (permalink / raw)
To: richardpreen; +Cc: msysgit, Git Mailing List
In-Reply-To: <SNT131-ds16B1679EFC8F74B62D4630C4780@phx.gbl>
This isn't a Windows specific question, and would be better for the
main git mailing list. I'm CC'ing it in hope that someone there knows
the answer.
On Thu, Dec 31, 2009 at 1:26 PM, <richardpreen@hotmail.com> wrote:
> I'm trying to use git to create a binary diff of two files and then apply
> the diff to the first file in an attempt to make both files the same (just
> testing the concept);
>
> git diff --binary --no-index original\t1.ppt modified\t1.ppt >
> original\my.diff
> cd original
> git apply my.diff
>
> This is giving me the following error message;
> fatal: git diff header lacks filename information (line 3)
>
> Any suggestions as to where I've gone wrong?
> Thanks.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"
From: public_vi @ 2009-12-31 13:32 UTC (permalink / raw)
To: git; +Cc: public_vi
From: Vitaly _Vi Shukela <public_vi@tut.by>
Signed-off-by: Vitaly _Vi Shukela <public_vi@tut.by>
---
git-gui/git-gui.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 14b92ba..28270ad 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2509,12 +2509,14 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
[list .mbar.commit entryconf [.mbar.commit index last] -state]
.mbar.commit add command -label [mc "Unstage From Commit"] \
- -command do_unstage_selection
+ -command do_unstage_selection \
+ -accelerator $M1T-U
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
.mbar.commit add command -label [mc "Revert Changes"] \
- -command do_revert_selection
+ -command do_revert_selection \
+ -accelerator $M1T-J
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
@@ -3254,6 +3256,10 @@ unset gm
bind $ui_comm <$M1B-Key-Return> {do_commit;break}
bind $ui_comm <$M1B-Key-t> {do_add_selection;break}
bind $ui_comm <$M1B-Key-T> {do_add_selection;break}
+bind $ui_comm <$M1B-Key-u> {do_unstage_selection;break}
+bind $ui_comm <$M1B-Key-U> {do_unstage_selection;break}
+bind $ui_comm <$M1B-Key-j> {do_revert_selection;break}
+bind $ui_comm <$M1B-Key-J> {do_revert_selection;break}
bind $ui_comm <$M1B-Key-i> {do_add_all;break}
bind $ui_comm <$M1B-Key-I> {do_add_all;break}
bind $ui_comm <$M1B-Key-x> {tk_textCut %W;break}
--
1.6.5.6
^ permalink raw reply related
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Johannes Sixt @ 2009-12-31 13:50 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <bdca99240912291649h1c727072q3b1e4099cab426df@mail.gmail.com>
Sebastian Schuberth schrieb:
> On Tue, Dec 29, 2009 at 22:09, Johannes Sixt <j6t@kdbg.org> wrote:
>
>>> MinGW: Use pid_t more consequently, introduce uid_t for greater
>>> compatibility
>> Why this? Compatibility with what? What's the problem with the status quo?
>
> I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit.
We have dos2unix. What's wrong with it?
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Johannes Schindelin @ 2009-12-31 14:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sebastian Schuberth, git
In-Reply-To: <4B3CAC2D.5050500@kdbg.org>
Hi,
On Thu, 31 Dec 2009, Johannes Sixt wrote:
> Sebastian Schuberth schrieb:
> > On Tue, Dec 29, 2009 at 22:09, Johannes Sixt <j6t@kdbg.org> wrote:
> >
> > > > MinGW: Use pid_t more consequently, introduce uid_t for greater
> > > > compatibility
> > > Why this? Compatibility with what? What's the problem with the status quo?
> >
> > I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit.
>
> We have dos2unix. What's wrong with it?
hd2u can handle mixed line endings, and it has a dry run mode IIUC.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Sebastian Schuberth @ 2009-12-31 14:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0912311511350.4985@pacific.mpi-cbg.de>
On Thu, Dec 31, 2009 at 15:12, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> > I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit.
>>
>> We have dos2unix. What's wrong with it?
>
> hd2u can handle mixed line endings, and it has a dry run mode IIUC.
Right. One of the best features over dos2unix IMHO is that hd2u can
detect line-endings (and any problems like mixed / stray line-endings)
without actually modifying any files. This makes it a very nice tool
to detect any line-ending issues in the working tree of cross-platform
projects due to wrong autocrlf configurations.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Johannes Schindelin @ 2009-12-31 14:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sebastian Schuberth, git
In-Reply-To: <alpine.DEB.1.00.0912311511350.4985@pacific.mpi-cbg.de>
Hi,
On Thu, 31 Dec 2009, Johannes Schindelin wrote:
> On Thu, 31 Dec 2009, Johannes Sixt wrote:
>
> > Sebastian Schuberth schrieb:
> > > On Tue, Dec 29, 2009 at 22:09, Johannes Sixt <j6t@kdbg.org> wrote:
> > >
> > > > > MinGW: Use pid_t more consequently, introduce uid_t for greater
> > > > > compatibility
> > > > Why this? Compatibility with what? What's the problem with the
> > > > status quo?
> > >
> > > I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit.
> >
> > We have dos2unix. What's wrong with it?
>
> hd2u can handle mixed line endings, and it has a dry run mode IIUC.
Having said that, I strongly feel this issue is over-discussed. We'll
just carry the necessary patches in 4msysgit.git and you can do what you
want.
Ciao,
Dscho
^ permalink raw reply
* Re: [Updated PATCH 1/2] Report exec errors from run-command
From: Tarmigan @ 2009-12-31 14:44 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091231104835.GA18848@Knoppix>
On Thu, Dec 31, 2009 at 5:48 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Thu, Dec 31, 2009 at 12:26:48AM -0500, Tarmigan wrote:
>> On Wed, Dec 30, 2009 at 5:52 AM, Ilari Liusvaara
>> <ilari.liusvaara@elisanet.fi> wrote:
>>
>> I was testing pu and 'git diff' and 'git log' would hang forever.
>
> V3 just sent to list. Should fix this issue.
Yep, that fixed it.
Thanks,
Tarmigan
^ permalink raw reply
* Re: [PATCH v2] cvsserver: make the output of 'update' more compatible with cvs.
From: Martin Langhoff @ 2009-12-31 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Sergei Organov, git
In-Reply-To: <7vfx6rzlkg.fsf@alter.siamese.dyndns.org>
On Thu, Dec 31, 2009 at 7:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Well, since I don't use cvsserver myself, but this v2 was done with
> improvements based on some review suggestions, I was waiting for a
> response or two from people who know better and care more about cvs server
> emulation than me, which unfortunately didn't happen.
Looks good to me -- good to get it into pu. While I continue to use
git extensively, I don't use cvsserver anymore, nor work with people
that do. Might have reason to revisit cvsserver in the near future
though, to help Moodle transition to git.
That transition will bring a few top-posters and Eclipse lovers to the
list. Looking past such details, they are fine people who may need a
little bit of git-newbie help ;-)
happy new year,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2009-12-31 15:44 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1262170338-11574-3-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara schrieb:
> @@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
> helper->out = -1;
> helper->err = 0;
> helper->argv = xcalloc(4, sizeof(*helper->argv));
> - strbuf_addf(&buf, "remote-%s", data->name);
> + strbuf_addf(&buf, "git-remote-%s", data->name);
> helper->argv[0] = strbuf_detach(&buf, NULL);
> helper->argv[1] = transport->remote->name;
> helper->argv[2] = transport->url;
> - helper->git_cmd = 1;
> - if (start_command(helper))
> - die("Unable to run helper: git %s", helper->argv[0]);
> + helper->git_cmd = 0;
> + if (start_command(helper)) {
> + if (errno == ENOENT)
> + die("Unable to find remote helper for \"%s\"",
> + data->name);
You should set helper->silent_exec_failure = 1 when you give your own
error message for the ENOENT case.
BTW, which error message do you see without your change in this case? You
only say "pretty much useless", but do not give an example.
> + else
> + die("Unable to run helper %s: %s", helper->argv[0],
> + strerror(errno));
You shouldn't write an error message here because start_command has
already reported the error.
-- Hannes
^ permalink raw reply
* Re: [updated patch v2 1/2] Report exec errors from run-command
From: Johannes Sixt @ 2009-12-31 16:22 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1262256488-22985-2-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara schrieb:
> +static inline void force_close(int fd)
> +{
> + int err = 0;
> + /*
> + * Retry EINTRs undefinitely, exit on EBADF immediately, other
> + * errors retry only up to three times (even if pipe close
> + * shouldn't cause other errors, but you never know with
> + * what broken systems may return on closed file descriptor).
> + * consequences of failure to close pipe here may include
> + * deadlocking.
> + */
> + while (close(fd) < 0 && errno != EBADF && err < 3)
> + if(errno != EINTR)
> + err++;
What's the point to iterate on all errors except EBADF? If the close()
fails once, it will fail again.
> + /*
> + * Clean up the process that did the failed execution
> + * so no zombies remain.
> + */
> +wait_again:
> + r = waitpid(cmd->pid, &ret, 0);
> + if (r < 0 && errno != ECHILD)
> + goto wait_again;
You really should iterate only on well-known errors. What's wrong with
while (waitpid(pid, &status, 0) < 0 && errno == EINTR)
; /* nothing */
similar to wait_or_whine()'s call to waitpid() and to avoid goto.
> +int main(int argc, char **argv)
> +{
> + char* procs[2];
> + struct child_process proc;
> + memset(&proc, 0, sizeof(proc));
> +
> + if(argc < 2)
> + return 1;
> +
> + if (argv[1][1] == '1')
> + procs[0] = "does-not-exist-62896869286";
> + procs[1] = NULL;
> + proc.argv = (const char **)procs;
> +
> + if (!run_command(&proc))
> + return 1;
> + if (errno != ENOENT)
> + return 1;
> + return 0;
> +}
This test is not specific enough: It would pass even without your change
to start_command(), because finish_command() detects the ENOENT case. You
really want to test that you see ENOENT after start_command() (i.e.,
before finish_command()).
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2009-12-31 16:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091230105536.GC22959@coredump.intra.peff.net>
Jeff King schrieb:
> If there are no metacharacters in the program to be run, we
> can just skip running the shell entirely and directly exec
> the program.
>
> The metacharacter test is pulled verbatim from
> launch_editor, which already implements this optimization.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Something inside me feels wrong with a catch-known-metacharacter test
> instead of an allow-known-good check. But this is the same test we have
> been using with launch_editor for some time, so I decided not to mess
> with it.
The git version that msysgit ships (and the one that I use on Windows) has
this sequence in pager.c:
static const char *pager_argv[] = { "sh", "-c", NULL, NULL };
...
pager_process.argv = &pager_argv[2];
pager_process.in = -1;
if (start_command(&pager_process)) {
pager_process.argv = pager_argv;
pager_process.in = -1;
if (start_command(&pager_process))
return;
}
to help people set
PAGER=C:\Program Files\cygwin\bin\less
That is, we first try to run the program without the shell, then retry
wrapped in sh -c.
Wouldn't it be possible to do the same here, assuming that we don't have
programs such as "editor -f" in the path?
It does assume that we are able to detect execvp failure due to ENOENT
which is currently proposed elsewhere by Ilari Liusvaara (and which is
already possible on Windows).
-- Hannes
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 16:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B3CC6E5.7090404@kdbg.org>
On Thu, Dec 31, 2009 at 04:44:37PM +0100, Johannes Sixt wrote:
> Ilari Liusvaara schrieb:
> >@@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
>
> You should set helper->silent_exec_failure = 1 when you give your
> own error message for the ENOENT case.
Ah yeah, might matter for Win32.
> BTW, which error message do you see without your change in this
> case? You only say "pretty much useless", but do not give an
> example.
git: 'remote-foo' is not a git-command. See 'git --help'.
And as first line of output, such thing is utterly confusing.
> >+ else
> >+ die("Unable to run helper %s: %s", helper->argv[0],
> >+ strerror(errno));
>
> You shouldn't write an error message here because start_command has
> already reported the error.
Its not printed on Unix.
-Ilari
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2009-12-31 17:48 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091231165904.GA24243@Knoppix>
Ilari Liusvaara schrieb:
> On Thu, Dec 31, 2009 at 04:44:37PM +0100, Johannes Sixt wrote:
>> Ilari Liusvaara schrieb:
>>> @@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
>> You should set helper->silent_exec_failure = 1 when you give your
>> own error message for the ENOENT case.
>
> Ah yeah, might matter for Win32.
Actually, no. I forgot to mention that your modified start_command should
treat ENOENT differently by looking at cmd->silent_exec_failure. But see
below.
>> BTW, which error message do you see without your change in this
>> case? You only say "pretty much useless", but do not give an
>> example.
>
> git: 'remote-foo' is not a git-command. See 'git --help'.
>
> And as first line of output, such thing is utterly confusing.
And you change this by treating the helper command not as a git command,
but as a normal command that happens to start with 'git-'. Whether this
interpretation is suitable for the transport layer, I do not want to
decide and I will certainly not object. :-)
An alternative solution would be to forward the silent_exec_failure flag
to exec_git_cmd() to unify the treatment of the error condition with the
non-git-command error path.
>>> + else
>>> + die("Unable to run helper %s: %s", helper->argv[0],
>>> + strerror(errno));
>> You shouldn't write an error message here because start_command has
>> already reported the error.
>
> Its not printed on Unix.
I see.
Documentation/technical/api-run-command.txt documents the error behavior.
There are three error cases:
1. system call failures
2. exec failure due to ENOENT
3. non-zero exit of the child and death through signal
Your patch makes all exec failures into category 1, but IMO, these are
actually category 3 (except for the ENOENT case).
In case 3, it is expected that the child process prints a suitable error
message. Therefore, you should start with merely replacing the unconditional
exit(127);
by
if (errno == ENOENT)
exit(127);
else
die_errno("Cannot exec %s", cmd->argv[0]);
And then you can think about how you support the ENOENT case better. My
proposal for this was to do the PATH lookup manually before the fork(),
and then the above conditional would melt down to simply:
die_errno("Cannot exec %s", cmd->argv[0]);
-- Hannes
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 18:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B3CE3D2.5010502@kdbg.org>
On Thu, Dec 31, 2009 at 06:48:02PM +0100, Johannes Sixt wrote:
> Ilari Liusvaara schrieb:
> >On Thu, Dec 31, 2009 at 04:44:37PM +0100, Johannes Sixt wrote:
> >>Ilari Liusvaara schrieb:
> And you change this by treating the helper command not as a git
> command, but as a normal command that happens to start with 'git-'.
> Whether this interpretation is suitable for the transport layer, I
> do not want to decide and I will certainly not object. :-)
The transport helpers are special: they shouldn't be built-in.
> An alternative solution would be to forward the silent_exec_failure
> flag to exec_git_cmd() to unify the treatment of the error condition
> with the non-git-command error path.
Won't work. The error in git command case would be noted in another memory
image. And passing that back would be nasty to say the least.
> In case 3, it is expected that the child process prints a suitable
> error message. Therefore, you should start with merely replacing the
> unconditional
>
> exit(127);
> by
> if (errno == ENOENT)
> exit(127);
> else
> die_errno("Cannot exec %s", cmd->argv[0]);
>
> And then you can think about how you support the ENOENT case better.
> My proposal for this was to do the PATH lookup manually before the
> fork(), and then the above conditional would melt down to simply:
>
> die_errno("Cannot exec %s", cmd->argv[0]);
>
The child process can't sanely print anything. Stderr would go to
who knows where. Parent process should have much better idea what to
do with errors.
-Ilari
^ permalink raw reply
* [updated patch v3 0/2] Imporve remote helpers exec failure reporting
From: Ilari Liusvaara @ 2009-12-31 18:26 UTC (permalink / raw)
To: git
Changes from previous rounds are:
- Don't loop on unknown errors from close.
- Don't loop on unknown errors from waitpid.
- Set silent_exec_failure on remote helper exec.
- Fix the test to actually test what it is supposed to.
Ilari Liusvaara (2):
Report exec errors from run-command
Improve transport helper exec failure reporting
Makefile | 1 +
run-command.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++--
t/t0061-run-command.sh | 13 ++++++
test-run-command.c | 35 +++++++++++++++++
transport-helper.c | 14 +++++--
5 files changed, 152 insertions(+), 8 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
^ permalink raw reply
* [updated patch v3 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-31 18:26 UTC (permalink / raw)
To: git
In-Reply-To: <1262284003-1417-1-git-send-email-ilari.liusvaara@elisanet.fi>
Previously run-command was unable to report errors happening in exec
call. Change it to pass errno from failed exec to errno value at
return.
The errno value passing can be done by opening close-on-exec pipe and
piping the error code through in case of failure. In case of success,
close-on-exec closes the pipe on successful exec and parent process
gets end of file on read.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
Makefile | 1 +
run-command.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++--
t/t0061-run-command.sh | 13 ++++++
test-run-command.c | 35 +++++++++++++++++
4 files changed, 142 insertions(+), 4 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
diff --git a/Makefile b/Makefile
index 4a1e5bc..452ad50 100644
--- a/Makefile
+++ b/Makefile
@@ -1725,6 +1725,7 @@ TEST_PROGRAMS += test-parse-options$X
TEST_PROGRAMS += test-path-utils$X
TEST_PROGRAMS += test-sha1$X
TEST_PROGRAMS += test-sigchain$X
+TEST_PROGRAMS += test-run-command$X
all:: $(TEST_PROGRAMS)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..1086c6d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -15,6 +15,18 @@ static inline void dup_devnull(int to)
close(fd);
}
+static inline void force_close(int fd)
+{
+ /*
+ * The close is deemed success or failed in non-transient way if
+ * close() suceeds, returns EBADF or error other than EINTR or
+ * EAGAIN.
+ */
+ while (close(fd) < 0 && errno != EBADF)
+ if(errno != EINTR && errno != EAGAIN)
+ break;
+}
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -76,9 +88,62 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef WIN32
+{
+ int report_pipe[2] = {-1, -1};
+
+ if (pipe(report_pipe) < 0) {
+ report_pipe[0] = -1;
+ report_pipe[1] = -1;
+ warning("Can't open pipe for exec status report: %s\n",
+ strerror(errno));
+ }
+
fflush(NULL);
cmd->pid = fork();
- if (!cmd->pid) {
+ if (cmd->pid > 0) {
+ int r = 0, ret;
+ force_close(report_pipe[1]);
+read_again:
+ if (report_pipe[0] >= 0)
+ r = read(report_pipe[0], &ret, sizeof(ret));
+ if (r < 0 && (errno == EAGAIN || errno == EINTR ||
+ errno == EWOULDBLOCK))
+ goto read_again;
+ else if (r < 0)
+ warning("Can't read exec status report: %s\n",
+ strerror(errno));
+ else if (r == 0)
+ ;
+ else if (r < sizeof(ret)) {
+ warning("Received incomplete exec status report.\n");
+ errno = EBADMSG;
+ } else {
+ failed_errno = ret;
+ /*
+ * Clean up the process that did the failed execution
+ * so no zombies remain.
+ */
+ if(waitpid(cmd->pid, &ret, 0) < 0 && errno == EINTR)
+ /* Nothing. */ ;
+ cmd->pid = -1;
+ }
+ } else if (!cmd->pid) {
+ int r = 0;
+ int flags;
+ force_close(report_pipe[0]);
+
+ flags = fcntl(report_pipe[1], F_GETFD);
+ if (flags < 0)
+ r = -1;
+ flags |= FD_CLOEXEC;
+ r = (r || fcntl(report_pipe[1], F_SETFD, flags));
+ if (r) {
+ warning("Can't FD_CLOEXEC pipe for exec status "
+ "report: %s\n", strerror(errno));
+ force_close(report_pipe[1]);
+ report_pipe[1] = -1;
+ }
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -119,20 +184,44 @@ fail_pipe:
unsetenv(*cmd->env);
}
}
- if (cmd->preexec_cb)
+ if (cmd->preexec_cb) {
+ /*
+ * We don't know what pre-exec callbacks do, and they
+ * may do something that causes deadlock with exec
+ * reporting. The sole user of this hook seems to
+ * be pager, and it is run through shell, so one
+ * wouldn't get useful error from exec reporting
+ * and would get useful error from shell anyway. So
+ * just disable exec reporting for such comamnds.
+ */
+ force_close(report_pipe[1]);
+ report_pipe[1] = -1;
cmd->preexec_cb();
+ }
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
+ failed_errno = errno;
+
trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
strerror(errno));
+
+ r = 0;
+write_again:
+ if (report_pipe[1] >= 0)
+ r = write(report_pipe[1], &failed_errno,
+ sizeof(failed_errno));
+ if (r < 0 && (errno == EAGAIN || errno == EINTR ||
+ errno == EWOULDBLOCK))
+ goto write_again;
+
exit(127);
- }
- if (cmd->pid < 0)
+ } else if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
+}
#else
{
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
new file mode 100755
index 0000000..1d9e82a
--- /dev/null
+++ b/t/t0061-run-command.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Ilari Liusvaara
+#
+
+test_description='Test run command'
+
+. ./test-lib.sh
+
+test_expect_success "reporting ENOENT" \
+"test-run-command 1"
+
+test_done
diff --git a/test-run-command.c b/test-run-command.c
new file mode 100644
index 0000000..4716033
--- /dev/null
+++ b/test-run-command.c
@@ -0,0 +1,35 @@
+/*
+ * test-run-command.c: test run command API.
+ *
+ * (C) 2009 Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "git-compat-util.h"
+#include "run-command.h"
+#include <string.h>
+#include <errno.h>
+
+int main(int argc, char **argv)
+{
+ char* procs[2];
+ struct child_process proc;
+ memset(&proc, 0, sizeof(proc));
+
+ if(argc < 2)
+ return 1;
+
+ if (argv[1][0] == '1')
+ procs[0] = "does-not-exist-62896869286";
+ procs[1] = NULL;
+ proc.argv = (const char **)procs;
+
+ if (!start_command(&proc))
+ return 1;
+ if (argv[1][0] == '1' && errno == ENOENT)
+ return 0;
+ return 1;
+}
--
1.6.6.3.gaa2e1
^ permalink raw reply related
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