[PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

This patch builds on the infrastructure for remote.<nick>.mirror and
tweaks the behavior of "git push".  The idea is that "git push",
"git push --all", "git push --mirror", instead of defaulting to origin,
become DWIM commands:

- "git push" pushes to origin *and* to all mirrors

- "git push --all" pushes to origin with --all.  I didn't make it push
  to mirrors because --all and --mirror are incompatible.

- "git push --mirror" only updates mirror repositories, without touching
  origin.

This is useful when a project has a public repository managed by the
integrator, but the integrator also wants to publish his own mirror
somewhere.  In this case, the integrator will just do "git push".
Similarly, if a developer uses the integrator's repository but
wishes to publish his own mirror somewhere, he can just do "git push
--mirror".

The code explicitly disables pushing to mirrors when a refspec is present.
This is just defensive, because right now refspecs cannot be specified
without giving a repository too.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-push.txt |   17 ++++++---
 builtin-push.c             |   43 ++++++++++++++++------
 t/t5517-push-mirror.sh     |   86 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 130 insertions(+), 16 deletions(-)

	Sent a week ago, no comments received.

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index dc1d4b0..8195517 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -29,6 +29,11 @@ OPTIONS
 	The "remote" repository that is destination of a push
 	operation.  See the section <<URLS,GIT URLS>> below.

+	The default behavior of the command when no repository is specified
+	is to push to "origin" if \--all is given, to push to all mirror
+	remotes if \--mirror is given, and to do both actions if neither
+	\--all nor \--mirror is given.
+
 <refspec>::
 	The canonical format of a <refspec> parameter is
 	`+?<src>:<dst>`; that is, an optional plus `+`, followed
@@ -69,9 +74,11 @@ the remote repository.
 	be mirrored to the remote repository.  Newly created local
 	refs will be pushed to the remote end, locally updated refs
 	will be force updated on the remote end, and deleted refs
-	will be removed from the remote end.  This is the default
-	if the configuration option `remote.<remote>.mirror` is
-	set.
+	will be removed from the remote end.
+
+	When a <repository> is given on the command line, git looks up the
+	corresponding configuration option `remote.<repository>.mirror`
+	and enables mirror mode if it is set.

 \--dry-run::
 	Do everything except actually send the updates.
@@ -97,8 +104,8 @@ the remote repository.
 	remote repository to lose commits; use it with care.

 \--repo=<repo>::
-	When no repository is specified the command defaults to
-	"origin"; this overrides it.
+	Overrides the default behavior of the command when no repository
+	is specified, so that <repo> is used as the destination repository.

 \--thin, \--no-thin::
 	These options are passed to `git-send-pack`.  Thin
diff --git a/builtin-push.c b/builtin-push.c
index e992c37..3756d5e 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -48,14 +48,9 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }

-static int do_push(const char *repo, int flags)
+static int do_push(struct remote *remote, int flags)
 {
 	int i, errs;
-	struct remote *remote = remote_get(repo);
-
-	if (!remote)
-		die("bad repository '%s'", repo);
-
 	if (remote->mirror)
 		flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);

@@ -99,6 +94,18 @@ static int do_push(const char *repo, int flags)
 	return !!errs;
 }

+static int push_to_mirrors(struct remote *remote, void *priv)
+{
+	int *p_flags = priv;
+	int rc = 0;
+	if (remote->mirror)
+		rc = do_push (remote, *p_flags);
+	
+	/* No command-line errors should occur.  */
+	assert (rc != -1);
+	return rc;
+}
+
 int cmd_push(int argc, const char **argv, const char *prefix)
 {
 	int flags = 0;
@@ -109,6 +116,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 	int tags = 0;
 	int rc;
 	const char *repo = NULL;	/* default repository */
+	struct remote *remote;

 	struct option options[] = {
 		OPT__VERBOSE(&verbose),
@@ -144,9 +152,22 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		set_refspecs(argv + 1, argc - 1);
 	}

-	rc = do_push(repo, flags);
-	if (rc == -1)
-		usage_with_options(push_usage, options);
-	else
-		return rc;
+	/* "git push --mirror" will only push to mirrors.  */
+	if (repo || !mirror) {
+		remote = remote_get(repo);
+		if (!remote)
+			die("bad repository '%s'", repo);
+	
+		rc = do_push(remote, flags);
+		if (rc == -1)
+			usage_with_options(push_usage, options);
+	}
+
+	/* "git push" with only --force, --dry-run, --verbose, --mirror options
+	   will also (or, in the case of "git push --mirror", only) push to
+	   all mirrors.  */
+	if (!rc && !repo && !refspec && !all)
+		rc = for_each_remote (push_to_mirrors, &flags);
+	
+	return rc;
 }
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index ea49ded..beb71f4 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -29,6 +29,26 @@ mk_repo_pair () {
 	)
 }

+# a more complicated setup where we have also an origin repo
+mk_repo_threesome () {
+	rm -rf master mirror origin &&
+	mkdir mirror &&
+	(
+		cd mirror &&
+		git init
+	) &&
+	mkdir origin &&
+	(
+		cd origin &&
+		git init
+		echo one >foo && git add foo && git commit -m one
+	) &&
+	git clone origin master &&
+	(
+		cd master &&
+		git remote add --mirror up ../mirror
+	)
+}

 # BRANCH tests
 test_expect_success 'push mirror creates new branches' '
@@ -264,4 +284,70 @@ test_expect_success 'remote.foo.mirror=no has no effect' '

 '

+test_expect_success 'mirrors are updated by "git push"' '
+
+	mk_repo_threesome &&
+	(
+		cd master &&
+		git branch keep master &&
+		git branch remove master &&
+		git push &&
+		git branch -D remove
+		git push
+	) &&
+	(
+		cd mirror &&
+		git show-ref -s --verify refs/heads/keep &&
+		invert git show-ref -s --verify refs/heads/remove
+	) &&
+	(
+		cd origin &&
+		invert git show-ref -s --verify refs/heads/keep &&
+		invert git show-ref -s --verify refs/heads/remove
+	)
+
+'
+
+test_expect_success 'mirrors are not updated by "git push --all"' '
+
+	mk_repo_threesome &&
+	(
+		cd master &&
+		git branch b1 master &&
+		git push --all
+	) &&
+	(
+		cd mirror &&
+		invert git show-ref -s --verify refs/heads/b1
+	) &&
+	(
+		cd origin &&
+		git show-ref -s --verify refs/heads/b1
+	)
+
+'
+
+test_expect_success 'mirrors are not updated by "git push --repo" or "git push <repo>"' '
+
+	mk_repo_threesome &&
+	(
+		cd master &&
+		git branch b1 master &&
+		git push origin
+		git branch b2 master &&
+		git push --repo=origin
+	) &&
+	(
+		cd mirror &&
+		invert git show-ref -s --verify refs/heads/b1 &&
+		invert git show-ref -s --verify refs/heads/b2
+	) &&
+	(
+		cd origin &&
+		invert git show-ref -s --verify refs/heads/b1 &&
+		invert git show-ref -s --verify refs/heads/b2
+	)
+
+'
+
 test_done
-- 
1.5.5

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Shawn O. Pearce]

Paolo Bonzini <bonzini@gnu.org> wrote:
> This patch builds on the infrastructure for remote.<nick>.mirror and
> tweaks the behavior of "git push".  The idea is that "git push",
> "git push --all", "git push --mirror", instead of defaulting to origin,
> become DWIM commands:
> 
> - "git push" pushes to origin *and* to all mirrors
> 
> - "git push --all" pushes to origin with --all.  I didn't make it push
>   to mirrors because --all and --mirror are incompatible.
> 
> - "git push --mirror" only updates mirror repositories, without touching
>   origin.
> 
> This is useful when a project has a public repository managed by the
> integrator, but the integrator also wants to publish his own mirror
> somewhere.  In this case, the integrator will just do "git push".

Sorry, I don't really see a use case behind this.  `git push` today
will push to origin all branches that exist both locally and already
on the remote.  If you want to push to multiple locations, just
specify the other URLs in the remote.origin.url configuration list.
Linus added support for that years ago.

> Similarly, if a developer uses the integrator's repository but
> wishes to publish his own mirror somewhere, he can just do "git push
> --mirror".

Why not just have a remote named "my-mirror" and do `git push my-mirror`?
Yes, its on keystroke longer to type.  Call it foo.  `git push foo` would
be shorter, and not require code changes in Git.

-- 
Shawn.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Why not just have a remote named "my-mirror" and do `git push my-mirror`?
> Yes, its on keystroke longer to type.  Call it foo.  `git push foo` would
> be shorter, and not require code changes in Git.

Configuring to push to multiple can already be done as you described, not
having to have a special case code like this patch is certainly very
attractive, and also it is one less "magic" applied to the configuration
(meaning, when you have to figure out what an unadorned "git push" does
for somebody else who is having trouble, you have one less thing to
consider).

I've been torn between

 (1) but then you have to have an extra 'foo' remote and with this patch
     it becomes unnecessary, and

 (2) no, by separating individual remotes (which are not 'foo') and a
     magic "pushing to everywhere" (which is 'foo'), that extra 'foo'
     simplifies things, to explain, understand, and diagnose (when
     something goes south).

I am leaning towards the latter argument now, especially after you
commented on this issue.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Why not just have a remote named "my-mirror" and do `git push my-mirror`?
> > Yes, its on keystroke longer to type.  Call it foo.  `git push foo` would
> > be shorter, and not require code changes in Git.
...
>  (2) no, by separating individual remotes (which are not 'foo') and a
>      magic "pushing to everywhere" (which is 'foo'), that extra 'foo'
>      simplifies things, to explain, understand, and diagnose (when
>      something goes south).

This is the only behavior that really makes sense to me.

When I first started to learn and use a DVCS I'll admit that I did
found it odd that "$dvcs commit" did not make my changes immediately
available to everyone else on the project.  I've gotten over that
and have become very used to the idea that "git push foo" is the
means that I publish my work to location(s) named "foo", using the
publication means I have pre-configured for that name.

Not all of my work from the same repository is always published
the same way.  For example in egit I can publish to both
the master egit tree (repo.or.cz/egit.git) and to my fork
(repo.or.cz/egit/spearce.git).  I publish to the latter almost
daily, and rebase even more often than that.  But the master tree
only receives stable work whose history does not rewind.

In git being able to configure two different remotes and specifically
pushing to the destination is very easy.  What is less easy is our
reliance on a default named "origin" and the syntax we have for
the remote configuration.  It is fairly simple, but new users do
seem to struggle with it a bit.

-- 
Shawn.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> 
> In git being able to configure two different remotes and specifically
> pushing to the destination is very easy.  What is less easy is our
> reliance on a default named "origin" and the syntax we have for
> the remote configuration.  It is fairly simple, but new users do
> seem to struggle with it a bit.

Perhaps I should clarify this statement a bit.

I _hate_ the default remote.  One of the first things I wind up
doing is deleting it and creating a new one.  At least git-clone has
the -o flag to setup your own name, which then the tools (git-fetch
and git-push) cannot find.

Anytime I use git-fetch, git-pull or git-push I am always giving
it a remote name, or a remote name and a refspec.  So having these
tools default to 'origin' is of little to no value to me.

-- 
Shawn.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> I _hate_ the default remote.  One of the first things I wind up
> doing is deleting it and creating a new one.  At least git-clone has
> the -o flag to setup your own name, which then the tools (git-fetch
> and git-push) cannot find.
>
> Anytime I use git-fetch, git-pull or git-push I am always giving
> it a remote name, or a remote name and a refspec.  So having these
> tools default to 'origin' is of little to no value to me.

It sounds as if you want to say it a bit stronger than that --- to you,
defaulting to 'origin' is not of "little to no" but "negative" value, is
it?

But I think we are minotiry.  To people with "CVS migrant" workflow,
cloning from _the_ central repo, hacking, and then pushing back will never
involve anything other than 'origin' and local repositories, and I am
sympathetic when they want to say "git push" and have it default to that
single other repository.

If you have more than one places to push, like we do, we have these
multiple repositories exactly because we would want to push to these
repositories for different reasons, and being able to name to which one we
would want to push in each invocation of push is a power.  But not all
people need to use that power.  If somebody pushes only to one place,
which may be very typical, that's fine, and in such a typical "single
remote" configuration, they will be pushing back to where they cloned
from.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

> Sorry, I don't really see a use case behind this.  `git push` today
> will push to origin all branches that exist both locally and already
> on the remote.  If you want to push to multiple locations, just
> specify the other URLs in the remote.origin.url configuration list.
> Linus added support for that years ago.

I publish my topic branches (with --mirror) on my personal site, and the 
master and stable branches on savannah.gnu.org.

>> Similarly, if a developer uses the integrator's repository but
>> wishes to publish his own mirror somewhere, he can just do "git push
>> --mirror".
> 
> Why not just have a remote named "my-mirror" and do `git push my-mirror`?

More precisely, it would be "git push && git push --mirror mirror".  My 
previous patch to add remote.<foo>.mirror shortens it to eliminate the 
--mirror, but I cannot condense it in one remote because one is mirror 
and the other isn't.

I can do this, in other words:

> For example in egit I can publish to both
> the master egit tree (repo.or.cz/egit.git) and to my fork
> (repo.or.cz/egit/spearce.git).  I publish to the latter almost
> daily, and rebase even more often than that.

... just by choosing whether to work in a topic branch or in a repo that 
is already on git.sv.gnu.org, but from a single checked out tree.  Like 
you guys, I have multiple places to push to -- and I want "git push" to 
DWIM.

Of course I have a git-mirror script that does it, but the use case 
seemed frequent enough to warrant the effort to provide it for other 
users too.

Replying to Junio:

> Configuring to push to multiple can already be done as you described, not
> having to have a special case code like this patch is certainly very
> attractive

I considered actually to change it to "push to every remote that has a 
push refspec", and adding code to "git clone" that added a push refspec 
for origin.  This would simplify the magic, but I wasn't sure of the 
ramifications and of whether it would change the behavior of the default 
remote.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

Patch withdrawn, I'll send a different series.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > I _hate_ the default remote. [...]
> 
> It sounds as if you want to say it a bit stronger than that --- to you,
> defaulting to 'origin' is not of "little to no" but "negative" value, is
> it?
> 
> But I think we are minotiry.  To people with "CVS migrant" workflow,
> cloning from _the_ central repo, hacking, and then pushing back will never
> involve anything other than 'origin' and local repositories, and I am
> sympathetic when they want to say "git push" and have it default to that
> single other repository.

