From: Paolo Bonzini <bonzini@gnu.org>
To: git@vger.kernel.org
Cc: spearce@spearce.org, gitster@pobox.com, peff@peff.net,
johannes.schindelin@gmx.de, srb@cuci.nl
Subject: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
Date: Mon, 28 Apr 2008 11:32:11 -0400 [thread overview]
Message-ID: <cover.1209391614.git.bonzini@gnu.org> (raw)
In-Reply-To: <4812DA50.3000702@gnu.org>
The aim of this series of patches limits the "magic" default of
"origin", that git sometimes uses in its fetch/push/pull commands,
to what I consider to be the bare acceptable minimum. (I will discuss
later what this minimum is).
This has two aims. The first is to make people more aware of what remote
they are interacting with. The second is to allow faster operation for
those people that do work with more than one remote. While "git remote
update" already does some of the latter, it is limited to fetching.
These patches use a different approach: they take the zero-argument
commands "git fetch", "git push", "git pull" that all git users know,
and make them scale nicely to use cases with >1 remote.
Patches 1 to 4 deal with "git push". The problem here is that the
"magic" default operation ("git push sends to origin all refs that
are already present there"), as of new, cannot be explained in the
configuration, and this is fixed by patches 1 and 2. Patch 1 adds a
special push refspec meaning "consider all refs already on the remote",
and patch 2 makes git-clone add one such line when it creates the
origin remote.
Patch 3 could also be split out of this series. It adds to "git-remote
add" a new --push option, that sets up a push refspec for the newly
created remote. If git-clone will ever use "git-remote add", it should
pass this option. This patch also defines the "--push --mirror" combo
to create a remote *which will backup the current repository*. I posted
this patch here, and placed it as the third, because some design decisions
in patch 4 are clearer if one considers the --push --mirror use case.
Patch 4 is a reworking of my previous patch. Instead of having "git
push" push to "all mirrors plus the magic origin branch", it will
push to "all remotes having a push refspec". In the future, this
will always include the origin branch because of patch 2, while
right now the origin branch is still used if no remote has a
push refspec (for backwards compatibility -- more discussion in the
patch log message).
This patch may cause incompatibilities to be warned about in
the release notes. Luckily, these incompatibilities only affect
users that already know their way in .git/config, because no porcelain
command creates push refspecs.
Patches 5 and 6 affect "git pull". Pulling uses the magic origin branch
less often, because branch.*.remote already establishes a saner default.
Therefore, here we can actually warn and deprecate the misfeature for
real (patch 6). Patch 5 however is still needed, so that "git pull"
itself decides when to use the magic "origin" branch instead of making
the decision in "git fetch".
Finally, patch 7 affects "git fetch". As hinted earlier, I chose to
duplicate the functionality already present in "git remote update"
(for the case where remotes are not grouped), but the code is much
simpler so there is no incentive (at least for now) in borrowing code
from "git remote update" into "git fetch"---actually, as a cleanup
it is maybe possible to borrow code in the other direction.
The patch series touches relatively many areas. Some patches could
go in separately as cleanups, new features or just because their effect
is less profound. In particular:
- patch 5 could go in separately as a code cleanup;
- patch 6 does not affect the user operation, it just adds a warning
that should not appear for the most common cases; it can go in IMHO
even if "git fetch" and "git push" keep the magic choice of "origin".
- patches 1 and 2 add a new feature and could go in separately.
As a closing comment (this cover letter is already too long possibly!),
I think this design is sound. In particular, here is a list of
citations from the earlier thread in light of which, I think, this
design makes a lot of sense.
"I _hate_ the default remote."
Well, this series does not make origin behave differently. Still,
a "remote configured by default to behave in a particular way",
is obviously much better than "a remote whose default behavior
is built into git". Also, even though this series could not
completely remove git's knowledge of origin, that's only motivated
by backwards compatibility.
"I am sympathetic when they want to say "git push" and have it default
to that single other repository."
So that's what git will keep doing. However...
"Should we [...] make people more aware that what _they_ do is the
special case to have only one remote to interact with?"
... after this series, it will scale to >1 remote consistently
with this aim. "git fetch" and "git push" will examine every
possible remote (and there is just one in the simple "CVS" case).
"BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes."
The series remove the need to switch from "git fetch" to
"git remote update" as one learns the power of DVCS.
"[Removing a default altogether] harms the `git pull` case that relies
upon the magic branch.$name.remote and branch.$name.merge keys."
Indeed, IMHO the way to go (in general, and especially for
"git pull") is to deprecate the magic usage of "origin"---not
to deprecate the zero-argument versions.
"I know git pretty well, and I find that particular distinction (that is,
needing to specify the remote if using refspecs, but not otherwise)
annoying. It is purely a syntactic issue that relying on order of
arguments means you can't default earlier ones but specify later ones."
The patches admittedly does not tackle that. It actually makes
it "harder to solve", because it is not anymore a matter of
default arguments. Zero-argument push and fetch work on
all remotes (suggested also by Stephen R. van der Berg in the
thread), not on just one. On the other hand, it makes it
easier to explain: all remotes? no need to specify anything;
one remote? always specify it.
Paolo Bonzini (7):
add special "matching refs" refspec
add push line in git-clone
Add a --push option to "git-remote add"
make "git push" update all push repositories.
don't rely on zero-argument "git fetch" from within git pull
warn on "git pull" without a given branch.<name>.remote value
make "git fetch" update all fetch repositories
Documentation/git-fetch.txt | 7 ++
Documentation/git-pull.txt | 9 ++-
Documentation/git-push.txt | 35 +++++++---
Documentation/git-remote.txt | 31 ++++++---
builtin-fetch.c | 109 ++++++++++++++++-------------
builtin-push.c | 67 +++++++++++++++---
builtin-remote.c | 32 ++++++--
builtin-send-pack.c | 10 +++-
git-clone.sh | 2 +
git-parse-remote.sh | 8 ++
git-pull.sh | 9 ++-
remote.c | 80 ++++++++++++++-------
remote.h | 1 +
t/t5400-send-pack.sh | 2 +-
t/t5505-remote.sh | 26 +++++++-
t/t5510-fetch.sh | 19 +++++-
t/t5511-refspec.sh | 5 +-
t/t5515-fetch-merge-logic.sh | 8 +--
t/t5515/fetch.br-branches-default | 8 --
t/t5515/fetch.br-branches-default-merge | 9 ---
t/t5515/fetch.br-branches-default-octopus | 10 ---
t/t5515/fetch.br-branches-one | 8 --
t/t5515/fetch.br-branches-one-merge | 9 ---
t/t5515/fetch.br-branches-one-octopus | 9 ---
t/t5515/fetch.br-config-explicit | 11 ---
t/t5515/fetch.br-config-explicit-merge | 11 ---
t/t5515/fetch.br-config-explicit-octopus | 11 ---
t/t5515/fetch.br-config-glob | 11 ---
t/t5515/fetch.br-config-glob-merge | 11 ---
t/t5515/fetch.br-config-glob-octopus | 11 ---
t/t5515/fetch.br-remote-explicit | 11 ---
t/t5515/fetch.br-remote-explicit-merge | 11 ---
t/t5515/fetch.br-remote-explicit-octopus | 11 ---
t/t5515/fetch.br-remote-glob | 11 ---
t/t5515/fetch.br-remote-glob-merge | 11 ---
t/t5515/fetch.br-remote-glob-octopus | 11 ---
t/t5515/fetch.br-unconfig | 11 ---
t/t5515/fetch.master | 11 ---
t/t5515/refs.br-branches-default | 12 ---
t/t5515/refs.br-branches-default-merge | 12 ---
t/t5515/refs.br-branches-default-octopus | 12 ---
t/t5515/refs.br-branches-one | 12 ---
t/t5515/refs.br-branches-one-merge | 12 ---
t/t5515/refs.br-branches-one-octopus | 12 ---
t/t5515/refs.br-config-explicit | 15 ----
t/t5515/refs.br-config-explicit-merge | 15 ----
t/t5515/refs.br-config-explicit-octopus | 15 ----
t/t5515/refs.br-config-glob | 15 ----
t/t5515/refs.br-config-glob-merge | 15 ----
t/t5515/refs.br-config-glob-octopus | 15 ----
t/t5515/refs.br-remote-explicit | 15 ----
t/t5515/refs.br-remote-explicit-merge | 15 ----
t/t5515/refs.br-remote-explicit-octopus | 15 ----
t/t5515/refs.br-remote-glob | 15 ----
t/t5515/refs.br-remote-glob-merge | 15 ----
t/t5515/refs.br-remote-glob-octopus | 15 ----
t/t5515/refs.br-unconfig | 11 ---
t/t5515/refs.master | 11 ---
t/t5516-fetch-push.sh | 41 +++++++++++
t/t5517-push-mirror.sh | 84 ++++++++++++++++++++++-
60 files changed, 452 insertions(+), 614 deletions(-)
delete mode 100644 t/t5515/fetch.br-branches-default
delete mode 100644 t/t5515/fetch.br-branches-default-merge
delete mode 100644 t/t5515/fetch.br-branches-default-octopus
delete mode 100644 t/t5515/fetch.br-branches-one
delete mode 100644 t/t5515/fetch.br-branches-one-merge
delete mode 100644 t/t5515/fetch.br-branches-one-octopus
delete mode 100644 t/t5515/fetch.br-config-explicit
delete mode 100644 t/t5515/fetch.br-config-explicit-merge
delete mode 100644 t/t5515/fetch.br-config-explicit-octopus
delete mode 100644 t/t5515/fetch.br-config-glob
delete mode 100644 t/t5515/fetch.br-config-glob-merge
delete mode 100644 t/t5515/fetch.br-config-glob-octopus
delete mode 100644 t/t5515/fetch.br-remote-explicit
delete mode 100644 t/t5515/fetch.br-remote-explicit-merge
delete mode 100644 t/t5515/fetch.br-remote-explicit-octopus
delete mode 100644 t/t5515/fetch.br-remote-glob
delete mode 100644 t/t5515/fetch.br-remote-glob-merge
delete mode 100644 t/t5515/fetch.br-remote-glob-octopus
delete mode 100644 t/t5515/fetch.br-unconfig
delete mode 100644 t/t5515/fetch.master
delete mode 100644 t/t5515/refs.br-branches-default
delete mode 100644 t/t5515/refs.br-branches-default-merge
delete mode 100644 t/t5515/refs.br-branches-default-octopus
delete mode 100644 t/t5515/refs.br-branches-one
delete mode 100644 t/t5515/refs.br-branches-one-merge
delete mode 100644 t/t5515/refs.br-branches-one-octopus
delete mode 100644 t/t5515/refs.br-config-explicit
delete mode 100644 t/t5515/refs.br-config-explicit-merge
delete mode 100644 t/t5515/refs.br-config-explicit-octopus
delete mode 100644 t/t5515/refs.br-config-glob
delete mode 100644 t/t5515/refs.br-config-glob-merge
delete mode 100644 t/t5515/refs.br-config-glob-octopus
delete mode 100644 t/t5515/refs.br-remote-explicit
delete mode 100644 t/t5515/refs.br-remote-explicit-merge
delete mode 100644 t/t5515/refs.br-remote-explicit-octopus
delete mode 100644 t/t5515/refs.br-remote-glob
delete mode 100644 t/t5515/refs.br-remote-glob-merge
delete mode 100644 t/t5515/refs.br-remote-glob-octopus
delete mode 100644 t/t5515/refs.br-unconfig
delete mode 100644 t/t5515/refs.master
next prev parent reply other threads:[~2008-04-28 15:34 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 7:31 [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors Paolo Bonzini
2008-04-26 17:01 ` Shawn O. Pearce
2008-04-26 17:46 ` Junio C Hamano
2008-04-27 4:30 ` Shawn O. Pearce
2008-04-27 4:40 ` Shawn O. Pearce
2008-04-27 5:23 ` Junio C Hamano
2008-04-27 17:34 ` Shawn O. Pearce
2008-04-27 20:13 ` Junio C Hamano
2008-04-27 20:22 ` Paolo Bonzini
2008-04-28 1:26 ` Jeff King
2008-04-28 5:07 ` Paolo Bonzini
2008-04-28 9:09 ` Jeff King
2008-04-28 9:11 ` Jeff King
2008-04-28 9:19 ` Paolo Bonzini
2008-04-28 10:33 ` Johannes Schindelin
2008-04-28 11:24 ` Paolo Bonzini
2008-04-28 11:57 ` Johannes Schindelin
2008-04-28 3:32 ` Shawn O. Pearce
2008-04-28 5:03 ` Paolo Bonzini
2008-04-28 6:08 ` Stephen R. van den Berg
2008-04-28 1:21 ` Jeff King
2008-04-27 9:03 ` Paolo Bonzini
2008-04-27 7:23 ` Paolo Bonzini
2008-04-28 15:32 ` Paolo Bonzini [this message]
2008-04-28 15:32 ` [PATCH 1/7] add special "matching refs" refspec Paolo Bonzini
2008-04-28 15:32 ` [PATCH 2/7] add push line in git-clone Paolo Bonzini
2008-04-28 15:32 ` [PATCH 3/7] Add a --push option to "git-remote add" Paolo Bonzini
2008-04-28 15:32 ` [PATCH 4/7] make "git push" update all push repositories Paolo Bonzini
2008-04-28 15:32 ` [PATCH 5/7] don't rely on zero-argument "git fetch" from within git pull Paolo Bonzini
2008-04-28 15:32 ` [PATCH 6/7] warn on "git pull" without a given branch.<name>.remote value Paolo Bonzini
2008-04-28 15:32 ` [PATCH 7/7] make "git fetch" update all fetch repositories Paolo Bonzini
2008-04-28 18:10 ` Alex Riesen
2008-04-28 18:19 ` Paolo Bonzini
2008-04-28 21:33 ` Alex Riesen
2008-04-29 4:52 ` Paolo Bonzini
2008-04-29 5:38 ` Alex Riesen
2008-04-29 6:05 ` Andreas Ericsson
2008-04-29 6:55 ` Paolo Bonzini
2008-04-29 16:13 ` Johannes Schindelin
2008-04-29 16:40 ` Paolo Bonzini
2008-04-29 20:34 ` Alex Riesen
2008-04-29 6:50 ` Paolo Bonzini
2008-04-29 7:16 ` Andreas Ericsson
2008-04-29 7:57 ` Paolo Bonzini
2008-04-29 8:48 ` Andreas Ericsson
2008-04-29 9:02 ` Paolo Bonzini
2008-04-29 21:08 ` しらいしななこ
[not found] ` <200804292108.m3TL8moV011790@mi1.bluebottle.com>
2008-04-29 21:21 ` Paolo Bonzini
2008-04-29 22:21 ` Johannes Schindelin
2008-04-29 20:44 ` Alex Riesen
2008-04-29 21:15 ` Paolo Bonzini
2008-04-29 21:33 ` Alex Riesen
2008-04-29 21:41 ` Paolo Bonzini
2008-04-29 21:53 ` Alex Riesen
2008-04-29 22:26 ` Johannes Schindelin
2008-04-29 23:02 ` Jeff King
2008-04-29 23:17 ` Junio C Hamano
2008-04-30 5:28 ` Paolo Bonzini
2008-04-29 21:39 ` Johannes Schindelin
2008-04-29 20:24 ` Alex Riesen
2008-05-01 6:28 ` [PATCH 2/7] add push line in git-clone Junio C Hamano
2008-05-06 8:37 ` Paolo Bonzini
2008-05-14 15:20 ` Paolo Bonzini
2008-05-14 18:16 ` Junio C Hamano
2008-05-14 19:07 ` Paolo Bonzini
2008-05-14 19:23 ` Junio C Hamano
2008-05-14 19:40 ` Paolo Bonzini
2008-04-30 9:23 ` [PATCH 1/7] add special "matching refs" refspec Junio C Hamano
2008-04-30 9:35 ` Paolo Bonzini
2008-04-29 19:35 ` [PATCH 0/7] limit the usage of the default remote "origin" to the minimum Jeff King
2008-04-29 21:42 ` Alex Riesen
2008-04-29 21:56 ` Junio C Hamano
2008-04-29 23:12 ` Jeff King
2008-04-30 5:24 ` Paolo Bonzini
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=cover.1209391614.git.bonzini@gnu.org \
--to=bonzini@gnu.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
--cc=srb@cuci.nl \
/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).