* Re: [PATCH v2 1/4] Documentation/git-merge: reword references to "remote" and "pull"
From: Thomas Rast @ 2010-01-10 12:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20100110041357.GF1083@progeny.tock>
Jonathan Nieder wrote:
> Thomas Rast wrote:
> > * Look at the diffs. 'git diff' will show a three-way diff,
> > - highlighting changes from both the HEAD and remote versions.
> > + highlighting changes from both the HEAD and their versions.
> >
> > * Look at the diffs on their own. 'git log --merge -p <path>'
>
> This is a bit awkward, since 'they' is playing two roles. Also,
> the context does not make it obvious what 'our' and 'their'
> versions are.
>
> Maybe:
>
> | * Look at the diffs. 'git diff' will show a three-way diff,
> | highlighting changes from both the HEAD and MERGE_HEAD
> | versions.
I like this idea, as it nicely assigns terminology to the "their"
side. We need to explain MERGE_HEAD (it's not in the manpage yet),
but that should fit in somewhere.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH 0/4] Detect exec errors in start_command early
From: Johannes Sixt @ 2010-01-10 13:04 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263044757-12560-2-git-send-email-ilari.liusvaara@elisanet.fi>
On Samstag, 9. Januar 2010, Ilari Liusvaara wrote:
> 6 files changed, 282 insertions(+), 13 deletions(-)
IMHO, you are going completely overboard with your patch.
You check every single possible and unlikely error condition in the new code
that you introde, but ignore that there are quite a number of calls in the
existing code whose error conditions go checked.
And as a result, you "only" report errno values of some calls, and ignore that
there is at least one potential die() call hidden in execv_git_cmd(). IOW,
your code is not a catch-all and only an isolated solution.
I hope I can do better.
I developed this series on top of il/vcs-helper. But patches 1-3/4 are
actually an independent topic and also suitable to be merged into
jk/run-command-use-shell to implement improved DWIM whether a shell is
needed.
Patch 4/4 is to address your problem of weak error reporting with transport
helpers. I think I understand now what your problem is -- namely that
previously no error was reported if a transport helper program did not exist.
The reason for the missing error message is IMO a design weakness in the
protocol: It requires that the parent talks first - and by talking to an
early-died child process it dies from SIGPIPE. I experimented with
signal(SIGPIPE, SIG_IGN) to get around this, but it didn't work (the SIGPIPE
arrived anyway).
Anyway, patch 4/4 goes on top of il/vcs-helper after merging the topic
consisting of 1-3/4.
Ilari Liusvaara (1):
Improve error message when a transport helper was not found
Johannes Sixt (3):
start_command: report child process setup errors to the parent's
stderr
run-command: move wait_or_whine earlier
start_command: detect execvp failures early
Makefile | 1 +
run-command.c | 177
+++++++++++++++++++++++++++++++++++-------------
t/t0061-run-command.sh | 14 ++++
test-run-command.c | 35 ++++++++++
transport-helper.c | 14 +++-
5 files changed, 191 insertions(+), 50 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
^ permalink raw reply
* [PATCH 1/4] start_command: report child process setup errors to the parent's stderr
From: Johannes Sixt @ 2010-01-10 13:07 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <201001101404.22258.j6t@kdbg.org>
When the child process's environment is set up in start_command(), error
messages were written to wherever the parent redirected the child's stderr
channel. However, even if the parent redirected the child's stderr, errors
during this setup process, including the exec itself, are usually an
indication of a problem in the parent's environment. Therefore, the error
messages should go to the parent's stderr.
Redirection of the child's error messages is usually only used to redirect
hook error messages during client-server exchanges. In these cases, hook
setup errors could be regarded as information leak.
This patch makes a copy of stderr if necessary and uses a special
die routine that is used for all die() calls in the child that sends the
errors messages to the parent's stderr.
The trace call that reported a failed execvp is removed (because it writes
to stderr) and replaced by die_errno() with special treatment of ENOENT.
The improvement in the error message can be seen with this sequence:
mkdir .git/hooks/pre-commit
git commit
Previously, the error message was
error: cannot run .git/hooks/pre-commit: No such file or directory
and now it is
fatal: cannot exec '.git/hooks/pre-commit': Permission denied
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
This should address your concern that "errors go to who-knows-where",
that I meanwhile share with you.
run-command.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..02c7bfb 100644
--- a/run-command.c
+++ b/run-command.c
@@ -15,6 +15,30 @@ static inline void dup_devnull(int to)
close(fd);
}
+#ifndef WIN32
+static int child_err = 2;
+
+static NORETURN void die_child(const char *err, va_list params)
+{
+ char msg[4096];
+ int len = vsnprintf(msg, sizeof(msg), err, params);
+ if (len > sizeof(msg))
+ len = sizeof(msg);
+
+ write(child_err, "fatal: ", 7);
+ write(child_err, msg, len);
+ write(child_err, "\n", 1);
+ exit(128);
+}
+
+static inline void set_cloexec(int fd)
+{
+ int flags = fcntl(fd, F_GETFD);
+ if (flags >= 0)
+ fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+#endif
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -79,6 +103,17 @@ fail_pipe:
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
+ /*
+ * Redirect the channel to write syscall error messages to
+ * before redirecting the process's stderr so that all die()
+ * in subsequent call paths use the parent's stderr.
+ */
+ if (cmd->no_stderr || need_err) {
+ child_err = dup(2);
+ set_cloexec(child_err);
+ }
+ set_die_routine(die_child);
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -126,9 +161,14 @@ fail_pipe:
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
- strerror(errno));
- exit(127);
+ /*
+ * Do not check for cmd->silent_exec_failure; the parent
+ * process will check it when it sees this exit code.
+ */
+ if (errno == ENOENT)
+ exit(127);
+ else
+ die_errno("cannot exec '%s'", cmd->argv[0]);
}
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* [PATCH 2/4] run-command: move wait_or_whine earlier
From: Johannes Sixt @ 2010-01-10 13:08 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <201001101404.22258.j6t@kdbg.org>
We want to reuse it from start_command.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
run-command.c | 84 ++++++++++++++++++++++++++++----------------------------
1 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/run-command.c b/run-command.c
index 02c7bfb..dccac37 100644
--- a/run-command.c
+++ b/run-command.c
@@ -39,6 +39,48 @@ static inline void set_cloexec(int fd)
}
#endif
+static int wait_or_whine(pid_t pid, const char *argv0, int silent_exec_failure)
+{
+ int status, code = -1;
+ pid_t waiting;
+ int failed_errno = 0;
+
+ while ((waiting = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
+ ; /* nothing */
+
+ if (waiting < 0) {
+ failed_errno = errno;
+ error("waitpid for %s failed: %s", argv0, strerror(errno));
+ } else if (waiting != pid) {
+ error("waitpid is confused (%s)", argv0);
+ } else if (WIFSIGNALED(status)) {
+ code = WTERMSIG(status);
+ error("%s died of signal %d", argv0, code);
+ /*
+ * This return value is chosen so that code & 0xff
+ * mimics the exit code that a POSIX shell would report for
+ * a program that died from this signal.
+ */
+ code -= 128;
+ } else if (WIFEXITED(status)) {
+ code = WEXITSTATUS(status);
+ /*
+ * Convert special exit code when execvp failed.
+ */
+ if (code == 127) {
+ code = -1;
+ failed_errno = ENOENT;
+ if (!silent_exec_failure)
+ error("cannot run %s: %s", argv0,
+ strerror(ENOENT));
+ }
+ } else {
+ error("waitpid is confused (%s)", argv0);
+ }
+ errno = failed_errno;
+ return code;
+}
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -272,48 +314,6 @@ fail_pipe:
return 0;
}
-static int wait_or_whine(pid_t pid, const char *argv0, int silent_exec_failure)
-{
- int status, code = -1;
- pid_t waiting;
- int failed_errno = 0;
-
- while ((waiting = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
- ; /* nothing */
-
- if (waiting < 0) {
- failed_errno = errno;
- error("waitpid for %s failed: %s", argv0, strerror(errno));
- } else if (waiting != pid) {
- error("waitpid is confused (%s)", argv0);
- } else if (WIFSIGNALED(status)) {
- code = WTERMSIG(status);
- error("%s died of signal %d", argv0, code);
- /*
- * This return value is chosen so that code & 0xff
- * mimics the exit code that a POSIX shell would report for
- * a program that died from this signal.
- */
- code -= 128;
- } else if (WIFEXITED(status)) {
- code = WEXITSTATUS(status);
- /*
- * Convert special exit code when execvp failed.
- */
- if (code == 127) {
- code = -1;
- failed_errno = ENOENT;
- if (!silent_exec_failure)
- error("cannot run %s: %s", argv0,
- strerror(ENOENT));
- }
- } else {
- error("waitpid is confused (%s)", argv0);
- }
- errno = failed_errno;
- return code;
-}
-
int finish_command(struct child_process *cmd)
{
return wait_or_whine(cmd->pid, cmd->argv[0], cmd->silent_exec_failure);
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* [PATCH 3/4] start_command: detect execvp failures early
From: Johannes Sixt @ 2010-01-10 13:11 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <201001101404.22258.j6t@kdbg.org>
Previously, failures during execvp could be detected only by
finish_command. However, in some situations it is beneficial for the
parent process to know earlier that the child process will not run.
The idea to use a pipe to signal failures to the parent process and
the test case were lifted from patches by Ilari Liusvaara.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Makefile | 1 +
run-command.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
t/t0061-run-command.sh | 14 ++++++++++++++
test-run-command.c | 35 +++++++++++++++++++++++++++++++++++
4 files changed, 96 insertions(+), 1 deletions(-)
create mode 100755 t/t0061-run-command.sh
create mode 100644 test-run-command.c
diff --git a/Makefile b/Makefile
index 87fc7ff..22c1546 100644
--- a/Makefile
+++ b/Makefile
@@ -1785,6 +1785,7 @@ TEST_PROGRAMS += test-genrandom$X
TEST_PROGRAMS += test-match-trees$X
TEST_PROGRAMS += test-parse-options$X
TEST_PROGRAMS += test-path-utils$X
+TEST_PROGRAMS += test-run-command$X
TEST_PROGRAMS += test-sha1$X
TEST_PROGRAMS += test-sigchain$X
diff --git a/run-command.c b/run-command.c
index dccac37..473b7f8 100644
--- a/run-command.c
+++ b/run-command.c
@@ -17,6 +17,12 @@ static inline void dup_devnull(int to)
#ifndef WIN32
static int child_err = 2;
+static int child_notifier = -1;
+
+static void notify_parent()
+{
+ write(child_notifier, "", 1);
+}
static NORETURN void die_child(const char *err, va_list params)
{
@@ -142,6 +148,11 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef WIN32
+{
+ int notify_pipe[2];
+ if (pipe(notify_pipe))
+ notify_pipe[0] = notify_pipe[1] = -1;
+
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
@@ -156,6 +167,11 @@ fail_pipe:
}
set_die_routine(die_child);
+ close(notify_pipe[0]);
+ set_cloexec(notify_pipe[1]);
+ child_notifier = notify_pipe[1];
+ atexit(notify_parent);
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -196,8 +212,16 @@ fail_pipe:
unsetenv(*cmd->env);
}
}
- if (cmd->preexec_cb)
+ if (cmd->preexec_cb) {
+ /*
+ * We cannot predict what the pre-exec callback does.
+ * Forgo parent notification.
+ */
+ close(child_notifier);
+ child_notifier = -1;
+
cmd->preexec_cb();
+ }
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
@@ -215,6 +239,27 @@ fail_pipe:
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
+
+ /*
+ * Wait for child's execvp. If the execvp succeeds (or if fork()
+ * failed), EOF is seen immediately by the parent. Otherwise, the
+ * child process sends a single byte.
+ * Note that use of this infrastructure is completely advisory,
+ * therefore, we keep error checks minimal.
+ */
+ close(notify_pipe[1]);
+ if (read(notify_pipe[0], ¬ify_pipe[1], 1) == 1) {
+ /*
+ * At this point we know that fork() succeeded, but execvp()
+ * failed. Errors have been reported to our stderr.
+ */
+ wait_or_whine(cmd->pid, cmd->argv[0],
+ cmd->silent_exec_failure);
+ failed_errno = errno;
+ cmd->pid = -1;
+ }
+ close(notify_pipe[0]);
+}
#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..10b26e4
--- /dev/null
+++ b/t/t0061-run-command.sh
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Ilari Liusvaara
+#
+
+test_description='Test run command'
+
+. ./test-lib.sh
+
+test_expect_success 'start_command reports ENOENT' '
+ test-run-command start-command-ENOENT ./does-not-exist
+'
+
+test_done
diff --git a/test-run-command.c b/test-run-command.c
new file mode 100644
index 0000000..a1d5306
--- /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)
+{
+ struct child_process proc;
+
+ memset(&proc, 0, sizeof(proc));
+
+ if(argc < 3)
+ return 1;
+ proc.argv = (const char **)argv+2;
+
+ if (!strcmp(argv[1], "start-command-ENOENT")) {
+ if (start_command(&proc) < 0 && errno == ENOENT)
+ return 0;
+ fprintf(stderr, "FAIL %s\n", argv[1]);
+ return 1;
+ }
+
+ fprintf(stderr, "check usage\n");
+ return 1;
+}
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* [PATCH 4/4] Improve error message when a transport helper was not found
From: Johannes Sixt @ 2010-01-10 13:18 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <201001101404.22258.j6t@kdbg.org>
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Perviously, the error message was:
git: 'remote-foo' is not a git-command. See 'git --help'.
By not treating the transport helper as a git command, a more suitable
error is reported:
fatal: Unable to find remote helper for 'foo'
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
While I agree mostly with the implementation of your patch, the justification
was completely off, and I think it was because you did not notice that the
parent process died from SIGPIPE. When patches 1-3/4 are applied, the
parent does not die from SIGPIPE anymore, and the issue is now only minor
(an unsuitable error message instead of no error message). Therefore,
I rewrote the commit message to tone it down.
-- Hannes
transport-helper.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 6ece0d9..d1bc3af 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -102,6 +102,7 @@ static struct child_process *get_helper(struct transport *transport)
int refspec_nr = 0;
int refspec_alloc = 0;
int duped;
+ int code;
if (data->helper)
return data->helper;
@@ -111,13 +112,18 @@ 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] = remove_ext_force(transport->url);
- helper->git_cmd = 1;
- if (start_command(helper))
- die("Unable to run helper: git %s", helper->argv[0]);
+ helper->git_cmd = 0;
+ helper->silent_exec_failure = 1;
+ code = start_command(helper);
+ if (code < 0 && errno == ENOENT)
+ die("Unable to find remote helper for '%s'", data->name);
+ else
+ exit(code);
+
data->helper = helper;
data->no_disconnect_req = 0;
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* Re: [PATCH] git-p4: Fix empty submit template when editor fires up
From: Kevin Leung @ 2010-01-10 13:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Simon Hausmann, gitster
In-Reply-To: <20100110111440.GB19612@progeny.tock>
On Sun, Jan 10, 2010 at 7:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jonathan Nieder wrote:
>> Kevin Leung wrote:
>> > read_pipe() returns "\n". We need to remove it before passing it
>> > to system().
>> >
>> > Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
>>
>> If I understand correctly, this is a cosmetic change:
>
> ... and of course I didn't the subject. Sorry about that. Thanks
> for cleaning up my mess.
>
> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
>
>> What is the rationale for the rewritten system() line? I would have
>> understood a change to
>>
>> os.spawnlp("sh", "-c", editor + " \"$@\"", fileName)
>
> I am still curious about this, though it is not so important.
You are right, the system() line is not so important. I can revert
that line of change.
Kevin
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Erik Faye-Lund @ 2010-01-10 17:06 UTC (permalink / raw)
To: Johannes Sixt, Linus Torvalds, Stephen R. van den Berg
Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e1001081649h5cb767d5t880110d923418300@mail.gmail.com>
On Sat, Jan 9, 2010 at 1:49 AM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Wed, Dec 2, 2009 at 8:27 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote:
>>> On Fri, Nov 27, 2009 at 8:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>>> > "relatively small chance of stuff blowing up"? The docs of
>>> > TerminateThread: "... the kernel32 state for the thread's process could
>>> > be inconsistent." That's scary if we are talking about a process that
>>> > should run for days or weeks without interruption.
>>>
>>> I think there's a misunderstanding here. I thought your suggestion was
>>> to simply call die(), which would take down the main process. After
>>> reading this explanation, I think you're talking about giving an error
>>> and rejecting the connection instead. Which makes more sense than to
>>> risk crashing the main-process, indeed.
>>
>> Just rejecting a connection is certainly the simplest do to keep the daemon
>> process alive. But the server can be DoS-ed from a single source IP.
>>
>> Currently git-daemon can only be DDoS-ed because there is a maximum number of
>> connections, which are not closed if all of them originate from different
>> IPs.
>>
>
> After some testing I've found that git-daemon can very much be DoS-ed
> from a single IP in it's current form. This is for two reasons:
> 1) The clever xcalloc + memcmp trick has a fault; the port for each
> connection is different, so there will never be a match. I have a
> patch[1] for this that I plan to send out soon.
> 2) Even with this patch the effect of the DoS-protection is kind of
> limited. This is because it's a child process of the fork()'d process
> again that does all the heavy lifting, and kill(pid, SIGHUP) doesn't
> kill child processes. So, the connection gets to continue the action
> until upload-pack (or whatever the current command is) finish. This
> might be quite lengthy.
>
Actually, this isn't the end of the story, there's an additional issue
that happens if 1) doesn't:
In commit 02d57da (Be slightly smarter about git-daemon client
shutdown), Linus adds the following hunk:
@@ -26,6 +26,12 @@ static int upload(char *dir, int dirlen)
access("HEAD", R_OK))
return -1;
+ /*
+ * We'll ignore SIGTERM from now on, we have a
+ * good client.
+ */
+ signal(SIGTERM, SIG_IGN);
+
/* git-upload-pack only ever reads stuff, so this is safe */
execlp("git-upload-pack", "git-upload-pack", ".", NULL);
return -1;
This is fine, because he also makes sure to first try to kill with
SIGTERM, and then fall back to SIGKILL if that failed. However,
Stephen later adds commit 3bd62c2 ("git-daemon: rewrite kindergarden,
new option --max-connections"), and here he leaves the hunk quoted
above, but removes the SIGKILL code-path. The consequence is that the
forked process doesn't die at all any more.
IMO, Stephen did kind-of right in removing the SIGKILL code-path,
since we don't kill just a random child anymore. But leaving the
SIGTERM-ignoring on looks like a bug to me.
Now, if that was fixed alone, I think we'd suffer even worse, due to
2) - since the child processes aren't killed, we'd end up allowing
more connections than the value of max_connections - upload-pack would
gladly continue in the background. Some quick testing showed that the
following patch solved the issue for me. I'm not very happy about it,
since I'm working on porting the code to Windows, and we don't have
the same process-group concept on windows... Oh well.
diff --git a/daemon.c b/daemon.c
index 918e560..bc6874c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -291,12 +291,6 @@ static int run_service(char *dir, struct
daemon_service *service)
return -1;
}
- /*
- * We'll ignore SIGTERM from now on, we have a
- * good client.
- */
- signal(SIGTERM, SIG_IGN);
-
return service->fn();
}
@@ -633,7 +627,8 @@ static void kill_some_child(void)
for (; (next = blanket->next); blanket = next)
if (!addrcmp(&blanket->address, &next->address)) {
- kill(blanket->pid, SIGTERM);
+ kill(-blanket->pid, SIGTERM);
break;
}
}
@@ -676,7 +671,8 @@ static void handle(int incoming, struct sockaddr
*addr, int addrlen)
add_child(pid, addr, addrlen);
return;
- }
+ } else
+ setpgid(0, 0);
dup2(incoming, 0);
dup2(incoming, 1);
--
Erik "kusma" Faye-Lund
^ permalink raw reply related
* Саня *** Ti-3 *** Бурим добавил Вас в друзья на сайте ВКонтакте.ру
From: ВКонтакте.ру @ 2010-01-10 18:08 UTC (permalink / raw)
To: Здравствуйте
Здравствуйте,
Саня *** Ti-3 *** Бурим добавил Вас в друзья на сайте ВКонтакте.ру
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: pBXAfZTw
ВКонтакте.ру - сайт, который ежедневно позволяет десяткам миллионов людей находить старых друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, пройдите по ссылке:
http://vk.com/login.php?regemail=git@vger.kernel.org#pBXAfZTw
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
С уважением,
Администрация ВКонтакте.ру
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #03; Sun, 10)
From: Junio C Hamano @ 2010-01-10 19:55 UTC (permalink / raw)
To: git
What's cooking in git.git (Jan 2010, #03; Sun, 10)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
--------------------------------------------------
[Graduated to "master"]
* tr/http-updates (2009-12-28) 4 commits
(merged to 'next' on 2010-01-02 at cf25698)
+ Remove http.authAny
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
(merged to 'next' on 2010-01-02 at 190d63b)
+ reset: unbreak hard resets with GIT_WORK_TREE
* jk/push-to-delete (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9ee293b)
+ builtin-push: add --delete as syntactic sugar for :foo
* mm/config-path (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9c0e81a)
+ builtin-config: add --path option doing ~ and ~user expansion.
* pm/cvs-environ (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 4c22932)
+ CVS Server: Support reading base and roots from environment
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at b785974)
+ bash completion: factor submodules into dirty state
* bg/maint-remote-update-default (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at 113009e)
+ Fix "git remote update" with remotes.defalt set
* mm/diag-path-in-treeish (2009-12-07) 1 commit
(merged to 'next' on 2010-01-06 at 6b4201e)
+ Detailed diagnosis when parsing an object name fails.
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
(merged to 'next' on 2010-01-06 at 03e00cd)
+ General --quiet improvements
--------------------------------------------------
[New Topics]
* bk/fix-relative-gitdir-file (2010-01-08) 2 commits
- Handle relative paths in submodule .git files
- Test update-index for a gitlink to a .git file
* jc/ident (2010-01-08) 3 commits
- ident.c: treat $EMAIL as giving user.email identity explicitly
(merged to 'next' on 2010-01-10 at f1f9ded)
+ ident.c: check explicit identity for name and email separately
+ ident.c: remove unused variables
* jc/ls-files-ignored-pathspec (2010-01-08) 4 commits
- ls-files: fix overeager pathspec optimization
- read_directory(): further split treat_path()
- read_directory_recursive(): refactor handling of a single path into a separate function
- t3001: test ls-files -o ignored/dir
* js/exec-error-report (2010-01-10) 4 commits
- Improve error message when a transport helper was not found
- start_command: detect execvp failures early
- run-command: move wait_or_whine earlier
- start_command: report child process setup errors to the parent's stderr
(this branch uses il/vcs-helper.)
--------------------------------------------------
[Stalled]
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
Needs tests.
* mh/rebase-fixup (2009-12-07) 2 commits
(merged to 'next' on 2010-01-06 at c4779a7)
+ Add a command "fixup" to rebase --interactive
+ t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Expecting further improvements to skip opening the editor if a pick is
followed only by "fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 1 commit
(merged to 'next' on 2010-01-06 at da4e2f5)
+ rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
Blocked by the above.
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
(merged to 'next' on 2010-01-02 at ae42130)
+ Add more testcases to test fast-import of notes
+ Rename t9301 to t9350, to make room for more fast-import tests
+ fast-import: Proper notes tree manipulation
http://thread.gmane.org/gmane.comp.version-control.git/134738
What's the status of the fourth and later patches on this topic? Overall
it looked reasonable, if I recall correctly what I thought when I reviewed
it last time, and I am tempted to merge it to 'next' soonish. Please
file complaints before I do so if people have objections.
Hold: JH on 2010-01-05, http://article.gmane.org/gmane.comp.version-control.git/136183
--------------------------------------------------
[Will graduate after a bit more cooking]
* nd/sparse (2010-01-04) 25 commits
(merged to 'next' on 2010-01-10 at fa73d6e)
+ t7002: test for not using external grep on skip-worktree paths
+ t7002: set test prerequisite "external-grep" if supported
(merged to 'next' on 2010-01-02 at 5499bbe)
+ grep: do not do external grep on skip-worktree entries
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
+ tests: rename duplicate t1009
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
I've queued the (close to) original tests for external grep, but as a belt
and suspender measure Nguyễn may also want to add the whitebox test
in the review thread.
* cc/reset-more (2010-01-08) 8 commits
(merged to 'next' on 2010-01-10 at 84730de)
+ t7111: check that reset options work as described in the tables
(merged to 'next' on 2010-01-06 at 96639cb)
+ Documentation: reset: add some missing tables
(merged to 'next' on 2010-01-04 at 8802c2c)
+ Fix bit assignment for CE_CONFLICTED
(merged to 'next' on 2010-01-03 at f83d4c6)
+ "reset --merge": fix unmerged case
+ reset: use "unpack_trees()" directly instead of "git read-tree"
+ reset: add a few tests for "git reset --merge"
+ Documentation: reset: add some tables to describe the different options
+ reset: improve mixed reset error message when in a bare repo
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
(merged to 'next' on 2010-01-03 at 92d7d15)
+ archive: complain about path specs that don't match anything
* il/vcs-helper (2010-01-09) 9 commits
(merged to 'next' on 2010-01-10 at 11e448e)
+ Reset possible helper before reusing remote structure
(merged to 'next' on 2010-01-06 at 7c79f42)
+ Remove special casing of http, https and ftp
+ Support remote archive from all smart transports
+ Support remote helpers implementing smart transports
+ Support taking over transports
+ Refactor git transport options parsing
+ Pass unknown protocols to external protocol handlers
+ Support mandatory capabilities
+ Add remote helper debug mode
(this branch is used by js/exec-error-report.)
--------------------------------------------------
[Cooking]
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
(merged to 'next' on 2010-01-10 at df14116)
+ checkout -m path: fix recreating conflicts
* jn/makefile (2010-01-06) 4 commits
(merged to 'next' on 2010-01-10 at f5a5d42)
+ Makefile: consolidate .FORCE-* targets
+ Makefile: learn to generate listings for targets requiring special flags
+ Makefile: use target-specific variable to pass flags to cc
+ Makefile: regenerate assembler listings when asked
* da/difftool (2010-01-09) 6 commits
(merged to 'next' on 2010-01-10 at 749c870)
+ git-diff.txt: Link to git-difftool
+ difftool: Allow specifying unconfigured commands with --extcmd
+ difftool--helper: Remove use of the GIT_MERGE_TOOL variable
+ difftool--helper: Update copyright and remove distracting comments
(merged to 'next' on 2010-01-06 at e957395)
+ git-difftool: Add '--gui' for selecting a GUI tool
+ t7800-difftool: Set a bogus tool for use by tests
* jh/gitweb-cached (2010-01-03) 4 commits
- gitweb: Makefile improvements
- gitweb: Optionally add "git" links in project list page
- gitweb: Add option to force version match
- gitweb: Load checking
Hold: Warthog on 2010-01-06, http://article.gmane.org/gmane.comp.version-control.git/136306
* tc/test-locate-httpd (2010-01-02) 1 commit
(merged to 'next' on 2010-01-06 at 9d913e5)
+ t/lib-http.sh: Restructure finding of default httpd location
* jc/fix-tree-walk (2009-09-14) 7 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- Aggressive three-way merge: fix D/F case
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
Resurrected from "Ejected" category. This is fix for a tricky codepath
and testing and improving before it hits 'next' by brave souls is greatly
appreciated (I am using this in my private build).
* jc/branch-d (2009-12-29) 1 commit
(merged to 'next' on 2010-01-10 at 61a14b7)
+ branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
(merged to 'next' on 2010-01-10 at e295b7f)
+ Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/run-command-use-shell (2010-01-01) 8 commits
(merged to 'next' on 2010-01-10 at 7479e2a)
+ t4030, t4031: work around bogus MSYS bash path conversion
+ diff: run external diff helper with shell
+ textconv: use shell to run helper
+ editor: use run_command's shell feature
+ run-command: optimize out useless shell calls
+ run-command: convert simple callsites to use_shell
+ t0021: use $SHELL_PATH for the filter script
+ run-command: add "use shell" option
Shuffled the commits in the topic, following J6t's suggestion in
http://thread.gmane.org/gmane.comp.version-control.git/136128
* tc/clone-v-progress (2009-12-26) 4 commits
(merged to 'next' on 2010-01-10 at ec2bfd7)
+ clone: use --progress to force progress reporting
+ clone: set transport->verbose when -v/--verbose is used
+ git-clone.txt: reword description of progress behaviour
+ check stderr with isatty() instead of stdout when deciding to show progress
Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* tc/smart-http-restrict (2010-01-02) 4 commits
(merged to 'next' on 2010-01-06 at 82736cb)
+ Smart-http tests: Test http-backend without curl or a webserver
+ Smart-http tests: Break test t5560-http-backend into pieces
+ Smart-http tests: Improve coverage in test t5560
+ Smart-http: check if repository is OK to export before serving it
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
Will wait a bit more before moving it to 'next'. J6t spotted an issue
with "rerere forget" and has a test script.
* jc/checkout-merge-base (2010-01-07) 4 commits
(merged to 'next' on 2010-01-07 at 5229608)
+ rebase -i: teach --onto A...B syntax
+ rebase: fix --onto A...B parsing and add tests
(merged to 'next' on 2010-01-02 at 6a8f6fc)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2010-01-08) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
Rerolled.
* sr/gfi-options (2009-12-04) 7 commits
(merged to 'next' on 2010-01-10 at 8b305fb)
+ fast-import: add (non-)relative-marks feature
+ fast-import: allow for multiple --import-marks= arguments
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: add feature command
+ fast-import: put marks reading in its own function
+ fast-import: put option parsing code in separate functions
^ permalink raw reply
* "What's cooking" incremental edition
From: Junio C Hamano @ 2010-01-10 19:55 UTC (permalink / raw)
To: git
This is "git show --ext-diff" output in 'todo' branch (see README.cooking
in the same branch) for today's updates to highlight the updated parts.
-- >8 --
-What's cooking in git.git (Jan 2010, #02; Thu, 07)
+What's cooking in git.git (Jan 2010, #03; Sun, 10)
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
-
-The tip of 'next' has been rebuilt on top of the current 'master'.
--------------------------------------------------
Born topics
[New Topics]
* bk/fix-relative-gitdir-file (2010-01-08) 2 commits
- Handle relative paths in submodule .git files
- Test update-index for a gitlink to a .git file
* jc/ident (2010-01-08) 3 commits
- ident.c: treat $EMAIL as giving user.email identity explicitly
(merged to 'next' on 2010-01-10 at f1f9ded)
+ ident.c: check explicit identity for name and email separately
+ ident.c: remove unused variables
* jc/ls-files-ignored-pathspec (2010-01-08) 4 commits
- ls-files: fix overeager pathspec optimization
- read_directory(): further split treat_path()
- read_directory_recursive(): refactor handling of a single path into a separate function
- t3001: test ls-files -o ignored/dir
* js/exec-error-report (2010-01-10) 4 commits
- Improve error message when a transport helper was not found
- start_command: detect execvp failures early
- run-command: move wait_or_whine earlier
- start_command: report child process setup errors to the parent's stderr
(this branch uses il/vcs-helper.)
--------------------------------------------------
Moved from [New Topics] to [Cooking]
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
- - checkout -m path: fix recreating conflicts
+ (merged to 'next' on 2010-01-10 at df14116)
+ + checkout -m path: fix recreating conflicts
* jn/makefile (2010-01-06) 4 commits
- - Makefile: consolidate .FORCE-* targets
- - Makefile: learn to generate listings for targets requiring special flags
- - Makefile: use target-specific variable to pass flags to cc
- - Makefile: regenerate assembler listings when asked
+ (merged to 'next' on 2010-01-10 at f5a5d42)
+ + Makefile: consolidate .FORCE-* targets
+ + Makefile: learn to generate listings for targets requiring special flags
+ + Makefile: use target-specific variable to pass flags to cc
+ + Makefile: regenerate assembler listings when asked
--------------------------------------------------
Moved from [Will graduate after a bit more cooking] to [Graduated to "master"]
* tr/http-updates (2009-12-28) 4 commits
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
* jk/push-to-delete (2009-12-30) 1 commit
* mm/config-path (2009-12-30) 1 commit
* pm/cvs-environ (2009-12-30) 1 commit
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
* bg/maint-remote-update-default (2009-12-31) 1 commit
--------------------------------------------------
Moved from [Cooking] to [Will graduate after a bit more cooking]
* cc/reset-more (2010-01-08) 8 commits
- - t7111: check that reset options work as described in the tables
+ (merged to 'next' on 2010-01-10 at 84730de)
+ + t7111: check that reset options work as described in the tables
(merged to 'next' on 2010-01-06 at 96639cb)
+ Documentation: reset: add some missing tables
(merged to 'next' on 2010-01-04 at 8802c2c)
+ Fix bit assignment for CE_CONFLICTED
(merged to 'next' on 2010-01-03 at f83d4c6)
+ "reset --merge": fix unmerged case
+ reset: use "unpack_trees()" directly instead of "git read-tree"
+ reset: add a few tests for "git reset --merge"
+ Documentation: reset: add some tables to describe the different options
+ reset: improve mixed reset error message when in a bare repo
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
-* il/vcs-helper (2009-12-09) 8 commits
+* il/vcs-helper (2010-01-09) 9 commits
+ (merged to 'next' on 2010-01-10 at 11e448e)
+ + Reset possible helper before reusing remote structure
(merged to 'next' on 2010-01-06 at 7c79f42)
+ Remove special casing of http, https and ftp
+ Support remote archive from all smart transports
+ Support remote helpers implementing smart transports
+ Support taking over transports
+ Refactor git transport options parsing
+ Pass unknown protocols to external protocol handlers
+ Support mandatory capabilities
+ Add remote helper debug mode
+ (this branch is used by js/exec-error-report.)
--------------------------------------------------
Moved from [Cooking] to [Stalled]
* jh/commit-status (2009-12-07) 1 commit
* mh/rebase-fixup (2009-12-07) 2 commits
-Initial round of "fixup" action that is similar to "squash" action in
-"rebase -i" that excludes the commit log message from follow-up commits
-when composing the log message for the updated one. Expected is a further
-improvement to skip opening the editor if a pick is followed only by
-"fixup" and no "squash".
+Expecting further improvements to skip opening the editor if a pick is
+followed only by "fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 1 commit
(merged to 'next' on 2010-01-06 at da4e2f5)
+ rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
+
+Blocked by the above.
* jh/notes (2009-12-07) 11 commits
-http://mid.gmane.org/201001051231.43048.johan@herland.net Hold!
+Hold: JH on 2010-01-05, http://article.gmane.org/gmane.comp.version-control.git/136183
* ap/merge-backend-opts (2008-07-18) 6 commits
--------------------------------------------------
Moved from [Cooking] to [Graduated to "master"]
* mm/diag-path-in-treeish (2009-12-07) 1 commit
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
--------------------------------------------------
Other topics
[Will graduate after a bit more cooking]
* nd/sparse (2010-01-04) 25 commits
- - t7002: test for not using external grep on skip-worktree paths
- - t7002: set test prerequisite "external-grep" if supported
+ (merged to 'next' on 2010-01-10 at fa73d6e)
+ + t7002: test for not using external grep on skip-worktree paths
+ + t7002: set test prerequisite "external-grep" if supported
(merged to 'next' on 2010-01-02 at 5499bbe)
+ grep: do not do external grep on skip-worktree entries
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
+ tests: rename duplicate t1009
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
+
+I've queued the (close to) original tests for external grep, but as a belt
+and suspender measure Nguyễn may also want to add the whitebox test
+in the review thread.
[Cooking]
-* da/difftool (2009-12-22) 2 commits
+* da/difftool (2010-01-09) 6 commits
+ (merged to 'next' on 2010-01-10 at 749c870)
+ + git-diff.txt: Link to git-difftool
+ + difftool: Allow specifying unconfigured commands with --extcmd
+ + difftool--helper: Remove use of the GIT_MERGE_TOOL variable
+ + difftool--helper: Update copyright and remove distracting comments
(merged to 'next' on 2010-01-06 at e957395)
+ git-difftool: Add '--gui' for selecting a GUI tool
+ t7800-difftool: Set a bogus tool for use by tests
* jh/gitweb-cached (2010-01-03) 4 commits
-Will merge to 'next', unless I hear objections within a few days.
+Hold: Warthog on 2010-01-06, http://article.gmane.org/gmane.comp.version-control.git/136306
* jc/fix-tree-walk (2009-09-14) 7 commits
Resurrected from "Ejected" category. This is fix for a tricky codepath
and testing and improving before it hits 'next' by brave souls is greatly
-appreciated. I am not very happy about the solution myself.
+appreciated (I am using this in my private build).
* jc/branch-d (2009-12-29) 1 commit
- - branch -d: base the "already-merged" safety on the branch it merges with
-
+ (merged to 'next' on 2010-01-10 at 61a14b7)
+ + branch -d: base the "already-merged" safety on the branch it merges with
-http://thread.gmane.org/gmane.comp.version-control.git/135837/focus=135863
-I am tempted to merge this to 'next', but please stop me if people see issues
-in it.
* jc/rerere (2009-12-04) 1 commit
- - Teach --[no-]rerere-autoupdate option to merge, revert and friends
+ (merged to 'next' on 2010-01-10 at e295b7f)
+ + Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/run-command-use-shell (2010-01-01) 8 commits
- - t4030, t4031: work around bogus MSYS bash path conversion
- - diff: run external diff helper with shell
- - textconv: use shell to run helper
- - editor: use run_command's shell feature
- - run-command: optimize out useless shell calls
- - run-command: convert simple callsites to use_shell
- - t0021: use $SHELL_PATH for the filter script
- - run-command: add "use shell" option
+ (merged to 'next' on 2010-01-10 at 7479e2a)
+ + t4030, t4031: work around bogus MSYS bash path conversion
+ + diff: run external diff helper with shell
+ + textconv: use shell to run helper
+ + editor: use run_command's shell feature
+ + run-command: optimize out useless shell calls
+ + run-command: convert simple callsites to use_shell
+ + t0021: use $SHELL_PATH for the filter script
+ + run-command: add "use shell" option
* tc/clone-v-progress (2009-12-26) 4 commits
- - clone: use --progress to force progress reporting
- - clone: set transport->verbose when -v/--verbose is used
- - git-clone.txt: reword description of progress behaviour
- - check stderr with isatty() instead of stdout when deciding to show progress
+ (merged to 'next' on 2010-01-10 at ec2bfd7)
+ + clone: use --progress to force progress reporting
+ + clone: set transport->verbose when -v/--verbose is used
+ + git-clone.txt: reword description of progress behaviour
+ + check stderr with isatty() instead of stdout when deciding to show progress
* jc/cache-unmerge (2009-12-25) 9 commits
-Will wait a bit more before moving it to 'next'.
+Will wait a bit more before moving it to 'next'. J6t spotted an issue
+with "rerere forget" and has a test script.
-* tr/http-push-ref-status (2009-12-24) 6 commits
+* tr/http-push-ref-status (2010-01-08) 6 commits
-Peff: $gmane/136169, 136167, 136168
-RC: $gmane/136172
+Rerolled.
* sr/gfi-options (2009-12-04) 7 commits
- - fast-import: add (non-)relative-marks feature
- - fast-import: allow for multiple --import-marks= arguments
- - fast-import: test the new option command
- - fast-import: add option command
- - fast-import: add feature command
- - fast-import: put marks reading in its own function
- - fast-import: put option parsing code in separate functions
-
-http://thread.gmane.org/gmane.comp.version-control.git/134540
-
+ (merged to 'next' on 2010-01-10 at 8b305fb)
+ + fast-import: add (non-)relative-marks feature
+ + fast-import: allow for multiple --import-marks= arguments
+ + fast-import: test the new option command
+ + fast-import: add option command
+ + fast-import: add feature command
+ + fast-import: put marks reading in its own function
+ + fast-import: put option parsing code in separate functions
-I haven't seen comments on this round, and I am tempted to merge it to
-'next' soonish. Please file complaints before I do so if people have
-objections.
--------------------------------------------------
Gone topics
Was in [Graduated to "master"]
* mo/bin-wrappers (2009-12-02) 3 commits
(merged to 'next' on 2010-01-03 at 8c5fa27)
+ INSTALL: document a simpler way to run uninstalled builds
+ run test suite without dashed git-commands in PATH
+ build dashless "bin-wrappers" directory similar to installed bindir
* mv/commit-date (2009-12-03) 2 commits
(merged to 'next' on 2010-01-03 at 1c45fdf)
+ Document date formats accepted by parse_date()
+ builtin-commit: add --date option
* bg/maint-add-all-doc (2009-12-07) 4 commits
(merged to 'next' on 2010-01-03 at b19a323)
+ squash! rm documentation--also mention add-u where we mention commit-a
+ git-rm doc: Describe how to sync index & work tree
+ git-add/rm doc: Consistently back-quote
+ Documentation: 'git add -A' can remove files
* so/cvsserver-update (2009-12-07) 1 commit
(merged to 'next' on 2010-01-03 at 99959b6)
+ cvsserver: make the output of 'update' more compatible with cvs.
* mg/tag-d-show (2009-12-10) 1 commit
(merged to 'next' on 2010-01-03 at 87657d2)
+ tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
(merged to 'next' on 2010-01-03 at ffe77d6)
+ octopus: remove dead code
+ octopus: reenable fast-forward merges
+ octopus: make merge process simpler to follow
* js/filter-branch-prime (2009-12-15) 1 commit
(merged to 'next' on 2010-01-03 at 7c90319)
+ filter-branch: remove an unnecessary use of 'git read-tree'
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-10 20:13 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Git Mailing List
In-Reply-To: <ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com>
On Sun, 10 Jan 2010, Leo Razoumov wrote:
> Hi List,
> I am trying to find a way to check availability of new commits
> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
> take "--dry-run" option (unlike push)
But... _Why_ do you want/need to do that?
You could use ls-remote to see what the remote branch is pointing to,
e.g.:
git ls-remote origin master
and compare with the local view of that remote branch:
git show-ref origin/master
And if both SHA1 strings match then there is nothing new to fetch.
> I am sure I am not the only one with such an itch.
Maybe you are. There is very little point knowing that the remote repo
has new commits if you're not going to fetch them, so I don't understand
why you need this.
Nicolas
^ permalink raw reply
* Re: "What's cooking" incremental edition
From: Sverre Rabbelier @ 2010-01-10 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmy0lpwes.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Jan 10, 2010 at 14:55, Junio C Hamano <gitster@pobox.com> wrote:
> * jn/makefile (2010-01-06) 4 commits
> - - Makefile: consolidate .FORCE-* targets
> - - Makefile: learn to generate listings for targets requiring special flags
> - - Makefile: use target-specific variable to pass flags to cc
> - - Makefile: regenerate assembler listings when asked
> + (merged to 'next' on 2010-01-10 at f5a5d42)
> + + Makefile: consolidate .FORCE-* targets
> + + Makefile: learn to generate listings for targets requiring special flags
> + + Makefile: use target-specific variable to pass flags to cc
> + + Makefile: regenerate assembler listings when asked
Fwiw, I find it harder to read due to the now ambiguous meaning of the
+ and - (it could either mean something is in pu/next, or that the
topic changed). Of course this is partly caused by the fact that I
don't read emails in fixed font (by default), but perhaps it's worth
considering using different symbols for pu/next-ness?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Junio C Hamano @ 2010-01-10 20:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Leo Razoumov, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001101501520.10143@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> I am sure I am not the only one with such an itch.
>
> Maybe you are. There is very little point knowing that the remote repo
> has new commits if you're not going to fetch them, so I don't understand
> why you need this.
A feel good factor is in play? IOW, "I am short of time, so I won't be
able to really afford to 'git pull' and test the result of re-integrating
my changes to what happened on the other end. If I can learn that there
is nothing happening over there, then I won't have to do anything and know
that I am up to date."
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-10 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Leo Razoumov, Git Mailing List
In-Reply-To: <7v8wc5itlc.fsf@alter.siamese.dyndns.org>
On Sun, 10 Jan 2010, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> >> I am sure I am not the only one with such an itch.
> >
> > Maybe you are. There is very little point knowing that the remote repo
> > has new commits if you're not going to fetch them, so I don't understand
> > why you need this.
>
> A feel good factor is in play? IOW, "I am short of time, so I won't be
> able to really afford to 'git pull' and test the result of re-integrating
> my changes to what happened on the other end. If I can learn that there
> is nothing happening over there, then I won't have to do anything and know
> that I am up to date."
Just do a fetch then. If the fetch progress display looks like if it is
going to take a while then just interrupt it and go home. If the fetch
looks trivial then just merge it. In any case, the "feel good" factor
can't be that great by only knowing if the remote has changed or not.
Well maybe if it hasn't changed then you know right away how to feel
about it (equally with a fetch in that case), and if the remote is
indeed different then you can't tell whether the changes are trivial or
not without actually fetching them.
Nicolas
^ permalink raw reply
* [PATCH] 0/2 Add tag message to gitk
From: Dave Dulson @ 2010-01-10 22:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
It would be nice to be able to create a full tag from gitk, so these
patches add that ability. I'm not sure about 2/2, but can't see what
using $tagobjid adds - hopefully Paul or similar will be able to weigh
in.
Cheers,
Dave
^ permalink raw reply
* [PATCH 1/2] Add tag message
From: Dave Dulson @ 2010-01-10 22:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Add tag message support to the dialog and exec call
Signed-off-by: David Dulson <dave@dulson.com>
---
gitk | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 86dff0f..b34b481 100755
--- a/gitk
+++ b/gitk
@@ -8701,6 +8701,11 @@ proc mktag {} {
${NS}::label $top.tlab -text [mc "Tag name:"]
${NS}::entry $top.tag -width 60
grid $top.tlab $top.tag -sticky w
+ ${NS}::label $top.op -text [mc "Tag message is optional"]
+ grid $top.op -columnspan 2 -sticky we
+ ${NS}::label $top.mlab -text [mc "Tag message:"]
+ ${NS}::entry $top.msg -width 60
+ grid $top.mlab $top.msg -sticky w
${NS}::frame $top.buts
${NS}::button $top.buts.gen -text [mc "Create"] -command mktaggo
${NS}::button $top.buts.can -text [mc "Cancel"] -command mktagcan
@@ -8718,6 +8723,7 @@ proc domktag {} {
set id [$mktagtop.sha1 get]
set tag [$mktagtop.tag get]
+ set msg [$mktagtop.msg get]
if {$tag == {}} {
error_popup [mc "No tag name specified"] $mktagtop
return 0
@@ -8727,7 +8733,11 @@ proc domktag {} {
return 0
}
if {[catch {
- exec git tag $tag $id
+ if {$msg != {}} {
+ exec git tag -a -m "$msg" $tag $id
+ } else {
+ exec git tag $tag $id
+ }
} err]} {
error_popup "[mc "Error creating tag:"] $err" $mktagtop
return 0
--
1.6.6.75.g37bae.dirty
^ permalink raw reply related
* [PATCH/RFC 2/2] Remove $tagobjid from tagcontents population
From: Dave Dulson @ 2010-01-10 22:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
When the showtag proc is called directly after the tag has been
created rereadrefs hasn't been called, meaning the tag doesn't exist
in $tagobjid. This causes the cat-file to fail.
Instead of using $tagobjid, pass the $tag directly, ensuring the tag
contents are populated correctly.
Signed-off-by: David Dulson <dave@dulson.com>
---
gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index b34b481..65721e3 100755
--- a/gitk
+++ b/gitk
@@ -10482,7 +10482,7 @@ proc listrefs {id} {
}
proc showtag {tag isnew} {
- global ctext tagcontents tagids linknum tagobjid
+ global ctext tagcontents tagids linknum
if {$isnew} {
addtohistory [list showtag $tag 0] savectextpos
@@ -10493,7 +10493,7 @@ proc showtag {tag isnew} {
set linknum 0
if {![info exists tagcontents($tag)]} {
catch {
- set tagcontents($tag) [exec git cat-file tag $tagobjid($tag)]
+ set tagcontents($tag) [exec git cat-file tag $tag]
}
}
if {[info exists tagcontents($tag)]} {
--
1.6.6.75.g37bae.dirty
^ permalink raw reply related
* Re: How to check new commit availability without full fetch?
From: Leo Razoumov @ 2010-01-11 1:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001101556490.10143@xanadu.home>
On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 10 Jan 2010, Junio C Hamano wrote:
> >
> > A feel good factor is in play? IOW, "I am short of time, so I won't be
> > able to really afford to 'git pull' and test the result of re-integrating
> > my changes to what happened on the other end. If I can learn that there
> > is nothing happening over there, then I won't have to do anything and know
> > that I am up to date."
>
>
> Just do a fetch then. If the fetch progress display looks like if it is
> going to take a while then just interrupt it and go home. If the fetch
> looks trivial then just merge it. In any case, the "feel good" factor
> can't be that great by only knowing if the remote has changed or not.
>
Forced interruption is not such a good idea. I would favor a
non-destructive way to monitor availability of remote commits.
BTW, pull and push are in a way symmetric operations. Is there any
deep reason why push supports --dry-run but pull/fetch does not??
--Leo--
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Tay Ray Chuan @ 2010-01-11 1:57 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com>
Hi,
On Mon, Jan 11, 2010 at 9:36 AM, Leo Razoumov <slonik.az@gmail.com> wrote:
> On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Sun, 10 Jan 2010, Junio C Hamano wrote:
>> >
>> > A feel good factor is in play? IOW, "I am short of time, so I won't be
>> > able to really afford to 'git pull' and test the result of re-integrating
>> > my changes to what happened on the other end. If I can learn that there
>> > is nothing happening over there, then I won't have to do anything and know
>> > that I am up to date."
>>
>>
>> Just do a fetch then. If the fetch progress display looks like if it is
>> going to take a while then just interrupt it and go home. If the fetch
>> looks trivial then just merge it. In any case, the "feel good" factor
>> can't be that great by only knowing if the remote has changed or not.
>>
>
> Forced interruption is not such a good idea. I would favor a
> non-destructive way to monitor availability of remote commits.
By default, when you add a remote (with git remote add), git sets up
the fetch refspec in your config that looks like
[remote "foo"]
url = git://foo.com/git/foo.git
fetch = refs/heads/*:refs/remotes/foo/*
That is to say, branches on the remote repo will be fetched into a
"safe" area, refs/remotes/foo/, away from the branches that you
normally work with in refs/heads/.
However, if you have a different config and you're fetching directly
into refs/heads/, then I can see why you would want to "peek" first
with --dry-run before fetching. Are you doing this?
> BTW, pull and push are in a way symmetric operations. Is there any
> deep reason why push supports --dry-run but pull/fetch does not??
It's more accurate to say that push and fetch are symmetric, because
pull is fetch with merge or rebase tacked on.
Even then, push and fetch are not _that_ symmetric...
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-11 1:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vpr5krxoo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Your implementation forgets to re-insert the forgotten resolutions into
>> MERGE_RR, therefore, the next 'git rerere' does not record the new
>> resolution.
>>
>> In my implementation of 'rerere forget', I had the following tests.
>
> Please filfre to roll a patch that adds the tests and code that inserts
> necessary MERGE_RR entries, if the feature is pressing; unfortunately I
> don't think I will have much git time during the coming weekend.
I ended up doing this myself. As we are dropping the postimage and adding
a new MERGE_RR entry, I also think that it is safer to update the preimage
with the conflict we got for this round, so I added that as well.
However, I think there is a room for improvement in preimage handling.
Currently, the rerere database is indexed with the conflict hash and for
each conflict hash you can record a single preimage-postimage pair to
replay. But you can have conflicts with the same conflict hash, but with
slightly different contexts outside the conflicted region, and the right
resolution can be different depending on the outside context.
In the traditional implementation, I punted this issue by noticing
conflicts in the three-way merge between pre, post and this images. If
preimage is too different from the conflicted contents we got during this
merge, then the previous resolution should not apply.
But I think the right solution would be to have more than one preimage and
postimage pairs (preimage.0 vs postimage.0,... etc.) and try to use each
of them in handle_path() until it finds one that can be used to cleanly
merge with the conflict we got in thisimage during this round.
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-11 2:01 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com>
On Sun, 10 Jan 2010, Leo Razoumov wrote:
> On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Sun, 10 Jan 2010, Junio C Hamano wrote:
> > >
> > > A feel good factor is in play? IOW, "I am short of time, so I won't be
> > > able to really afford to 'git pull' and test the result of re-integrating
> > > my changes to what happened on the other end. If I can learn that there
> > > is nothing happening over there, then I won't have to do anything and know
> > > that I am up to date."
> >
> >
> > Just do a fetch then. If the fetch progress display looks like if it is
> > going to take a while then just interrupt it and go home. If the fetch
> > looks trivial then just merge it. In any case, the "feel good" factor
> > can't be that great by only knowing if the remote has changed or not.
> >
>
> Forced interruption is not such a good idea. I would favor a
> non-destructive way to monitor availability of remote commits.
You still don't answer my question though. Again, _why_ do you need to
know about remote commit availability without fetching them?
> BTW, pull and push are in a way symmetric operations. Is there any
> deep reason why push supports --dry-run but pull/fetch does not??
Pushing involves resource usage on your own machine while
pulling/fetching involves the remote machine. Your choice to "waste"
CPU cycles on your own machine is not the same as having anybody do the
same on a central server.
Nicolas
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Junio C Hamano @ 2010-01-11 2:08 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: SLONIK.AZ, Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <be6fef0d1001101757w7f54c9b2ye58c66179137efb1@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> By default, when you add a remote (with git remote add), git sets up
> the fetch refspec in your config that looks like
>
> [remote "foo"]
> url = git://foo.com/git/foo.git
> fetch = refs/heads/*:refs/remotes/foo/*
>
> That is to say, branches on the remote repo will be fetched into a
> "safe" area, refs/remotes/foo/, away from the branches that you
> normally work with in refs/heads/.
>
> However, if you have a different config and you're fetching directly
> into refs/heads/, then I can see why you would want to "peek" first
> with --dry-run before fetching.
I don't. Until all the objects are safely transferred, none of the refs
are updated, whether they are directly slurped into local branch namespace
or remote tracking branch namespace. So no matter what the configuration
is, interrupted transfer, forced or otherwise, is safe.
^ permalink raw reply
* Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees
From: Jonathan Nieder @ 2010-01-11 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vskaefp2v.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Oh, that is a problem. Maybe 'git merge' should refuse to merge
>> unless told otherwise, if there is a dirty index and there might be
>> conflicts.
>
> "git reset --merge" will keep your local changes after such a merge, and
> "mergy" operations (not just "merge" but also "revert", "am -3", etc)
> won't get you into a situation where you cannot, by refusing to do
> anything when e.g. your index is dirty. Especially when Christian's
> "reset --merge" update becomes solid, "... is hard to back out of" will
> become a false statement.
Here is a scenario I worry about:
Suppose I have a change to main.c staged, to add a feature that others
have discussed as well. After a short distraction, I return and run
‘git pull’ to see what upstream has been working on. As luck would
have it, the remote version of main.c is exactly the same as my
modified version, so the merge happily proceeds. Some other files
merge cleanly. Eventually there is some conflict.
Now I regret the pull. Will ‘reset --merge’ restore the index and
work tree to its original state?
If the change to main.c was _not_ staged, then the merge would have
failed early, so that is not something to worry about.
> Of course, the user needs to understand what he or she is doing (see
> http://thread.gmane.org/gmane.comp.version-control.git/136166/focus=136171
> for example).
Agreed. And probably the user who understands what is going on will
not make the mistake I described above. Otherwise, they could succumb
to a related problem:
Suppose all is as above, except that git detects no conflict. Suppose
further that some upstream commit was bogus.
Now I regret the pull. How can I restore the index and work tree to
its original state?
If I reset --hard (or --merge) to the previous HEAD commit, the
modification to main.c is forgotten. In practice, I would do
'git reset --hard HEAD^ && git checkout HEAD@{1} -- main.c'.
^ permalink raw reply
* Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees
From: Junio C Hamano @ 2010-01-11 2:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20100111021322.GA8480@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Here is a scenario I worry about:
>
> Suppose I have a change to main.c staged, to add a feature that others
> have discussed as well. After a short distraction, I return and run
> ‘git pull’ to see what upstream has been working on.
If your index is dirty, any "mergy" operation will refuse to work *before*
touching anything, so you won't use "git reset --merge" to begin with.
You are allowed to have local modifications only in your work tree.
Furthermore, even git experts limit them to something they feel they can
afford to lose and recreate easily if necessary. See for example:
http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476
That is why I said:
Of course, the user needs to understand what he or she is doing (see
http://thread.gmane.org/gmane.comp.version-control.git/136166/focus=136171
for example). And that is one reason we (at least I) try to teach new
people to start working from a clean tree, until they get comfortable
working with mergy operations.
and that is why the archived article referenced above refers to
http://gitster.livejournal.com/29060.html
You need to be able to tell the two ways in which a "mergy" operation can
"fail" apart [*1*].
- One that stops before touching anything (either your index was dirty
and nothing happened, or your index was clean but you had local
modifications in your work tree). You do not run "git reset --merge",
for this one; and
- Another that goes ahead and results in conflicts. When you got these
conflicts, you can "reset --merge" them away.
[Footnote]
*1* Strictly speaking, the latter is not even a "failure"; it allowed you
to make progress, merging all the auto-mergeable parts without your help,
and only asking you to handle the remainder.
^ 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