public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Nanako Shiraishi <nanako3@lavabit•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: "Bernhard R. Link" <brlink@debian•org>, git@vger•kernel.org
Subject: Re: equal-tree-merges as way to make rebases fast-forward-able
Date: Wed, 02 Dec 2009 19:20:26 +0900	[thread overview]
Message-ID: <20091202192026.6117@nanako3.lavabit.com> (raw)
In-Reply-To: <7vmy23bl4o.fsf@alter.siamese.dyndns.org>

Quoting Junio C Hamano <gitster@pobox•com> writes:

> I think we really should start deprecating the ancient form, but the
> original sample script using this syntax from Linus was copied by many
> people and are still found everywhere, I think, and people may still
> use their scripts that were written with the ancient syntax.
>
> In any case, at least this patch will make it start behaving a bit
> more sanely.

Thank you; it fixes the bug for me. Do I have to say 

    Tested-by: Nanako Shiraishi <nanako3@lavabit•com>

to ask you to include it in the new release?

> -- >8 --
> Subject: Do not misidentify "git merge foo HEAD" as an old-style invocation
>
> This was misinterpreted as an ancient style "git merge <message> HEAD
> <commit> <commit>..." that merges one (or more) <commit> into the current
> branch and record the resulting commit with the given message.  Then a
> later sanity check found that there is no <commit> specified and gave
> a usage message.
>
> Signed-off-by: Junio C Hamano <gitster@pobox•com>
> ---
>
> diff --git a/builtin-merge.c b/builtin-merge.c
> index e95c5dc..e5cf795 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -792,7 +792,7 @@ static int suggest_conflicts(void)
>  static struct commit *is_old_style_invocation(int argc, const char **argv)
>  {
>  	struct commit *second_token = NULL;
> -	if (argc > 1) {
> +	if (argc > 2) {
>  		unsigned char second_sha1[20];
>  
>  		if (get_sha1(argv[1], second_sha1))

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

  parent reply	other threads:[~2009-12-02 10:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 14:43 equal-tree-merges as way to make rebases fast-forward-able Bernhard R. Link
2009-11-30 14:43 ` [PATCH 1/7] add new command git equal-tree-marker Bernhard R. Link
2009-11-30 15:36   ` Michael J Gruber
2009-11-30 14:44 ` [PATCH 2/7] add option to only visit the first parent of a equal tree merge Bernhard R. Link
2009-11-30 14:44 ` [PATCH 3/7] format-patch defaults to --first-equal-tree-only Bernhard R. Link
2009-11-30 14:44 ` [PATCH 4/7] support equal tree merges in interactive rebase Bernhard R. Link
2009-11-30 14:45 ` [PATCH 5/7] make rebase -m equal tree marker aware Bernhard R. Link
2009-11-30 14:45 ` [PATCH 6/7] add support for creating equal tree markers after rebase Bernhard R. Link
2009-11-30 14:45 ` [PATCH 7/7] add support for creating equal tree markers to rebase -i Bernhard R. Link
2009-11-30 15:10 ` equal-tree-merges as way to make rebases fast-forward-able Sverre Rabbelier
2009-11-30 15:31 ` Paolo Bonzini
2009-11-30 16:22   ` Bernhard R. Link
2009-11-30 15:35 ` Michael J Gruber
2009-11-30 15:59 ` Michael J Gruber
2009-11-30 16:54   ` Bernhard R. Link
2009-11-30 17:19 ` Johannes Schindelin
2009-11-30 18:18 ` Junio C Hamano
2009-11-30 18:55   ` Bernhard R. Link
2009-12-01  0:25     ` Junio C Hamano
2009-11-30 19:26   ` Johannes Sixt
2009-11-30 20:32     ` Junio C Hamano
2009-11-30 22:12   ` Nanako Shiraishi
2009-12-01  0:20     ` Junio C Hamano
2009-12-01  0:23       ` [PATCH] git-merge: a deprecation notice of the ancient command line syntax Junio C Hamano
2009-12-01  3:55         ` Nicolas Pitre
2009-12-01  4:07           ` Junio C Hamano
2009-12-02 10:20       ` Nanako Shiraishi [this message]
2009-12-02 18:03         ` equal-tree-merges as way to make rebases fast-forward-able Junio C Hamano
2009-12-01 11:50 ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091202192026.6117@nanako3.lavabit.com \
    --to=nanako3@lavabit$(echo .)com \
    --cc=brlink@debian$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox