* [StGit PATCH 1/2] Rename the mail --refid and --noreply options to match Git
From: Catalin Marinas @ 2010-01-07 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
The new option names are --in-reply-to and --no-thread.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/mail.py | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 8ff0bd4..a78c9d2 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -56,7 +56,7 @@ specified file (defaulting to '.git/covermail.tmpl' or
All the subsequent e-mails appear as replies to the first e-mail sent
(either the preamble or the first patch). E-mails can be seen as
-replies to a different e-mail by using the '--refid' option.
+replies to a different e-mail by using the '--in-reply-to' option.
SMTP authentication is also possible with '--smtp-user' and
'--smtp-password' options, also available as configuration settings:
@@ -107,7 +107,7 @@ options = [
short = 'Add BCC to the Bcc: list'),
opt('--auto', action = 'store_true',
short = 'Automatically cc the patch signers'),
- opt('--noreply', action = 'store_true',
+ opt('--no-thread', action = 'store_true',
short = 'Do not send subsequent messages as replies'),
opt('--unrelated', action = 'store_true',
short = 'Send patches without sequence numbering'),
@@ -127,7 +127,7 @@ options = [
short = 'Edit each patch before sending'),
opt('-s', '--sleep', type = 'int', metavar = 'SECONDS',
short = 'Sleep for SECONDS between e-mails sending'),
- opt('--refid',
+ opt('--in-reply-to', metavar = 'REFID',
short = 'Use REFID as the reference id'),
opt('--smtp-server', metavar = 'HOST[:PORT] or "/path/to/sendmail -t -i"',
short = 'SMTP server or command to use for sending mail'),
@@ -495,7 +495,7 @@ def __build_cover(tmpl, msg_id, options, patches):
if not options.git:
__build_address_headers(msg, options)
- __build_extra_headers(msg, msg_id, options.refid)
+ __build_extra_headers(msg, msg_id, options.in_reply_to)
__encode_message(msg)
return msg
@@ -638,11 +638,11 @@ def func(parser, options, args):
if total_nr == 0:
raise CmdException, 'No patches to send'
- if options.refid:
- if options.noreply or options.unrelated:
+ if options.in_reply_to:
+ if options.no_thread or options.unrelated:
raise CmdException, \
- '--refid option not allowed with --noreply or --unrelated'
- ref_id = options.refid
+ '--in-reply-to option not allowed with --no-thread or --unrelated'
+ ref_id = options.in_reply_to
else:
ref_id = None
@@ -663,7 +663,7 @@ def func(parser, options, args):
msg_id = __send_message('cover', tmpl, options, patches)
# subsequent e-mails are seen as replies to the first one
- if not options.noreply:
+ if not options.no_thread:
ref_id = msg_id
# send the patches
@@ -681,5 +681,5 @@ def func(parser, options, args):
msg_id = __send_message('patch', tmpl, options, p, n, total_nr, ref_id)
# subsequent e-mails are seen as replies to the first one
- if not options.noreply and not options.unrelated and not ref_id:
+ if not options.no_thread and not options.unrelated and not ref_id:
ref_id = msg_id
^ permalink raw reply related
* [StGit PATCH 2/2] Pass the --in-reply-to and --no-thread options to git send-email
From: Catalin Marinas @ 2010-01-07 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20100107160932.3226.95737.stgit@pc1117.cambridge.arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/mail.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index a78c9d2..b6f5d8d 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -241,6 +241,10 @@ def __send_message_git(msg, options):
cmd.append("--suppress-cc=self")
if not options.auto:
cmd.append("--suppress-cc=body")
+ if options.in_reply_to:
+ cmd.append("--in-reply-to %s" % options.in_reply_to)
+ if options.no_thread:
+ cmd.append("--no-thread")
# We only support To/Cc/Bcc in git send-email for now.
for x in ['to', 'cc', 'bcc']:
^ permalink raw reply related
* [PATCH] Documentation: do not advertise --all in git-pull(1)
From: Thomas Rast @ 2010-01-07 16:09 UTC (permalink / raw)
To: git; +Cc: Zing, Björn Gustavsson, Junio C Hamano
In-Reply-To: <hi2mu8ob@ger.gmane.org>
Since 9c4a036 (Teach the --all option to 'git fetch', 2009-11-09), we
document git-fetch's option --all in fetch-options.txt. However, that
file is also included by git-pull.txt, where the option makes no
sense.
Wrap the option with ifdef so that it does not appear on the git-pull
manpage.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Zing <zing@fastmail.fm> wrote:
> In 1.6.6, if I do:
>
> $ git pull --all
> Fetching origin
> Fetching gnome
> You asked to pull from the remote '--all', but did not specify
> a branch. Because this is not the default configured remote
> for your current branch, you must specify a branch on the command line.
This one fixes the documentation problem, but I think there's a deeper
misunderstanding. What did you hope to do with 'git pull --all'? I
suspect most people on this list would take it to mean "fetch all
branches from all remotes, and merge them into HEAD". I cannot
imagine a use-case where that would make any sense. (And it wouldn't
work, because the current implementation of 'git fetch --all' leaves
only the last remote's branches in FETCH_HEAD.)
>From earlier discussions on the non-intuitiveness of git-pull, I kind
of suspect you wanted to fetch all remotes, and then "update" all
local branches that track some remote with their corresponding
remote-tracking branches. In which case the question is: why do you
use local branches if you have them "blindly" track the upstream?
Documentation/fetch-options.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ab6419f..6271615 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,5 +1,7 @@
+ifndef::git-pull[]
--all::
Fetch all remotes.
+endif::git-pull[]
-a::
--append::
--
1.6.6.202.gdf32a
^ permalink raw reply related
* git-send-email, prompt for Message-ID: bug or feature?
From: Matthieu Moy @ 2010-01-07 16:59 UTC (permalink / raw)
To: git
Hi,
When I send a mail with
git send-email -s --to git@vger.kernel.org --annotate -1
I normally get prompted for my from address, and then "Message-ID to
be used as In-Reply-To for the first email?".
If I set sendemail.from to avoid the first question, then the same
question doesn't ask for a Message-ID anymore.
This behavior seems to have been introduced here:
commit 1f038a0c31e06e7a248be0990549ac717399c540
Author: Ryan Anderson <ryan@michonline.com> Mon Sep 5 07:13:07 2005
Committer: Junio C Hamano <junkio@cox.net> Mon Sep 5 08:33:17 2005
[PATCH] Make git-send-email-script ignore some unnecessary options when operating in batch mode.
Add a "--compose" option that uses $EDITOR to edit an "introductory" email to the patch series.
I understand the need to be possibly non-interactive, but how does one
get git send-email ask just one question for the Message-ID, and skip
the others?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 1/2] Documentation/git-merge: reword references to "remote" and "pull"
From: Thomas Rast @ 2010-01-07 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The git-merge manpage was written in terms of merging a "remote",
which is no longer the case: you merge local or remote-tracking
branches; pull is for actual remotes.
Adjust the manpage accordingly. We refer to the arguments as
"commits", and change instances of "remote" to "other" (where branches
are concerned) or "theirs" (where conflict sides are concerned).
Remove the single reference to "pulling".
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Out of sheer curiosity:
The git-merge manpage was written in terms of merging a "remote",
which is no longer the case
Was this ever the case? Or is it just stale terminology?
Documentation/git-merge.txt | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e886c2e..7dbde7a 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,17 +10,17 @@ SYNOPSIS
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
- [-m <msg>] <remote>...
-'git merge' <msg> HEAD <remote>...
+ [-m <msg>] <commit>...
+'git merge' <msg> HEAD <commit>...
DESCRIPTION
-----------
-This is the top-level interface to the merge machinery
-which drives multiple merge strategy scripts.
+Merges the history specified by <commit> into HEAD, optionally using a
+specific merge strategy.
-The second syntax (<msg> `HEAD` <remote>) is supported for
+The second syntax (<msg> `HEAD` <commit>...) is supported for
historical reasons. Do not use it from the command line or in
-new scripts. It is the same as `git merge -m <msg> <remote>`.
+new scripts. It is the same as `git merge -m <msg> <commit>...`.
OPTIONS
@@ -33,10 +33,10 @@ include::merge-options.txt[]
used to give a good default for automated 'git merge'
invocations.
-<remote>...::
- Other branch heads to merge into our branch. You need at
- least one <remote>. Specifying more than one <remote>
- obviously means you are trying an Octopus.
+<commit>...::
+ Commits, usually other branch heads, to merge into our branch.
+ You need at least one <commit>. Specifying more than one
+ <commit> obviously means you are trying an Octopus.
include::merge-strategies.txt[]
@@ -96,8 +96,8 @@ file matches exactly the current `HEAD` commit; otherwise we
will write out your local changes already registered in your
index file along with the merge result, which is not good.
Because 1. involves only those paths differing between your
-branch and the remote branch you are pulling from during the
-merge (which is typically a fraction of the whole tree), you can
+branch and the branch you are merging
+(which is typically a fraction of the whole tree), you can
have local modifications in your working tree as long as they do
not overlap with what the merge updates.
@@ -110,7 +110,7 @@ When there are conflicts, the following happens:
3. For conflicting paths, the index file records up to three
versions; stage1 stores the version from the common ancestor,
- stage2 from `HEAD`, and stage3 from the remote branch (you
+ stage2 from `HEAD`, and stage3 from the other branch (you
can inspect the stages with `git ls-files -u`). The working
tree files contain the result of the "merge" program; i.e. 3-way
merge results with familiar conflict markers `<<< === >>>`.
@@ -202,15 +202,15 @@ You can work through the conflict with a number of tools:
mergetool which will work you through the merge.
* Look at the diffs. 'git diff' will show a three-way diff,
- highlighting changes from both the HEAD and remote versions.
+ highlighting changes from both the HEAD and 'theirs' versions.
* Look at the diffs on their own. 'git log --merge -p <path>'
will show diffs first for the HEAD version and then the
- remote version.
+ 'theirs' version.
* Look at the originals. 'git show :1:filename' shows the
common ancestor, 'git show :2:filename' shows the HEAD
- version and 'git show :3:filename' shows the remote version.
+ version and 'git show :3:filename' shows 'their' version.
EXAMPLES
--
1.6.6.202.gdf32a
^ permalink raw reply related
* [NON-PATCH 3/2] Documentation/git-merge: format full commands in typewriter font
From: Thomas Rast @ 2010-01-07 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <2e53c91e536e1ff585bc7464c1b8863e6cc45c45.1262883414.git.trast@student.ethz.ch>
Use `code snippet` style instead of 'emphasis' for the full commands
specified in the "how to resolve conflicts" section.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Not intended for application, but for discussion.
I originally wanted to tack this on the series as an "obvious
cleanup", but then I noticed two things:
* While the general trend as per
git grep '`git '
git grep \''git '
seems to go towards the `code` style where full commands are
concerned, and the 'emphasis' where only a git-command is named,
this is not consistent yet. Especially the git-svn manpage seems to
have a few hybrids.
* More importantly, while `code` style seems to be an improvement in
HTML output (because it gives typewriter font), my local 'man'
renders 'emphasis' as underlines -- which actually makes the code
snippets much more visible than `literal` quotes which are not
rendered specially at all.
So which way should it be changed?
Documentation/git-merge.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index b224daf..e04c800 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -193,7 +193,7 @@ After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-ups you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; 'git-reset --hard' can
+ up working tree changes made by 2. and 3.; `git-reset --hard` can
be used for this.
* Resolve the conflicts. Git will mark the conflicts in
@@ -202,19 +202,19 @@ After seeing a conflict, you can do two things:
You can work through the conflict with a number of tools:
- * Use a mergetool. 'git mergetool' to launch a graphical
+ * Use a mergetool. `git mergetool` to launch a graphical
mergetool which will work you through the merge.
- * Look at the diffs. 'git diff' will show a three-way diff,
+ * Look at the diffs. `git diff` will show a three-way diff,
highlighting changes from both the HEAD and 'theirs' versions.
- * Look at the diffs on their own. 'git log --merge -p <path>'
+ * Look at the diffs on their own. `git log --merge -p <path>`
will show diffs first for the HEAD version and then the
'theirs' version.
- * Look at the originals. 'git show :1:filename' shows the
- common ancestor, 'git show :2:filename' shows the HEAD
- version and 'git show :3:filename' shows 'their' version.
+ * Look at the originals. `git show :1:filename` shows the
+ common ancestor, `git show :2:filename` shows the HEAD
+ version and `git show :3:filename` shows 'their' version.
EXAMPLES
--
1.6.6.202.gdf32a
^ permalink raw reply related
* origin/branchname and tracking branch pointing to different commits?
From: Eugene Sajine @ 2010-01-07 17:03 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
Could you, please, help me to understand how it is possible to have a
tracking branch named qa which tracks origin/qa both pointing to
different commits after git pull origin qa?
I.e. I currently see this picture in my repository when
$ git co qa
$git log
gives me qa branch history advanced by 4 commits comparing to origin/qa
while
$git pull origin qa
says it is already up to date
So, generally, speaking qa branch is fine and is in synch with the
remote mainline, but the state of local origin/qa is not clear.
Thanks,
Eugene
^ permalink raw reply
* [PATCH 2/2] Documentation: warn prominently against merging with dirty trees
From: Thomas Rast @ 2010-01-07 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <2e53c91e536e1ff585bc7464c1b8863e6cc45c45.1262883414.git.trast@student.ethz.ch>
We do this for both git-merge and git-pull, so as to hopefully alert
(over)users of git-pull to the issue.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-merge.txt | 4 ++++
Documentation/git-pull.txt | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 7dbde7a..b224daf 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -22,6 +22,10 @@ The second syntax (<msg> `HEAD` <commit>...) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m <msg> <commit>...`.
+*Warning*: Running 'git-merge' with uncommitted changes is
+discouraged: while possible, it leaves you in a state that is hard to
+back out of in the case of a conflict.
+
OPTIONS
-------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index b932011..b3fa312 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -24,6 +24,10 @@ when merging local branches into the current branch.
Also note that options meant for 'git-pull' itself and underlying
'git-merge' must be given before the options meant for 'git-fetch'.
+*Warning*: Running 'git-pull' (actually, the underlying 'git-merge')
+with uncommitted changes is discouraged: while possible, it leaves you
+in a state that is hard to back out of in the case of a conflict.
+
OPTIONS
-------
--
1.6.6.202.gdf32a
^ permalink raw reply related
* Re: origin/branchname and tracking branch pointing to different commits?
From: Matthieu Moy @ 2010-01-07 17:06 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> gives me qa branch history advanced by 4 commits comparing to
> origin/qa
This means you have local commits which are not in the remote branch.
> $git pull origin qa
If you want to send your local commits, use "git push".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This is a hack, to scratch my itch. These patches add "git ls",
which is equivalent to "git ls-files --max-depth 1|column"
Anyone up for coloring? ;)
Nguyễn Thái Ngọc Duy (3):
ls-files: support --max-depth
ls-files: support -o --max-depth (more of a hack as fill_directory
should support this)
Add "ls", which is basically ls-files with user-friendly settings
builtin-ls-files.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
3 files changed, 74 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/3] ls-files: support --max-depth
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 7382157..2bb851a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -30,6 +30,7 @@ static int error_unmatch;
static char *ps_matched;
static const char *with_tree;
static int exc_given;
+static int max_depth = 0;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -232,6 +233,30 @@ static void prune_cache(const char *prefix)
active_nr = last;
}
+/*
+ * It is assumed that prune_cache() as been called before this
+ */
+static void prune_cache_by_depth(const char *prefix, int max_depth)
+{
+ int i = active_nr-1;
+
+ while (i >= 0) {
+ int slashes = 0;
+ const char *entry = active_cache[i]->name + prefix_len;
+ while ((entry = strchr(entry, '/')) != NULL) {
+ slashes++;
+ if (slashes >= max_depth) {
+ memmove(active_cache + i, active_cache + i + 1,
+ (active_nr - i - 1) * sizeof(struct cache_entry *));
+ active_nr--;
+ break;
+ }
+ entry++;
+ }
+ i--;
+ }
+}
+
static const char *verify_pathspec(const char *prefix)
{
const char **p, *n, *prev;
@@ -476,6 +501,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
"if any <file> is not in the index, treat this as an error"),
OPT_STRING(0, "with-tree", &with_tree, "tree-ish",
"pretend that paths removed since <tree-ish> are still present"),
+ OPT_INTEGER(0, "max-depth", &max_depth, "max recursive depth"),
OPT__ABBREV(&abbrev),
OPT_END()
};
@@ -541,6 +567,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
if (prefix)
prune_cache(prefix);
+
+ if (max_depth)
+ prune_cache_by_depth(prefix, max_depth);
+
if (with_tree) {
/*
* Basic sanity check; show-stages and show-unmerged
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 2/3] ls-files: support -o --max-depth (more of a hack as fill_directory should support this)
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2bb851a..e16638e 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -51,6 +51,17 @@ static void show_dir_entry(const char *tag, struct dir_entry *ent)
if (!match_pathspec(pathspec, ent->name, ent->len, len, ps_matched))
return;
+ if (max_depth) {
+ int slashes = 0;
+ const char *entry = ent->name + prefix_offset;
+ while ((entry = strchr(entry, '/')) != NULL) {
+ slashes++;
+ if (slashes >= max_depth)
+ return;
+ entry++;
+ }
+ }
+
fputs(tag, stdout);
write_name_quoted(ent->name + offset, stdout, line_terminator);
}
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 31 +++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index e16638e..f63b039 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -11,6 +11,7 @@
#include "builtin.h"
#include "tree.h"
#include "parse-options.h"
+#include "run-command.h"
static int abbrev;
static int show_deleted;
@@ -31,6 +32,7 @@ static char *ps_matched;
static const char *with_tree;
static int exc_given;
static int max_depth = 0;
+static int show_colums = 0;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -461,6 +463,7 @@ static int option_parse_exclude_standard(const struct option *opt,
int cmd_ls_files(int argc, const char **argv, const char *prefix)
{
+ struct child_process cp;
int require_work_tree = 0, show_tag = 0;
struct dir_struct dir;
struct option builtin_ls_files_options[] = {
@@ -513,6 +516,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "with-tree", &with_tree, "tree-ish",
"pretend that paths removed since <tree-ish> are still present"),
OPT_INTEGER(0, "max-depth", &max_depth, "max recursive depth"),
+ OPT_BOOLEAN(0, "columns", &show_colums, "show in columns"),
OPT__ABBREV(&abbrev),
OPT_END()
};
@@ -591,6 +595,20 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
die("ls-files --with-tree is incompatible with -s or -u");
overlay_tree_on_cache(with_tree, prefix);
}
+
+ if (show_colums) {
+ const char *argv[] = { "column", NULL };
+
+ memset(&cp, 0, sizeof(cp));
+ cp.in = -1;
+ cp.out = dup(1);
+ cp.argv = argv;
+ start_command(&cp);
+ close(1);
+ dup2(cp.in, 1);
+ close(cp.in);
+ }
+
show_files(&dir, prefix);
if (ps_matched) {
@@ -602,5 +620,18 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
return bad ? 1 : 0;
}
+ if (show_colums) {
+ fflush(stdout);
+ close(1);
+ finish_command(&cp);
+ }
+
return 0;
}
+
+int cmd_ls(int argc, const char **argv, const char *prefix)
+{
+ max_depth = 1;
+ show_colums = 1;
+ return cmd_ls_files(argc, argv, prefix);
+}
diff --git a/builtin.h b/builtin.h
index c3f83c0..d8980e5 100644
--- a/builtin.h
+++ b/builtin.h
@@ -61,6 +61,7 @@ extern int cmd_init_db(int argc, const char **argv, const char *prefix);
extern int cmd_log(int argc, const char **argv, const char *prefix);
extern int cmd_log_reflog(int argc, const char **argv, const char *prefix);
extern int cmd_ls_files(int argc, const char **argv, const char *prefix);
+extern int cmd_ls(int argc, const char **argv, const char *prefix);
extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_ls_remote(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 11544cd..4aff5ec 100644
--- a/git.c
+++ b/git.c
@@ -323,6 +323,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "init-db", cmd_init_db },
{ "log", cmd_log, RUN_SETUP | USE_PAGER },
{ "ls-files", cmd_ls_files, RUN_SETUP },
+ { "ls", cmd_ls, RUN_SETUP },
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
{ "ls-remote", cmd_ls_remote },
{ "mailinfo", cmd_mailinfo },
--
1.6.6.315.g1a406
^ permalink raw reply related
* Re: origin/branchname and tracking branch pointing to different commits?
From: Thomas Rast @ 2010-01-07 17:12 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com>
Eugene Sajine wrote:
> $git pull origin qa
[...]
> So, generally, speaking qa branch is fine and is in synch with the
> remote mainline, but the state of local origin/qa is not clear.
'git pull $remote $branch' does not update the $remote/$branch
remote-tracking branch; it stores in FETCH_HEAD and merges straight
from there.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: origin/branchname and tracking branch pointing to different commits?
From: Eugene Sajine @ 2010-01-07 17:25 UTC (permalink / raw)
To: Thomas Rast, git
In-Reply-To: <201001071813.01187.trast@student.ethz.ch>
On Thu, Jan 7, 2010 at 12:12 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Eugene Sajine wrote:
>> $git pull origin qa
> [...]
>> So, generally, speaking qa branch is fine and is in synch with the
>> remote mainline, but the state of local origin/qa is not clear.
>
> 'git pull $remote $branch' does not update the $remote/$branch
> remote-tracking branch; it stores in FETCH_HEAD and merges straight
> from there.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Yep. That's what i though it is. I.e. origin/branchname will point
always to the last pushed commit only. Isn't it a bit strange that git
fetch doesn't update origin/qa?
Probably the problem is that whenever I'm pulling or pushing to remote
repo i expect the last updated state of particular remote branch to be
reflected in origin/branchname, but IMHO it is correct expectation...
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Matthieu Moy @ 2010-01-07 17:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This is a hack, to scratch my itch. These patches add "git ls",
> which is equivalent to "git ls-files --max-depth 1|column"
You also want --exclude-standard to be the default in porcelain.
I've had "alias.ls = ls-files --exclude-standard" for a while in my
~/.gitconfig ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Nguyen Thai Ngoc Duy @ 2010-01-07 17:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq3a2hlsnx.fsf@bauges.imag.fr>
On 1/8/10, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > This is a hack, to scratch my itch. These patches add "git ls",
> > which is equivalent to "git ls-files --max-depth 1|column"
>
>
> You also want --exclude-standard to be the default in porcelain.
>
> I've had "alias.ls = ls-files --exclude-standard" for a while in my
> ~/.gitconfig ;-).
Yeah, just added that after realizing "git ls -o" is too annoying.
--
Duy
^ permalink raw reply
* Re: base85: Two tiny fixes
From: Nicolas Pitre @ 2010-01-07 17:58 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001071558.30065.agruen@suse.de>
On Thu, 7 Jan 2010, Andreas Gruenbacher wrote:
> While looking at the base85 code I found a bug in the debug code and an
> unnecessary call. You may want to have a look at the two fixes here:
>
> http://www.kernel.org/pub/scm/linux/kernel/git/agruen/git.git
ACK. Please post them to this list.
> There is another little oddity in the way the de85 table is set up: 0
> indicates an invalid entry; to avoid this from clashing with a valid entry,
> valid entries are incremented by one and decremented again while decoding.
> This leads to slightly worse code than using a negative number to indicate
> invalid values (and avoiding to increment/decrement).
You can make a patch to modify that as well if you wish. And in that
case don't forget to make de85 explicitly signed as a char is unsigned
by default on some platforms.
Nicolas
^ permalink raw reply
* Strange happening with 'git fetch'
From: David Kirk @ 2010-01-07 17:59 UTC (permalink / raw)
To: git
This is very strange, and defies the understanding of everyone in the
office familiar with git. Is it a bug, or some feature we don't
understand?
Basically, when I do a 'git fetch', it updates my local repository.
Now nobody else is doing anything, so the remote repository does not
change. Doing another 'git fetch' should report that nothing needs to
be done and nothing should change. But instead, it reports something
about the remote HEAD, and changes my local branch 'master' to some
strange location! Running 'git fetch' again restores it to the
correct state, reporting that it is updating 'master'. Repeated
invocations will toggle between these two results. Below is a
transcript from the bash shell.
Can someone please explain this?
---- bash console ----
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 03c60a4...209b0bc HEAD -> origin/HEAD (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 209b0bc...03c60a4 master -> origin/master (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 03c60a4...209b0bc HEAD -> origin/HEAD (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 209b0bc...03c60a4 master -> origin/master (forced update)
Thanks,
-David
^ permalink raw reply
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +
> + if (show_colums) {
> + const char *argv[] = { "column", NULL };
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.in = -1;
> + cp.out = dup(1);
> + cp.argv = argv;
> + start_command(&cp);
> + close(1);
> + dup2(cp.in, 1);
> + close(cp.in);
> + }
I think the code for columnar output used in producing "git help -a"
output should be reusable (if not, should be made reusable and reused
here).
^ permalink raw reply
* Re: [PATCH 2/3] ls-files: support -o --max-depth (more of a hack as fill_directory should support this)
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Subject: Re: [PATCH 2/3] ls-files: support -o --max-depth (more of a hack
as fill_directory should support this)
Perhaps you would want to look at how builtin_grep()'s walker and the
walker in dir.c can be consolidated? The former has support for
max_depth.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-merge: reword references to "remote" and "pull"
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <2e53c91e536e1ff585bc7464c1b8863e6cc45c45.1262883414.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The git-merge manpage was written in terms of merging a "remote",
> which is no longer the case: you merge local or remote-tracking
> branches; pull is for actual remotes.
>
> Adjust the manpage accordingly. We refer to the arguments as
> "commits", and change instances of "remote" to "other" (where branches
> are concerned) or "theirs" (where conflict sides are concerned).
> Remove the single reference to "pulling".
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
Looks sensible, modulo a few "'theirs' version" that I think should simply
be "their version".
> Out of sheer curiosity:
>
> The git-merge manpage was written in terms of merging a "remote",
> which is no longer the case
>
> Was this ever the case? Or is it just stale terminology?
Somewhere in between stale and lax. Originally we didn't even have
refs/remotes hierarchy and the distinction between what's local and what's
remote was only in the user's head, and "one branch per repository"
(i.e. you do local clone to work on multiple things, and pull between
them), where even a topic-branch merge is to merge a commit from a remote
(= neighbouring repository of your own), was a more widely practiced
workflow.
Saying <commit> is much more correct than <remote> (technically it can
even be a <committish>, i.e. a tag that peels to a commit).
However...
> @@ -33,10 +33,10 @@ include::merge-options.txt[]
> used to give a good default for automated 'git merge'
> invocations.
>
> -<remote>...::
> - Other branch heads to merge into our branch. You need at
> - least one <remote>. Specifying more than one <remote>
> - obviously means you are trying an Octopus.
> +<commit>...::
> + Commits, usually other branch heads, to merge into our branch.
> + You need at least one <commit>. Specifying more than one
> + <commit> obviously means you are trying an Octopus.
I am tempted to suggest describing the command in terms of more common use
pattern, describing the flexible and more general form as "an aside" for
more advanced users, perhaps like this.
<branch>...:
Other branch to merge into the current branch...trying an
Octopus merge.
+
Strictly speaking, these can name arbitrary commits, not necessarily
at the tip of branches. e.g. "git merge topic{tilde}4" lets you merge
the topic except for the last 4 commits.
I don't know if such an arrangement really makes the document more
approachable to new people, or it is making the description longer and
more complicated without helping new people, though (that is why this is
just "I am tempted to").
^ permalink raw reply
* Re: Strange happening with 'git fetch'
From: Ilari Liusvaara @ 2010-01-07 18:07 UTC (permalink / raw)
To: David Kirk; +Cc: git
In-Reply-To: <de73f1891001070959h30e4ecebw7c852f0417647419@mail.gmail.com>
On Thu, Jan 07, 2010 at 11:59:39AM -0600, David Kirk wrote:
> This is very strange, and defies the understanding of everyone in the
> office familiar with git. Is it a bug, or some feature we don't
> understand?
>
> Basically, when I do a 'git fetch', it updates my local repository.
> Now nobody else is doing anything, so the remote repository does not
> change. Doing another 'git fetch' should report that nothing needs to
> be done and nothing should change. But instead, it reports something
> about the remote HEAD, and changes my local branch 'master' to some
> strange location! Running 'git fetch' again restores it to the
> correct state, reporting that it is updating 'master'. Repeated
> invocations will toggle between these two results. Below is a
> transcript from the bash shell.
>
> Can someone please explain this?
I have seen that before. Looks like you have local branch 'HEAD' (_not_
the special ref HEAD) on remote side and that is messing it up.
ls-remote'ing the repository shows 'refs/heads/HEAD', right (there's
also HEAD, that's the required special ref)?
-Ilari
^ permalink raw reply
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Nguyen Thai Ngoc Duy @ 2010-01-07 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx6h4ww3.fsf@alter.siamese.dyndns.org>
On 1/8/10, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > +
> > + if (show_colums) {
> > + const char *argv[] = { "column", NULL };
> > +
> > + memset(&cp, 0, sizeof(cp));
> > + cp.in = -1;
> > + cp.out = dup(1);
> > + cp.argv = argv;
> > + start_command(&cp);
> > + close(1);
> > + dup2(cp.in, 1);
> > + close(cp.in);
> > + }
>
>
> I think the code for columnar output used in producing "git help -a"
> output should be reusable (if not, should be made reusable and reused
> here).
I saw that and even exported term_columns() but was too lazy to make
pretty_print_string_list() something reusable. Will think of it again
when I see this command is worth pushing forward.
--
Duy
^ permalink raw reply
* [PATCH v5] Be more user-friendly when refusing to do something because of conflict.
From: Matthieu Moy @ 2010-01-07 18:10 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1262878552-4775-1-git-send-email-Matthieu.Moy@imag.fr>
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Ahem. *This* one passes the test-suite :-\. Sorry for not having ran it earlier.
Since the test for git-merge is changed a bit, I added the last
paragraph of the commit message.
Documentation/config.txt | 4 ++++
advice.c | 16 ++++++++++++++++
advice.h | 5 +++++
builtin-commit.c | 14 ++++++++++++--
builtin-merge.c | 19 ++++++++++++++-----
builtin-revert.c | 15 ++++++++++++++-
git-pull.sh | 25 +++++++++++++++++++++++--
t/t3030-merge-recursive.sh | 6 ++++--
t/t3501-revert-cherry-pick.sh | 2 +-
9 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 304eabb..8761411 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -130,6 +130,10 @@ advice.*::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwritting local changes.
Default: true.
+ resolveConflict::
+ Advices shown by various commands when conflicts
+ prevent the operation from being performed.
+ Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index cb666ac..3309521 100644
--- a/advice.c
+++ b/advice.c
@@ -3,6 +3,7 @@
int advice_push_nonfastforward = 1;
int advice_status_hints = 1;
int advice_commit_before_merge = 1;
+int advice_resolve_conflict = 1;
static struct {
const char *name;
@@ -11,6 +12,7 @@ static struct {
{ "pushnonfastforward", &advice_push_nonfastforward },
{ "statushints", &advice_status_hints },
{ "commitbeforemerge", &advice_commit_before_merge },
+ { "resolveconflict", &advice_resolve_conflict },
};
int git_default_advice_config(const char *var, const char *value)
@@ -27,3 +29,17 @@ int git_default_advice_config(const char *var, const char *value)
return 0;
}
+
+void NORETURN die_resolve_conflict(const char *me)
+{
+ if (advice_resolve_conflict)
+ /*
+ * Message used both when 'git commit' fails and when
+ * other commands doing a merge do.
+ */
+ die("'%s' is not possible because you have unmerged files.\n"
+ "Please, fix them up in the work tree, and then use 'git add/rm <file>' as\n"
+ "appropriate to mark resolution and make a commit, or use 'git commit -a'.", me);
+ else
+ die("'%s' is not possible because you have unmerged files.", me);
+}
diff --git a/advice.h b/advice.h
index 3de5000..acd5fdd 100644
--- a/advice.h
+++ b/advice.h
@@ -1,10 +1,15 @@
#ifndef ADVICE_H
#define ADVICE_H
+#include "git-compat-util.h"
+
extern int advice_push_nonfastforward;
extern int advice_status_hints;
extern int advice_commit_before_merge;
+extern int advice_resolve_conflict;
int git_default_advice_config(const char *var, const char *value);
+extern void NORETURN die_resolve_conflict(const char *me);
+
#endif /* ADVICE_H */
diff --git a/builtin-commit.c b/builtin-commit.c
index 592b103..c56dca0 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -244,6 +244,16 @@ static void create_base_index(void)
exit(128); /* We've already reported the error, finish dying */
}
+static void refresh_cache_or_die(int refresh_flags)
+{
+ /*
+ * refresh_flags contains REFRESH_QUIET, so the only errors
+ * are for unmerged entries.
+ */
+ if (refresh_cache(refresh_flags | REFRESH_IN_PORCELAIN))
+ die_resolve_conflict("commit");
+}
+
static char *prepare_index(int argc, const char **argv, const char *prefix, int is_status)
{
int fd;
@@ -283,7 +293,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (all || (also && pathspec && *pathspec)) {
int fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die("unable to write new_index file");
@@ -302,7 +312,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
*/
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die("unable to write new_index file");
diff --git a/builtin-merge.c b/builtin-merge.c
index f1c84d7..79a35c3 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -847,11 +847,20 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
const char *best_strategy = NULL, *wt_strategy = NULL;
struct commit_list **remotes = &remoteheads;
- if (file_exists(git_path("MERGE_HEAD")))
- die("You have not concluded your merge. (MERGE_HEAD exists)");
- if (read_cache_unmerged())
- die("You are in the middle of a conflicted merge."
- " (index unmerged)");
+ if (read_cache_unmerged()) {
+ die_resolve_conflict("merge");
+ }
+ if (file_exists(git_path("MERGE_HEAD"))) {
+ /*
+ * There is no unmerged entry, don't advise 'git
+ * add/rm <file>', just 'git commit'.
+ */
+ if (advice_resolve_conflict)
+ die("You have not concluded your merge (MERGE_HEAD exists).\n"
+ "Please, commit your changes before you can merge.");
+ else
+ die("You have not concluded your merge (MERGE_HEAD exists).");
+ }
/*
* Check if we are _not_ on a detached HEAD, i.e. if there is a
diff --git a/builtin-revert.c b/builtin-revert.c
index 151aa6a..d14dde3 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -233,6 +233,19 @@ static struct tree *empty_tree(void)
return tree;
}
+static NORETURN void die_dirty_index(const char *me)
+{
+ if (read_cache_unmerged()) {
+ die_resolve_conflict(me);
+ } else {
+ if (advice_commit_before_merge)
+ die("Your local changes would be overwritten by %s.\n"
+ "Please, commit your changes or stash them to proceed.", me);
+ else
+ die("Your local changes would be overwritten by %s.\n", me);
+ }
+}
+
static int revert_or_cherry_pick(int argc, const char **argv)
{
unsigned char head[20];
@@ -269,7 +282,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (get_sha1("HEAD", head))
die ("You do not have a valid HEAD");
if (index_differs_from("HEAD", 0))
- die ("Dirty index: cannot %s", me);
+ die_dirty_index(me);
}
discard_cache();
diff --git a/git-pull.sh b/git-pull.sh
index 9e69ada..54ce0af 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -13,8 +13,29 @@ set_reflog_action "pull $*"
require_work_tree
cd_to_toplevel
-test -z "$(git ls-files -u)" ||
- die "You are in the middle of a conflicted merge."
+
+die_conflict () {
+ git diff-index --cached --name-status -r --ignore-submodules HEAD --
+ if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
+ die "Pull is not possible because you have unmerged files.
+Please, fix them up in the work tree, and then use 'git add/rm <file>'
+as appropriate to mark resolution, or use 'git commit -a'."
+ else
+ die "Pull is not possible because you have unmerged files."
+ fi
+}
+
+die_merge () {
+ if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
+ die "You have not concluded your merge (MERGE_HEAD exists).
+Please, commit your changes before you can merge."
+ else
+ die "You have not concluded your merge (MERGE_HEAD exists)."
+ fi
+}
+
+test -z "$(git ls-files -u)" || die_conflict
+test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity=
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 9b3fa2b..9929f82 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -276,11 +276,13 @@ test_expect_success 'fail if the index has unresolved entries' '
test_must_fail git merge "$c5" &&
test_must_fail git merge "$c5" 2> out &&
+ grep "not possible because you have unmerged files" out &&
+ git add -u &&
+ test_must_fail git merge "$c5" 2> out &&
grep "You have not concluded your merge" out &&
rm -f .git/MERGE_HEAD &&
test_must_fail git merge "$c5" 2> out &&
- grep "You are in the middle of a conflicted merge" out
-
+ grep "Your local changes to .* would be overwritten by merge." out
'
test_expect_success 'merge-recursive remove conflict' '
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index bb4cf00..7f85815 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -66,7 +66,7 @@ test_expect_success 'revert forbidden on dirty working tree' '
echo content >extra_file &&
git add extra_file &&
test_must_fail git revert HEAD 2>errors &&
- grep "Dirty index" errors
+ grep "Your local changes would be overwritten by " errors
'
--
1.6.6.198.g3c5474
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox