* [PATCH v3 6/6] transport-helper.c::push_refs(): emit "no refs" error message
From: Tay Ray Chuan @ 2009-12-24 7:45 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Daniel Barkalow, Jeff King, Junio C Hamano
In-Reply-To: <20091224154445.ad4b7a01.rctay89@gmail.com>
Emit an error message when remote_refs is not set.
This behaviour is consistent with that of builtin-send-pack.c and
http-push.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Changed nothing from v2.
transport-helper.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index bdfa07e..5910384 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -321,8 +321,11 @@ static int push_refs(struct transport *transport,
struct child_process *helper;
struct ref *ref;
- if (!remote_refs)
+ if (!remote_refs) {
+ fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
+ "Perhaps you should specify a branch such as 'master'.\n");
return 0;
+ }
helper = get_helper(transport);
if (!data->push)
--
1.6.6.rc1.249.g048b3
^ permalink raw reply related
* [PATCH v3 1/6] t5541-http-push.sh: add tests for non-fast-forward pushes
From: Tay Ray Chuan @ 2009-12-24 7:40 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Daniel Barkalow, Jeff King, Junio C Hamano
In-Reply-To: <20091224154005.a642c8ec.rctay89@gmail.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
t/t5541-http-push.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 2a58d0c..f49c7c4 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -88,5 +88,28 @@ test_expect_success 'used receive-pack service' '
test_cmp exp act
'
+test_expect_success 'non-fast-forward push fails' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ git checkout master &&
+ echo "changed" > path2 &&
+ git commit -a -m path2 --amend &&
+
+ HEAD=$(git rev-parse --verify HEAD) &&
+ !(git push -v origin >output 2>&1) &&
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
+ test $HEAD != $(git rev-parse --verify HEAD))
+'
+
+test_expect_failure 'non-fast-forward push show ref status' '
+ grep "^ ! \[rejected\][ ]*master -> master (non-fast-forward)$" output
+'
+
+test_expect_failure 'non-fast-forward push shows help message' '
+ grep \
+"To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
+section of '"'git push --help'"' for details." output
+'
+
stop_httpd
test_done
--
1.6.6.rc1.249.g048b3
^ permalink raw reply related
* [Squash PATCH] fprintf(stderr, "Warning...") -> warning("...")
From: Ilari Liusvaara @ 2009-12-24 10:41 UTC (permalink / raw)
To: git
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
transport-helper.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
This fixes the small nit about fprintf(stderr, "Warning: ") by using
warning() API.
It can be appiled on top of "Support remote helpers implementing smart
transports" or squashed to it.
diff --git a/transport-helper.c b/transport-helper.c
index 55427df..8c8ca8e 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -420,11 +420,10 @@ static int process_connect_service(struct transport *transport,
if (strcmp(name, exec)) {
r = set_helper_option(transport, "servpath", exec);
if (r > 0)
- fprintf(stderr, "Warning: Setting remote service path "
- "not supported by protocol.\n");
+ warning("Setting remote service path not supported "
+ "by protocol.\n");
else if (r < 0)
- fprintf(stderr, "Warning: Invalid remote service "
- "path.\n");
+ warning("Invalid remote service path.\n");
}
if (data->connect)
--
1.6.6.3.gaa2e1
^ permalink raw reply related
* Re: Patch which adds syslog support to git-shell
From: Erik Faye-Lund @ 2009-12-24 11:38 UTC (permalink / raw)
To: Gerhard Gappmeier; +Cc: git
In-Reply-To: <200912231832.03541.gerhard.gappmeier@ascolab.com>
Please read Documentation/SubmittingPatches. We prefer inline patches,
as they are easier to review.
On Wed, Dec 23, 2009 at 6:32 PM, Gerhard Gappmeier
<gerhard.gappmeier@ascolab.com> wrote:
> Hi
>
> I'm not sure if this is the right list, but here is my first GIT patch.
>
It's the right list :)
> I had a problem with git-shell and wanted to analyze it.
> Unfortunately it does not contain any trace capabilities.
> So I cloned git and added some basic syslog support.
> After that I recognized that the current git version just works ;-)
> but the syslog functionality is always a nice thing I think.
> So here is the patch.
Looking at your patch, I see there's a lot of white-space changes. Stuff like:
> - const char *cvsserver_argv[3] = {
> - "cvsserver", "server", NULL
> - };
> + const char *cvsserver_argv[3] = {
> + "cvsserver", "server", NULL
> + };
just makes this harder to review. Besides, we use tabs for indentation in git.
Also, I think it would be better to use set_die_routine() from usage.h
than to change all the die call-sites. This is what git-daemon does:
--->8---
if (log_syslog) {
openlog("git-daemon", LOG_PID, LOG_DAEMON);
set_die_routine(daemon_die);
}
--->8---
Look at daemon.c for the implementation of daemon_die().
+/* Syslog defines */
+#define GIT_SYSLOG_IDENT "git-shell"
+#define GIT_SYSLOG_OPTION 0
+#define GIT_SYSLOG_FACILITY LOG_LOCAL0
+
Is this really needed? These are only used at one place. Just doing
+ openlog("git-shell", 0, LOG_LOCAL0);
would IMO be cleaner.
Anyway, this is all I bother to point out before I see an inlined,
white-space fixed patch.
> Merry X-Mas.
Happy holidays to you too :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Patch which adds syslog support to git-shell
From: Erik Faye-Lund @ 2009-12-24 13:03 UTC (permalink / raw)
To: Gerhard Gappmeier; +Cc: git
In-Reply-To: <40aa078e0912240338g7765d17cyf948650deab2aa01@mail.gmail.com>
On Thu, Dec 24, 2009 at 12:38 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> Anyway, this is all I bother to point out before I see an inlined,
> white-space fixed patch.
>
Actually, I'll add one thing: using syslog in git-shell breaks the
Windows builds. I don't know about other platforms.
Currently, git-daemon is the only git-program that depends on syslog,
and it's excluded from Windows builds (but this is something that
might change soon).
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: elegant(?) debian topgit workflow?
From: Felipe Contreras @ 2009-12-24 15:14 UTC (permalink / raw)
To: thomas; +Cc: vcs-pkg-discuss, git, debian-devel
In-Reply-To: <200912161113.38396.thomas@koch.ro>
On Wed, Dec 16, 2009 at 12:13 PM, Thomas Koch <thomas@koch.ro> wrote:
> branches
> --------
>
> upstream
I would call it 'master'. That's how upstream would call it.
> debian/*, fixes/*, features/* - topgit branches based on upstream
> patches - the hero
> master - contains the debian/ dir and is the branch we build from
Think about other systems, like Ubuntu and Maemo, it would be nice to
have branches both for Maemo and Debian on the same repo:
debian - what you call 'master'
debian-patches - what you call 'patches'
maemo5 - contains the debian/ dir, but for Maemo 5
maemo5-patches - patches for Maemo 5, might be based on top of debian-patches
--
Felipe Contreras
^ permalink raw reply
* Re: elegant(?) debian topgit workflow?
From: David Greaves @ 2009-12-24 16:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: thomas, debian-devel, git, vcs-pkg-discuss
In-Reply-To: <94a0d4530912240714y798085d8r3bf88011e8ec782b@mail.gmail.com>
Felipe Contreras wrote:
> On Wed, Dec 16, 2009 at 12:13 PM, Thomas Koch <thomas@koch.ro> wrote:
>> branches
>> --------
>>
>> upstream
>
> I would call it 'master'. That's how upstream would call it.
>
>> debian/*, fixes/*, features/* - topgit branches based on upstream
>> patches - the hero
>> master - contains the debian/ dir and is the branch we build from
>
> Think about other systems, like Ubuntu and Maemo, it would be nice to
> have branches both for Maemo and Debian on the same repo:
> debian - what you call 'master'
> debian-patches - what you call 'patches'
> maemo5 - contains the debian/ dir, but for Maemo 5
> maemo5-patches - patches for Maemo 5, might be based on top of debian-patches
I've been touting for feedback on this for a while :)
http://wiki.maemo.org/Mer/Build/UsingGitorious
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
^ permalink raw reply
* [RFC PATCH 0/2] Report remote helper exec failures
From: Ilari Liusvaara @ 2009-12-24 17:49 UTC (permalink / raw)
To: git
Actually give useful error messages if executing git remote helper fails
for some reason.
The previous error message was:
git: 'remote-fail' is not a git-command. See 'git --help'
This changes the error message to:
'Unable to find remote helper for "nonexistent"'
or
'Unable to run helper HelperThatGetsEACCESS: Permission denied'
(or whatever the errno is).
Patch series is based on v1.6.6.
One of the changes is adjacent to changes in external helper dispatch
support change and gets merge conflict. Here's how I resolved that
conflict for testing:
helper->argv[2] = remove_ext_force(transport->url);
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));
}
The first line in that comes from dispatch support and the rest come from
exec failure reporting.
Ilari Liusvaara (2):
Report exec errors from run-command
Improve transport helper exec failure reporting
run-command.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++--
transport-helper.c | 14 +++++++---
2 files changed, 79 insertions(+), 7 deletions(-)
^ permalink raw reply
* [RFC PATCH 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-24 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <1261676971-3285-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
* [RFC PATCH 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-24 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <1261676971-3285-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>
---
run-command.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..d334d0f 100644
--- a/run-command.c
+++ b/run-command.c
@@ -76,9 +76,60 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef WIN32
+{
+ int report_pipe[2] = {-1, -1};
+
+ if (pipe(report_pipe) < 0)
+ 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;
+ while(close(report_pipe[1]) < 0 && errno != EBADF);
+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");
+ 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;
+ while(close(report_pipe[0]) < 0 && errno != EBADF);
+
+ 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));
+ while(close(report_pipe[1]) < 0 && errno != EBADF);
+ report_pipe[1] = -1;
+ }
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -126,13 +177,28 @@ fail_pipe:
} 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;
+ else if (r < 0)
+ warning("Can't write exec status report: %s\n",
+ strerror(errno));
+
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 */
--
1.6.6.3.gaa2e1
^ permalink raw reply related
* Some stats for 1.6.6
From: Junio C Hamano @ 2009-12-24 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vpr65kwnt.fsf@alter.siamese.dyndns.org>
Now 1.6.6 is out, the next one will be 1.7.0 that hopefully will happen
sometime late in February 2010. I wish people happy holidays, and expect
them to slow down (I would ;-) for the remainder of the year.
Here are a few sets of numbers to help relax your mind away from hacking.
The very initial release of "git" consisted of 11 files, 1244 lines in
total, all written by Linus. Here is the result of a "reverse-blame" that
counts how much of that original version still can be found in the latest
version:
surviving original path (survival%)
16 40 Makefile (40.00%)
16 168 README (9.52%)
54 93 cache.h (58.06%)
4 23 cat-file.c (17.39%)
6 172 commit-tree.c (3.48%)
4 51 init-db.c (7.84%)
99 259 read-cache.c (38.22%)
0 43 read-tree.c (0.00%)
7 81 show-diff.c (8.64%)
39 248 update-cache.c (15.72%)
0 66 write-tree.c (0.00%)
245 1244 Total (19.69%)
As can be seen in "cache.h", the very basic data structures and accessor
methods haven't changed much. v0.99, which was the last version Linus
tagged before handing the development over to me, still retained 46% of
the original.
Here is a contributor statistics.
release new this total date
v0.99 47 47 47 2005-07-10
v1.0.0 68 89 115 2005-12-21
v1.1.0 4 19 119 2006-01-08
v1.2.0 8 32 127 2006-02-12
v1.3.0 22 56 149 2006-04-18
v1.4.0 18 57 167 2006-06-10
v1.4.1 3 30 170 2006-07-01
v1.4.2 13 47 183 2006-08-12
v1.4.3 9 43 192 2006-10-18
v1.4.4 8 42 200 2006-11-14
v1.5.0 25 72 225 2007-02-14
v1.5.1 14 59 239 2007-04-03
v1.5.2 19 70 258 2007-05-20
v1.5.3 53 126 311 2007-09-02
v1.5.4 82 163 393 2008-02-01
v1.5.5 33 112 426 2008-04-07
v1.5.6 46 114 472 2008-06-18
v1.6.0 40 105 512 2008-08-17
v1.6.1 49 147 561 2008-12-24
v1.6.2 34 109 595 2009-03-03
v1.6.3 45 117 640 2009-05-06
v1.6.4 26 98 666 2009-07-29
v1.6.5 27 101 693 2009-10-10
v1.6.6 17 99 710 2009-12-23
During the entire history leading to 1.6.6, 710 authors contributed code
and documentation. The changes since 1.6.5 were made by 99 authors, among
which 17 are the new contributors to the project.
Let's thank and welcome them to the community(sorted LC_ALL=C): Andrew
Myrick, Brian Collins, Carlos R. Mafra, Dan Zwell, Erick Mattos, Gisle
Aas, Guillermo S. Romero, Jean Privat, Jimmy Angelakos, Jindrich
Makovicka, Mizar, Nasser Grainawi, Pauli Virtanen, Raman Gupta, Robert
Zeh, Tim Henigan, and Vietor Liu.
^ permalink raw reply
* Re: Some stats for 1.6.6
From: Shawn O. Pearce @ 2009-12-24 19:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v637wjlor.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Here is a contributor statistics.
>
> release new this total date
> v0.99 47 47 47 2005-07-10
...
> v1.6.5 27 101 693 2009-10-10
> v1.6.6 17 99 710 2009-12-23
>
> During the entire history leading to 1.6.6, 710 authors contributed code
> and documentation. The changes since 1.6.5 were made by 99 authors, among
> which 17 are the new contributors to the project.
This is what impresses me most about Git.
Its not our simple on disk format, or our network protocols, or how
well we have been able to avoid breaking things. Its our community.
Almost 100 people contributed code into the most recent release,
and in just the last 6 months we picked up 44 new contributors.
I wish all open source projects ran this well.
> Let's thank and welcome them to the community(sorted LC_ALL=C): Andrew
> Myrick, Brian Collins, Carlos R. Mafra, Dan Zwell, Erick Mattos, Gisle
> Aas, Guillermo S. Romero, Jean Privat, Jimmy Angelakos, Jindrich
> Makovicka, Mizar, Nasser Grainawi, Pauli Virtanen, Raman Gupta, Robert
> Zeh, Tim Henigan, and Vietor Liu.
Welcome! But more importantly, thank you for making Git better!
:-)
--
Shawn.
^ permalink raw reply
* You have local changes; cannot switch branches error question
From: Eugene Sajine @ 2009-12-24 22:25 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
First of all Merry Christmas and Happy New Year to everybody! I wish
Git to move to global dominance during next year even faster then it
does now;)
My question is related to the fact that most of the time when i have
some local file changes Git is switching branches OK. But from time to
time in some repos I'm hitting this error and I cannot figure out why
it suddenly starts to complain about it?
For example in one of my repos I somehow got to a state when I have
three files modified, and when I'm trying to switch branches it
complains about one of them being changed locally, so it refuses to
switch branch
OTOH i have tried many different scenarios in another repo to leave
some uncommitted staged or not staged changes and switch branches and
same version of git does that just fine. (v 1.6.5.6).
So, what is correct behavior - do not switch or switch branches when
there are uncommitted changes?
Thanks,
Eugene
^ permalink raw reply
* Re: You have local changes; cannot switch branches error question
From: Nanako Shiraishi @ 2009-12-24 22:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912241425k741b24e9ie8ed92ca7cb8a659@mail.gmail.com>
Quoting Eugene Sajine <euguess@gmail.com>
> My question is related to the fact that most of the time when i have
> some local file changes Git is switching branches OK. But from time to
> time in some repos I'm hitting this error and I cannot figure out why
> it suddenly starts to complain about it?
The command is telling you that it refrained to overwrite
your local changes. It's not complaining. There is an
excellent summary of what switching branches with 'git
checkout' while you have local changes in your working tree.
http://thread.gmane.org/gmane.comp.version-control.git/77700/focus=77708
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: You have local changes; cannot switch branches error question
From: Junio C Hamano @ 2009-12-24 23:32 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912241425k741b24e9ie8ed92ca7cb8a659@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> For example in one of my repos I somehow got to a state when I have
> three files modified, and when I'm trying to switch branches it
> complains about one of them being changed locally, so it refuses to
> switch branch
Suppose you have a history like this:
o---B side
/
---o----o----A master
and both branches 'master' and 'side' have file, F and G. G is different
between commits A and B while F is the same between these two commits.
You have 'master' checked out, and modified both F and G. This table
shows the contents you have in each path:
path master work tree side
-----------------------------------------
F F1 F2 F1
G G1 G2 G3
In git, your local modification does _not_ belong to any branch. You need
to commit them if you want to make them part of the history of your
current branch. Checking out a different branch means you switch to the
branch and carry these changes along with you. But it is not necessarily
be possible to do so without modifying what is in your work tree.
For path F, your local change is (F2-F1), and switching to branch 'side'
means you would transplant that change on top of what that branch has,
which happens to be F1. That means the result is F2 (= F1 + (F2-F1)).
IOW, because F is identical between master and side, the file in your work
tree can stay the same.
Now, think what should happen to path G. The local change is (G2-G1), and
you need to transplant that change on top of G3, that is different from
G1. This computation will involve a merge, which you may or may not be
prepared to resolve.
If you are used to CVS/SVN workflow where you "update" to merge other's
changes to your work tree with your own local changes, you will know that
with such a merge, depending on the amount of change between G1 and G3,
you may end up losing quite a lot of work of your own (G2-G1), when the
merge is too complicated for you to handle. The message you saw is a
safety valve to prevent you from trashing your work that way.
There are two ways to deal with this situation, one safely, and another
quickly.
- You can "stash save" to first save the changes in your work tree,
"checkout" to switch to branch 'side', and then "stash pop" to attempt
the merge.
The last step of unstashing on the new branch _will_ give you the same
kind of conflict while computing G3 + (G2 - G1) to update file G, but
the approach has one huge advantage compared to CVS/SVN's "update", in
that you can "reset --hard" and "stash pop" to reset to a clean state
and attempt resolution if you failed resolve conflicts and end up
making a mess in your first try.
- If you _know_ that the changes between G1 and G3 do not conflict with
what you did between G1 and G2, you can "checkout -m" to instruct it to
act as if it were CVS/SVN's "update" command.
This can potentially make an unresolvable mess in your work tree, and
you can end up losing your changes G2-G1, but it is quicker than "stash
save"/"stash pop" pair.
^ permalink raw reply
* Branch shuffling after 1.6.6 release plans
From: Junio C Hamano @ 2009-12-25 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vpr65kwnt.fsf@alter.siamese.dyndns.org>
Here is a list of short-term branch shuffling I plan to do.
- Kick a few topics back to 'pu'. They were merged to 'next' in the hope
of them either getting discussed to form a consensus or perfected, but
they ended up in limbo for a long time without progress (pre-release
freeze didn't have any impact on them),
This involves applying a few reverts directly on top of 'next', which
I've already done privately. People _could_ vote to bring them back by
working on perfecting them and/or discussing them to reach concensus.
* je/send-email-no-subject (2009-08-05) 1 commit
- send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
- rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* tr/reset-checkout-patch (2009-11-19) 1 commit
- {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
- Graduate the following topics to 'master':
* sr/vcs-helper (2009-12-07) 14 commits
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
Also possibly:
* jk/1.7.0-status (2009-12-11) 16 commits
* jc/1.7.0-status (2009-09-05) 4 commits
For these topics, we would need to decide what to do with the
"submodule summary" stuff in the --porcelain format output, which we
promised will never change in the documentation. My current thinking
is to keep the current code and don't show anything; Porcelains can
choose to run "git log" inside submodule directories if they so desire.
- Rebuild 'next' on top of the updated 'master' with remaining topics.
I actually won't do this step before the new year, so that people who
based their topics on 'next' can still fast-forward, but with many
topics for 1.7.0 graduating this week to 'master' hopefully it would be
easier for them to rebase on top of 'master'.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 7:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261676971-3285-2-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> 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.
Thanks; I think overall this is a good idea, even though I have no clue
if WIN32 side wants a similar support.
- At first reading, the "while (close(fd) < 0 && errno != EBADF);"
pattern was a bit of eyesore. It might be worth factoring that out to
a small static helper function that a smart compiler would
automatically inline (or mark it as a static inline).
- Is it guaranteed that a failed pipe(2) never touches its int fildes[2]
parameter, or the values are undefined when it fails? The approach
would save one extra variable, compared to an alternative approach to
keep an explicit variable to record a pipe failure, but It feels iffy
that the code relies on them being left as their initial -1 values.
- Should we worry about partial write as well (you seem to warn when you
get a partial read)? Is it worth using xread() and friends found in
wrapper.c instead of goto read/write_again?
- Shouldn't any of these warning() be die() instead?
- The two extra file descriptors this patch uses are allocated after all
the existing pipe flipping is done, and all the dup's done in the child
process are to use dup2() to set up the known file descriptors at low
numbers, so I don't think we have to worry about this patch changing
the behaviour of the process pair by changing the assignment of file
descriptors (we had a bug or two in the past that made subprocess
misbehave under some funky condition, e.g. run with fd#0 closed).
^ permalink raw reply
* Re: [RFC PATCH 2/2] Improve transport helper exec failure reporting
From: Junio C Hamano @ 2009-12-25 7:44 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261676971-3285-3-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> 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>
Looks pretty straightforward, except that I have this nagging feeling that
we should *not* be married to the idea of "'proc->git_cmd = 1' is merely a
way to save you from typing 'git-' prefix in start_command(proc)".
> 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)) {
For example, we might later want to use different $PATH only when running
a git subcommand, and telling run_command() explicitly that we are running
a git thing would help if you don't add "git-" to the command line and
drop "proc->git_cmd = 1" in the caller like your patch does.
> + 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
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
>> 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.
>
> Thanks; I think overall this is a good idea, even though I have no clue
> if WIN32 side wants a similar support.
By the way, at least it should be pretty straightforward to add a test or
two for [1/2] if not [2/2].
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 8:40 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> - At first reading, the "while (close(fd) < 0 && errno != EBADF);"
> pattern was a bit of eyesore. It might be worth factoring that out to
> a small static helper function that a smart compiler would
> automatically inline (or mark it as a static inline).
This also is a minor style thing, but we prefer your
>>+ while(close(report_pipe[1]) < 0 && errno != EBADF);
formatted like this:
while (foobar)
; /* noop */
to
(1) have SP after syntactic keyword like while/if/switch to differentiate
from function calls; and
(2) make the no-op stand out for a bit more visibility.
^ permalink raw reply
* Re: [RFC PATCH 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-25 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgrebv2.fsf@alter.siamese.dyndns.org>
On Thu, Dec 24, 2009 at 11:44:49PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> Looks pretty straightforward, except that I have this nagging feeling that
> we should *not* be married to the idea of "'proc->git_cmd = 1' is merely a
> way to save you from typing 'git-' prefix in start_command(proc)".
That is already broken. If nothing previous broke it, then 1/2 of this
series did.
The immediate executable to run for 'git-foo' && git_cmd = 0: 'git-foo'.
The immediate executable to run for 'foo' && git_cmd = 1: 'git'(!).
And one wants exec status for 'git-remote-foo', NOT for 'git'. Thus,
git_cmd must be 0 (at least without additional flags or flag values).
> For example, we might later want to use different $PATH only when running
> a git subcommand, and telling run_command() explicitly that we are running
> a git thing would help if you don't add "git-" to the command line and
> drop "proc->git_cmd = 1" in the caller like your patch does.
Well, that would require new flag (or git_cmd field value) to mean do direct
exec with gitexecdir in $PATH. Otherwise, you would either break this piece
of code, or it would be already broken (depending on value of git_cmd).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-25 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
On Thu, Dec 24, 2009 at 11:35:04PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> Thanks; I think overall this is a good idea, even though I have no clue
> if WIN32 side wants a similar support.
It would. But I have no clue about WIN32. But there are other people
on this list who have. :-)
> - At first reading, the "while (close(fd) < 0 && errno != EBADF);"
> pattern was a bit of eyesore. It might be worth factoring that out to
> a small static helper function that a smart compiler would
> automatically inline (or mark it as a static inline).
Done (with bit of reformatting to add space, line break and comment.
> - Is it guaranteed that a failed pipe(2) never touches its int fildes[2]
> parameter, or the values are undefined when it fails? The approach
> would save one extra variable, compared to an alternative approach to
> keep an explicit variable to record a pipe failure, but It feels iffy
> that the code relies on them being left as their initial -1 values.
I added explicit set to -1 on failure case (I think failed pipe doesn't touch
those, but you never know about what some oddball OS is going to do).
> - Should we worry about partial write as well (you seem to warn when you
> get a partial read)? Is it worth using xread() and friends found in
> wrapper.c instead of goto read/write_again?
That's hairy code. One really can't print any errors in write path, as those
errors would go to who knows where due to redirections (I took the error
warning out).
That partial read warning is more for detecting 'can't happen' situations
since pipe should be large enough to atomically transfer integer.
> - Shouldn't any of these warning() be die() instead?
If error reporting failures are fatal, all of them.
-Ilari
^ permalink raw reply
* Re: Branch shuffling after 1.6.6 release plans
From: Thomas Rast @ 2009-12-25 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgrgar9.fsf@alter.siamese.dyndns.org>
Thanks for 1.6.6!
Junio C Hamano wrote:
> * tr/maint-merge-ours-clarification (2009-11-15) 1 commit
> - rebase: refuse to rebase with -s ours
>
> I do not think we reached a concensus for solving conflicts between "give
> them rope" and "protect users from clearly meaningless combinations". The
> author obviously is for the latter (and I am inclined to agree); Dscho
> seems to think otherwise.
I can try hacking some internal option into the merge helpers, by
which they declare to be (in)compatible with rebasing. I think this
what Dscho or Sverre mentioned in the corresponding thread, but I
forgot about it when I noticed you had already promoted the above to
'next'.
> * tr/reset-checkout-patch (2009-11-19) 1 commit
> - {checkout,reset} -p: make patch direction configurable
>
> I do not particularly like a configuration like this that changes the
> behaviour of a command in a drastic way---it will make helping others
> much harder.
I think it's not quite as drastic as you make it sound ;-)
But I don't need this feature, and Peff mentioned something about
being happy except for the patch editing mode. Unfortunately the
above pretty much hits the limits of add--interactive's flexibility,
so an interactive direction toggling feature would need some rewiring.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Branch shuffling after 1.6.6 release plans
From: Ilari Liusvaara @ 2009-12-25 12:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200912251230.48243.trast@student.ethz.ch>
On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:
>
> I can try hacking some internal option into the merge helpers, by
> which they declare to be (in)compatible with rebasing. I think this
> what Dscho or Sverre mentioned in the corresponding thread, but I
> forgot about it when I noticed you had already promoted the above to
> 'next'.
If you do that, maybe do all relevant flags (such as "no fast forwards"
and "no trivial merging") at the same time. That would allow external
strategies to use those flags.
-Ilari
^ permalink raw reply
* [PATCH] user-manual: use standarized quoting
From: Felipe Contreras @ 2009-12-25 13:05 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Hi,
This is a big patch that was sent before, but now I'm explaining my rationale
for the quoting style I used. I noticed a few deviations on my own rules, so I
fixed them.
What do you think?
Felipe Contreras (1):
user-manual: general quoting improvements
Documentation/user-manual.txt | 884 ++++++++++++++++++++--------------------
1 files changed, 442 insertions(+), 442 deletions(-)
^ 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