threads / patch / 13265

patchmake "git push" update origin and mirrors, "git push --mirror" update mirrors

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

## tl;dr

74 messages between Apr 26, 2008 and May 14, 2008. Diffs are folded; open one to read it.

replies: 73people: 9as markdown or json

Paolo Bonzini· Apr 26, 2008, 07:31 UTC · lore

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.
Show changes to 3 files +130 −16

Documentation/git-push.txt, builtin-push.c, t/t5517-push-mirror.sh

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
Shawn O. Pearce· Apr 26, 2008, 17:01 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini <bonzini@gnu.org> wrote:
Show 16 quoted lines
> 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.
Junio C Hamano· Apr 26, 2008, 17:46 UTC · re: Shawn O. Pearce · lore

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

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

Shawn O. Pearce· Apr 27, 2008, 04:30 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> "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.
Shawn O. Pearce· Apr 27, 2008, 04:40 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> wrote:
Show 6 quoted lines
> 
> 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.
Junio C Hamano· Apr 27, 2008, 05:23 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 8 quoted lines
> 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.

Shawn O. Pearce· Apr 27, 2008, 17:34 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> "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.
Junio C Hamano· Apr 27, 2008, 20:13 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 10 quoted lines
> 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?

Paolo Bonzini· Apr 27, 2008, 20:22 UTC · re: Junio C Hamano · lore

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

> 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
Jeff King· Apr 28, 2008, 01:26 UTC · re: Paolo Bonzini · lore

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

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
Paolo Bonzini· Apr 28, 2008, 05:07 UTC · re: Jeff King · lore

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

Show 7 quoted lines
>> 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
Jeff King· Apr 28, 2008, 09:09 UTC · re: Paolo Bonzini · lore

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

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
Jeff King· Apr 28, 2008, 09:11 UTC · re: Jeff King · lore

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

On Mon, Apr 28, 2008 at 05:09:48AM -0400, Jeff King wrote:
Show 9 quoted lines
> 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
Paolo Bonzini· Apr 28, 2008, 09:19 UTC · re: Jeff King · lore

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

Show 5 quoted lines
> 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
Johannes Schindelin· Apr 28, 2008, 10:33 UTC · re: Paolo Bonzini · lore

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

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

Paolo Bonzini· Apr 28, 2008, 11:24 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin wrote:
Show 9 quoted lines
> 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
Johannes Schindelin· Apr 28, 2008, 11:57 UTC · re: Paolo Bonzini · lore

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

Hi,
On Mon, 28 Apr 2008, Paolo Bonzini wrote:
Show 14 quoted lines
> 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

Shawn O. Pearce· Apr 28, 2008, 03:32 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> "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.
Paolo Bonzini· Apr 28, 2008, 05:03 UTC · re: Shawn O. Pearce · lore

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

Show 8 quoted lines
> 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
Stephen R. van den Berg· Apr 28, 2008, 06:08 UTC · re: Shawn O. Pearce · lore

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

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.
Jeff King· Apr 28, 2008, 01:21 UTC · re: Shawn O. Pearce · lore

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

On Sun, Apr 27, 2008 at 01:34:46PM -0400, Shawn O. Pearce wrote:
Show 5 quoted lines
> 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
Paolo Bonzini· Apr 27, 2008, 07:23 UTC · re: Shawn O. Pearce · lore

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

Show 5 quoted lines
> 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.

Show 5 quoted lines
>> 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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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).
Show changes to 6 files +115 −35

Documentation/git-push.txt, builtin-send-pack.c, remote.c, remote.h, t/t5511-refspec.sh, t/t5516-fetch-push.sh

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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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(-)
Show changes to git-clone.sh +2 −0
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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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.
Show changes to 4 files +69 −16

Documentation/git-remote.txt, builtin-remote.c, t/t5505-remote.sh, t/t5517-push-mirror.sh

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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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.
Show changes to 5 files +161 −22

Documentation/git-push.txt, Documentation/git-remote.txt, builtin-push.c, t/t5400-send-pack.sh, t/t5517-push-mirror.sh

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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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(-)
Show changes to git-pull.sh +6 −3
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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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.
Show changes to 2 files +13 −4

Documentation/git-pull.txt, git-parse-remote.sh

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
Paolo Bonzini· Apr 28, 2008, 15:32 UTC · re: Paolo Bonzini · lore

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

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.
Show changes to 44 files +88 −536

