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
next 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).