From: Junio C Hamano <junkio@cox•net>
To: Shawn Pearce <spearce@spearce•org>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
Date: Thu, 28 Dec 2006 01:35:03 -0800 [thread overview]
Message-ID: <7vac18wego.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20061228081701.GA18029@spearce.org> (Shawn Pearce's message of "Thu, 28 Dec 2006 03:17:01 -0500")
Shawn Pearce <spearce@spearce•org> writes:
>> I personally think this is not an improvement, but rather a new
>> source of confusion. If the user wants a local merge, there is
>> 'git-merge'. And the distinction between the commands makes it
>> clear that local merge can merge any commits exactly because
>> they are available locally, while remote fetch+merge needs to
>> choose from what the remote side offers so not arbitrary commits
>> like foo@{3.days.ago} cannot be pulled.
>
> True. But you know you are doing a local merge with `git pull .`.
> So why should you be restricted from using the capabilities of a
> local merge just because the frontend you prefer to use is limited
> when its doing remote merges?
Personally I do not mind much about it because I happen to
understand what "git pull" is doing.
But I do mind having to spend time defending why we special case
only the dot form, when people with twisted minds start
complaining about inconsistencies among "git pull .git", "git
pull ." and "git pull $(pwd)". And no, I do not want to
introduce likes of "test `cd .git && pwd` == `cd $1 && pwd`" in
the code to make them behave consistently.
next prev parent reply other threads:[~2006-12-28 9:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
2006-12-28 7:34 ` [PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase Shawn O. Pearce
2006-12-28 7:34 ` [PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 5/11] Honor pull.{twohead,octopus} in git-merge Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 6/11] Allow git-merge to select the default strategy Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible Shawn O. Pearce
2006-12-28 8:08 ` Junio C Hamano
2006-12-28 8:17 ` Shawn Pearce
2006-12-28 9:35 ` Junio C Hamano [this message]
2006-12-28 7:35 ` [PATCH 8/11] Move better_branch_name above get_ref in merge-recursive Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 9/11] Allow merging bare trees " Shawn O. Pearce
2006-12-28 8:08 ` Junio C Hamano
2006-12-28 7:35 ` [PATCH 10/11] Use merge-recursive in git-am -3 Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 11/11] Improve merge performance by avoiding in-index merges Shawn O. Pearce
2006-12-28 8:08 ` Junio C Hamano
2006-12-28 8:24 ` Shawn Pearce
2006-12-29 17:44 ` 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=7vac18wego.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=spearce@spearce$(echo .)org \
/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