Yes, I think we are in the minority.  Many people come to Git from
a centralized system so the idea of just a single place to pull/push
from makes perfect sense to them.

But then they later wonder why they need `git pull origin branch`
to merge in branch, when they usually just say `git pull`.  What is
the need for that funny keyword `origin`?  Why do I have to say
where to get the branch from sometimes and not others?

I think this argument is like the one we had with `git pull . branch`
vs. `git merge branch`.  However we probably could have gotten users
to accept `git merge . branch`, as the main argument there was the
fact that git-merge (the natural command to invoke) didn't actually do
what the user wanted, and git-pull did.

Just take the above as the rantings of someone who knows git a
little too well, and has tried to teach it to people who don't,
and they all have asked about the funny (to them) need for origin
in git-pull/git-push command line sometimes (no refspecs) and not
others (with refspecs).

-- 
Shawn.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> But then they later wonder why they need `git pull origin branch`
> to merge in branch, when they usually just say `git pull`.  What is
> the need for that funny keyword `origin`?  Why do I have to say
> where to get the branch from sometimes and not others?
> ...
> Just take the above as the rantings of someone who knows git a
> little too well, and has tried to teach it to people who don't,
> and they all have asked about the funny (to them) need for origin
> in git-pull/git-push command line sometimes (no refspecs) and not
> others (with refspecs).

What's the constructive suggestion for improvement we can draw from this
after all?  Should we deprecate the defaulting of "origin" so that
everybody now should always say "git pull $where"?  In other words, make
people more aware that what _they_ do is the special case to have only one
remote to interact with?

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

> What's the constructive suggestion for improvement we can draw from this
> after all?  Should we deprecate the defaulting of "origin" so that
> everybody now should always say "git pull $where"?

branch.*.remote would still provide a default, wouldn't it?  And if 
master is by default set up to track origin/master, the behavior 
wouldn't change.

> In other words, make
> people more aware that what _they_ do is the special case to have only one
> remote to interact with?

I think "git pull" is different, because it is more often fetching from 
one defined place (while Shawn said that he has a need for one-to-many 
"git push"es and so do I).  For "git pull", the branch config provides a 
valuable default more often than for "git push".

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Jeff King]

On Sun, Apr 27, 2008 at 01:34:46PM -0400, Shawn O. Pearce wrote:

> Just take the above as the rantings of someone who knows git a
> little too well, and has tried to teach it to people who don't,
> and they all have asked about the funny (to them) need for origin
> in git-pull/git-push command line sometimes (no refspecs) and not
> others (with refspecs).

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.  And it _is_ a bit funny, but it has nothing to do with
concepts. It is purely a syntactic issue that relying on order of
arguments means you can't default earlier ones but specify later ones.

Whether you hit this particular syntactic funniness depends totally on
your workflow. If you don't tend to default that particular argument,
then you won't see it. But there are plenty of workflows where you
never need to specify a remote, and then typing "git push master:foo"
makes you stop and blink for a second when it fails.

Of course, I don't think there is a reasonable fix now, short of "git
push --ref master:foo".

-Peff

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Jeff King]

On Sun, Apr 27, 2008 at 10:22:47PM +0200, Paolo Bonzini wrote:

> I think "git pull" is different, because it is more often fetching from  
> one defined place (while Shawn said that he has a need for one-to-many  
> "git push"es and so do I).  For "git pull", the branch config provides a  
> valuable default more often than for "git push".

I think it is highly dependent on your workflow. I would have said the
exact opposite.

For example, on one project, I keep a "working" repo on my laptop where
I develop and integrate work from others. I get their work by pulling
individually from other developers. But when I push, it always goes to
one place: my "publish" repo, where the other developers will grab my
changes.

In that workflow, I pull from many different places, but always push to
one. I assumed that is actually similar to the Linus "integrator"
workflow (although I think he just does one-shot pulls without defining
remotes).

-Peff

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > But then they later wonder why they need `git pull origin branch`
> > to merge in branch, when they usually just say `git pull`.  What is
> > the need for that funny keyword `origin`?  Why do I have to say
> > where to get the branch from sometimes and not others?
> 
> What's the constructive suggestion for improvement we can draw from this
> after all?  Should we deprecate the defaulting of "origin" so that
> everybody now should always say "git pull $where"?

Yes, I think that is what I was thinking.  By making users always say
where they are pulling, fetching or pushing from/to it becomes less
weird when you have to give a refspec too.

But this clearly harms the `git pull` case that relies upon the magic
branch.$name.remote and branch.$name.merge keys, as now git-pull is
expecting the user to supply a remote name, but one was already saved
for this current branch.

It also clearly harms people who have only origin and want to grab
updates from there with just `git fetch` or `git pull`.  Such a
change would be asking these users to enter a longer command line.

On the other hand, I think it would teach those users how to better
make use of git, and may cause less questions when they have to
step slightly outside of their normal use case and specify a refspec.

> In other words, make
> people more aware that what _they_ do is the special case to have only one
> remote to interact with?

My special case is always the other guys' common case.  You can't
please everone.  But here I think that _our_ special case (where we
always give the remote name/URL to fetch/pull/push) helps users to
learn the tool better, because it erases a special case from their
vocabularly of Git commands.

-- 
Shawn.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

> Yes, I think that is what I was thinking.  By making users always say
> where they are pulling, fetching or pushing from/to it becomes less
> weird when you have to give a refspec too.
> 
> But this clearly harms the `git pull` case that relies upon the magic
> branch.$name.remote and branch.$name.merge keys, as now git-pull is
> expecting the user to supply a remote name, but one was already saved
> for this current branch.

I would have no problem at all in removing the defaulting to "origin". 
Leaving the magic branch.<name>.{remote,merge} as the only case where 
0-argument "git pull" is allowed, would be much simpler to explain, and 
would not impact the "centralized" operation mode.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

>> I think "git pull" is different, because it is more often fetching from  
>> one defined place (while Shawn said that he has a need for one-to-many  
>> "git push"es and so do I).  For "git pull", the branch config provides a  
>> valuable default more often than for "git push".
> 
> I think it is highly dependent on your workflow. I would have said the
> exact opposite.

Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of 
merge).  I use "git pull" (without arguments) only when I can blindly 
not care about what's on the other side, e.g. because it's Junio who 
assures it is good. :-)

I actually think I never use "git pull" with arguments, but that's 
evidently me.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Stephen R. van den Berg]

Shawn O. Pearce wrote:
>It also clearly harms people who have only origin and want to grab
>updates from there with just `git fetch` or `git pull`.  Such a
>change would be asking these users to enter a longer command line.

Maybe this can be accomodated by having git fetch/git pull reference
all targets specified in the config file if none are specified on the
command line?

>On the other hand, I think it would teach those users how to better
>make use of git, and may cause less questions when they have to
>step slightly outside of their normal use case and specify a refspec.

I've been using git since november, and I found the magic "origin"
default one of the most confusing aspects (to figure out when it applies
and when not, and why (or why not)).
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg.

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Jeff King]

On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:

> Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of  
> merge).  I use "git pull" (without arguments) only when I can blindly not 
> care about what's on the other side, e.g. because it's Junio who assures 
> it is good. :-)

Well, I lied a little; I also use fetch + examine + merge. But the idea
about arguments holds true for "git fetch".

-Peff

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Jeff King]

On Mon, Apr 28, 2008 at 05:09:48AM -0400, Jeff King wrote:

> On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:
> 
> > Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of  
> > merge).  I use "git pull" (without arguments) only when I can blindly not 
> > care about what's on the other side, e.g. because it's Junio who assures 
> > it is good. :-)
> 
> Well, I lied a little; I also use fetch + examine + merge. But the idea
> about arguments holds true for "git fetch".

BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes. That seems
to be analagous to what you want with "git push". IOW, maybe instead of
changing the default behavior of "git push" you would be happy with a
"git remote push" which impacted multiple remotes.

-Peff

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

> BTW, I find myself decreasingly using "git fetch" in favor of "git
> remote update" which handles fetching from multiple remotes. That seems
> to be analagous to what you want with "git push". IOW, maybe instead of
> changing the default behavior of "git push" you would be happy with a
> "git remote push" which impacted multiple remotes.

I'm preparing a patch that has "git fetch" fetch from all remotes (same 
as "git remote update" with no groups defined) and "git push" push to 
all remotes.  I think this is much more sound; and it's not really as 
easy as this, but that's the idea. :-)

As always, thanks to the list for straightening my first design.  It 
happened for --track, for prepare-commit-msg (by the way, I am using it 
now that it's in 1.5.5, and it helps me so much) and for this too.  I 
hope that my improvements to git is worth your time, guys.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Johannes Schindelin]

Hi,

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

> I'm preparing a patch that has "git fetch" fetch from all remotes (same 
> as "git remote update" with no groups defined)

Funny, I would think that this functionality belongs into git-remote 
instead of git-fetch.  Especially since it would be possible to reuse the 
code you referred to...

Ciao,
Dscho

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Paolo Bonzini]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 28 Apr 2008, Paolo Bonzini wrote:
> 
>> I'm preparing a patch that has "git fetch" fetch from all remotes (same 
>> as "git remote update" with no groups defined)
> 
> Funny, I would think that this functionality belongs into git-remote 
> instead of git-fetch.

Maybe, but I'm pretty satisfied with the result.  It would take more 
effort than that to add all the functionality within "git remote 
update", and my patch series removes most of the magic associated with 
"origin".

> Especially since it would be possible to reuse the 
> code you referred to...

I checked and there's not much to reuse, since we don't care about 
groups or anything else.

Stay tuned -- I'm looking forward to any criticism.

Paolo

Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

[Johannes Schindelin]

Hi,

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

> Johannes Schindelin wrote:
>
> > On Mon, 28 Apr 2008, Paolo Bonzini wrote:
> > 
> > > I'm preparing a patch that has "git fetch" fetch from all remotes 
> > > (same as "git remote update" with no groups defined)
> > 
> > Funny, I would think that this functionality belongs into git-remote 
> > instead of git-fetch.
> 
> Maybe, but I'm pretty satisfied with the result.  It would take more 
> effort than that to add all the functionality within "git remote 
> update", and my patch series removes most of the magic associated with 
> "origin".

Then I must have misread your statement "same as "git remote 
update" with no groups defined".

Ciao,
Dscho

[PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Paolo Bonzini]

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

[PATCH 1/7] add special "matching refs" refspec

[Paolo Bonzini]

This patch provides a way to specify "push matching heads" using a
special refspec ":".  This is used in the following patches to
remove some of the magic behind "origin", but can also be useful
independent of those patches, because it allows "push = +:" as a way
to specify that matching refs will be pushed but, in addition,
forced updates will be allowed.

Allowing +: goes in the direction of setting per-remote "git push"
options in the configuration.  Previously, it was not possible to force
updates *and* keep the default behavior of only pushing matching refs.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-push.txt |   13 ++++---
 builtin-send-pack.c        |   10 +++++-
 remote.c                   |   80 +++++++++++++++++++++++++++++---------------
 remote.h                   |    1 +
 t/t5511-refspec.sh         |    5 ++-
 t/t5516-fetch-push.sh      |   41 ++++++++++++++++++++++
 6 files changed, 115 insertions(+), 35 deletions(-)

	The new code for match_refs, which does not have to distinguish
	whether pat is NULL or not, is much more readable IMHO.
	Unfortunately, diff makes a mess out of it.

	Enabling more "git push" options to be set in the configuration
	was suggested by Dscho, and is particularly useful if "git push"
	is to work on more than one repository (as is the case at the
	end of this series).

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index f06d94e..0cc44d7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -46,12 +46,6 @@ specified, the same ref that <src> referred to locally).  If
 the optional leading plus `+` is used, the remote ref is updated
 even if it does not result in a fast forward update.
 +
