git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gareth Adams <gareth.adams@gmail.com>
To: git@vger.kernel.org
Subject: default behaviour for `gitmerge` (no arguments)
Date: Mon, 11 Jan 2010 18:49:38 +0000 (UTC)	[thread overview]
Message-ID: <loom.20100111T185144-655@post.gmane.org> (raw)

Hi there, long time user; first time caller here.

I wanted to suggest an improvement to git-merge which will either save some
typing or save some network resources. It won't save huge amounts of either but
every little helps!

Currently, some of my colleagues frequently end up typing:

    git pull; ...; git checkout otherbranch; git pull

Now, we have quite a low commit rate, it's unlikely (albeit vaguely possible)
that two people are working on the branch at the same time. This means the
second pull is doing a fetch which it effectively pointless.

Now of course this is a tiny amount of wastage, and while I could argue that it
would be an issue under poor network conditions that's not my point. As a coder
I'd want to get rid of the redundant fetch if I know it's redundant.

Unfortunately my other option is:

    git pull; ...; git checkout otherbranch; git merge myremote/otherbranch

which is annoying extra typing. Even with tab completion, it's redundant extra
typing because in these cases I'm trying to merge with the branch being tracked.

My suggestion is that `git merge` defaults to the same merge that a `git pull`
would perform, and there are 2 extra factors that make me think it's a workable
idea:

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

2) When I checkout a branch which has unmerged changes in the tracking branch,
git *tells me* what branch I will be taking action with "Your branch is behind
the tracked remote branch '...' by 4 commits, and can be fast-forwarded" - but
then makes me type it out explicitly anyway!

I appreciate that there are many workflows where there is an advantage in
performing a second pull in case there are additional changes since the first
pull, but I still think there is a string case for git merge having a more
sensible default, as git pull does.

What do you think?

Thanks,
Gareth

             reply	other threads:[~2010-01-11 18:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-11 18:49 Gareth Adams [this message]
2010-01-11 19:43 ` default behaviour for `gitmerge` (no arguments) Junio C Hamano
2010-01-12 16:23   ` Jeff King
2010-01-12 18:11     ` Junio C Hamano
2010-01-12 18:25       ` Jeff King
2010-01-13  6:57         ` Junio C Hamano
2010-01-13  9:26           ` Johannes Schindelin
2010-01-13  9:47             ` Junio C Hamano
2010-01-13 11:04               ` Johannes Schindelin
2010-01-13 19:48                 ` Junio C Hamano
2010-01-13 22:49                   ` Johannes Schindelin
2010-01-13 23:13                     ` Junio C Hamano
2010-01-20  9:38           ` [PATCH 0/2] @{u} updates Junio C Hamano
2010-01-20  9:38             ` [PATCH 1/2] t1506: more test for @{upstream} syntax Junio C Hamano
2010-01-26 13:07               ` Jeff King
2010-01-26 19:58                 ` Junio C Hamano
2010-01-27 10:24                   ` Jeff King
2010-01-27 18:50                     ` Junio C Hamano
2010-01-28  8:52                       ` Jeff King
2010-01-26 21:32                 ` Junio C Hamano
2010-01-27 11:40                   ` Jeff King
2010-01-27 19:10                     ` Junio C Hamano
2010-01-28  9:44                       ` Jeff King
2010-01-28  9:50                         ` [PATCH 1/3] test combinations of @{} syntax Jeff King
2010-01-28  9:52                         ` [PATCH 2/3] fix parsing of @{-1}@{u} combination Jeff King
2010-01-28  9:56                         ` [PATCH 3/3] reject @{-1} not at beginning of object name Jeff King
2010-01-28 20:02                           ` Junio C Hamano
2010-01-29 11:22                             ` Jeff King
2010-01-20  9:38             ` [PATCH 2/2] Teach @{upstream} syntax to strbuf_branchanme() Junio C Hamano
2010-01-20 13:08             ` [PATCH 0/2] @{u} updates Johannes Schindelin

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=loom.20100111T185144-655@post.gmane.org \
    --to=gareth.adams@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).