* Re: [PATCH] git-status: show short sequencer state
From: Matthieu Moy @ 2012-10-23 6:05 UTC (permalink / raw)
To: Phil Hord
Cc: phil.hord, Junio C Hamano, konglu, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <1350948569-28445-2-git-send-email-hordp@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> + merge a git-merge is in progress
> + am a git-am is in progress
> + rebase a git-rebase is in progress
> + rebase-interactive a git-rebase--interactive is in progress
> + cherry-pick a git-cherry-pick is in progress
> + bisect a git-bisect is in progress
Avoid using git-foo syntax in documentation, it suggests that this is
valid command, which isn't true anymore. `git foo` seems the most common
syntax. Also, git-rebase--interactive is not user-visible => `git rebase
--interactive`.
> - if (state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_NOMINAL)
> status_printf_ln(s, color,
> _("The current patch is empty."));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The "if" suggests everything is allright, and the
message below is very specific. This at least deserves a comment.
> if (advice_status_hints) {
> - if (!state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_CONFLICTED)
Spaces around ==.
> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
> +{
> + color_fprintf(s->fp, color, "%s", token);
> + fputc(s->null_termination ? '\0' : '\n', s->fp);
> +}
The output format seems to be meant only for machine-consumption. Is
there any case when we'd want color? I'd say we can disable coloring
completely for this format (normally, color=auto does the right thing,
but I prefer being 100% sure I'll get no color when writing scripts)
> +static void wt_shortstatus_print_sequencer(struct wt_status *s)
[...]
> +void wt_sequencer_print(struct wt_status *s)
> +{
> + wt_shortstatus_print_sequencer(s);
> +}
> +
Why do you need this trivial wrapper?
Other than that, I like the idea (although I have no concrete use-case
in mind), but I didn't actually test the patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [BUG] (git commit --patch --message $MESSAGE) disallows hunk editing
From: Max Nanasy @ 2012-10-23 5:48 UTC (permalink / raw)
To: git
Tested against v1.7.12.4
Steps to reproduce:
A. cd $DIRTY_WORKING_COPY
B. git commit --patch --message $MESSAGE
C. Stage this hunk? e
Expected behavior:
After step C, the hunk opens in the user's editor
Actual behavior:
After step C, the hunk is selected unedited (as if the user had entered "y")
AFAICT, this occurs because of the following code in
builtin/commit.c:parse_and_validate_options:
if (... || message.len || ...)
use_editor = 0;
...
if (!use_editor)
setenv("GIT_EDITOR", ":", 1);
Because --message is specified, GIT_EDITOR is set to ":", which
prevents the user from editing hunks, although the intent is most
likely to just prevent the user from editing the commit message.
^ permalink raw reply
* Re: Links broken in ref docs.
From: Scott Chacon @ 2012-10-23 5:11 UTC (permalink / raw)
To: Mike Norman; +Cc: Andrew Ardill, git
In-Reply-To: <CAJr+XPETQ2Jifns3_dfoB-sLLru2=Jkofb5RrBxLE4Fa9Aqp7A@mail.gmail.com>
So, this is due to the major AWS outage today. git-scm.com is hosted
on Heroku and thus on AWS. Heroku is continuing to bring up their
database systems in the wake of the massive AWS outage. Once that is
back online, git-scm.com will also be back online.
As for the git-fetch issue, we'll look into it once Heroku is back online.
Scott
On Mon, Oct 22, 2012 at 7:34 PM, Mike Norman <mknorman@gmail.com> wrote:
> This seems worse. The entire site is now down with an application
> error. Reporting this out of surprise and just in case the dev on the
> job has the site cached somehow and can't see the error. Image
> (hopefully) attached and the message is as appears below, in case the
> attachment gets stripped. (Tags for convenience and not part of
> error.)
>
> <errortext>
> Application Error
>
> An error occurred in the application and your page could not be
> served. Please try again in a few moments.
>
> If you are the application owner, check your logs for details.
> </errortext>
>
> Hope this helps,
> Mike Norman
> On Sun, Oct 21, 2012 at 9:45 PM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>> On 21 October 2012 18:31, Mike Norman <mknorman@gmail.com> wrote:
>>> Many links on scm-git.org/docs simply reload the page.
>>>
>>> For example, all of Sharing and Updating section simply reload the
>>> docs page. And tons others. Must be a broken link or routing problem.
>>> Repros on FF 14.0.1 and Chrome. Good luck!
>>>
>>
>> Including Scott Chacon as he manages this site (to my knowledge).
>>
>> Looking at the request, I am getting a 302:
>>
>> Request URL:http://git-scm.com/docs/git-fetch
>> Request Method:GET
>> Status Code:302 Moved Temporarily
>>
>> Maybe those pages are not done yet? That doesn't seem right as this is
>> simply the reference manual, but perhaps there is something else going
>> on here.
>>
>> On another (related) note, the wayback machine has some very
>> interesting entries for the scm-git.org domain [1] and it seems the
>> /doc directory is not indexed at all. Is this on purpose?
>>
>> Regards,
>>
>> Andrew Ardill
>>
>> [1] http://wayback.archive.org/web/*/http://git-scm.com/*
^ permalink raw reply
* [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Nguyễn Thái Ngọc Duy @ 2012-10-23 2:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
These functions are called in sequencer.c, which is part of
libgit.a. This makes libgit.a potentially require builtin/merge.c for
external git commands.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I made some unrelated changes in sequencer.c and this problem shown
up. merge-recursive.c is probably not the best place for these
functions. I just don't want to create merge.c for them.
builtin/merge.c | 106 +----------------------------------------------------
cache.h | 3 --
merge-recursive.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
merge-recursive.h | 4 ++
sequencer.c | 2 +-
5 files changed, 115 insertions(+), 108 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 0ec8f0d..a96e8ea 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -628,59 +628,6 @@ static void write_tree_trivial(unsigned char *sha1)
die(_("git write-tree failed to write a tree"));
}
-static const char *merge_argument(struct commit *commit)
-{
- if (commit)
- return sha1_to_hex(commit->object.sha1);
- else
- return EMPTY_TREE_SHA1_HEX;
-}
-
-int try_merge_command(const char *strategy, size_t xopts_nr,
- const char **xopts, struct commit_list *common,
- const char *head_arg, struct commit_list *remotes)
-{
- const char **args;
- int i = 0, x = 0, ret;
- struct commit_list *j;
- struct strbuf buf = STRBUF_INIT;
-
- args = xmalloc((4 + xopts_nr + commit_list_count(common) +
- commit_list_count(remotes)) * sizeof(char *));
- strbuf_addf(&buf, "merge-%s", strategy);
- args[i++] = buf.buf;
- for (x = 0; x < xopts_nr; x++) {
- char *s = xmalloc(strlen(xopts[x])+2+1);
- strcpy(s, "--");
- strcpy(s+2, xopts[x]);
- args[i++] = s;
- }
- for (j = common; j; j = j->next)
- args[i++] = xstrdup(merge_argument(j->item));
- args[i++] = "--";
- args[i++] = head_arg;
- for (j = remotes; j; j = j->next)
- args[i++] = xstrdup(merge_argument(j->item));
- args[i] = NULL;
- ret = run_command_v_opt(args, RUN_GIT_CMD);
- strbuf_release(&buf);
- i = 1;
- for (x = 0; x < xopts_nr; x++)
- free((void *)args[i++]);
- for (j = common; j; j = j->next)
- free((void *)args[i++]);
- i += 2;
- for (j = remotes; j; j = j->next)
- free((void *)args[i++]);
- free(args);
- discard_cache();
- if (read_cache() < 0)
- die(_("failed to read the cache"));
- resolve_undo_clear();
-
- return ret;
-}
-
static int try_merge_strategy(const char *strategy, struct commit_list *common,
struct commit_list *remoteheads,
struct commit *head, const char *head_arg)
@@ -762,56 +709,6 @@ static int count_unmerged_entries(void)
return ret;
}
-int checkout_fast_forward(const unsigned char *head, const unsigned char *remote)
-{
- struct tree *trees[MAX_UNPACK_TREES];
- struct unpack_trees_options opts;
- struct tree_desc t[MAX_UNPACK_TREES];
- int i, fd, nr_trees = 0;
- struct dir_struct dir;
- struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
-
- refresh_cache(REFRESH_QUIET);
-
- fd = hold_locked_index(lock_file, 1);
-
- memset(&trees, 0, sizeof(trees));
- memset(&opts, 0, sizeof(opts));
- memset(&t, 0, sizeof(t));
- if (overwrite_ignore) {
- memset(&dir, 0, sizeof(dir));
- dir.flags |= DIR_SHOW_IGNORED;
- setup_standard_excludes(&dir);
- opts.dir = &dir;
- }
-
- opts.head_idx = 1;
- opts.src_index = &the_index;
- opts.dst_index = &the_index;
- opts.update = 1;
- opts.verbose_update = 1;
- opts.merge = 1;
- opts.fn = twoway_merge;
- setup_unpack_trees_porcelain(&opts, "merge");
-
- trees[nr_trees] = parse_tree_indirect(head);
- if (!trees[nr_trees++])
- return -1;
- trees[nr_trees] = parse_tree_indirect(remote);
- if (!trees[nr_trees++])
- return -1;
- for (i = 0; i < nr_trees; i++) {
- parse_tree(trees[i]);
- init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
- }
- if (unpack_trees(nr_trees, t, &opts))
- return -1;
- if (write_cache(fd, active_cache, active_nr) ||
- commit_locked_index(lock_file))
- die(_("unable to write new index file"));
- return 0;
-}
-
static void split_merge_strategies(const char *string, struct strategy **list,
int *nr, int *alloc)
{
@@ -1424,7 +1321,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
if (checkout_fast_forward(head_commit->object.sha1,
- commit->object.sha1)) {
+ commit->object.sha1,
+ overwrite_ignore)) {
ret = 1;
goto done;
}
diff --git a/cache.h b/cache.h
index a58df84..415c777 100644
--- a/cache.h
+++ b/cache.h
@@ -1265,9 +1265,6 @@ struct startup_info {
};
extern struct startup_info *startup_info;
-/* builtin/merge.c */
-int checkout_fast_forward(const unsigned char *from, const unsigned char *to);
-
int sane_execvp(const char *file, char *const argv[]);
#endif /* CACHE_H */
diff --git a/merge-recursive.c b/merge-recursive.c
index d882060..4d2422a 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -21,6 +21,9 @@
#include "merge-recursive.h"
#include "dir.h"
#include "submodule.h"
+#include "run-command.h"
+#include "resolve-undo.h"
+#include "unpack-trees.h"
static struct tree *shift_tree_object(struct tree *one, struct tree *two,
const char *subtree_shift)
@@ -2087,3 +2090,108 @@ int parse_merge_opt(struct merge_options *o, const char *s)
return -1;
return 0;
}
+
+static const char *merge_argument(struct commit *commit)
+{
+ if (commit)
+ return sha1_to_hex(commit->object.sha1);
+ else
+ return EMPTY_TREE_SHA1_HEX;
+}
+
+int try_merge_command(const char *strategy, size_t xopts_nr,
+ const char **xopts, struct commit_list *common,
+ const char *head_arg, struct commit_list *remotes)
+{
+ const char **args;
+ int i = 0, x = 0, ret;
+ struct commit_list *j;
+ struct strbuf buf = STRBUF_INIT;
+
+ args = xmalloc((4 + xopts_nr + commit_list_count(common) +
+ commit_list_count(remotes)) * sizeof(char *));
+ strbuf_addf(&buf, "merge-%s", strategy);
+ args[i++] = buf.buf;
+ for (x = 0; x < xopts_nr; x++) {
+ char *s = xmalloc(strlen(xopts[x])+2+1);
+ strcpy(s, "--");
+ strcpy(s+2, xopts[x]);
+ args[i++] = s;
+ }
+ for (j = common; j; j = j->next)
+ args[i++] = xstrdup(merge_argument(j->item));
+ args[i++] = "--";
+ args[i++] = head_arg;
+ for (j = remotes; j; j = j->next)
+ args[i++] = xstrdup(merge_argument(j->item));
+ args[i] = NULL;
+ ret = run_command_v_opt(args, RUN_GIT_CMD);
+ strbuf_release(&buf);
+ i = 1;
+ for (x = 0; x < xopts_nr; x++)
+ free((void *)args[i++]);
+ for (j = common; j; j = j->next)
+ free((void *)args[i++]);
+ i += 2;
+ for (j = remotes; j; j = j->next)
+ free((void *)args[i++]);
+ free(args);
+ discard_cache();
+ if (read_cache() < 0)
+ die(_("failed to read the cache"));
+ resolve_undo_clear();
+
+ return ret;
+}
+
+int checkout_fast_forward(const unsigned char *head,
+ const unsigned char *remote,
+ int overwrite_ignore)
+{
+ struct tree *trees[MAX_UNPACK_TREES];
+ struct unpack_trees_options opts;
+ struct tree_desc t[MAX_UNPACK_TREES];
+ int i, fd, nr_trees = 0;
+ struct dir_struct dir;
+ struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
+
+ refresh_cache(REFRESH_QUIET);
+
+ fd = hold_locked_index(lock_file, 1);
+
+ memset(&trees, 0, sizeof(trees));
+ memset(&opts, 0, sizeof(opts));
+ memset(&t, 0, sizeof(t));
+ if (overwrite_ignore) {
+ memset(&dir, 0, sizeof(dir));
+ dir.flags |= DIR_SHOW_IGNORED;
+ setup_standard_excludes(&dir);
+ opts.dir = &dir;
+ }
+
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.update = 1;
+ opts.verbose_update = 1;
+ opts.merge = 1;
+ opts.fn = twoway_merge;
+ setup_unpack_trees_porcelain(&opts, "merge");
+
+ trees[nr_trees] = parse_tree_indirect(head);
+ if (!trees[nr_trees++])
+ return -1;
+ trees[nr_trees] = parse_tree_indirect(remote);
+ if (!trees[nr_trees++])
+ return -1;
+ for (i = 0; i < nr_trees; i++) {
+ parse_tree(trees[i]);
+ init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
+ }
+ if (unpack_trees(nr_trees, t, &opts))
+ return -1;
+ if (write_cache(fd, active_cache, active_nr) ||
+ commit_locked_index(lock_file))
+ die(_("unable to write new index file"));
+ return 0;
+}
diff --git a/merge-recursive.h b/merge-recursive.h
index 58f3435..e01a9c0 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -64,4 +64,8 @@ int try_merge_command(const char *strategy, size_t xopts_nr,
const char **xopts, struct commit_list *common,
const char *head_arg, struct commit_list *remotes);
+int checkout_fast_forward(const unsigned char *from,
+ const unsigned char *to,
+ int overwrite_ignore);
+
#endif
diff --git a/sequencer.c b/sequencer.c
index e3723d2..be0cb8b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -191,7 +191,7 @@ static int fast_forward_to(const unsigned char *to, const unsigned char *from)
struct ref_lock *ref_lock;
read_cache();
- if (checkout_fast_forward(from, to))
+ if (checkout_fast_forward(from, to, 1))
exit(1); /* the callee should have complained already */
ref_lock = lock_any_ref_for_update("HEAD", from, 0);
return write_ref_sha1(ref_lock, to, "cherry-pick");
--
1.8.0.rc3.18.g0d9b108
^ permalink raw reply related
* Re: [PATCH] remote-testgit: properly check for errors
From: Felipe Contreras @ 2012-10-23 0:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Junio C Hamano, Jeff King, Shawn O. Pearce
In-Reply-To: <CAGdFq_gOb3GX1iZshGZahZEbj3RqQSEk8AN_hHXKyD5aHwfxYA@mail.gmail.com>
On Mon, Oct 22, 2012 at 11:01 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
>> index 5f3ebd2..b8707e6 100644
>> --- a/git-remote-testgit.py
>> +++ b/git-remote-testgit.py
>> @@ -159,6 +159,11 @@ def do_import(repo, args):
>> ref = line[7:].strip()
>> refs.append(ref)
>>
>> + print "feature done"
>
> There's not enough context for me to see in which part of the code
> this is, import or export?
Isn't this enough?
>> @@ -159,6 +159,11 @@ def do_import(repo, args):
It's import.
> If you advertise 'feature done', shouldn't
> you also print 'done' when you finish writing the fast-export stream?
> If that's already the case feel free to ignore me :)
It's already there:
http://git.kernel.org/?p=git/git.git;a=blob;f=git-remote-testgit.py#l165
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] git-status: show short sequencer state
From: Phil Hord @ 2012-10-22 23:29 UTC (permalink / raw)
To: hordp
Cc: phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as "conflicted" or "resolved".
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-pick a git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editing interactive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
---
Documentation/git-status.txt | 18 ++++++
builtin/commit.c | 12 +++-
wt-status.c | 128 +++++++++++++++++++++++++++++++++++--------
wt-status.h | 13 ++++-
4 files changed, 146 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..200a8e2 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a git-merge is in progress
+ am a git-am is in progress
+ rebase a git-rebase is in progress
+ rebase-interactive a git-rebase--interactive is in progress
+ cherry-pick a git-cherry-pick is in progress
+ bisect a git-bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editing interactive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', "branch", &s.show_branch,
N_("show branch information")),
+ OPT_SET_INT('S', "sequence", &status_format,
+ N_("show sequencer state"),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, "porcelain", &status_format,
N_("machine-readable output"),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(&s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(&s);
+ break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
s.ignore_submodule_arg = ignore_submodule_arg;
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..996b454 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,7 +781,7 @@ static void show_merge_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You have unmerged paths."));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -802,11 +802,11 @@ static void show_am_in_progress(struct wt_status *s,
{
status_printf_ln(s, color,
_("You are in the middle of an am session."));
- if (state->am_empty_patch)
+ if (state->substate==WT_SUBSTATE_NOMINAL)
status_printf_ln(s, color,
_("The current patch is empty."));
if (advice_status_hints) {
- if (!state->am_empty_patch)
+ if (state->substate==WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and then run \"git am --resolved\")"));
status_printf_ln(s, color,
@@ -867,9 +867,7 @@ static void show_rebase_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- struct stat st;
-
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
@@ -879,19 +877,19 @@ static void show_rebase_in_progress(struct wt_status *s,
status_printf_ln(s, color,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
- } else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
+ } else if (state->substate == WT_SUBSTATE_RESOLVED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
- } else if (split_commit_in_progress(s)) {
+ } else if (state->substate == WT_SUBSTATE_SPLITTING) {
status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (Once your working directory is clean, run \"git rebase --continue\")"));
} else {
status_printf_ln(s, color, _("You are currently editing a commit during a rebase."));
- if (advice_status_hints && !s->amend) {
+ if (advice_status_hints && state->substate == WT_SUBSTATE_EDITING) {
status_printf_ln(s, color,
_(" (use \"git commit --amend\" to amend the current commit)"));
status_printf_ln(s, color,
@@ -907,7 +905,7 @@ static void show_cherry_pick_in_progress(struct wt_status *s,
{
status_printf_ln(s, color, _("You are currently cherry-picking."));
if (advice_status_hints) {
- if (has_unmerged(s))
+ if (state->substate == WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and run \"git commit\")"));
else
@@ -928,34 +926,66 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s , struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
+ // Determine main sequencer activity
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
- if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->am_in_progress = 1;
+ if (stat(git_path("rebase-apply/patch"), &st) || st.st_size)
+ state->substate = WT_SUBSTATE_CONFLICTED;
} else {
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st))
- state.bisect_in_progress = 1;
+ state->bisect_in_progress = 1;
+
+ // Check for unmerged files
+ if (state->rebase_in_progress || state->rebase_interactive_in_progress ||
+ state->cherry_pick_in_progress || state->merge_in_progress) {
+ if (has_unmerged(s)) {
+ state->substate = WT_SUBSTATE_CONFLICTED;
+ } else {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ }
+ }
+
+ // Interactive Rebase is more nuanced
+ if (state->rebase_interactive_in_progress && state->substate != WT_SUBSTATE_CONFLICTED) {
+ if (!stat(git_path("MERGE_MSG"), &st)) {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ } else if (split_commit_in_progress(s)) {
+ state->substate = WT_SUBSTATE_SPLITTING;
+ } else {
+ if (s->amend) {
+ state->substate = WT_SUBSTATE_EDITED;
+ } else {
+ state->substate = WT_SUBSTATE_EDITING;
+ }
+ }
+ }
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -1192,6 +1222,53 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
fputc(s->null_termination ? '\0' : '\n', s->fp);
}
+static void wt_print_token(struct wt_status *s, const char *color, const char *token)
+{
+ color_fprintf(s->fp, color, "%s", token);
+ fputc(s->null_termination ? '\0' : '\n', s->fp);
+}
+
+static void wt_shortstatus_print_sequencer(struct wt_status *s)
+{
+ struct wt_status_state state;
+ const char *state_color = color(WT_STATUS_HEADER, s);
+
+ wt_status_get_state(s, &state);
+
+ if (state.merge_in_progress)
+ wt_print_token(s, state_color, "merge");
+ if (state.am_in_progress)
+ wt_print_token(s, state_color, "am");
+ if (state.rebase_in_progress)
+ wt_print_token(s, state_color, "rebase");
+ if (state.rebase_interactive_in_progress)
+ wt_print_token(s, state_color, "rebase-interactive");
+ if (state.cherry_pick_in_progress)
+ wt_print_token(s, state_color, "cherry-pick");
+ if (state.bisect_in_progress)
+ wt_print_token(s, state_color, "bisect");
+
+ switch (state.substate) {
+ case WT_SUBSTATE_NOMINAL:
+ break;
+ case WT_SUBSTATE_CONFLICTED:
+ wt_print_token(s, state_color, "conflicted");
+ break;
+ case WT_SUBSTATE_RESOLVED:
+ wt_print_token(s, state_color, "resolved");
+ break;
+ case WT_SUBSTATE_EDITED:
+ wt_print_token(s, state_color, "edited");
+ break;
+ case WT_SUBSTATE_EDITING:
+ wt_print_token(s, state_color, "editing");
+ break;
+ case WT_SUBSTATE_SPLITTING:
+ wt_print_token(s, state_color, "splitting");
+ break;
+ }
+}
+
void wt_shortstatus_print(struct wt_status *s)
{
int i;
@@ -1224,6 +1301,11 @@ void wt_shortstatus_print(struct wt_status *s)
}
}
+void wt_sequencer_print(struct wt_status *s)
+{
+ wt_shortstatus_print_sequencer(s);
+}
+
void wt_porcelain_print(struct wt_status *s)
{
s->use_color = 0;
diff --git a/wt-status.h b/wt-status.h
index 236b41f..3de4b26 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -59,6 +59,7 @@ struct wt_status {
unsigned colopts;
int null_termination;
int show_branch;
+ int show_sequencer;
/* These are computed during processing of the individual sections */
int commitable;
@@ -71,14 +72,23 @@ struct wt_status {
struct string_list ignored;
};
+enum wt_status_substate {
+ WT_SUBSTATE_NOMINAL = 0,
+ WT_SUBSTATE_CONFLICTED,
+ WT_SUBSTATE_RESOLVED,
+ WT_SUBSTATE_SPLITTING,
+ WT_SUBSTATE_EDITING,
+ WT_SUBSTATE_EDITED,
+};
+
struct wt_status_state {
int merge_in_progress;
int am_in_progress;
- int am_empty_patch;
int rebase_in_progress;
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ enum wt_status_substate substate;
};
void wt_status_prepare(struct wt_status *s);
@@ -86,6 +96,7 @@ void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
void wt_shortstatus_print(struct wt_status *s);
+void wt_sequencer_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
void status_printf_ln(struct wt_status *s, const char *color, const char *fmt, ...)
--
1.8.0.2.ge1a3bdd
^ permalink raw reply related
* Re: Migrating from StarTeam to GIT
From: victorcruz @ 2012-10-22 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60902190919p2cdbe349o4a2a659617dae341@mail.gmail.com>
victor cruz alonso
vitycruz@gmail.com
The following is a small web application that converts projects of StarTeam
to GIT repository.
http://dl.dropbox.com/u/101447754/startgit.tar.gz
I developed because in my work decided to migrate and give the possibility
that any group without previous research work to make such a process.
Now:
StartGIT es una sencilla herramienta para trabajar con Controladores de
Versiones, su fin es poder convertir un repositorio en Starteam a GIT, para
ello se hace uso del script "svnimporter-1.2-st" obtenido en
"http://www.polarion.com/user/direct_register.php?dl=svnimporterst":
Tener instalado:
- GIT
- git-svn
- java
- apache2
Pasos:
- Descomprimir "startgit.zip"
- Colocar la carpeta descomprimida "startgit" en el directorio "/var/www/"
- Abrir navegador web y colocar la siguiente direccción
"http://localhost/startgit"
//-------------------------------------------------------------
StartGIT is a simple tool, its purpose is to convert a Starteam repository
to GIT.
This script uses the "svnimporter-1.2-st" obtained "http://www.polarion.com
/ user / direct_register.php? dl = svnimporterst "
Have installed:
- GIT
- Git-svn
- java
- apache2
steps:
- Unzip "startgit.zip"
- Place the unzipped folder "startgit" in the "/ var / www /"
- Open web browser and "http://localhost/startgit"
--
View this message in context: http://git.661346.n2.nabble.com/Migrating-from-StarTeam-to-GIT-tp2354198p7569734.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 1/2] git-pull: Avoid merge-base on detached head
From: Phil Hord @ 2012-10-22 22:50 UTC (permalink / raw)
To: git
Cc: gitster, phil.hord, santi, Elijah Newren, Johannes Schindelin,
Phil Hord
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
"usage" help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few parameters.
Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick and the usage noise.
---
git-pull.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..266e682 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -200,6 +200,7 @@ test true = "$rebase" && {
require_clean_work_tree "pull with rebase" "Please commit or stash them."
fi
oldremoteref= &&
+ test -n "$curr_branch" &&
. git-parse-remote &&
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
--
1.8.0.2.ge1a3bdd
^ permalink raw reply related
* Re: tag storage format
From: Andreas Schwab @ 2012-10-22 22:46 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5ATiAx09eAEo1=6+=hPv=5c6qtOiLRG5jrQn5dfCKUrvMQ@mail.gmail.com>
Uri Moszkowicz <uri@4refs.com> writes:
> Perhaps Git should switch to a single-file block text or binary format
> once a large number of tags becomes present in a repository.
This is what git pack-refs (called by git gc) does (by putting the refs
in .git/packed-refs).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* tag storage format
From: Uri Moszkowicz @ 2012-10-22 22:23 UTC (permalink / raw)
To: git
I'm doing some testing on a large Git repository and am finding local
clones to take a very long time. After some investigation I've
determined that the problem is due to a very large number of tags
(~38k). Even with hard links, it just takes a really long time to
visit that many inodes. As it happens, I don't care for most of these
tags and will prune many of them anyway but I expect that over time it
will creep back up again. Have others reported this problem before and
is there a workaround? Perhaps Git should switch to a single-file
block text or binary format once a large number of tags becomes
present in a repository.
^ permalink raw reply
* Re: The config include mechanism doesn't allow for overwriting
From: Jeff King @ 2012-10-22 21:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4cu9XuS5AtduWrNeXNUeZ4rqDUzRdmyz2b3cXtmo1nqQ@mail.gmail.com>
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I was hoping to write something like this:
>
> [user]
> name = Luser
> email = some-default@example.com
> [include]
> path = ~/.gitconfig.d/user-email
>
> Where that file would contain:
>
> [user]
> email = local-email@example.com
The intent is that it would work as you expect, and produce
local-email@example.com.
> But when you do that git prints:
>
> $ git config --get user.email
> some-default@example.com
> error: More than one value for the key user.email: local-email@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser <local-email@example.com> 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
> I think config inclusion is much less useful when you can't clobber
> previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
---
builtin/config.c | 111 ++++++++++++-----------------------
1 file changed, 38 insertions(+), 73 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d6a066b..72cb0a8 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -16,7 +16,6 @@ static int do_not_match;
static int use_key_regexp;
static int do_all;
static int do_not_match;
-static int seen;
static char delim = '=';
static char key_delim = ' ';
static char term = '\n';
@@ -110,12 +109,19 @@ static int show_config(const char *key_, const char *value_, void *cb)
return 0;
}
-static int show_config(const char *key_, const char *value_, void *cb)
+struct strbuf_list {
+ struct strbuf *items;
+ int nr;
+ int alloc;
+};
+
+static int collect_config(const char *key_, const char *value_, void *cb)
{
+ struct strbuf_list *values = cb;
+ struct strbuf *buf;
char value[256];
const char *vptr = value;
int must_free_vptr = 0;
- int dup_error = 0;
int must_print_delim = 0;
if (!use_key_regexp && strcmp(key_, key))
@@ -126,12 +132,15 @@ static int show_config(const char *key_, const char *value_, void *cb)
(do_not_match ^ !!regexec(regexp, (value_?value_:""), 0, NULL, 0)))
return 0;
+ ALLOC_GROW(values->items, values->nr + 1, values->alloc);
+ buf = &values->items[values->nr++];
+ strbuf_init(buf, 0);
+
if (show_keys) {
- printf("%s", key_);
+ strbuf_addstr(buf, key_);
must_print_delim = 1;
}
- if (seen && !do_all)
- dup_error = 1;
+
if (types == TYPE_INT)
sprintf(value, "%d", git_config_int(key_, value_?value_:""));
else if (types == TYPE_BOOL)
@@ -153,16 +162,12 @@ static int show_config(const char *key_, const char *value_, void *cb)
vptr = "";
must_print_delim = 0;
}
- seen++;
- if (dup_error) {
- error("More than one value for the key %s: %s",
- key_, vptr);
- }
- else {
- if (must_print_delim)
- printf("%c", key_delim);
- printf("%s%c", vptr, term);
- }
+
+ if (must_print_delim)
+ strbuf_addch(buf, key_delim);
+ strbuf_addstr(buf, vptr);
+ strbuf_addch(buf, term);
+
if (must_free_vptr)
/* If vptr must be freed, it's a pointer to a
* dynamically allocated buffer, it's safe to cast to
@@ -175,20 +180,8 @@ static int get_value(const char *key_, const char *regex_)
static int get_value(const char *key_, const char *regex_)
{
- int ret = CONFIG_GENERIC_ERROR;
- char *global = NULL, *xdg = NULL, *repo_config = NULL;
- const char *system_wide = NULL, *local;
- struct config_include_data inc = CONFIG_INCLUDE_INIT;
- config_fn_t fn;
- void *data;
-
- local = given_config_file;
- if (!local) {
- local = repo_config = git_pathdup("config");
- if (git_config_system())
- system_wide = git_etc_gitconfig();
- home_config_paths(&global, &xdg, "config");
- }
+ struct strbuf_list values = {0};
+ int i;
if (use_key_regexp) {
char *tl;
@@ -211,14 +204,11 @@ static int get_value(const char *key_, const char *regex_)
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
free(key);
- ret = CONFIG_INVALID_PATTERN;
- goto free_strings;
+ return CONFIG_INVALID_PATTERN;
}
} else {
- if (git_config_parse_key(key_, &key, NULL)) {
- ret = CONFIG_INVALID_KEY;
- goto free_strings;
- }
+ if (git_config_parse_key(key_, &key, NULL))
+ return CONFIG_INVALID_KEY;
}
if (regex_) {
@@ -230,37 +220,12 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n", regex_);
- ret = CONFIG_INVALID_PATTERN;
- goto free_strings;
+ return CONFIG_INVALID_PATTERN;
}
}
- fn = show_config;
- data = NULL;
- if (respect_includes) {
- inc.fn = fn;
- inc.data = data;
- fn = git_config_include;
- data = &inc;
- }
-
- if (do_all && system_wide)
- git_config_from_file(fn, system_wide, data);
- if (do_all && xdg)
- git_config_from_file(fn, xdg, data);
- if (do_all && global)
- git_config_from_file(fn, global, data);
- if (do_all)
- git_config_from_file(fn, local, data);
- git_config_from_parameters(fn, data);
- if (!do_all && !seen)
- git_config_from_file(fn, local, data);
- if (!do_all && !seen && global)
- git_config_from_file(fn, global, data);
- if (!do_all && !seen && xdg)
- git_config_from_file(fn, xdg, data);
- if (!do_all && !seen && system_wide)
- git_config_from_file(fn, system_wide, data);
+ git_config_with_options(collect_config, &values,
+ given_config_file, respect_includes);
free(key);
if (regexp) {
@@ -268,16 +233,16 @@ static int get_value(const char *key_, const char *regex_)
free(regexp);
}
- if (do_all)
- ret = !seen;
- else
- ret = (seen == 1) ? 0 : seen > 1 ? 2 : 1;
+ if (!values.nr)
+ return 1;
-free_strings:
- free(repo_config);
- free(global);
- free(xdg);
- return ret;
+ for (i = 0; i < values.nr; i++) {
+ struct strbuf *buf = values.items + i;
+ if (do_all || i == values.nr - 1)
+ fwrite(buf->buf, 1, buf->len, stdout);
+ strbuf_release(buf);
+ }
+ return 0;
}
static char *normalize_value(const char *key, const char *value)
^ permalink raw reply related
* Re: [PATCH] remote-testgit: properly check for errors
From: Sverre Rabbelier @ 2012-10-22 21:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King, Shawn O. Pearce
In-Reply-To: <1350939394-21622-1-git-send-email-felipe.contreras@gmail.com>
On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> index 5f3ebd2..b8707e6 100644
> --- a/git-remote-testgit.py
> +++ b/git-remote-testgit.py
> @@ -159,6 +159,11 @@ def do_import(repo, args):
> ref = line[7:].strip()
> refs.append(ref)
>
> + print "feature done"
There's not enough context for me to see in which part of the code
this is, import or export? If you advertise 'feature done', shouldn't
you also print 'done' when you finish writing the fast-export stream?
If that's already the case feel free to ignore me :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] remote-testgit: properly check for errors
From: Felipe Contreras @ 2012-10-22 20:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce,
Felipe Contreras
'feature done' was missing, which allowed fast-import exit properly, and
transport-helper to continue checking for refs and what not when in fact
the remote-helper died.
Let's enable that, and make sure the error paths are triggered.
Now transport-helper correctly detects the errors from fast-import,
unfortunately, not from fast-export because it might finish before
detecting a SIGPIPE. This means transport-helper will quit silently and
the user will not see any errors, which is bad. Hopefully the helper
will print the error before dying anyway, so not all is lost.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-remote-testgit.py | 8 ++++++++
t/t5800-remote-helpers.sh | 21 +++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..b8707e6 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -159,6 +159,11 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
+ print "feature done"
+
+ if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
@@ -172,6 +177,9 @@ def do_export(repo, args):
if not repo.gitdir:
die("Need gitdir to export")
+ if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
update_local_repo(repo)
changed = repo.importer.do_import(repo.gitdir)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..446cc8e 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -145,4 +145,25 @@ test_expect_failure 'push new branch with old:new refspec' '
compare_refs clone HEAD server refs/heads/new-refspec
'
+test_expect_success 'proper failure checks for fetching' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ cd localclone &&
+ test_must_fail git fetch 2>&1 | \
+ grep "Error while running fast-import"
+ )
+'
+
+# We sleep to give fast-export a chance to catch the SIGPIPE
+test_expect_failure 'proper failure checks for pushing' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ GIT_REMOTE_TESTGIT_SLEEPY=1 &&
+ export GIT_REMOTE_TESTGIT_SLEEPY &&
+ cd localclone &&
+ test_must_fail git push --all 2>&1 | \
+ grep "Error while running fast-export"
+ )
+'
+
test_done
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v3 6/8] longest_ancestor_length(): require prefix list entries to be normalized
From: Johannes Sixt @ 2012-10-22 20:04 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, Jiang Xin, Lea Wiemann, David Reiss, git
In-Reply-To: <1350799057-13846-7-git-send-email-mhagger@alum.mit.edu>
Am 21.10.2012 07:57, schrieb Michael Haggerty:
> Move the responsibility for normalizing the prefixes passed to
> longest_ancestor_length() to its caller. In t0060, only test
> longest_ancestor_lengths using normalized paths: remove empty entries
> and non-absolute paths, strip trailing slashes from the paths, and
> remove tests that thereby become redundant.
t0060 does not pass on Windows with this change. Bash's path mangling
strikes again, but the real reason for the failure is that
test-path-util does not normalize its input before it calls into
longest_ancestor_length(). It is not sufficient to reduce the test cases
to normalized ones, because due to path mangling on Windows they are
turned into unnormalized paths (with backslashes instead of forward
slashes).
I suggest to export the new normalize_ceiling_entry() and use it from
test-path-util. Then don't change or remove existing tests.
-- Hannes
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 19:35 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <CAMP44s27oPMu8Goded-Tcw9_fmgRux3yiNvu0FBPUxHOdp1Zgw@mail.gmail.com>
On Mon, Oct 22, 2012 at 7:12 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
> I've tried everything, and yet a SIGPIPE is detected only with
> remote-testgit, not with my code, and they both exit the same way, and
> at the same time, and fast-export exits the main function (apparently
> a process can finish with SIGPIPE after main?)
>
> I have no idea what's going on, so I don't know if we need any extra
> code in transport-helper at all.
>
> Any ideas?
Must be a timing issue:
sh -c 'echo hello' | sh -c 'exit 1' -> no signal
sh -c 'echo hello' | /usr/bin/false -> SIGPIPE
I can trigger it by adding an extra delay:
This works:
test_expect_success 'proper failure checks for pushing 1' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Error while running fast-export" errors
'
This doesn't:
test_expect_success 'proper failure checks for pushing 2' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
export GIT_REMOTE_TESTGIT_SLEEPY=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Error while running fast-export" errors
'
This does:
test_expect_success 'proper failure checks for pushing 3' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
export GIT_REMOTE_TESTGIT_SLEEPY=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Told to fail" errors
'
So, depending on your luck, transport-helper might or might display an
error, it will exit at the right place nonetheless, because of:
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
exit(128);
}
Not ideal, but I guess it's not a big deal.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King @ 2012-10-22 16:34 UTC (permalink / raw)
To: Git; +Cc: W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This removes a configuration step if you're trying to setup Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
workflow from
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
If you're not using that workflow, I see no harm in recording the
branch used to determine the original submodule commit.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 4 ++++
t/t7400-submodule-basic.sh | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..b9f437f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -207,7 +207,8 @@ OPTIONS
-b::
--branch::
- Branch of repository to add as submodule.
+ Branch of repository to add as submodule. The branch name is
+ recorded in .gitmodules for future reference.
-f::
--force::
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..fd15a54 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -366,6 +366,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..5031e2a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test "$(git config -f .gitmodules submodule.submod-branch.branch)" = initial &&
git submodule init
) &&
--
1.8.0.2.g09b91ca
^ permalink raw reply related
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 17:12 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <CAMP44s1m9eVqqrgJFuWOBa3DCZAzAqpVwG8Nxn-6MbXWbF_2fw@mail.gmail.com>
On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> -> import-begin
> <- feature X
> <- feature Y
> -> import refs/heads/master
> <- exported stuff
> -> import refs/heads/devel
> <- exported stuff
> -> import-end
> <- done
>
> This would certainly makes things easier for transport-helpers that
> support multiple ref selections (like my remote-hg). Maybe I should
> add code that does this if certain feature is specified (so it doesn't
> break other helpers)
Never mind this, it's possible to do the same by assuming that all the
imports will be together, and finished by a line feed, so the code can
do:
if import
do import-begin stuff
while import
import stuff
do import-end stuff
Of course, this could break if for some reason transport-helper
changes, but that seems unlikely.
> But at least on my tests, even with 'feature done' the crash is not
> detected properly, either by the transport-helper, or fast-import.
Never mind this either; I was forcing the error before exporting that
feature. See the code at the end.
> And also, the msysgit branch does the same check for fast-export,
> which actually uses the 'done' feature always, so it should work fine,
> but perhaps because of the strange issue with fast-import I just
> mentioned, it's not actually detected. I should add tests for this
> too.
I have added tests for this, and the failure is detected reliably...
but only with remote-testgit, not with my remote-hg, and I've no idea
what is different.
I've tried everything, and yet a SIGPIPE is detected only with
remote-testgit, not with my code, and they both exit the same way, and
at the same time, and fast-export exits the main function (apparently
a process can finish with SIGPIPE after main?)
I have no idea what's going on, so I don't know if we need any extra
code in transport-helper at all.
Any ideas?
Here is what I have so far:
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..b8707e6 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -159,6 +159,11 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
+ print "feature done"
+
+ if os.getenv("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
@@ -172,6 +177,9 @@ def do_export(repo, args):
if not repo.gitdir:
die("Need gitdir to export")
+ if os.getenv("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
update_local_repo(repo)
changed = repo.importer.do_import(repo.gitdir)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..00b0cd3 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -145,4 +145,16 @@ test_expect_failure 'push new branch with old:new
refspec' '
compare_refs clone HEAD server refs/heads/new-refspec
'
+test_expect_success 'proper failure checks for fetching' '
+ export GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ (cd localclone && ! git fetch) 2> errors &&
+ grep -q "Error while running fast-import" errors
+'
+
+test_expect_success 'proper failure checks for pushing' '
+ export GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ (cd localclone && ! git push --all) 2> errors &&
+ grep -q "Error while running fast-export" errors
+'
+
test_done
--
Felipe Contreras
^ permalink raw reply related
* merging branches
From: Коньков Евгений @ 2012-10-22 16:33 UTC (permalink / raw)
To: git
Hi, Git.
While merging branches I get conflicts in files that I have not touch.
Why they occour??
My suggestion is that that files that was automerged GIT counts as
they were modified by me, so next automerge to those files fill FAIL.
If so, how I can escape from that CONFLICT situation?
--
С уважением,
Коньков Евгений
Программист
Регистратор доменных имен REG.RU
Телефон: +38 (097) 7654-676
www.reg.ru
___________________
Sincerely yours,
Konkov Eugen
Developer
Accredited domain Registrar REG.RU, LLC.
Phone: +38 (097) 7654-676
www.reg.ru/en/
mailto:kes@reg.ru
^ permalink raw reply
* git BUG
From: Коньков Евгений @ 2012-10-22 16:28 UTC (permalink / raw)
To: git
Hi, git
I have get git bug while merging branches.
the farm has branch one year old. say b1
I have develop some feature in this year so I start new branch
git checkout master
git checkout -b b2
I get task to develop feature b1. b1 require changes in b2
git checkout b1
git merge b2
git checkout --theirs
git commit
after some time I need new code from master
git merge master
after this merge I notice that some code, that was developed in b2, is
disappeared despite on it was merged into b1
so I start to merge it again:
git merge b2
No results. So I decide to do some testing. I go to b2
git checkout b2
make changes into file on b2:
diff --git a/lib/SRS/Domain.pm b/lib/SRS/Domain.pm
index 8fa1b1a..23a9429 100644
--- a/lib/SRS/Domain.pm
+++ b/lib/SRS/Domain.pm
@@ -2804,6 +2804,7 @@ sub can_renew_state {
sub zone {
my ( $self ) = @_;
+
load_class 'SRS::Comm::Zone::Domain';
return
I have add one empty line to subroutine that have developed in b2.
git commit
git checkout b1
git merge b2
and I get conflict:
+++ b/lib/SRS/Domain.pm
@@@ -2830,24 -2801,20 +2830,29 @@@ sub can_renew_state
=cut
-sub zone {
- my ( $self ) = @_;
+sub can_cancel_transin {
+ my $self = shift;
++<<<<<<< HEAD
+ return if $self->{freeze_date};
+ return unless $self->{create_method} eq 'trans' && $self->{state} eq 'N';
++=======
+
+ load_class 'SRS::Comm::Zone::Domain';
++>>>>>>> yandex_mail_new_api
- return
- SRS::Comm::Zone::Domain->new(
- dname => $self->{dname},
- service => $self,
- );
+ my ( $pos_id ) = dbh_rw->selectrow_array(
+ 'SELECT bi.pos_id FROM billitems bi JOIN bills b ON b.bill_id = bi.bill_id WHERE service_id =
+ undef,
+ $self->{service_id}, $self->{user_id}
+ );
+
+ return $pos_id;
}
-=back
+=item cancel_transin
+
+Ф-ция отмены переноса
=cut
As you can see conflict at 'can_cancel_transin' subroutine
but I do changes in 'zone' subroutine
Please help to resolve that CONFLICT and return code from b2 to be
alive again in b1.
And, if you can, please explain why this occur
--
С уважением,
Коньков Евгений
Программист
Регистратор доменных имен REG.RU
Телефон: +38 (097) 7654-676
www.reg.ru
___________________
Sincerely yours,
Konkov Eugen
Developer
Accredited domain Registrar REG.RU, LLC.
Phone: +38 (097) 7654-676
www.reg.ru/en/
mailto:kes@reg.ru
^ permalink raw reply related
* The config include mechanism doesn't allow for overwriting
From: Ævar Arnfjörð Bjarmason @ 2012-10-22 15:55 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, Junio C Hamano
I was hoping to write something like this:
[user]
name = Luser
email = some-default@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-email@example.com
But when you do that git prints:
$ git config --get user.email
some-default@example.com
error: More than one value for the key user.email: local-email@example.com
I couldn't find information in either the commt that introduced the
feature or the documentation explaining whether this was the intent or
not.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:47 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <508459B3.6030403@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> The problem is that I don't have the time to split all these out. Dag
> has indicated that he does not have the time either.
I would have the time to review and integrate separate patches. I do
not have time to unwrap the ball of wax and ensure the quality of each
feature and bug fix. That is the responsibility of the submitter. You
can't expect reviewers to do your work for you. I'm not being harsh, it
is simply the reality of how things work in every project I've been
involved with.
> This single ball of wax was already an alternative to the 'messy' merge
> history it had accumulated. The result of merging from dozens of github
> forks with numerous levels of parallel/contra-productive whitspace fixes.
Yes, we don't really want that history. You have a single patch now. A
series of git rebase -i + git add -i should make it easy to separate it
into patches for each feature and bug fix, as I suggested previously.
It really, really shouldn't be that hard unless the code is atrocious.
-David
^ permalink raw reply
* git daemon test fails
From: Joachim Schmitz @ 2012-10-22 14:48 UTC (permalink / raw)
To: git
Here's one test failing (on HP NonStop, git-1.8.0), which needs to get enable first.
/home/jojo/git/git/t $ PATH=/usr/local/bin:$PATH GIT_TEST_GIT_DAEMON=true bash ./t5570-git-daemon.sh
ok 1 - setup repository
ok 2 - create git-accessible bare repository
ok 3 - clone git repository
[946798748] Connection from 127.0.0.1:1569
[946798748] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[946798748] Request upload-pack for '/repo.git'
[577699972] [946798748] Disconnected
ok 4 - fetch changes via git protocol
[275710128] Connection from 127.0.0.1:1570
[275710128] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[275710128] Request upload-pack for '/repo.git'
[577699972] [275710128] Disconnected
not ok 5 - remote detects correct HEAD # TODO known breakage
ok 6 - prepare pack objects
ok 7 - fetch notices corrupt pack
[611254461] Connection from 127.0.0.1:1571
[611254461] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[611254461] Request upload-pack for '/repo_bad2.git'
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: unable to find 8a64388133550192054d8f512739602b36fdd015
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: refs/heads/master does not point to a valid object!
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: refs/heads/other does not point to a valid object!
[611254461] error: git upload-pack: git-pack-objects died with error.
[611254461] fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
[577699972] [611254461] Disconnected (with error)
ok 8 - fetch notices corrupt idx
[711917757] Connection from 127.0.0.1:9908
[711917757] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[711917757] Request upload-pack for '/nowhere.git'
[711917757] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository
[577699972] [711917757] Disconnected (with error)
ok 9 - clone non-existent
[779026621] Connection from 127.0.0.1:9909
[779026621] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[779026621] Request receive-pack for '/repo.git'
[779026621] 'receive-pack': service not enabled for '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git'
[577699972] [779026621] Disconnected (with error)
ok 10 - push disabled
[846135485] Connection from 127.0.0.1:9910
[846135485] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[846135485] Request upload-pack for '/repo.git'
[846135485] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git' does not appear to be a git repository
[577699972] [846135485] Disconnected (with error)
ok 11 - read access denied
[913244349] Connection from 127.0.0.1:9911
[913244349] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[913244349] Request upload-pack for '/repo.git'
[913244349] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git': repository not exported.
[577699972] [913244349] Disconnected (with error)
ok 12 - not exported
[1013907645] Connection from 127.0.0.1:9912
[1013907645] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[1013907645] Request upload-pack for '/nowhere.git'
[1013907645] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository
[577699972] [1013907645] Disconnected (with error)
not ok - 13 clone non-existent
# test_remote_error 'no such repository' clone nowhere.git
ok 14 - push disabled
ok 15 - read access denied
ok 16 - not exported
# still have 1 known breakage(s)
# failed 1 among remaining 15 test(s)
1..16
So one test fails.
But in real live here on HP NonStop "git clone" fails for any repository larger than a certain size (56k?) and it fails on the
daemon side (as e.g. a "git clone git://Gitgub/com/git/git.git" works just fine)
$ git clone git://localhost/some-repo.git
Cloning into 'some-repo'...
remote: warning: no threads support, ignoring --threads
remote: Counting objects: 485, done.
remote: Compressing objects: 100% (472/472), done. <<<< here it sits forever or until a timeout hits (if one is configured)
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
If I allow upload-archive, I get some 47k downloaded, then it hangs (and doesn't get killed by a timeout, so that "git-daemon
--timeout" only affects upload-pack apparently?)
Also it is always only a tar file, regardless whether I request zip, tar or tar.gz.
Any ideas anyone?
Bye, Jojo
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Herman van Rink, greened, Hilco Wijbenga, Git Users
In-Reply-To: <7vfw57fvtl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I haven't formed an opinion on the particular change as to how bad
> its collapsing unrelated changes into a single change is. Maybe they
> are not as unrelated and form a coherent whole. Maybe not.
It is difficult for me to tell which is one of the red flags that caused
me to request breaking it up. It's much to hard to review this patch as
it is. It conflates multiple features and bug fixes. It includes
comments to the effect of, "I don't like this but I don't know of a
better way." Part of the reson we do reviews is to have people help out
and find a better way. I don't think people can do that with the way
the patch is currently structured.
> Note that I was not following the thread very closely, so I may have
> misread the discussion. I read his "Unless Junio accepts..." to
> mean "I (dag) still object, but if Junio accepts that patch I object
> to directly, there is nothing I can do about it". That is very
> different from "I am on the fence and cannot decide it is a good
> patch or not. I'll let Junio decide; I am OK as long as he is".
Yopur first reading is the correct one.
-David
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:41 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <5084102A.2010006@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>> Herman van Rink <rink@initfour.nl> writes:
>>
>>> Junio, Could you please consider merging the single commit from my
>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>> In general, in areas like contrib/ where there is a volunteer area
>> maintainer, unless the change something ultra-urgent (e.g. serious
>> security fix) and the area maintainer is unavailable, I'm really
>> reluctant to bypass and take a single patch that adds many things
>> that are independent from each other.
>
> Who do you see as volunteer area maintainer for contrib/subtree?
> My best guess would be Dave. And he already indicated earlier in the
> thread to be ok with the combined patch as long as you are ok with it.
Let's be clear. Junio owns the project so what he says goes, no
question. I provided some review feedback which I thought would help
the patches get in more easily. We really shouldn't be adding multiple
features in one patch. This is easily separated into multiple patches.
Then there is the issue of testcases. We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment. We should use what the
usptream project uses. That will make mainlining this much easier in
the future.
If Junio is ok with overriding my decisions here, that's fine. But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy. Certainly easier than convincing me
they are in good shape currently. :)
-David
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 14:31 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <50854E20.1040303@viscovery.net>
On Mon, Oct 22, 2012 at 3:46 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 10/22/2012 13:50, schrieb Felipe Contreras:
>> On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Another thought: In your use-case, isn't it so that it would be an error
>>> that the process exited for whatever reason? I.e., even if it exited with
>>> code 0 ("success"), it would be an error because it violated the protocol?
>>
>> How is that violating the protocol?
>
> Because the helper stops talking too early. But as I said, I actually
> don't know the protocol.
We could use the 'feature done' of fast-import, but this causes
problems because of the way transport-helper uses it:
-> import refs/heads/master
<- exported stuff
<- done
-> import refs/heads/devel
<- exported stuff
<- done
'done' will terminate the fast-import process, so the second exported
stuff won't be processed; the fast-import process is reused.
For some reason remote-testgit doesn't exercise this multiple import
stuff properly, but my remote-hg certainly does, so I can't just say
'done'.
It would be much better if the transport-helper protocol was something
like this:
-> import-begin
<- feature X
<- feature Y
-> import refs/heads/master
<- exported stuff
-> import refs/heads/devel
<- exported stuff
-> import-end
<- done
This would certainly makes things easier for transport-helpers that
support multiple ref selections (like my remote-hg). Maybe I should
add code that does this if certain feature is specified (so it doesn't
break other helpers)
But at least on my tests, even with 'feature done' the crash is not
detected properly, either by the transport-helper, or fast-import.
And also, the msysgit branch does the same check for fast-export,
which actually uses the 'done' feature always, so it should work fine,
but perhaps because of the strange issue with fast-import I just
mentioned, it's not actually detected. I should add tests for this
too.
> I was just infering what I saw in transport-helper.c: get_helper() dup's
> the output of the helper process and stores it in data->out (after
> fdopen()ing on it). (The original file descriptor is handed over to
> fast-import or fast-export.)
>
> Actually, I didn't find a spot where data->out was used except to fclose()
> it. But I take it that there is a reason that it exists and infer that
> further output from the helper is expected by something after fast-import
> or fast-export have exited.
>
> But I may be completely off...
Yes, further output is expected, or at least in theory.
Cheers.
--
Felipe Contreras
^ 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