-Note: If no explicit refspec is found, (that is neither
-on the command line nor in any Push line of the
-corresponding remotes file---see below), then "matching" heads are
-pushed: for every head that exists on the local side, the remote side is
-updated if a head of the same name already exists on the remote side.
-+
 `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
 +
 A parameter <ref> without a colon pushes the <ref> from the source
@@ -59,6 +53,13 @@ repository to the destination repository under the same name.
 +
 Pushing an empty <src> allows you to delete the <dst> ref from
 the remote repository.
++
+The special refspec `:` (or `+:` to allow non-fast forward updates)
+directs git to push "matching" heads: for every head that exists on
+the local side, the remote side is updated if a head of the same name
+already exists on the remote side.  This is the default operation mode
+if no explicit refspec is found (that is neither on the command line
+nor in any Push line of the corresponding remotes file---see below).
 
 \--all::
 	Instead of naming each ref to push, specifies that all
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 7f7bddf..8d1e7be 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -642,9 +642,17 @@ static void verify_remote_names(int nr_heads, const char **heads)
 	int i;
 
 	for (i = 0; i < nr_heads; i++) {
+		const char *local = heads[i];
 		const char *remote = strrchr(heads[i], ':');
 
-		remote = remote ? (remote + 1) : heads[i];
+		if (*local == '+')
+			local++;
+
+		/* A matching refspec is okay.  */
+		if (remote == local && remote[1] == '\0')
+			continue;
+
+		remote = remote ? (remote + 1) : local;
 		switch (check_ref_format(remote)) {
 		case 0: /* ok */
 		case CHECK_REF_FORMAT_ONELEVEL:
diff --git a/remote.c b/remote.c
index 870d224..386213e 100644
--- a/remote.c
+++ b/remote.c
@@ -434,6 +434,14 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
 		}
 
 		rhs = strrchr(lhs, ':');
+
+		/* Before going on, special case ":" (or "+:") as a refspec
+		   for matching refs.  */
+		if (!fetch && rhs == lhs && rhs[1] == '\0') {
+			rs[i].matching = 1;
+			continue;
+		}
+
 		if (rhs) {
 			rhs++;
 			rlen = strlen(rhs);
@@ -847,7 +855,7 @@ static int match_explicit(struct ref *src, struct ref *dst,
 	const char *dst_value = rs->dst;
 	char *dst_guess;
 
-	if (rs->pattern)
+	if (rs->pattern || rs->matching)
 		return errs;
 
 	matched_src = matched_dst = NULL;
@@ -937,13 +945,23 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
 						 const struct ref *src)
 {
 	int i;
+	int matching_refs = -1;
 	for (i = 0; i < rs_nr; i++) {
+		if (rs[i].matching &&
+		    (matching_refs == -1 || rs[i].force)) {
+			matching_refs = i;
+			continue;
+		}
+
 		if (rs[i].pattern &&
 		    !prefixcmp(src->name, rs[i].src) &&
 		    src->name[strlen(rs[i].src)] == '/')
 			return rs + i;
 	}
-	return NULL;
+	if (matching_refs != -1)
+		return rs + matching_refs;
+	else
+		return NULL;
 }
 
 /*
@@ -954,11 +972,17 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
 int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
 	       int nr_refspec, const char **refspec, int flags)
 {
-	struct refspec *rs =
-		parse_push_refspec(nr_refspec, (const char **) refspec);
+	struct refspec *rs;
 	int send_all = flags & MATCH_REFS_ALL;
 	int send_mirror = flags & MATCH_REFS_MIRROR;
 
+	static const char *default_refspec[] = { ":", 0 };
+	if (!nr_refspec) {
+		nr_refspec = 1;
+		refspec = default_refspec;
+	}
+
+	rs = parse_push_refspec(nr_refspec, (const char **) refspec);
 	if (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))
 		return -1;
 
@@ -969,48 +993,50 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
 		char *dst_name;
 		if (src->peer_ref)
 			continue;
-		if (nr_refspec) {
-			pat = check_pattern_match(rs, nr_refspec, src);
-			if (!pat)
-				continue;
-		}
-		else if (!send_mirror && prefixcmp(src->name, "refs/heads/"))
+
+		pat = check_pattern_match(rs, nr_refspec, src);
+		if (!pat)
+			continue;
+
+		if (pat->matching) {
 			/*
 			 * "matching refs"; traditionally we pushed everything
 			 * including refs outside refs/heads/ hierarchy, but
 			 * that does not make much sense these days.
 			 */
-			continue;
+			if (!send_mirror && prefixcmp(src->name, "refs/heads/"))
+				continue;
+			dst_name = xstrdup(src->name);
 
-		if (pat) {
+		} else {
 			const char *dst_side = pat->dst ? pat->dst : pat->src;
 			dst_name = xmalloc(strlen(dst_side) +
 					   strlen(src->name) -
 					   strlen(pat->src) + 2);
 			strcpy(dst_name, dst_side);
 			strcat(dst_name, src->name + strlen(pat->src));
-		} else
-			dst_name = xstrdup(src->name);
+		}
 		dst_peer = find_ref_by_name(dst, dst_name);
-		if (dst_peer && dst_peer->peer_ref)
-			/* We're already sending something to this ref. */
-			goto free_name;
+		if (dst_peer) {
+			if (dst_peer->peer_ref)
+				/* We're already sending something to this ref. */
+				goto free_name;
+
+		} else {
+			if (pat->matching && !(send_all || send_mirror))
+				/*
+				 * Remote doesn't have it, and we have no
+				 * explicit pattern, and we don't have
+				 * --all nor --mirror.
+				 */
+				goto free_name;
 
-		if (!dst_peer && !nr_refspec && !(send_all || send_mirror))
-			/*
-			 * Remote doesn't have it, and we have no
-			 * explicit pattern, and we don't have
-			 * --all nor --mirror.
-			 */
-			goto free_name;
-		if (!dst_peer) {
 			/* Create a new one and link it */
 			dst_peer = make_linked_ref(dst_name, dst_tail);
 			hashcpy(dst_peer->new_sha1, src->new_sha1);
 		}
 		dst_peer->peer_ref = src;
-		if (pat)
-			dst_peer->force = pat->force;
+		dst_peer->force = pat->force;
 	free_name:
 		free(dst_name);
 	}
diff --git a/remote.h b/remote.h
index 6878c52..5b0a2b4 100644
--- a/remote.h
+++ b/remote.h
@@ -47,6 +47,7 @@ int remote_has_url(struct remote *remote, const char *url);
 struct refspec {
 	unsigned force : 1;
 	unsigned pattern : 1;
+	unsigned matching : 1;
 
 	char *src;
 	char *dst;
diff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh
index 670a8f1..22ba380 100755
--- a/t/t5511-refspec.sh
+++ b/t/t5511-refspec.sh
@@ -23,10 +23,13 @@ test_refspec () {
 }
 
 test_refspec push ''						invalid
-test_refspec push ':'						invalid
+test_refspec push ':'
+test_refspec push '::'						invalid
+test_refspec push '+:'
 
 test_refspec fetch ''
 test_refspec fetch ':'
+test_refspec fetch '::'						invalid
 
 test_refspec push 'refs/heads/*:refs/remotes/frotz/*'
 test_refspec push 'refs/heads/*:refs/remotes/frotz'		invalid
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 0a757d5..53e47e1 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -165,6 +165,47 @@ test_expect_success 'push with matching heads' '
 
 '
 
+test_expect_success 'push with matching heads on the command line' '
+
+	mk_test heads/master &&
+	git push testrepo : &&
+	check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'failed (non-fast-forward) push with matching heads' '
+
+	mk_test heads/master &&
+	git push testrepo : &&
+	git commit --amend -massaged &&
+	! git push testrepo &&
+	check_push_result $the_commit heads/master &&
+	git reset --hard $the_commit
+
+'
+
+test_expect_success 'push --force with matching heads' '
+
+	mk_test heads/master &&
+	git push testrepo : &&
+	git commit --amend -massaged &&
+	git push --force testrepo &&
+	! check_push_result $the_commit heads/master &&
+	git reset --hard $the_commit
+
+'
+
+test_expect_success 'push with matching heads and forced update' '
+
+	mk_test heads/master &&
+	git push testrepo : &&
+	git commit --amend -massaged &&
+	git push testrepo +: &&
+	! check_push_result $the_commit heads/master &&
+	git reset --hard $the_commit
+
+'
+
 test_expect_success 'push with no ambiguity (1)' '
 
 	mk_test heads/master &&
-- 
1.5.5

[PATCH 2/7] add push line in git-clone

[Paolo Bonzini]

This patch makes git-clone add a remote.origin.push line, using the
new ":" special refspec.  This is useful in the following patches that
modify the behavior of "git push"; right now, it only adds clarity.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 git-clone.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 2636159..7a5570a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -480,6 +480,8 @@ then
 	# Set up the mappings to track the remote branches.
 	git config remote."$origin".fetch \
 		"+refs/heads/*:$remote_top/*" '^$' &&
+	git config remote."$origin".push \
+		":" '^$' &&
 
 	# Write out remote.$origin config, and update our "$head_points_at".
 	case "$head_points_at" in
-- 
1.5.5

[PATCH 3/7] Add a --push option to "git-remote add"

[Paolo Bonzini]

This patch adds a --push option to "git-remote add" which sets up a
push refspec.  This will be useful after the following patch to
"git-push", which will make heavier use of push refspecs.  Even now,
however, the option combination "--mirror --push" can be used to set
up a mirror *of this repository*, with a normal fetch refspec
(refs/heads/*:refs/remotes/mirror/*) but with the remote.<nick>.mirror
option set.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-remote.txt |   25 +++++++++++++++++++------
 builtin-remote.c             |   32 ++++++++++++++++++++++++--------
 t/t5505-remote.sh            |   26 +++++++++++++++++++++++++-
 t/t5517-push-mirror.sh       |    2 +-
 4 files changed, 69 insertions(+), 16 deletions(-)

	My earlier preference for "--mirror" as an option for
	mirrored-from-here remotes is due to my earlier experience
	with arch (from which I migrated to git).  However, I'm very
	fine with "--mirror --push" since it's consistent with the
	meaning of the new option --push.

	This patch does not depend on patch 4, on the contrary the
	dependency is the other way round.  However, it does not make
	much sense as an independent change.  That's why the documentation
	for --push leaves something to be desired.  It will be fixed in
	patch 4, as the doc will refer to the behavior implemented there.

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index b20e851..e779905 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git-remote'
-'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] [--push] <name> <url>
 'git-remote' rm <name>
 'git-remote' show <name>
 'git-remote' prune <name>
@@ -47,11 +47,24 @@ With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
 up to point at remote's `<master>` branch instead of whatever
 branch the `HEAD` at the remote repository actually points at.
 +
-In mirror mode, enabled with `\--mirror`, the refs will not be stored
-in the 'refs/remotes/' namespace, but in 'refs/heads/'.  This option
-only makes sense in bare repositories.  If a remote uses mirror
-mode, furthermore, `git push` will always behave as if `\--mirror`
-was passed.
+`\--push` mode adds a `push` configuration line for the remote.
+It also affects the operation of mirror mode.
++
+Mirror mode, enabled with `\--mirror`, specifies that one of the
+repositories (either the current one or the remote one) is giving
+up control on its refs namespace to the other repository.  If a
+remote uses mirror mode, furthermore, `git push` will always
+behave as if `\--mirror` was passed.
+
+If `\--mirror` is given without `\--push`, this repository will
+act as a mirror of the remote, and hence the remote's refs will not
+be stored in the 'refs/remotes/' namespace, but in 'refs/heads/';
+this only makes sense in bare repositories.  If the two options
+are given in combination, instead, the other repository will
+act as a mirror of this one; in this case, the effect of mirror
+mode is that `git-push` will always add any newly created local
+refs to the remote, will force updates of locally updated refs,
+and will remove any deleted refs from the remote too.
 
 'rm'::
 
diff --git a/builtin-remote.c b/builtin-remote.c
index 8b63619..759dddb 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -56,7 +56,7 @@ static int fetch_remote(const char *name)
 
 static int add(int argc, const char **argv)
 {
-	int fetch = 0, mirror = 0;
+	int fetch = 0, mirror = 0, push = 0;
 	struct path_list track = { NULL, 0, 0 };
 	const char *master = NULL;
 	struct remote *remote;
@@ -71,6 +71,7 @@ static int add(int argc, const char **argv)
 			"branch(es) to track", opt_parse_track),
 		OPT_STRING('m', "master", &master, "branch", "master branch"),
 		OPT_BOOLEAN(0, "mirror", &mirror, "no separate remotes"),
+		OPT_BOOLEAN(0, "push", &push, "make \"git push\" work on this remote"),
 		OPT_END()
 	};
 
@@ -101,23 +102,38 @@ static int add(int argc, const char **argv)
 	strbuf_reset(&buf);
 	strbuf_addf(&buf, "remote.%s.fetch", name);
 
-	if (track.nr == 0)
-		path_list_append("*", &track);
-	for (i = 0; i < track.nr; i++) {
-		struct path_list_item *item = track.items + i;
+	for (i = 0; i < (track.nr ? track.nr : 1); i++) {
+		const char *path = track.nr ? track.items[i].path : "*";
 
 		strbuf_reset(&buf2);
 		strbuf_addch(&buf2, '+');
-		if (mirror)
+		if (mirror && !push)
 			strbuf_addf(&buf2, "refs/%s:refs/%s",
-					item->path, item->path);
+					path, path);
 		else
 			strbuf_addf(&buf2, "refs/heads/%s:refs/remotes/%s/%s",
-					item->path, name, item->path);
+					path, name, path);
 		if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
 			return 1;
 	}
 
+	if (push) {
+		strbuf_reset(&buf);
+		strbuf_addf(&buf, "remote.%s.push", name);
+
+		for (i = 0; i < (track.nr ? track.nr : 1); i++) {
+			strbuf_reset(&buf2);
+			if (track.nr) {
+				const char *path = track.items[i].path;
+				strbuf_addf(&buf2, "refs/heads/%s:refs/heads/%s",
+						path, path);
+			} else
+				strbuf_addstr(&buf2, ":");
+			if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+				return 1;
+		}
+	}
+
 	if (mirror) {
 		strbuf_reset(&buf);
 		strbuf_addf(&buf, "remote.%s.mirror", name);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 48ff2d4..56e5e06 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -28,7 +28,7 @@ tokens_match () {
 }
 
 check_remote_track () {
-	actual=$(git remote show "$1" | sed -n -e '$p') &&
+	actual=$(git remote show "$1" | sed -n -e '/Tracked/!d;n;p') &&
 	shift &&
 	tokens_match "$*" "$actual"
 }
@@ -269,4 +269,28 @@ test_expect_success 'reject adding remote with an invalid name' '
 
 '
 
+test_expect_success 'fetching from push mirror leaves refs/head intact' '
+
+	(cd four && git init
+	 >file34 &&
+	 git add file34 &&
+	 test_tick &&
+	 git commit -m "Initial alternative")
+	cd one && 
+	git remote add --mirror --push four ../four &&
+	git fetch four &&
+	git rev-parse -s --verify refs/remotes/four/master
+	! test -f file34
+'
+
+test_expect_success 'fetching from mirror overwrites refs/head' '
+
+	cd four &&
+	test -f file34 &&
+	git remote add --mirror one ../one &&
+	git fetch one &&
+	! git rev-parse -s --verify refs/remotes/one/master
+	! test -f file34
+'
+
 test_done
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index ea49ded..cacc08c 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -25,7 +25,7 @@ mk_repo_pair () {
 	(
 		cd master &&
 		git init &&
-		git remote add $1 up ../mirror
+		git remote add --push $1 up ../mirror
 	)
 }
 
-- 
1.5.5

[PATCH 4/7] make "git push" update all push repositories.

[Paolo Bonzini]

This patch builds on the infrastructure for "git remote add --push"
to make the behavior of "git push" more general.  Because now remotes
can be explicitly designated for pushing (previously, you had no
way to do this *and* keep the "matching refspecs" behavior of "git push"),
now "git push" and "git push --mirror" can work like this:

- "git push" pushes to all push remotes.

- "git push --mirror" only updates mirror repositories, without touching
  other push remotes.

Furthermore, "git push --all" is now invalid without a repository.
I did this because --all and --mirror are incompatible, and so the
operation of a DWIM "git push --all" would probably not be what
the user meant.

Among the use cases of this, consider when a project has a public
repository managed by the integrator, but the integrator also wants to
publish his own topic branches somewhere.  In this case, the integrator can
just do "git push" and push the public branches to the public repository,
as well as his own topic branches to his own unofficial mirror.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-push.txt   |   22 +++++++++--
 Documentation/git-remote.txt |   10 +++---
 builtin-push.c               |   67 ++++++++++++++++++++++++++++------
 t/t5400-send-pack.sh         |    2 +-
 t/t5517-push-mirror.sh       |   82 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 161 insertions(+), 22 deletions(-)

	I think it is too early to warn if there is no push refspec for.
	origin (as I'll do for git-fetch in the final patch of the series).
	After all, clones made with any current version of git do *not*
	have a remote.origin.push refspec.

	This changes the behavior of "git push" if the user has a remote
	with push refspecs in his configuration; in this case the user
	should execute "git config remote.origin.push :" so that "git
	push" considers the origin remote too.  This should be written in
	the release notes.

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 0cc44d7..a1436f4 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -29,6 +29,14 @@ OPTIONS
 	The "remote" repository that is destination of a push
 	operation.  See the section <<URLS,GIT URLS>> below.
 
+	Unless \--all or \--tags are given, it is possible to
+	omit the destination repository and refspec.  In this
+	case, git will push to all remotes that have a
+	`remote.<name>.push` configuration line.  In case
+	git finds none, it will push to the "origin" remote;
+	this however is only done for backwards compatibility
+	with older versions of git.
+
 <refspec>::
 	The canonical format of a <refspec> parameter is
 	`+?<src>:<dst>`; that is, an optional plus `+`, followed
@@ -71,8 +79,14 @@ nor in any Push line of the corresponding remotes file---see below).
 	be mirrored to the remote repository.  Newly created local
 	refs will be pushed to the remote end, locally updated refs
 	will be force updated on the remote end, and deleted refs
-	will be removed from the remote end.  This is the default
-	if the configuration option `remote.<remote>.mirror` is
+	will be removed from the remote end.
+
+	For every repository that git tries as a destination, it will
+	also look up the corresponding configuration option
+	`remote.<repository>.mirror` and enables mirror mode
+	if it is set.  Furthermore, if `git push --mirror` is used
+	without specifying a destination repository, git will
+	only push to those remotes that have the configuration option
 	set.
 
 \--dry-run::
@@ -99,8 +113,8 @@ nor in any Push line of the corresponding remotes file---see below).
 	remote repository to lose commits; use it with care.
 
 \--repo=<repo>::
-	When no repository is specified the command defaults to
-	"origin"; this overrides it.
+	Overrides the default behavior of the command when no repository
+	is specified, so that <repo> is used as the destination repository.
 
 \--thin, \--no-thin::
 	These options are passed to `git-send-pack`.  Thin
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index e779905..d313a2f 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -47,8 +47,9 @@ With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
 up to point at remote's `<master>` branch instead of whatever
 branch the `HEAD` at the remote repository actually points at.
 +
-`\--push` mode adds a `push` configuration line for the remote.
-It also affects the operation of mirror mode.
+`\--push` mode configures the remote so that `git push` with
+no arguments will attempt pushing to it.  It also affects the
+operation of `\--mirror`.
 +
 Mirror mode, enabled with `\--mirror`, specifies that one of the
 repositories (either the current one or the remote one) is giving
@@ -102,9 +103,8 @@ be updated.  (See linkgit:git-config[1]).
 DISCUSSION
 ----------
 
-The remote configuration is achieved using the `remote.origin.url` and
-`remote.origin.fetch` configuration variables.  (See
-linkgit:git-config[1]).
+The remote configuration is achieved using the `remote.<name>.*`
+configuration variables.  (See linkgit:git-config[1]).
 
 Examples
 --------
diff --git a/builtin-push.c b/builtin-push.c
index b35aad6..f877e49 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -48,14 +48,12 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }
 
-static int do_push(const char *repo, int flags)
+static int do_push(struct remote *remote, int flags)
 {
 	int i, errs;
-	struct remote *remote = remote_get(repo);
-
-	if (!remote)
-		die("bad repository '%s'", repo);
-
+	const char **push_refspec = refspec;
+	int push_refspec_nr = refspec_nr;
+
 	if (remote->mirror)
 		flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
 
@@ -70,8 +68,8 @@ static int do_push(const char *repo, int flags)
 	if (!refspec
 		&& !(flags & TRANSPORT_PUSH_ALL)
 		&& remote->push_refspec_nr) {
-		refspec = remote->push_refspec;
-		refspec_nr = remote->push_refspec_nr;
+		push_refspec = remote->push_refspec;
+		push_refspec_nr = remote->push_refspec_nr;
 	}
 	errs = 0;
 	for (i = 0; i < remote->url_nr; i++) {
@@ -86,7 +84,7 @@ static int do_push(const char *repo, int flags)
 
 		if (verbose)
 			fprintf(stderr, "Pushing to %s\n", remote->url[i]);
-		err = transport_push(transport, refspec_nr, refspec, flags);
+		err = transport_push(transport, push_refspec_nr, push_refspec, flags);
 		err |= transport_disconnect(transport);
 
 		if (!err)
@@ -98,6 +96,27 @@ static int do_push(const char *repo, int flags)
 	return !!errs;
 }
 
+static int num_push_remotes;
+
+static int push_to_remote(struct remote *remote, void *priv)
+{
+	int *p_flags = priv;
+	int rc;
+
+	/* With "git-push --mirror", only push to mirrors.  */
+	if ((*p_flags & TRANSPORT_PUSH_MIRROR) && !remote->mirror)
+		return 0;
+	if (!remote->push_refspec_nr)
+		return 0;
+
+	num_push_remotes++;
+	rc = do_push (remote, *p_flags);
+
+	/* No command-line errors should occur.  */
+	assert (rc != -1);
+	return rc;
+}
+
 int cmd_push(int argc, const char **argv, const char *prefix)
 {
 	int flags = 0;
@@ -108,6 +127,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 	int tags = 0;
 	int rc;
 	const char *repo = NULL;	/* default repository */
+	struct remote *remote;
 
 	struct option options[] = {
 		OPT__VERBOSE(&verbose),
@@ -143,9 +163,32 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		set_refspecs(argv + 1, argc - 1);
 	}
 
-	rc = do_push(repo, flags);
+	if (!repo) {
+		/* Don't attempt to figure DWIM behavior when refspecs are
+		   provided.  */
+		if (all || tags)
+			die("please specify destination repository together "
+			    "with --all or --tags");
+
+		assert (!refspec);
+		rc = for_each_remote (push_to_remote, &flags);
+		if (rc)
+			return rc;
+		if (num_push_remotes)
+			return 0;
+
+		/* Fallback: use origin, but not for "git push --mirror".  */
+		if (mirror)
+			die("no mirrors configured, use git-push --mirror <repo> to force operation");
+	}
+
+	remote = remote_get(repo);
+	if (!remote)
+		die("bad repository '%s'", repo);
+
+	rc = do_push(remote, flags);
 	if (rc == -1)
 		usage_with_options(push_usage, options);
-	else
-		return rc;
+
+	return rc;
 }
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 2b6b6e3..ab01b2a 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -118,7 +118,7 @@ test_expect_success \
 	mkdir parent && cd parent &&
 	git-init && touch file && git-add file && git-commit -m add &&
 	cd .. &&
-	git-clone parent child && cd child && git-push --all &&
+	git-clone parent child && cd child && git-push --all origin &&
 	cd ../parent &&
 	git-branch -a >branches && ! grep origin/master branches
 '
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index cacc08c..9afa741 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -29,6 +29,26 @@ mk_repo_pair () {
 	)
 }
 
+# a more complicated setup where we have also an origin repo
+mk_repo_three () {
+	rm -rf master mirror origin &&
+	mkdir mirror &&
+	(
+		cd mirror &&
+		git init
+	) &&
+	mkdir origin &&
+	(
+		cd origin &&
+		git init
+		echo one >foo && git add foo && git commit -m one
+	) &&
+	git clone origin master &&
+	(
+		cd master &&
+		git remote add --push --mirror up ../mirror
+	)
+}
 
 # BRANCH tests
 test_expect_success 'push mirror creates new branches' '
@@ -264,4 +284,66 @@ test_expect_success 'remote.foo.mirror=no has no effect' '
 
 '
 
+test_expect_success 'mirrors are updated by "git push"' '
+
+	mk_repo_three &&
+	(
+		cd master &&
+		git branch keep master &&
+		git branch remove master &&
+		git push &&
+		git branch -D remove
+		git push
+	) &&
+	(
+		cd mirror &&
+		git show-ref -s --verify refs/heads/keep &&
+		invert git show-ref -s --verify refs/heads/remove
+	) &&
+	(
+		cd origin &&
+		invert git show-ref -s --verify refs/heads/keep &&
+		invert git show-ref -s --verify refs/heads/remove
+	)
+
+'
+
+test_expect_success '"git push --all mirror" fails and does not leave half updates' '
+
+	mk_repo_three &&
+	(
+		cd master &&
+		git branch b1 master &&
+		invert git push --all mirror
+	) &&
+	(
+		cd mirror &&
+		invert git show-ref -s --verify refs/heads/b1
+	)
+
+'
+
+test_expect_success 'mirrors are not updated by "git push --repo" or "git push <repo>"' '
+
+	mk_repo_three &&
+	(
+		cd master &&
+		git branch b1 master &&
+		git push origin
+		git branch b2 master &&
+		git push --repo=origin
+	) &&
+	(
+		cd mirror &&
+		invert git show-ref -s --verify refs/heads/b1 &&
+		invert git show-ref -s --verify refs/heads/b2
+	) &&
+	(
+		cd origin &&
+		invert git show-ref -s --verify refs/heads/b1 &&
+		invert git show-ref -s --verify refs/heads/b2
+	)
+
+'
+
 test_done
-- 
1.5.5

[PATCH 5/7] don't rely on zero-argument "git fetch" from within git pull

[Paolo Bonzini]

Since the series will change the meaning of zero-argument
"git fetch", it is necessary that git pull does not rely on it.
Instead, it resolves it using git-parse-remote, which will
return either branch.*.remote or "origin" (at the end of the
series, the latter will throw out a big deprecation warning).

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 git-pull.sh |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index bf0c298..5dec4cf 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -106,10 +106,13 @@ error_on_no_merge_candidates () {
 	exit 1
 }
 
+. git-parse-remote
+if test $# = 0; then
+	set x $(get_default_remote); shift
+fi
+
+origin="$1"
 test true = "$rebase" && {
-	. git-parse-remote &&
-	origin="$1"
-	test -z "$origin" && origin=$(get_default_remote)
 	reflist="$(get_remote_refs_for_fetch "$@" 2>/dev/null |
 		sed "s|refs/heads/\(.*\):|\1|")" &&
 	oldremoteref="$(git rev-parse --verify \
-- 
1.5.5

[PATCH 6/7] warn on "git pull" without a given branch.<name>.remote value

[Paolo Bonzini]

This patch deprecates the behavior of "git pull" without a
branch.<name>.remote value in the configuration.  The value
"origin" will be used, but a warning will be printed too.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-pull.txt |    9 +++++----
 git-parse-remote.sh        |    8 ++++++++
 2 files changed, 13 insertions(+), 4 deletions(-)

	In this case, I think we can warn because branch.*.remote
	lines are created by checkouts made with 1.5 or later.

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 3405ca0..18898f6 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -58,10 +58,11 @@ DEFAULT BEHAVIOUR
 -----------------
 
 Often people use `git pull` without giving any parameter.
-Traditionally, this has been equivalent to saying `git pull
-origin`.  However, when configuration `branch.<name>.remote` is
-present while on branch `<name>`, that value is used instead of
-`origin`.
+While on branch `<name>`, this will use the value of configuration
+`branch.<name>.remote` as the branch to pull from.  If the
+value is not present, it will be implicitly considered to be
+`origin`; however, this is deprecated and you consider
+writing the value explicitly in the configuration file.
 
 In order to determine what URL to use to fetch from, the value
 of the configuration `remote.<origin>.url` is consulted
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..eddb593 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -54,9 +54,17 @@ get_remote_url () {
 	esac
 }
 
+warned_about_default_remote=no
 get_default_remote () {
 	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
 	origin=$(git config --get "branch.$curr_branch.remote")
+	if test -z "$origin" && test "$warned_about_default_remote" = no; then
+	        echo "warning: you asked me to pull without telling me which repository"
+	        echo "warning: you want to pull from, and 'branch.${curr_branch}.remote'"
+	        echo "warning: in your configuration file does not tell me either."
+	        echo "warning: proceeding with 'origin'."
+		warned_about_default_remote=yes
+	fi
 	echo ${origin:-origin}
 }
 
-- 
1.5.5

[PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

This patch parallels what a previous patch did to "git push".
It makes "git fetch" with no repository argument similar to
"git remote update" with no default group set.  Of course,
"git fetch" with no arguments honors skipDefaultUpdate too.

The patch also modifies the existing tests so that they do not execute
git-fetch without arguments.  In the case of t5515, tests that executed
git-fetch without arguments are removed completely.  A new test is
added to t5510 that tests the new operation mode.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
---
 Documentation/git-fetch.txt               |    7 ++
 builtin-fetch.c                           |  109 ++++++++++++++++-------------
 t/t5510-fetch.sh                          |   19 +++++-
 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 ---
 44 files changed, 88 insertions(+), 536 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

	The patch is a little more complicated than necessary because
	some global variables were shadowed by locals.  That's a useful
	cleanup of its own.

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index d982f96..f212d89 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -31,6 +31,13 @@ branches you are not interested in, you will not get them.
 
 OPTIONS
 -------
+<repository>::
+        The "remote" repository whose updates are to be
+	fetched.  If no repository is specified, all remotes
+	which do not have the configuration parameter
+	remote.<name>.skipDefaultUpdate set to true will
+	be updated.  (See linkgit:git-config[1])
+
 include::fetch-options.txt[]
 
 include::pull-fetch-param.txt[]
diff --git a/builtin-fetch.c b/builtin-fetch.c
index e4486e4..d4aaf67 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -23,11 +23,13 @@ enum {
 };
 
 static int append, force, keep, update_head_ok, verbose, quiet;
-static int tags = TAGS_DEFAULT;
+static int fetch_tags = TAGS_DEFAULT;
 static const char *depth;
 static const char *upload_pack;
 static struct strbuf default_rla = STRBUF_INIT;
 static struct transport *transport;
+static struct refspec *refs;
+static int ref_count = 0;
 
 static struct option builtin_fetch_options[] = {
 	OPT__QUIET(&quiet),
@@ -38,9 +40,9 @@ static struct option builtin_fetch_options[] = {
 		   "path to upload pack on remote end"),
 	OPT_BOOLEAN('f', "force", &force,
 		    "force overwrite of local branch"),
-	OPT_SET_INT('t', "tags", &tags,
+	OPT_SET_INT('t', "tags", &fetch_tags,
 		    "fetch all tags and associated objects", TAGS_SET),
-	OPT_SET_INT('n', NULL, &tags,
+	OPT_SET_INT('n', NULL, &fetch_tags,
 		    "do not fetch all tags (--no-tags)", TAGS_UNSET),
 	OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"),
 	OPT_BOOLEAN('u', "update-head-ok", &update_head_ok,
@@ -523,15 +525,44 @@ static void find_non_local_tags(struct transport *transport,
 	path_list_clear(&new_refs, 0);
 }
 
-static int do_fetch(struct transport *transport,
-		    struct refspec *refs, int ref_count)
+static void set_option(const char *name, const char *value)
+{
+	int r = transport_set_option(transport, name, value);
+	if (r < 0)
+		die("Option \"%s\" value \"%s\" is not valid for %s\n",
+			name, value, transport->url);
+	if (r > 0)
+		warning("Option \"%s\" is ignored for %s\n",
+			name, transport->url);
+}
+
+
+static int do_fetch(struct remote *remote)
 {
 	struct ref *ref_map;
 	struct ref *rm;
-	int autotags = (transport->remote->fetch_tags == 1);
-	if (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)
+	int autotags = (remote->fetch_tags == 1);
+	int tags = fetch_tags;
+
+	if (!remote->url_nr)
+		die("Where do you want to fetch from today?");
+
+	transport = transport_get(remote, remote->url[0]);
+	assert (transport->url);
+	if (verbose >= 2)
+		transport->verbose = 1;
+	if (quiet)
+		transport->verbose = -1;
+	if (upload_pack)
+		set_option(TRANS_OPT_UPLOADPACK, upload_pack);
+	if (keep)
+		set_option(TRANS_OPT_KEEP, "yes");
+	if (depth)
+		set_option(TRANS_OPT_DEPTH, depth);
+
+	if (remote->fetch_tags == 2 && tags != TAGS_UNSET)
 		tags = TAGS_SET;
-	if (transport->remote->fetch_tags == -1)
+	if (remote->fetch_tags == -1)
 		tags = TAGS_UNSET;
 
 	if (!transport->get_refs_list || !transport->fetch)
@@ -544,6 +575,7 @@ static int do_fetch(struct transport *transport,
 		if (!fp)
 			return error("cannot open %s: %s\n", filename, strerror(errno));
 		fclose(fp);
+		append = 1;
 	}
 
 	ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
@@ -557,7 +589,7 @@ static int do_fetch(struct transport *transport,
 		transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, "1");
 	if (fetch_refs(transport, ref_map)) {
 		free_refs(ref_map);
-		return 1;
+		goto error;
 	}
 	free_refs(ref_map);
 
@@ -576,27 +608,26 @@ static int do_fetch(struct transport *transport,
 	}
 
 	transport_disconnect(transport);
-
 	return 0;
+
+error:
+	unlock_pack ();
+	return 1;
 }
 
-static void set_option(const char *name, const char *value)
+static int fetch_one_remote(struct remote *remote, void *unused)
 {
-	int r = transport_set_option(transport, name, value);
-	if (r < 0)
-		die("Option \"%s\" value \"%s\" is not valid for %s\n",
-			name, value, transport->url);
-	if (r > 0)
-		warning("Option \"%s\" is ignored for %s\n",
-			name, transport->url);
+	if (remote->skip_default_update || !remote->url_nr)
+		return 0;
+
+	do_fetch (remote);
 }
 
 int cmd_fetch(int argc, const char **argv, const char *prefix)
 {
 	struct remote *remote;
 	int i;
-	static const char **refs = NULL;
-	int ref_nr = 0;
+	static const char **arg_refs = NULL;
 
 	/* Record the command line for the reflog */
 	strbuf_addstr(&default_rla, "fetch");
@@ -606,29 +637,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 	argc = parse_options(argc, argv,
 			     builtin_fetch_options, builtin_fetch_usage, 0);
 
-	if (argc == 0)
-		remote = remote_get(NULL);
-	else
-		remote = remote_get(argv[0]);
-
-	transport = transport_get(remote, remote->url[0]);
-	if (verbose >= 2)
-		transport->verbose = 1;
-	if (quiet)
-		transport->verbose = -1;
-	if (upload_pack)
-		set_option(TRANS_OPT_UPLOADPACK, upload_pack);
-	if (keep)
-		set_option(TRANS_OPT_KEEP, "yes");
-	if (depth)
-		set_option(TRANS_OPT_DEPTH, depth);
-
-	if (!transport->url)
-		die("Where do you want to fetch from today?");
-
 	if (argc > 1) {
 		int j = 0;
-		refs = xcalloc(argc + 1, sizeof(const char *));
+		arg_refs = xcalloc(argc + 1, sizeof(const char *));
 		for (i = 1; i < argc; i++) {
 			if (!strcmp(argv[i], "tag")) {
 				char *ref;
@@ -640,16 +651,18 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 				strcat(ref, argv[i]);
 				strcat(ref, ":refs/tags/");
 				strcat(ref, argv[i]);
-				refs[j++] = ref;
+				arg_refs[j++] = ref;
 			} else
-				refs[j++] = argv[i];
+				arg_refs[j++] = argv[i];
 		}
-		refs[j] = NULL;
-		ref_nr = j;
+		arg_refs[j] = NULL;
+		ref_count = j;
 	}
+	refs = parse_fetch_refspec(ref_count, arg_refs);
 
 	signal(SIGINT, unlock_pack_on_signal);
-	atexit(unlock_pack);
-	return do_fetch(transport,
-			parse_fetch_refspec(ref_nr, refs), ref_nr);
+	if (argc == 0)
+		return for_each_remote (fetch_one_remote, NULL);
+	else
+		return do_fetch (remote_get(argv[0]));
 }
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 6946557..28da6bd 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -45,7 +45,7 @@ test_expect_success "fetch test" '
 	echo >file updated by origin &&
 	git commit -a -m "updated by origin" &&
 	cd two &&
-	git fetch &&
+	git fetch one &&
 	test -f .git/refs/heads/one &&
 	mine=`git rev-parse refs/heads/one` &&
 	his=`cd ../one && git rev-parse refs/heads/master` &&
@@ -55,12 +55,29 @@ test_expect_success "fetch test" '
 test_expect_success "fetch test for-merge" '
 	cd "$D" &&
 	cd three &&
+	git fetch two &&
+	test -f .git/refs/heads/two &&
+	test -f .git/refs/heads/one &&
+	master_in_two=`cd ../two && git rev-parse master` &&
+	one_in_two=`cd ../two && git rev-parse one` &&
+	{
+		echo "$master_in_two	not-for-merge"
+		echo "$one_in_two	"
+	} >expected &&
+	cut -f -2 .git/FETCH_HEAD >actual &&
+	diff expected actual'
+
+test_expect_success "fetch all remotes" '
+	cd "$D" &&
+	cd three &&
 	git fetch &&
 	test -f .git/refs/heads/two &&
 	test -f .git/refs/heads/one &&
+	master_in_origin=`cd .. && git rev-parse master` &&
 	master_in_two=`cd ../two && git rev-parse master` &&
 	one_in_two=`cd ../two && git rev-parse one` &&
 	{
+		echo "$master_in_origin	not-for-merge"
 		echo "$master_in_two	not-for-merge"
 		echo "$one_in_two	"
 	} >expected &&
diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
index 65c3774..8568b4b 100755
--- a/t/t5515-fetch-merge-logic.sh
+++ b/t/t5515-fetch-merge-logic.sh
@@ -91,10 +91,7 @@ test_expect_success setup '
 # Merge logic depends on branch properties and Pull: or .fetch lines
 for remote in $remotes ; do
     for branch in "" "-merge" "-octopus" ; do
-cat <<EOF
-br-$remote$branch
-br-$remote$branch $remote
-EOF
+	echo br-$remote$branch $remote
     done
 done > tests
 
@@ -103,7 +100,6 @@ done > tests
 # Use two branches completely unrelated from the arguments,
 # the clone default and one without branch properties
 for branch in master br-unconfig ; do
-    echo $branch
     for remote in $remotes ; do
 	echo $branch $remote
     done
@@ -140,7 +136,7 @@ do
 		{
 			echo "# $cmd"
 			set x $cmd; shift
-			git symbolic-ref HEAD refs/heads/$1 ; shift
+			git symbolic-ref HEAD refs/heads/$1; shift
 			rm -f .git/FETCH_HEAD
 			rm -f .git/refs/heads/*
 			rm -f .git/refs/remotes/rem/*
diff --git a/t/t5515/fetch.br-branches-default b/t/t5515/fetch.br-branches-default
deleted file mode 100644
index 2e0414f..0000000
--- a/t/t5515/fetch.br-branches-default
+++ /dev/null
@@ -1,8 +0,0 @@
-# br-branches-default
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f		branch 'master' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-branches-default-merge b/t/t5515/fetch.br-branches-default-merge
deleted file mode 100644
index ca2cc1d..0000000
--- a/t/t5515/fetch.br-branches-default-merge
+++ /dev/null
@@ -1,9 +0,0 @@
-# br-branches-default-merge
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-branches-default-octopus b/t/t5515/fetch.br-branches-default-octopus
deleted file mode 100644
index ec39c54..0000000
--- a/t/t5515/fetch.br-branches-default-octopus
+++ /dev/null
@@ -1,10 +0,0 @@
-# br-branches-default-octopus
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-branches-one b/t/t5515/fetch.br-branches-one
deleted file mode 100644
index 12ac8d2..0000000
--- a/t/t5515/fetch.br-branches-one
+++ /dev/null
@@ -1,8 +0,0 @@
-# br-branches-one
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-branches-one-merge b/t/t5515/fetch.br-branches-one-merge
deleted file mode 100644
index b4b3b35..0000000
--- a/t/t5515/fetch.br-branches-one-merge
+++ /dev/null
@@ -1,9 +0,0 @@
-# br-branches-one-merge
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-branches-one-octopus b/t/t5515/fetch.br-branches-one-octopus
deleted file mode 100644
index 96e3029..0000000
--- a/t/t5515/fetch.br-branches-one-octopus
+++ /dev/null
@@ -1,9 +0,0 @@
-# br-branches-one-octopus
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-explicit b/t/t5515/fetch.br-config-explicit
deleted file mode 100644
index e2fa9c8..0000000
--- a/t/t5515/fetch.br-config-explicit
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-explicit
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f		branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-explicit-merge b/t/t5515/fetch.br-config-explicit-merge
deleted file mode 100644
index ec1a723..0000000
--- a/t/t5515/fetch.br-config-explicit-merge
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-explicit-merge
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-explicit-octopus b/t/t5515/fetch.br-config-explicit-octopus
deleted file mode 100644
index 7011dfc..0000000
--- a/t/t5515/fetch.br-config-explicit-octopus
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-explicit-octopus
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-glob b/t/t5515/fetch.br-config-glob
deleted file mode 100644
index e75ec2f..0000000
--- a/t/t5515/fetch.br-config-glob
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-glob
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-glob-merge b/t/t5515/fetch.br-config-glob-merge
deleted file mode 100644
index ce8f739..0000000
--- a/t/t5515/fetch.br-config-glob-merge
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-glob-merge
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-config-glob-octopus b/t/t5515/fetch.br-config-glob-octopus
deleted file mode 100644
index 938e532..0000000
--- a/t/t5515/fetch.br-config-glob-octopus
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-config-glob-octopus
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-explicit b/t/t5515/fetch.br-remote-explicit
deleted file mode 100644
index 83534d2..0000000
--- a/t/t5515/fetch.br-remote-explicit
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-explicit
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f		branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-explicit-merge b/t/t5515/fetch.br-remote-explicit-merge
deleted file mode 100644
index a9064dd..0000000
--- a/t/t5515/fetch.br-remote-explicit-merge
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-explicit-merge
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-explicit-octopus b/t/t5515/fetch.br-remote-explicit-octopus
deleted file mode 100644
index ecf020d..0000000
--- a/t/t5515/fetch.br-remote-explicit-octopus
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-explicit-octopus
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-glob b/t/t5515/fetch.br-remote-glob
deleted file mode 100644
index 94e6ad3..0000000
--- a/t/t5515/fetch.br-remote-glob
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-glob
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-glob-merge b/t/t5515/fetch.br-remote-glob-merge
deleted file mode 100644
index 09362e2..0000000
--- a/t/t5515/fetch.br-remote-glob-merge
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-glob-merge
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b		branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-remote-glob-octopus b/t/t5515/fetch.br-remote-glob-octopus
deleted file mode 100644
index b08e046..0000000
--- a/t/t5515/fetch.br-remote-glob-octopus
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-remote-glob-octopus
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689		branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8		branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.br-unconfig b/t/t5515/fetch.br-unconfig
deleted file mode 100644
index 65ce6d9..0000000
--- a/t/t5515/fetch.br-unconfig
+++ /dev/null
@@ -1,11 +0,0 @@
-# br-unconfig
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/fetch.master b/t/t5515/fetch.master
deleted file mode 100644
index 950fd07..0000000
--- a/t/t5515/fetch.master
+++ /dev/null
@@ -1,11 +0,0 @@
-# master
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	branch 'master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	branch 'one' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	branch 'three' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	branch 'two' of ../
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f	not-for-merge	tag 'tag-master' of ../
-8e32a6d901327a23ef831511badce7bf3bf46689	not-for-merge	tag 'tag-one' of ../
-22feea448b023a2d864ef94b013735af34d238ba	not-for-merge	tag 'tag-one-tree' of ../
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b	not-for-merge	tag 'tag-three' of ../
-0e3b14047d3ee365f4f2a1b673db059c3972589c	not-for-merge	tag 'tag-three-file' of ../
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8	not-for-merge	tag 'tag-two' of ../
diff --git a/t/t5515/refs.br-branches-default b/t/t5515/refs.br-branches-default
deleted file mode 100644
index 21917c1..0000000
--- a/t/t5515/refs.br-branches-default
+++ /dev/null
@@ -1,12 +0,0 @@
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-branches-default-merge b/t/t5515/refs.br-branches-default-merge
deleted file mode 100644
index 21917c1..0000000
--- a/t/t5515/refs.br-branches-default-merge
+++ /dev/null
@@ -1,12 +0,0 @@
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-branches-default-octopus b/t/t5515/refs.br-branches-default-octopus
deleted file mode 100644
index 21917c1..0000000
--- a/t/t5515/refs.br-branches-default-octopus
+++ /dev/null
@@ -1,12 +0,0 @@
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-branches-one b/t/t5515/refs.br-branches-one
deleted file mode 100644
index 8a705a5..0000000
--- a/t/t5515/refs.br-branches-one
+++ /dev/null
@@ -1,12 +0,0 @@
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-branches-one-merge b/t/t5515/refs.br-branches-one-merge
deleted file mode 100644
index 8a705a5..0000000
--- a/t/t5515/refs.br-branches-one-merge
+++ /dev/null
@@ -1,12 +0,0 @@
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-branches-one-octopus b/t/t5515/refs.br-branches-one-octopus
deleted file mode 100644
index 8a705a5..0000000
--- a/t/t5515/refs.br-branches-one-octopus
+++ /dev/null
@@ -1,12 +0,0 @@
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-explicit b/t/t5515/refs.br-config-explicit
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-explicit
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-explicit-merge b/t/t5515/refs.br-config-explicit-merge
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-explicit-merge
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-explicit-octopus b/t/t5515/refs.br-config-explicit-octopus
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-explicit-octopus
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-glob b/t/t5515/refs.br-config-glob
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-glob
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-glob-merge b/t/t5515/refs.br-config-glob-merge
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-glob-merge
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-config-glob-octopus b/t/t5515/refs.br-config-glob-octopus
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-config-glob-octopus
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-explicit b/t/t5515/refs.br-remote-explicit
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-explicit
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-explicit-merge b/t/t5515/refs.br-remote-explicit-merge
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-explicit-merge
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-explicit-octopus b/t/t5515/refs.br-remote-explicit-octopus
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-explicit-octopus
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-glob b/t/t5515/refs.br-remote-glob
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-glob
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-glob-merge b/t/t5515/refs.br-remote-glob-merge
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-glob-merge
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-remote-glob-octopus b/t/t5515/refs.br-remote-glob-octopus
deleted file mode 100644
index 9bbbfd9..0000000
--- a/t/t5515/refs.br-remote-glob-octopus
+++ /dev/null
@@ -1,15 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.br-unconfig b/t/t5515/refs.br-unconfig
deleted file mode 100644
index 13e4ad2..0000000
--- a/t/t5515/refs.br-unconfig
+++ /dev/null
@@ -1,11 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
diff --git a/t/t5515/refs.master b/t/t5515/refs.master
deleted file mode 100644
index 13e4ad2..0000000
--- a/t/t5515/refs.master
+++ /dev/null
@@ -1,11 +0,0 @@
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD
-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one
-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three
-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two
-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master
-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one
-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree
-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three
-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file
-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two
-- 
1.5.5

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Mon, Apr 28, 2008 17:32:18 +0200:
> This patch parallels what a previous patch did to "git push".
> It makes "git fetch" with no repository argument similar to
> "git remote update" with no default group set.  Of course,
> "git fetch" with no arguments honors skipDefaultUpdate too.

You may consider to update "git remote add" to make all new remotes
.skipDefaultUpdate. And otherwise, I promise to hate your patch
everytime when I mindlessly type "git fetch" in, for instance, my v4l2
repo (which is a pretty collection of all kinds of remotes). All of
sudden it starts updating them and losing old references. And that
without me even touching configuration.

Please, consider making this behaviour non-default. Just because the
all current repos suddenly start updating itself where they didn't
before. Same goes for you "git push" patch.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

> my v4l2
> repo (which is a pretty collection of all kinds of remotes)

I can add a global boolean configuration to change the default value of 
skipDefaultRemote.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>> my v4l2
>> repo (which is a pretty collection of all kinds of remotes)
>
> I can add a global boolean configuration to change the default value of  
> skipDefaultRemote.
>

With the default NOT so that current behaviour stays?
And "git remote add" update?

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

Alex Riesen wrote:
> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>>> my v4l2
>>> repo (which is a pretty collection of all kinds of remotes)
>> I can add a global boolean configuration to change the default value of  
>> skipDefaultRemote.
>>
> 
> With the default NOT so that current behaviour stays?

No, absolutely.  In fact if I were you I would set skipDefaultUpdate 
*now* on the remotes of that repo.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
> Alex Riesen wrote:
>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>>>> my v4l2
>>>> repo (which is a pretty collection of all kinds of remotes)
>>> I can add a global boolean configuration to change the default value 
>>> of  skipDefaultRemote.
>>>
>>
>> With the default NOT so that current behaviour stays?
>
> No, absolutely.  In fact if I were you I would set skipDefaultUpdate  
> *now* on the remotes of that repo.

And all the others, who don't read this discussion, are just expected
to adapt?

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Andreas Ericsson]

Alex Riesen wrote:
> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
>> Alex Riesen wrote:
>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>>>>> my v4l2
>>>>> repo (which is a pretty collection of all kinds of remotes)
>>>> I can add a global boolean configuration to change the default value 
>>>> of  skipDefaultRemote.
>>>>
>>> With the default NOT so that current behaviour stays?
>> No, absolutely.  In fact if I were you I would set skipDefaultUpdate  
>> *now* on the remotes of that repo.
> 
> And all the others, who don't read this discussion, are just expected
> to adapt?
> 

One for Alex's side here. I have several remotes in many of the repos
I'm using. Some of them point to my colleagues laptops, where temporary
git-daemons sometimes serve content, and sometimes it doesn't.

For me no refs would be updated, but they would generate errors which
would make real errors harder to see.

If you're gonna change the default of something, make really sure it
doesn't ever destroy anything for anybody. Otherwise, make it configurable
and off by default.

How about renaming "skipDefaultUpdate" to "fetch.fetchAllRemotes" and
let it default to false?

Although when I come to think about it, you'd probably want to mark
some remotes for auto-fetching while keeping others on "manual" fetch.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

Alex Riesen wrote:
> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
>> Alex Riesen wrote:
>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>>>>> my v4l2
>>>>> repo (which is a pretty collection of all kinds of remotes)
>>>> I can add a global boolean configuration to change the default value 
>>>> of  skipDefaultRemote.
>>>>
>>> With the default NOT so that current behaviour stays?
>> No, absolutely.  In fact if I were you I would set skipDefaultUpdate  
>> *now* on the remotes of that repo.
> 
> And all the others, who don't read this discussion, are just expected
> to adapt?

Man, that's what release notes are for.  You are expected to read those.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

> Some of them point to my colleagues laptops, where temporary
> git-daemons sometimes serve content, and sometimes it doesn't.

Again, you should probably have skipDefaultUpdate set on those remotes 
even now!  A patch that makes a "wrong" (or incomplete) configuration 
more apparent, is not necessarily wrong in itself.  (I was sort of 
expecting these objections -- the patches are designed to make the 
common use cases easier, and of course on this list you will find 
experts with less common scenarios).

In case it was not clear: it's not like the fetch command will *always* 
update all repositories.  Only the zero-argument variation will.

> How about renaming "skipDefaultUpdate" to "fetch.fetchAllRemotes" and
> let it default to false?

Renaming can be done (as a followup preferably, the patch series touches 
enough places like this).  But not setting the default, as that would 
destroy the "base case" where "git fetch" just fetches from origin.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Andreas Ericsson]

Paolo Bonzini wrote:
> Alex Riesen wrote:
>> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
>>> Alex Riesen wrote:
>>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
>>>>>> my v4l2
>>>>>> repo (which is a pretty collection of all kinds of remotes)
>>>>> I can add a global boolean configuration to change the default 
>>>>> value of  skipDefaultRemote.
>>>>>
>>>> With the default NOT so that current behaviour stays?
>>> No, absolutely.  In fact if I were you I would set skipDefaultUpdate  
>>> *now* on the remotes of that repo.
>>
>> And all the others, who don't read this discussion, are just expected
>> to adapt?
> 
> Man, that's what release notes are for.  You are expected to read those.
> 

So you actually read the release-notes for every application you have
installed? Remind me to never employ you. I doubt you'd ever get any
work done.

Failing that, would you get slightly annoyed, or perhaps even quite
vexed if you find out that insert-program-used-to-do-some-work-with-here
did omething stupid that made you lose some of your work?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

>> Man, that's what release notes are for.  You are expected to read those.
> 
> So you actually read the release-notes for every application you have
> installed?

Not for every one, but I do for some applications.  Right now only git 
and autoconf come to mind.  Especially searching for the magic words 
"backwards incompatible" -- the more "power user" you are of an 
application, the more you should read the release notes.  And in the 
case of git I don't consider myself a power user but I learnt quite a 
few tricks from the release notes.

> Remind me to never employ you. I doubt you'd ever get any
> work done.

Well, the same should apply to reading mailing lists...

> Failing that, would you get slightly annoyed, or perhaps even quite
> vexed if you find out that insert-program-used-to-do-some-work-with-here
> did omething stupid that made you lose some of your work?

Sorry, how does the patch make you lose some of your work (as opposed to 
some of your time, which is possible as is the case for every backwards 
incompatible change)?

1) what about the reflog?

2) the patch does not touch refs/heads/* unless you are tweaking your 
configuration (and quite heavily so).  IMHO that's using enough rope 
that you really ought to know about the reflog and... look for backwards 
incompatible changes in the release notes!

3) your complaint was that it gave errors.  Alex did talk about losing 
his work, but questions 1 and 2 would apply to him too.

4) one man's stupidity is another man's... [fill in]  In particular, did 
you understand the rationale for this change?  Do you have any 
alternative ideas?

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Andreas Ericsson]

Paolo Bonzini wrote:
> 
>>> Man, that's what release notes are for.  You are expected to read those.
>>
>> So you actually read the release-notes for every application you have
>> installed?
> 
> Not for every one, but I do for some applications.  Right now only git 
> and autoconf come to mind.  Especially searching for the magic words 
> "backwards incompatible" -- the more "power user" you are of an 
> application, the more you should read the release notes.  And in the 
> case of git I don't consider myself a power user but I learnt quite a 
> few tricks from the release notes.
> 
>> Remind me to never employ you. I doubt you'd ever get any
>> work done.
> 
> Well, the same should apply to reading mailing lists...
> 
>> Failing that, would you get slightly annoyed, or perhaps even quite
>> vexed if you find out that insert-program-used-to-do-some-work-with-here
>> did omething stupid that made you lose some of your work?
> 
> Sorry, how does the patch make you lose some of your work (as opposed to 
> some of your time, which is possible as is the case for every backwards 
> incompatible change)?
> 

Because I will lose some of the refs and then have to dig them up in the
reflog.

> 1) what about the reflog?
> 

I'm not comfortable with the reflog. I appreciate its usefulness, but I'm
thoroughly unhappy when I'm forced to use it.

> 2) the patch does not touch refs/heads/* unless you are tweaking your 
> configuration (and quite heavily so).  IMHO that's using enough rope 
> that you really ought to know about the reflog and... look for backwards 
> incompatible changes in the release notes!
> 

No, but it does touch refs/remotes/*/heads

> 3) your complaint was that it gave errors.  Alex did talk about losing 
> his work, but questions 1 and 2 would apply to him too.
> 
> 4) one man's stupidity is another man's... [fill in]  In particular, did 
> you understand the rationale for this change?  Do you have any 
> alternative ideas?
> 

Yes, I understand the rationale, and I do have an alternative idea, which
is to make it configurable. Now that I think about it, it's probably useful
to have it togglable via command-line switch as well. Something along the
lines of "git fetch --all-remotes", perhaps. I'm not against the idea as
such. I'm against making it the default.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

>> Sorry, how does the patch make you lose some of your work (as opposed 
>> to some of your time, which is possible as is the case for every 
>> backwards incompatible change)?
> 
> Because I will lose some of the refs and then have to dig them up in the
> reflog.
> 
> I'm not comfortable with the reflog. I appreciate its usefulness, but I'm
> thoroughly unhappy when I'm forced to use it.

So am I, but still it would lose time (to dig refs up in the reflog), 
not work (e.g. having to rewrite code).  I think we're in agreement on 
this part.

> Yes, I understand the rationale, and I do have an alternative idea, which
> is to make it configurable.

Then sorry, but I think you don't understand the rationale.  The cover 
letter has excerpts from other git hackers' e-mails that explain it 
better than I can.  But shortly speaking, the point of the patch is to 
remove the "magic" operation of "git fetch" as "git fetch origin". 
Removing is quite the opposite of "add a configuration option that 
disables it, but leave the old behavior as default".

> Now that I think about it, it's probably useful to have it
> togglable via command-line switch as well. Something along the
> lines of "git fetch --all-remotes", perhaps.

Making it accessible via a command-line switch is pointless, as we 
already have "git remote update" for that.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Johannes Schindelin]

Hi,

On Tue, 29 Apr 2008, Paolo Bonzini wrote:

> > Some of them point to my colleagues laptops, where temporary
> > git-daemons sometimes serve content, and sometimes it doesn't.
> 
> Again, you should probably have skipDefaultUpdate set on those remotes even
> now!

Umm, why?

>  A patch that makes a "wrong" (or incomplete) configuration more
> apparent, is not necessarily wrong in itself.

Your suggested changes are actively _making_ them wrong.  They are not 
wrong now.

Happily, I am quite certain that Junio will not allow such dramatic 
changes into Git, at least not without a long, long time of warning, 
during which I can safely undo the changes in my personal branch.

Because I do like to call "git remote update" from time to time, and I 
absolutely hate the idea of "origin" _not_ being special.

Ciao,
Dscho

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

>>> Some of them point to my colleagues laptops, where temporary
>>> git-daemons sometimes serve content, and sometimes it doesn't.
>> Again, you should probably have skipDefaultUpdate set on those remotes even
>> now!
> 
> Umm, why?

Because I don't want to make sure my colleagues *all* have their laptops 
turned on when I run "git remote update" (on the default group).  Those 
remotes should be fetched individually as the need arises, or maybe with 
a special group, but not by default.

>> A patch that makes a "wrong" (or incomplete) configuration more
>> apparent, is not necessarily wrong in itself.
> 
> Your suggested changes are actively _making_ them wrong.  They are not 
> wrong now.

Sure, you can consider a configuration that affects "git remote update" 
to be correct if you're not using "git remote update" at all.  But a 
wrong you never saw/experienced is not a right.  My changes are actively 
making the wrongness apply more broadly, that's clear.

> Happily, I am quite certain that Junio will not allow such dramatic 
> changes into Git, at least not without a long, long time of warning, 
> during which I can safely undo the changes in my personal branch.

I wouldn't be surprised if it didn't go in 1.5.6 -- indeed.

Actually I think the "git pull" changes (patches 5 and 6) and the 
matching refs refspec (patches 1 and 2) can go in sooner, but I sort of 
expect the other 3 patches to lie in limbo for a longer time.

> I absolutely hate the idea of "origin" _not_ being special.

Well, Junio and Shawn convinced me of the contrary, so I guess they 
disagree with you on this one...

Paolo

Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Jeff King]

On Mon, Apr 28, 2008 at 05:23:53PM +0200, Paolo Bonzini wrote:

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

I like patches 1 and 2. The principle of "remove defaults from code, and
put them into the automatically generated config file" makes sense to
me. It gives users an easy place to look to understand and change such
behavior. So even without the rest of the patches, I think this is an
improvement.

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

This feels a little wrong, since we treat push and fetch lines
differently. That is, I can add just a fetch ("git remote add"), or both
("git remote add --push"), but not just a push. It seems like the
concepts should be orthogonal to "git remote" (as they are in the config
file).

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

I think you understand the compatibility issues, but I think it needs to
be not "warned in the release notes" but "warned in the release notes,
followed by a period of adjustment, and then the change". And maybe it
would even make sense to wait for a larger-number version change (like
1.6.0).

> 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".

I agree that patch 5 is a reasonable cleanup, regardless.

I'm not sure about patch 6. What are the cases that can trigger this? I
assume people still with ancient .git/remotes files? Are those actually
deprecated?

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

Again, I like this behavior just fine, but it probably needs a warning
period and a major version bump.

> "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.

This was from me, and I do like this behavior better.

-Peff

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 08:50:15 +0200:
>>>>> I can add a global boolean configuration to change the default
>>>>> value of  skipDefaultRemote.
>>>>>
>>>> With the default NOT so that current behaviour stays?
>>> No, absolutely.  In fact if I were you I would set
>>> skipDefaultUpdate  *now* on the remotes of that repo.
>>
>> And all the others, who don't read this discussion, are just
>> expected to adapt?
>
> Man, that's what release notes are for.  You are expected to read those.
>

So, a sysadm of a big development site reads them... and faces a big
update in all the hundreds of repos (which exists since git-1.4 and
were good all this time, BTW). Besides, he faces a need to explain the
need for this behavioural change in a really core tool.  And, being
not really convinced himself that it was needed (I, for one, am not
convinced), he finds it real hard.

No, I don't have hundreds of repos. Just around 30. And I am (mostly)
alone working with them. I still don't like the idea of updating them.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 18:40:24 +0200:
>> Happily, I am quite certain that Junio will not allow such dramatic  
>> changes into Git, at least not without a long, long time of warning,  
>> during which I can safely undo the changes in my personal branch.
>
> I wouldn't be surprised if it didn't go in 1.5.6 -- indeed.
>

I hope it wont go in till 1.6 (like in many months). And long before
there will be a change in "git remote add" which sets
skipDefaultUpdate to true. And there will be a change in "git fetch"
which will warn the user in legacy repositories which have no
skipDefaultUpdate at all.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:
>> Failing that, would you get slightly annoyed, or perhaps even quite
>> vexed if you find out that insert-program-used-to-do-some-work-with-here
>> did omething stupid that made you lose some of your work?
>
> Sorry, how does the patch make you lose some of your work (as opposed to  
> some of your time, which is possible as is the case for every backwards  
> incompatible change)?
>
> 1) what about the reflog?

It could not be enabled in repos before May 2006 (as the feature did
not exist back than).

> 2) the patch does not touch refs/heads/* unless you are tweaking your  
> configuration (and quite heavily so).  IMHO that's using enough rope  
> that you really ought to know about the reflog and... look for backwards  
> incompatible changes in the release notes!

Since when do you depend on people reading release notes and
immediately and correctly changing their behaviour?

> 3) your complaint was that it gave errors.  Alex did talk about losing  
> his work, but questions 1 and 2 would apply to him too.

Yes. And I can loose my work if "git fetch" (which I type without
thinking) will now update some remote I didn't mean it to.
Remote references can be shared - updated from different sites (think
mirros like kernel.org and repo.or.cz). Setups like this are used
elsewhere too (I use them).

> 4) one man's stupidity is another man's... [fill in]  In particular, did  
> you understand the rationale for this change?  Do you have any  
> alternative ideas?

Do you have a convincing one by now? And an acceptable transition plan?
("Read RelNotes!", yes, you mentioned. Another one?)

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[しらいしななこ]

Quoting Paolo Bonzini <bonzini@gnu.org>:

>>> Sorry, how does the patch make you lose some of your work (as
>>> opposed to some of your time, which is possible as is the case for
>>> every backwards incompatible change)?
>>
>> Because I will lose some of the refs and then have to dig them up in the
>> reflog.
>>
>> I'm not comfortable with the reflog. I appreciate its usefulness, but I'm
>> thoroughly unhappy when I'm forced to use it.
>
> So am I, but still it would lose time (to dig refs up in the reflog),
> not work (e.g. having to rewrite code).  I think we're in agreement on
> this part.
>
>> Yes, I understand the rationale, and I do have an alternative idea, which
>> is to make it configurable.
>
> Then sorry, but I think you don't understand the rationale.  The cover
> letter has excerpts from other git hackers' e-mails that explain it
> better than I can.  But shortly speaking, the point of the patch is to
> remove the "magic" operation of "git fetch" as "git fetch
> origin". Removing is quite the opposite of "add a configuration option
> that disables it, but leave the old behavior as default".
>
>> Now that I think about it, it's probably useful to have it
>> togglable via command-line switch as well. Something along the
>> lines of "git fetch --all-remotes", perhaps.
>
> Making it accessible via a command-line switch is pointless, as we
> already have "git remote update" for that.
>
> Paolo

Sorry but then why does this patch have to even touch "git fetch"?  Isn't it enough to run "git remote update"?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

>> 2) the patch does not touch refs/heads/* unless you are tweaking your  
>> configuration (and quite heavily so).  IMHO that's using enough rope  
>> that you really ought to know about the reflog and... look for backwards  
>> incompatible changes in the release notes!
> 
> Since when do you depend on people reading release notes and
> immediately and correctly changing their behaviour?

I don't, that's why I never expected all patches to go in 1.5.6.

I sent them together to provide a single coherent series and an aim for 
a transition plan -- which I'd prefer to work out with the git 
community, who knows the release mechanics much better than I do.  Jeff 
King's reply to the cover letter is a start towards that; your e-mails 
are also a start towards that, even though I don't think your transition 
plan is feasible (also because it would break "git remote update" 
completely).

>> 4) one man's stupidity is another man's... [fill in]  In particular, did  
>> you understand the rationale for this change?  Do you have any  
>> alternative ideas?
> 
> Do you have a convincing one by now?

See the (long) cover letter.

> And an acceptable transition plan?
> ("Read RelNotes!", yes, you mentioned. Another one?)

See above.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

> Sorry but then why does this patch have to even touch "git fetch"?  
> Isn't it enough to run "git remote update"?

I'm tired of answering.  Please read the cover letter.  It's not about 
adding new features (it does in patches 1 to 3, but only as means to an 
end).  It's about rationalizing existing behavior so that "newbie usage 
patterns" generalize better, and patches 4 and 7 are the most important 
(and the most controversial) in this respect.

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 23:15:02 +0200:
>>> 2) the patch does not touch refs/heads/* unless you are tweaking your 
>>>  configuration (and quite heavily so).  IMHO that's using enough rope 
>>>  that you really ought to know about the reflog and... look for 
>>> backwards  incompatible changes in the release notes!
>>
>> Since when do you depend on people reading release notes and
>> immediately and correctly changing their behaviour?
>
> I don't, that's why I never expected all patches to go in 1.5.6.
>

Oh, the next minor release...

> I sent them together to provide a single coherent series and an aim for  
> a transition plan -- which I'd prefer to work out with the git  
> community, who knows the release mechanics much better than I do.  Jeff  
> King's reply to the cover letter is a start towards that; your e-mails  

Hmm... Which one do you mean? I cannot find his reply to message-id
<cover.1209391614.git.bonzini@gnu.org>

> are also a start towards that, even though I don't think your transition  
> plan is feasible (also because it would break "git remote update"  
> completely).

Which part of "warn people in git-fetch" will break "git remote update"?
Or what will break after the "git remote add" start setting
skipDefaultUpdate?

>>> 4) one man's stupidity is another man's... [fill in]  In particular, 
>>> did  you understand the rationale for this change?  Do you have any   
>>> alternative ideas?
>>
>> Do you have a convincing one by now?
>
> See the (long) cover letter.
>

It is not. It seem to propose, instead of fixing existing behaviour,
change it incompatibly. And dangerously, I believe.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Johannes Schindelin]

Hi,

On Tue, 29 Apr 2008, Alex Riesen wrote:

> Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:
>
> > 3) your complaint was that it gave errors.  Alex did talk about losing 
> >    his work, but questions 1 and 2 would apply to him too.
> 
> Yes. And I can loose my work if "git fetch" (which I type without 
> thinking) will now update some remote I didn't mean it to. Remote 
> references can be shared - updated from different sites (think mirros 
> like kernel.org and repo.or.cz). Setups like this are used elsewhere too 
> (I use them).

Like I said, I think this change affects too many existing users in a very 
negative way.

But then, I respect Junio's very careful way of dealing with such issues, 
and am not really doubting that it will take a long, long time to change 
the default behaviour of Git, if at all.  Which is a good thing.

And I am certain that Paolo does not believe his release notes argument 
either.  Not seriously, anyway.

Ciao,
Dscho

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

>> I sent them together to provide a single coherent series and an aim for  
>> a transition plan -- which I'd prefer to work out with the git  
>> community, who knows the release mechanics much better than I do.  Jeff  
>> King's reply to the cover letter is a start towards that; your e-mails  
> 
> Hmm... Which one do you mean? I cannot find his reply to message-id
> <cover.1209391614.git.bonzini@gnu.org>

http://permalink.gmane.org/gmane.comp.version-control.git/80720

>> are also a start towards that, even though I don't think your transition  
>> plan is feasible (also because it would break "git remote update"  
>> completely).
> 
> Which part of "warn people in git-fetch" will break "git remote update"?
> Or what will break after the "git remote add" start setting
> skipDefaultUpdate?

People will expect the new remotes to be, ehm, updated by "git remote 
update".

> It is not. It seem to propose, instead of fixing existing behaviour,

Do you know how to "fix" existing behavior?

I mean, I just wonder why as long as I had one remote only, I could 
write "git push", while now I have to write "git push origin && git push 
mirror".  The patch to "git fetch" comes from this observation too, and 
I think it is a good idea, even though I'm less attached to it and it 
would influence my workflow much less.

Paolo

Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Alex Riesen]

Jeff King, Tue, Apr 29, 2008 21:35:36 +0200:
> On Mon, Apr 28, 2008 at 05:23:53PM +0200, Paolo Bonzini wrote:
> > 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.
> 
> I think you understand the compatibility issues, but I think it needs to
> be not "warned in the release notes" but "warned in the release notes,
> followed by a period of adjustment, and then the change". And maybe it
> would even make sense to wait for a larger-number version change (like
> 1.6.0).

But please, make this "period of adjustment" actually visible to the
USER WHO DOES NOT READ RELEASE NOTES. Say loud and clear when you do
something different. And better yet - do not do anything unexpected
just yet. Describe it, print instructions about changing
configuration. So that next less-minor-release with changed behavior
(but the warning still in place) is less of a surprise.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Alex Riesen]

Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200:
>> Hmm... Which one do you mean? I cannot find his reply to message-id
>> <cover.1209391614.git.bonzini@gnu.org>
>
> http://permalink.gmane.org/gmane.comp.version-control.git/80720
>

Just received it

>>> are also a start towards that, even though I don't think your 
>>> transition  plan is feasible (also because it would break "git remote 
>>> update"  completely).
>>
>> Which part of "warn people in git-fetch" will break "git remote update"?
>> Or what will break after the "git remote add" start setting
>> skipDefaultUpdate?
>
> People will expect the new remotes to be, ehm, updated by "git remote  
> update".
>

Ah, right. How about a warning, then? Like:

    $ git remote add abc host:src/project
    warning: fetch and push without arguments WILL update the references of "abc"
    $

>> It is not. It seem to propose, instead of fixing existing behaviour,
>
> Do you know how to "fix" existing behavior?
>

Never considered it broken. OTOH, it hasn't occured to me to run "git
push" without arguments. And I do expect "git fetch" to fetch just the
remote my current branch is related to (and not all remotes).

> I mean, I just wonder why as long as I had one remote only, I could  
> write "git push", while now I have to write "git push origin && git push  
> mirror".  The patch to "git fetch" comes from this observation too, and  
> I think it is a good idea, even though I'm less attached to it and it  
> would influence my workflow much less.

Have you tested your patches in your workflow? Worked with them for
some weeks? Gave them to your peers?

Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... The principle of "remove defaults from code, and
> put them into the automatically generated config file" makes sense to
> me. It gives users an easy place to look to understand and change such
> behavior. So even without the rest of the patches, I think this is an
> improvement.

If the removal of defaults do not break expectations of users of an
existing repository, I'd agree.  Is it the case, or the lack of default
that is supposed to be there now suddenly makes the tool do unexpected
things?

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

Didn't we already have this discussion and don't we already have a way to
define a remote that you can use to push to more than one places?

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

"Knowledgeable people all _can_ work around the change" does not change
the fact that you are forcing existing users unnecessary change to their
configurations.  Why does this patch need to break existing users setups?

> ... I
> assume people still with ancient .git/remotes files? Are those actually
> deprecated?

No.

Neither .git/branches.  When you interact with hundreds of remote
repositories, one interesting branch per each, like akpm does, the format
of one-file-per-remote is far easier and simpler to work with.

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Johannes Schindelin]

Hi,

On Tue, 29 Apr 2008, Paolo Bonzini wrote:

> > Sorry but then why does this patch have to even touch "git fetch"?  
> > Isn't it enough to run "git remote update"?
> 
> I'm tired of answering.  Please read the cover letter.

Actually, this is unfair.  You did not answer it to my satisfaction, but I 
thought that maybe it is just me.

Alas, apparently it is not just me.  I think that "git fetch" is something 
more concise than "git remote update", and that it is a good thing.

Ciao,
Dscho

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Johannes Schindelin]

Hi,

On Tue, 29 Apr 2008, Paolo Bonzini wrote:

> I mean, I just wonder why as long as I had one remote only, I could 
> write "git push", while now I have to write "git push origin && git push 
> mirror".  The patch to "git fetch" comes from this observation too, and 
> I think it is a good idea, even though I'm less attached to it and it 
> would influence my workflow much less.

I wonder why you need to make such a big change, which _is_ incompatible, 
and not do the obvious thing, namely introduce a subcommand to "git 
remote" which does the "push" equivalent of "git remote update"...

Do you really think that it is a good idea to push down a huge change like 
this down everybody else's throat, just because you do not want to type 
"git remote ..." but "git fetch ..." in your workflow?

Ciao,
Dscho

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Jeff King]

On Tue, Apr 29, 2008 at 11:26:46PM +0100, Johannes Schindelin wrote:

> I wonder why you need to make such a big change, which _is_ incompatible, 
> and not do the obvious thing, namely introduce a subcommand to "git 
> remote" which does the "push" equivalent of "git remote update"...
> 
> Do you really think that it is a good idea to push down a huge change like 
> this down everybody else's throat, just because you do not want to type 
> "git remote ..." but "git fetch ..." in your workflow?

I wonder this a bit, too, and I am even somebody who _likes_ the new
behavior. But there is a difference between "should have been designed
this way in the first place" and "is currently designed some other way,
and will cause pain to switch it to this way."

So it might simply not be worth the trouble to change. OTOH, I think
this is how we end up with many commands to do slightly different
things, which can end up confusing new users. I'm not sure what the
right answer is.

-Peff

Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Jeff King]

On Tue, Apr 29, 2008 at 02:56:24PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > ... The principle of "remove defaults from code, and
> > put them into the automatically generated config file" makes sense to
> > me. It gives users an easy place to look to understand and change such
> > behavior. So even without the rest of the patches, I think this is an
> > improvement.
> 
> If the removal of defaults do not break expectations of users of an
> existing repository, I'd agree.  Is it the case, or the lack of default
> that is supposed to be there now suddenly makes the tool do unexpected
> things?

I think in the case of patches 1 and 2 (but without the later patches)
it becomes redundant. And of course, Paolo's idea is that it opens us up
to changing the default later, in which case it will cease to be
redundant. But I think even in the meantime that it gives the user
a clue when looking in the config file about what can be tweaked.

> > ... I
> > assume people still with ancient .git/remotes files? Are those actually
> > deprecated?
> 
> No.
> 
> Neither .git/branches.  When you interact with hundreds of remote
> repositories, one interesting branch per each, like akpm does, the format
> of one-file-per-remote is far easier and simpler to work with.

Then in that case, I think the warning is definitely bogus.

-Peff

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I wonder this a bit, too, and I am even somebody who _likes_ the new
> behavior. But there is a difference between "should have been designed
> this way in the first place" and "is currently designed some other way,
> and will cause pain to switch it to this way."
>
> So it might simply not be worth the trouble to change. OTOH, I think
> this is how we end up with many commands to do slightly different
> things, which can end up confusing new users. I'm not sure what the
> right answer is.

Well, the thing is, push and fetch are different, so expecting the same
behaviour and syntax from them is a lost cause to begin with.  Even if we
were designing fetch and push right now, I do not necessarily think the
series shows a way that "should have been designed in the first place".

Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

[Paolo Bonzini]

>>> ... The principle of "remove defaults from code, and
>>> put them into the automatically generated config file" makes sense to
>>> me. It gives users an easy place to look to understand and change such
>>> behavior. So even without the rest of the patches, I think this is an
>>> improvement.
>> If the removal of defaults do not break expectations of users of an
>> existing repository, I'd agree.  Is it the case, or the lack of default
>> that is supposed to be there now suddenly makes the tool do unexpected
>> things?
> 
> I think in the case of patches 1 and 2 (but without the later patches)
> it becomes redundant. And of course, Paolo's idea is that it opens us up
> to changing the default later, in which case it will cease to be
> redundant. But I think even in the meantime that it gives the user
> a clue when looking in the config file about what can be tweaked.

Agreed.  Patches 1 and 2 can definitely go in earlier and can help in 
the transition (see later).

> Didn't we already have this discussion and don't we already have a way to
> define a remote that you can use to push to more than one places?

No, because you may want to push to some places, and mirror to others. 
Unfortunately, mirroring is not handled entirely within match_refs but 
is also special-cased in builtin-send-pack.c.  So you cannot handle it 
with a magic refspec (like --force), and you are forced to use a 
separate remote, independent of remote.*.mirror.

>>> ... I
>>> assume people still with ancient .git/remotes files? Are those actually
>>> deprecated?
>>
>> Neither .git/branches.  When you interact with hundreds of remote
>> repositories, one interesting branch per each, like akpm does, the format
>> of one-file-per-remote is far easier and simpler to work with.
> 
> Then in that case, I think the warning is definitely bogus.

When you use .git/remotes and .git/branches, do you actually use them 
with the zero-argument versions of "git pull" (and "git fetch")?  I'm 
not sure about that, actually I very much doubt so.

So here is my plan.

1) Merge patches 1 and 2 now.

2) Add a warning to "git push" if it pushes to something without a push 
refspec.  Merge patch 3, the doc can say that --push suppresses this 
warning.  Make sure the warning suggests how to silence it.

3) Merge patch 5 as it is just a cleanup.

4) Merge patch 6.

5) Add a similar warning to "git fetch".

6) Add a warning when "git push" is used with zero-arguments and there 
is more than one remote with a push refspec.  Something like, "git push 
will only push to ***.  This may not be what you want, and it may change 
in future versions of git".

7) If there is a revolt against the warning in (5), revert it and add a 
warning whenever the "magic origin" behavior is triggered by "git push".


For 1.6.0, the remaining changes would be harder to warn about 
preventively, so this part can be refined:

8) In "git pull", turn the warning into an error.

9) Ditto for "git fetch".

10) Ditto for "git push" if we had to go for (7).  If we didn't, merge 
patch 4 for 1.6.0.  Put a prominent note in the release notes that "git 
push" will push to all remotes with a push refspec.  By now, users will 
have added push refspecs appropriately thanks to the warning in step 2 
above; so at least "git push" will not stop pushing to origin.


In the meanwhile, decide what is the best thing to do for patch 7.  If 
we decide it is to go in, steps 5 and 9 will have to be replaced with 
something else (I don't know what).

Paolo

Re: [PATCH 7/7] make "git fetch" update all fetch repositories

[Paolo Bonzini]

> Do you really think that it is a good idea to push down a huge change like 
> this down everybody else's throat, just because you do not want to type 
> "git remote ..." but "git fetch ..." in your workflow?

It's not that I don't want.  I couldn't care less, but I just don't see 
why I should have learnt it in the first place.

>> I wonder this a bit, too, and I am even somebody who _likes_ the new
>> behavior. But there is a difference between "should have been designed
>> this way in the first place" and "is currently designed some other way,
>> and will cause pain to switch it to this way."

Agreed.

>> So it might simply not be worth the trouble to change. OTOH, I think
>> this is how we end up with many commands to do slightly different
>> things, which can end up confusing new users. I'm not sure what the
>> right answer is.
> 
> Well, the thing is, push and fetch are different, so expecting the same
> behaviour and syntax from them is a lost cause to begin with.  Even if we
> were designing fetch and push right now, I do not necessarily think the
> series shows a way that "should have been designed in the first place".

To me, "push and pull" are different obviously (because pull modifies 
two refs, the remote one and the local one).  But "push and fetch" are 
not so different, so I do expect lots of different options but the gist 
of the command-line syntax to be the same.

There are definitely uncontroversial changes in the series, we can start 
from there.

Paolo

Re: [PATCH 1/7] add special "matching refs" refspec

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> @@ -937,13 +945,23 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
>  						 const struct ref *src)
>  {
>  	int i;
> +	int matching_refs = -1;
>  	for (i = 0; i < rs_nr; i++) {
> +		if (rs[i].matching &&
> +		    (matching_refs == -1 || rs[i].force)) {
> +			matching_refs = i;
> +			continue;
> +		}
> +
>  		if (rs[i].pattern &&
>  		    !prefixcmp(src->name, rs[i].src) &&
>  		    src->name[strlen(rs[i].src)] == '/')
>  			return rs + i;
>  	}
> -	return NULL;
> +	if (matching_refs != -1)
> +		return rs + matching_refs;
> +	else
> +		return NULL;
>  }

It is probably better to document that you would force if you have both
"+:" and ":" for the same remote, even though I am not sure if allowing
that (instead of diagnosing it as an error) is the right thing to do.

Is it an error to have both ":" and "some:other" refspecs for the same
remote?  If so who makes the check?

Otherwise this patch seems to be very cleanly done.  Especially I like how
the updated match_refs() looks.

Re: [PATCH 1/7] add special "matching refs" refspec

[Paolo Bonzini]

>> +		if (rs[i].matching &&
>> +		    (matching_refs == -1 || rs[i].force)) {
>> +			matching_refs = i;
>> +			continue;
>> +		}
>
> It is probably better to document that you would force if you have both
> "+:" and ":" for the same remote, even though I am not sure if allowing
> that (instead of diagnosing it as an error) is the right thing to do.

I screwed up here.  I was sure that something like

         push = refs/heads/*:refs/heads/*
         push = +refs/heads/*:refs/heads/*

would also force, instead the first one wins.  I'm ok with just removing 
the "|| rs[i].force" part.

> Is it an error to have both ":" and "some:other" refspecs for the same
> remote?  If so who makes the check?

No, it is not an error.  For example, it allows to have a

	push = refs/tags/*:refs/tags/*
	push = :

refspec, which pushes all tags but only pushes branches if there is a 
matching ref on the other side.  I don't have a use for this, but it 
made sense to support the general case.

> Otherwise this patch seems to be very cleanly done.  Especially I like how
> the updated match_refs() looks.

Thanks.  Should I resubmit?

Paolo

Re: [PATCH 2/7] add push line in git-clone

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> This patch makes git-clone add a remote.origin.push line, using the
> new ":" special refspec.  This is useful in the following patches that
> modify the behavior of "git push"; right now, it only adds clarity.

Used together with [1/7], this change is Ok in a homogeneous environment,
but it would break people who use git of different vintage on the same
repository (think of a repository on a networked filesystem).  You clone
like this, and older git won't grok the push configuration anymore.

It may look a very minor point, but I think it deserves mentioning.

Re: [PATCH 2/7] add push line in git-clone

[Paolo Bonzini]

> Used together with [1/7], this change is Ok in a homogeneous environment,
> but it would break people who use git of different vintage on the same
> repository (think of a repository on a networked filesystem).  You clone
> like this, and older git won't grok the push configuration anymore.
> 
> It may look a very minor point, but I think it deserves mentioning.

I think it is reasonable to require cloning with the 
least-common-denominator version in this case.  Think of what happened 
if the pack format changed.

Paolo

Re: [PATCH 2/7] add push line in git-clone

[Paolo Bonzini]

Paolo Bonzini wrote:
> 
>> Used together with [1/7], this change is Ok in a homogeneous environment,
>> but it would break people who use git of different vintage on the same
>> repository (think of a repository on a networked filesystem).  You clone
>> like this, and older git won't grok the push configuration anymore.
>>
>> It may look a very minor point, but I think it deserves mentioning.
> 
> I think it is reasonable to require cloning with the 
> least-common-denominator version in this case.  Think of what happened 
> if the pack format changed.

Any news on this (and on 1/7, which is in pu)?

Paolo

Re: [PATCH 2/7] add push line in git-clone

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> Paolo Bonzini wrote:
>>
>>> Used together with [1/7], this change is Ok in a homogeneous environment,
>>> but it would break people who use git of different vintage on the same
>>> repository (think of a repository on a networked filesystem).  You clone
>>> like this, and older git won't grok the push configuration anymore.
>>>
>>> It may look a very minor point, but I think it deserves mentioning.
>>
>> I think it is reasonable to require cloning with the
>> least-common-denominator version in this case.  Think of what
>> happened if the pack format changed.
>
> Any news on this (and on 1/7, which is in pu)?

I did not personally find that argument convincing, and I thought list
agreed with me with silence ;-).

The pack-format change is a big deal and benefit everybody.  Comparing it
with this change feels like comparing an apple and a poppy seed, doesn't
it?

Re: [PATCH 2/7] add push line in git-clone

[Paolo Bonzini]

Junio C Hamano wrote:
> Paolo Bonzini <bonzini@gnu.org> writes:
> 
>> Paolo Bonzini wrote:
>>>> Used together with [1/7], this change is Ok in a homogeneous environment,
>>>> but it would break people who use git of different vintage on the same
>>>> repository (think of a repository on a networked filesystem).  You clone
>>>> like this, and older git won't grok the push configuration anymore.
>>>>
>>>> It may look a very minor point, but I think it deserves mentioning.
>>>
>>> I think it is reasonable to require cloning with the
>>> least-common-denominator version in this case.  Think of what
>>> happened if the pack format changed.
>> Any news on this (and on 1/7, which is in pu)?
> 
> The pack-format change is a big deal and benefit everybody.  Comparing it
> with this change feels like comparing an apple and a poppy seed, doesn't
> it?

Yes, but it is the same.  Another example is when remotes started being 
created in refs/remotes/origin upon cloning.  In general, you cannot 
expect a clone to be downwards-compatible (or, you should expect a clone 
*not* to be downwards-compatible).

Paolo

Re: [PATCH 2/7] add push line in git-clone

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

>>>> I think it is reasonable to require cloning with the
>>>> least-common-denominator version in this case.  Think of what
>>>> happened if the pack format changed.
>>> Any news on this (and on 1/7, which is in pu)?
>>
>> The pack-format change is a big deal and benefit everybody.  Comparing it
>> with this change feels like comparing an apple and a poppy seed, doesn't
>> it?
>
> Yes, but it is the same.  Another example is when remotes started
> being created in refs/remotes/origin upon cloning.  In general, you
> cannot expect a clone to be downwards-compatible (or, you should
> expect a clone *not* to be downwards-compatible).

I think we are in agreement and that is all the more reason we have to be
extremely careful not to introduce incompatibility without a clear
advantage.  The commands involved with your patch work with or without the
new default entry in the config created by the clone exactly the same way,
and the versions before your patch would choke with the new default entry.

Re: [PATCH 2/7] add push line in git-clone

[Paolo Bonzini]

> I think we are in agreement and that is all the more reason we have to be
> extremely careful not to introduce incompatibility without a clear
> advantage.  The commands involved with your patch work with or without the
> new default entry in the config created by the clone exactly the same way,
> and the versions before your patch would choke with the new default entry.

Ok, this patch is (for now :-) withdrawn.  I think I'll punt and prepare 
something along the lines of "git remote push".  When I get to that, we 
can reconsider this patch too.

Paolo