Documentation/git-fetch.txt, builtin-fetch.c, t/t5510-fetch.sh, t/t5515-fetch-merge-logic.sh, t/t5515/fetch.br-branches-default, t/t5515/fetch.br-branches-default-merge, t/t5515/fetch.br-branches-default-octopus, t/t5515/fetch.br-branches-one, t/t5515/fetch.br-branches-one-merge, t/t5515/fetch.br-branches-one-octopus, t/t5515/fetch.br-config-explicit, t/t5515/fetch.br-config-explicit-merge, t/t5515/fetch.br-config-explicit-octopus, t/t5515/fetch.br-config-glob, t/t5515/fetch.br-config-glob-merge, t/t5515/fetch.br-config-glob-octopus, t/t5515/fetch.br-remote-explicit, t/t5515/fetch.br-remote-explicit-merge, t/t5515/fetch.br-remote-explicit-octopus, t/t5515/fetch.br-remote-glob, t/t5515/fetch.br-remote-glob-merge, t/t5515/fetch.br-remote-glob-octopus, t/t5515/fetch.br-unconfig, t/t5515/fetch.master, t/t5515/refs.br-branches-default, t/t5515/refs.br-branches-default-merge, t/t5515/refs.br-branches-default-octopus, t/t5515/refs.br-branches-one, t/t5515/refs.br-branches-one-merge, t/t5515/refs.br-branches-one-octopus, t/t5515/refs.br-config-explicit, t/t5515/refs.br-config-explicit-merge, t/t5515/refs.br-config-explicit-octopus, t/t5515/refs.br-config-glob, t/t5515/refs.br-config-glob-merge, t/t5515/refs.br-config-glob-octopus, t/t5515/refs.br-remote-explicit, t/t5515/refs.br-remote-explicit-merge, t/t5515/refs.br-remote-explicit-octopus, t/t5515/refs.br-remote-glob, t/t5515/refs.br-remote-glob-merge, t/t5515/refs.br-remote-glob-octopus, t/t5515/refs.br-unconfig, t/t5515/refs.master

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
Alex Riesen· Apr 28, 2008, 18:10 UTC · re: Paolo Bonzini · lore

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

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.

Paolo Bonzini· Apr 28, 2008, 18:19 UTC · re: Alex Riesen · lore

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

> 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
Alex Riesen· Apr 28, 2008, 21:33 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Show 6 quoted lines
>> 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?

Paolo Bonzini· Apr 29, 2008, 04:52 UTC · re: Alex Riesen · lore

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

Alex Riesen wrote:
Show 8 quoted lines
> 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
Alex Riesen· Apr 29, 2008, 05:38 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
Show 12 quoted lines
> 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?

Andreas Ericsson· Apr 29, 2008, 06:05 UTC · re: Alex Riesen · lore

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

Alex Riesen wrote:
Show 15 quoted lines
> 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
Paolo Bonzini· Apr 29, 2008, 06:55 UTC · re: Andreas Ericsson · lore

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

> 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
Johannes Schindelin· Apr 29, 2008, 16:13 UTC · re: Paolo Bonzini · lore

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

Hi,
On Tue, 29 Apr 2008, Paolo Bonzini wrote:
Show 5 quoted lines
> > 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

Paolo Bonzini· Apr 29, 2008, 16:40 UTC · re: Johannes Schindelin · lore

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

Show 6 quoted lines
>>> 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.

Show 5 quoted lines
>> 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
Alex Riesen· Apr 29, 2008, 20:34 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 18:40:24 +0200:
Show 6 quoted lines
>> 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.

Paolo Bonzini· Apr 29, 2008, 06:50 UTC · re: Alex Riesen · lore

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

Alex Riesen wrote:
Show 14 quoted lines
> 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
Andreas Ericsson· Apr 29, 2008, 07:16 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini wrote:
Show 18 quoted lines
> 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
Paolo Bonzini· Apr 29, 2008, 07:57 UTC · re: Andreas Ericsson · lore

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

>> 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
Andreas Ericsson· Apr 29, 2008, 08:48 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini wrote:
Show 26 quoted lines
> 
>>> 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.

Show 5 quoted lines
> 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
Show 7 quoted lines
> 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
Paolo Bonzini· Apr 29, 2008, 09:02 UTC · re: Andreas Ericsson · lore

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

Show 9 quoted lines
>> 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
しらいしななこ· Apr 29, 2008, 21:08 UTC · re: Paolo Bonzini · lore

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

Quoting Paolo Bonzini <bonzini@gnu.org>:
Show 32 quoted lines
>>> 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
Alex Riesen· Apr 29, 2008, 20:44 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:
Show 9 quoted lines
>> 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?)

