Re: default behaviour for `gitmerge` (no arguments)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2010, 19:43 UTC
Message-ID: <7v7hrojukz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <loom.20100111T185144-655@post.gmane.org>

Gareth Adams <gareth.adams@gmail.com> writes:

Show 5 quoted lines

> Unfortunately my other option is:
>
>     git pull; ...; git checkout otherbranch; git merge myremote/otherbranch
>
> which is annoying extra typing.

Replace 'pull' with 'fetch' and a bit more regular pattern would emerge.

The code indeed knows (as you can see "git pull" can figure it out) what other ref the current branch is configured to merge with by default. There is even a plumbing to do this for script writers.

    $ git for-each-ref --format='%(upstream)' $(git symbolic-ref HEAD)

We can teach this short-hand to "git merge", perhaps:

    $ git merge --default

But "no argument" cannot be the short-hand, because...

> 1) At the moment, `git merge` does nothing. Except mock me for not giving it a
> command in a format it recognises. This change wouldn't have any effect that
> would cause anyone a problem

... except for people who uses a script that does

    commits=
    while some condition
    do
    	commit=$(find some other commit that should be merged)
        commits="$commits$commit "
    done
    git merge $commits

and expect the last step will fail without doing any damage when the loop finds no new developments. "no argument means --default" will break their scripts.