With 1.7.10 we'll get merge edit messages by default (which I like)
but I wonder if we could better clarify this to users when they see a
merge message pop up.
Firstly (and as a more general thing) I think we should add a mention
of "git merge --abort" to the message, just saving an empty file is
not sufficient to fully clear the merge state:
diff --git a/builtin/merge.c b/builtin/merge.c
index d3e1e8d..9169c74 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -889,8 +889,8 @@ static const char merge_editor_comment[] =
N_("Please enter a commit message to explain why this merge is
necessary,\n"
"especially if it merges an updated upstream into a topic branch.\n"
"\n"
- "Lines starting with '#' will be ignored, and an empty message aborts\n"
- "the commit.\n");
+ "Lines starting with '#' will be ignored, and an empty message
followed\n"
+ "by 'git merge --abort' the merge.\n");
static void prepare_to_commit(void)
{
Additionally, perhaps it would be a good idea to:
* Detect if the user didn't run this explicitly but implicitly from a
"git pull". We could pass some env var along or another option
(e.g. --internal-from-porcelain=pull) and add this:
You've merged implicitly via a "git pull", if you're just
updating some local work in progress to keep up with upstream
you may want to use "git pull --rebase" instead (or set the
pull.rebase configuration variable) to rebase instead of merge.
* Explicitly check if we're merging an updated upstream into the
work-in-progress topic, then mentioning some succinct version of
Junio's #1 point at
http://git-blame.blogspot.com/2012/02/anticipating-git-1710.html
I work with a lot of inexperienced git users and a lot of them are
going to be very confused by this change. I still think it's a good
change to make, but we could do a lot more to mitigate the inevitable
confusion.
One thing that would help these users in particular would be to have
some easy to use replacement for their frequent use of "git
pull".
They don't often commit their work (because of git inexperience) so
rebasing will error out because the tree is unclean. I tried to hack
support for unclean trees into git-rebase(1) the other day but it was
difficult because at various points in the process it'll do a "git
reset --hard".
Maybe having an option to "git pull" that would make it do:
git stash save --include-untracked -- "Automatically created stash
by \"git pull\" at $(date)"
git pull --rebase
git stash pop
Would make things easier. It could be called "git pull --rebase
--stash".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html