Paolo Bonzini· Apr 29, 2008, 21:15 UTC · re: Alex Riesen · lore

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

Show 7 quoted lines
>> 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).

Show 5 quoted lines
>> 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
Alex Riesen· Apr 29, 2008, 21:33 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 23:15:02 +0200:
Show 10 quoted lines
>>> 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?

Show 8 quoted lines
>>> 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.

Paolo Bonzini· Apr 29, 2008, 21:41 UTC · re: Alex Riesen · lore

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

Show 7 quoted lines
>> 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
Show 7 quoted lines
>> 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
Alex Riesen· Apr 29, 2008, 21:53 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200:
Show 5 quoted lines
>> 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
Show 11 quoted lines
>>> 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).

Show 5 quoted lines
> 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?

Johannes Schindelin· Apr 29, 2008, 22:26 UTC · re: Paolo Bonzini · lore

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

Hi,
On Tue, 29 Apr 2008, Paolo Bonzini wrote:
Show 5 quoted lines
> 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

Jeff King· Apr 29, 2008, 23:02 UTC · re: Johannes Schindelin · lore

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

On Tue, Apr 29, 2008 at 11:26:46PM +0100, Johannes Schindelin wrote:
Show 7 quoted lines
> 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
Junio C Hamano· Apr 29, 2008, 23:17 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 9 quoted lines
> 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".

Paolo Bonzini· Apr 30, 2008, 05:28 UTC · re: Junio C Hamano · lore

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

> 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.
Show 9 quoted lines
>> 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
Johannes Schindelin· Apr 29, 2008, 21:39 UTC · re: Alex Riesen · lore

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

Hi,
On Tue, 29 Apr 2008, Alex Riesen wrote:
Show 10 quoted lines
> 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

Alex Riesen· Apr 29, 2008, 20:24 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini, Tue, Apr 29, 2008 08:50:15 +0200:
Show 12 quoted lines
>>>>> 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.

Junio C Hamano· May 1, 2008, 06:28 UTC · re: Paolo Bonzini · lore

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

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.
Paolo Bonzini· May 6, 2008, 08:37 UTC · re: Junio C Hamano · lore

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

Show 6 quoted lines
> 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
Paolo Bonzini· May 14, 2008, 15:20 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini wrote:
Show 11 quoted lines
> 
>> 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
Junio C Hamano· May 14, 2008, 18:16 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini <bonzini@gnu.org> writes:
Show 14 quoted lines
> 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?

Paolo Bonzini· May 14, 2008, 19:07 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 18 quoted lines
> 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
Junio C Hamano· May 14, 2008, 19:23 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini <bonzini@gnu.org> writes:
Show 13 quoted lines
>>>> 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.

Paolo Bonzini· May 14, 2008, 19:40 UTC · re: Junio C Hamano · lore

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

Show 5 quoted lines
> 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
Junio C Hamano· Apr 30, 2008, 09:23 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini <bonzini@gnu.org> writes:
Show 23 quoted lines
> @@ -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.

Paolo Bonzini· Apr 30, 2008, 09:35 UTC · re: Junio C Hamano · lore

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

Show 9 quoted lines
>> +		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
Jeff King· Apr 29, 2008, 19:35 UTC · re: Paolo Bonzini · lore

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

On Mon, Apr 28, 2008 at 05:23:53PM +0200, Paolo Bonzini wrote:
Show 7 quoted lines
> 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).

Show 12 quoted lines
> 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).

Show 6 quoted lines
> 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?

Show 6 quoted lines
> 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
Alex Riesen· Apr 29, 2008, 21:42 UTC · re: Jeff King · lore

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

Jeff King, Tue, Apr 29, 2008 21:35:36 +0200:
Show 11 quoted lines
> 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.

Junio C Hamano· Apr 29, 2008, 21:56 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> ... 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?

Show 7 quoted lines
>> 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.

Jeff King· Apr 29, 2008, 23:12 UTC · re: Junio C Hamano · lore

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

On Tue, Apr 29, 2008 at 02:56:24PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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.

Show 9 quoted lines
> > ... 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
Paolo Bonzini· Apr 30, 2008, 05:24 UTC · re: Jeff King · lore

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

Show 15 quoted lines
>>> ... 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.

Show 9 quoted lines
>>> ... 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
Paolo Bonzini· Apr 29, 2008, 21:21 UTC · lore

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

> 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
Johannes Schindelin· Apr 29, 2008, 22:21 UTC · re: Paolo Bonzini · lore

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

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

← back to recent threads