make "git push" update origin and mirrors, "git push --mirror" update mirrors
PATCH RESEND 1/1 make "git push" update origin and mirrors, "git push --mirror" update mirrors
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.
--- 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.
Documentation/git-push.txt +12 -5
@@ -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
builtin-push.c +32 -11
67 lines not on this page · raw message
t/t5517-push-mirror.sh +86 -0
96 lines not on this page · raw message
Signature · 1 line
1.5.5
Quoted 10 lines · Paolo Bonzini
This patch builds on the infrastructure for remote.<nick>.mirror and tweaks the behavior of "git push". The idea is that "git push", "git push --all", "git push --mirror", instead of defaulting to origin, become DWIM commands:
- "git push" pushes to origin *and* to all mirrors
- "git push --all" pushes to origin with --all. I didn't make it push to mirrors because --all and --mirror are incompatible.
Quoted 6 lines
- "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.
Quoted 3 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? Yes, its on keystroke longer to type. Call it foo. git push foo would be shorter, and not require code changes in Git.
Signature · 1 line
Shawn.
Quoted 6 lines
Sorry, I don't really see a use case behind this.
git pushtoday 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.
Quoted 5 lines
Quoted 3 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:
Quoted 4 lines
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:
Quoted 3 lines
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
Quoted 3 lines · Shawn O. Pearce
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 foowould 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.
Quoted 5 lines · Junio C Hamano
Quoted 3 lines · Shawn O. Pearce
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 foowould be shorter, and not require code changes in Git.
...
Quoted 4 lines
(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.
Signature · 1 line
Shawn.
Quoted 6 lines · Shawn O. Pearce
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.
Signature · 1 line
Shawn.
Patch withdrawn, I'll send a different series.
Paolo
Quoted 8 lines · Shawn O. Pearce
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.
Quoted 8 lines · Junio C Hamano
Quoted 1 line · Shawn O. Pearce
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?
Quoted 5 lines
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).
Signature · 1 line
Shawn.
Quoted 5 lines · Shawn O. Pearce
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
Quoted 10 lines · Shawn O. Pearce
But then they later wonder why they need
git pull origin branchto merge in branch, when they usually just saygit pull. What is the need for that funny keywordorigin? 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?
Quoted 10 lines · Junio C Hamano
Quoted 4 lines · Shawn O. Pearce
But then they later wonder why they need
git pull origin branchto merge in branch, when they usually just saygit pull. What is the need for that funny keywordorigin? 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.
Quoted 3 lines
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.
Signature · 1 line
Shawn.
Quoted 3 lines · Shawn O. Pearce
It also clearly harms people who have only origin and want to grab updates from there with just
git fetchorgit 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?
Quoted 3 lines
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)).
Signature · 2 lines
Sincerely, [email protected] Stephen R. van den Berg.
Quoted 9 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 pullcase 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
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 4 lines · Paolo Bonzini
I think "git pull" is different, because it is more often fetching from one defined place (while Shawn said that he has a need for one-to-many "git push"es and so do I). For "git pull", the branch config provides a valuable default more often than for "git push".
I think it is highly dependent on your workflow. I would have said the exact opposite.
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
Quoted 5 lines
Quoted 2 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
Quoted 4 lines · Paolo Bonzini
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
Quoted 9 lines · Jeff King
Quoted 4 lines · Paolo Bonzini
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
Quoted 6 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
Hi,
Quoted 2 lines · Paolo Bonzini
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
Quoted 7 lines · Johannes Schindelin
Hi,
Quoted 1 line · Paolo Bonzini
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".
Quoted 1 line
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
Hi,
Quoted 7 lines · Paolo Bonzini
Quoted 5 lines · Johannes Schindelin
Quoted 2 lines · Paolo Bonzini
I'm preparing a patch that has "git fetch" fetch from all remotes (same as "git remote update" with no groups defined)
Quoted 7 lines
Quoted 2 lines
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
cover limit the usage of the default remote "origin" to the minimum
In reply to Paolo BonziniThe aim of this series of patches limits the "magic" default of "origin", that git sometimes uses in its fetch/push/pull commands, to what I consider to be the bare acceptable minimum. (I will discuss later what this minimum is).
This has two aims. The first is to make people more aware of what remote they are interacting with. The second is to allow faster operation for those people that do work with more than one remote. While "git remote update" already does some of the latter, it is limited to fetching. These patches use a different approach: they take the zero-argument commands "git fetch", "git push", "git pull" that all git users know, and make them scale nicely to use cases with >1 remote.
Patches 1 to 4 deal with "git push". The problem here is that the "magic" default operation ("git push sends to origin all refs that are already present there"), as of new, cannot be explained in the configuration, and this is fixed by patches 1 and 2. Patch 1 adds a special push refspec meaning "consider all refs already on the remote", and patch 2 makes git-clone add one such line when it creates the origin remote.
Patch 3 could also be split out of this series. It adds to "git-remote add" a new --push option, that sets up a push refspec for the newly created remote. If git-clone will ever use "git-remote add", it should pass this option. This patch also defines the "--push --mirror" combo to create a remote *which will backup the current repository*. I posted this patch here, and placed it as the third, because some design decisions in patch 4 are clearer if one considers the --push --mirror use case.
Patch 4 is a reworking of my previous patch. Instead of having "git push" push to "all mirrors plus the magic origin branch", it will push to "all remotes having a push refspec". In the future, this will always include the origin branch because of patch 2, while right now the origin branch is still used if no remote has a push refspec (for backwards compatibility -- more discussion in the patch log message).
This patch may cause incompatibilities to be warned about in the release notes. Luckily, these incompatibilities only affect users that already know their way in .git/config, because no porcelain command creates push refspecs.
Patches 5 and 6 affect "git pull". Pulling uses the magic origin branch less often, because branch.*.remote already establishes a saner default. Therefore, here we can actually warn and deprecate the misfeature for real (patch 6). Patch 5 however is still needed, so that "git pull" itself decides when to use the magic "origin" branch instead of making the decision in "git fetch".
Finally, patch 7 affects "git fetch". As hinted earlier, I chose to duplicate the functionality already present in "git remote update" (for the case where remotes are not grouped), but the code is much simpler so there is no incentive (at least for now) in borrowing code from "git remote update" into "git fetch"---actually, as a cleanup it is maybe possible to borrow code in the other direction.
The patch series touches relatively many areas. Some patches could go in separately as cleanups, new features or just because their effect is less profound. In particular:
- patch 5 could go in separately as a code cleanup;
- patch 6 does not affect the user operation, it just adds a warning that should not appear for the most common cases; it can go in IMHO even if "git fetch" and "git push" keep the magic choice of "origin".
- patches 1 and 2 add a new feature and could go in separately.
As a closing comment (this cover letter is already too long possibly!), I think this design is sound. In particular, here is a list of citations from the earlier thread in light of which, I think, this design makes a lot of sense.
"I _hate_ the default remote."
Well, this series does not make origin behave differently. Still, a "remote configured by default to behave in a particular way", is obviously much better than "a remote whose default behavior is built into git". Also, even though this series could not completely remove git's knowledge of origin, that's only motivated by backwards compatibility.
"I am sympathetic when they want to say "git push" and have it default
to that single other repository."
So that's what git will keep doing. However...
"Should we [...] make people more aware that what _they_ do is the
special case to have only one remote to interact with?"
... after this series, it will scale to >1 remote consistently with this aim. "git fetch" and "git push" will examine every possible remote (and there is just one in the simple "CVS" case).
"BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes."
The series remove the need to switch from "git fetch" to "git remote update" as one learns the power of DVCS.
"[Removing a default altogether] harms the git pull case that relies upon the magic branch.$name.remote and branch.$name.merge keys."
Indeed, IMHO the way to go (in general, and especially for "git pull") is to deprecate the magic usage of "origin"---not to deprecate the zero-argument versions.
"I know git pretty well, and I find that particular distinction (that is, needing to specify the remote if using refspecs, but not otherwise) annoying. It is purely a syntactic issue that relying on order of arguments means you can't default earlier ones but specify later ones."
The patches admittedly does not tackle that. It actually makes it "harder to solve", because it is not anymore a matter of default arguments. Zero-argument push and fetch work on all remotes (suggested also by Stephen R. van der Berg in the thread), not on just one. On the other hand, it makes it easier to explain: all remotes? no need to specify anything; one remote? always specify it.
Paolo Bonzini (7):
add special "matching refs" refspec
add push line in git-clone
Add a --push option to "git-remote add"
make "git push" update all push repositories.
don't rely on zero-argument "git fetch" from within git pull warn on "git pull" without a given branch.<name>.remote value make "git fetch" update all fetch repositories
Documentation/git-fetch.txt | 7 ++ Documentation/git-pull.txt | 9 ++- Documentation/git-push.txt | 35 +++++++--- Documentation/git-remote.txt | 31 ++++++--- builtin-fetch.c | 109 ++++++++++++++++------------- builtin-push.c | 67 +++++++++++++++--- builtin-remote.c | 32 ++++++-- builtin-send-pack.c | 10 +++- git-clone.sh | 2 + git-parse-remote.sh | 8 ++ git-pull.sh | 9 ++- remote.c | 80 ++++++++++++++------- remote.h | 1 + t/t5400-send-pack.sh | 2 +- t/t5505-remote.sh | 26 +++++++- t/t5510-fetch.sh | 19 +++++- t/t5511-refspec.sh | 5 +- t/t5515-fetch-merge-logic.sh | 8 +-- t/t5515/fetch.br-branches-default | 8 -- t/t5515/fetch.br-branches-default-merge | 9 --- t/t5515/fetch.br-branches-default-octopus | 10 --- t/t5515/fetch.br-branches-one | 8 -- t/t5515/fetch.br-branches-one-merge | 9 --- t/t5515/fetch.br-branches-one-octopus | 9 --- t/t5515/fetch.br-config-explicit | 11 --- t/t5515/fetch.br-config-explicit-merge | 11 --- t/t5515/fetch.br-config-explicit-octopus | 11 --- t/t5515/fetch.br-config-glob | 11 --- t/t5515/fetch.br-config-glob-merge | 11 --- t/t5515/fetch.br-config-glob-octopus | 11 --- t/t5515/fetch.br-remote-explicit | 11 --- t/t5515/fetch.br-remote-explicit-merge | 11 --- t/t5515/fetch.br-remote-explicit-octopus | 11 --- t/t5515/fetch.br-remote-glob | 11 --- t/t5515/fetch.br-remote-glob-merge | 11 --- t/t5515/fetch.br-remote-glob-octopus | 11 --- t/t5515/fetch.br-unconfig | 11 --- t/t5515/fetch.master | 11 --- t/t5515/refs.br-branches-default | 12 --- t/t5515/refs.br-branches-default-merge | 12 --- t/t5515/refs.br-branches-default-octopus | 12 --- t/t5515/refs.br-branches-one | 12 --- t/t5515/refs.br-branches-one-merge | 12 --- t/t5515/refs.br-branches-one-octopus | 12 --- t/t5515/refs.br-config-explicit | 15 ---- t/t5515/refs.br-config-explicit-merge | 15 ---- t/t5515/refs.br-config-explicit-octopus | 15 ---- t/t5515/refs.br-config-glob | 15 ---- t/t5515/refs.br-config-glob-merge | 15 ---- t/t5515/refs.br-config-glob-octopus | 15 ---- t/t5515/refs.br-remote-explicit | 15 ---- t/t5515/refs.br-remote-explicit-merge | 15 ---- t/t5515/refs.br-remote-explicit-octopus | 15 ---- t/t5515/refs.br-remote-glob | 15 ---- t/t5515/refs.br-remote-glob-merge | 15 ---- t/t5515/refs.br-remote-glob-octopus | 15 ---- t/t5515/refs.br-unconfig | 11 --- t/t5515/refs.master | 11 --- t/t5516-fetch-push.sh | 41 +++++++++++ t/t5517-push-mirror.sh | 84 ++++++++++++++++++++++- 60 files changed, 452 insertions(+), 614 deletions(-) delete mode 100644 t/t5515/fetch.br-branches-default delete mode 100644 t/t5515/fetch.br-branches-default-merge delete mode 100644 t/t5515/fetch.br-branches-default-octopus delete mode 100644 t/t5515/fetch.br-branches-one delete mode 100644 t/t5515/fetch.br-branches-one-merge delete mode 100644 t/t5515/fetch.br-branches-one-octopus delete mode 100644 t/t5515/fetch.br-config-explicit delete mode 100644 t/t5515/fetch.br-config-explicit-merge delete mode 100644 t/t5515/fetch.br-config-explicit-octopus delete mode 100644 t/t5515/fetch.br-config-glob delete mode 100644 t/t5515/fetch.br-config-glob-merge delete mode 100644 t/t5515/fetch.br-config-glob-octopus delete mode 100644 t/t5515/fetch.br-remote-explicit delete mode 100644 t/t5515/fetch.br-remote-explicit-merge delete mode 100644 t/t5515/fetch.br-remote-explicit-octopus delete mode 100644 t/t5515/fetch.br-remote-glob delete mode 100644 t/t5515/fetch.br-remote-glob-merge delete mode 100644 t/t5515/fetch.br-remote-glob-octopus delete mode 100644 t/t5515/fetch.br-unconfig delete mode 100644 t/t5515/fetch.master delete mode 100644 t/t5515/refs.br-branches-default delete mode 100644 t/t5515/refs.br-branches-default-merge delete mode 100644 t/t5515/refs.br-branches-default-octopus delete mode 100644 t/t5515/refs.br-branches-one delete mode 100644 t/t5515/refs.br-branches-one-merge delete mode 100644 t/t5515/refs.br-branches-one-octopus delete mode 100644 t/t5515/refs.br-config-explicit delete mode 100644 t/t5515/refs.br-config-explicit-merge delete mode 100644 t/t5515/refs.br-config-explicit-octopus delete mode 100644 t/t5515/refs.br-config-glob delete mode 100644 t/t5515/refs.br-config-glob-merge delete mode 100644 t/t5515/refs.br-config-glob-octopus delete mode 100644 t/t5515/refs.br-remote-explicit delete mode 100644 t/t5515/refs.br-remote-explicit-merge delete mode 100644 t/t5515/refs.br-remote-explicit-octopus delete mode 100644 t/t5515/refs.br-remote-glob delete mode 100644 t/t5515/refs.br-remote-glob-merge delete mode 100644 t/t5515/refs.br-remote-glob-octopus delete mode 100644 t/t5515/refs.br-unconfig delete mode 100644 t/t5515/refs.master
PATCH 1/7 add special "matching refs" refspec
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.
--- 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).
Documentation/git-push.txt +7 -6
@@ -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
builtin-send-pack.c +9 -1
@@ -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 :
remote.c +53 -27
138 lines not on this page · raw message
remote.h +1 -0
@@ -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;
t/t5511-refspec.sh +4 -1
@@ -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
t/t5516-fetch-push.sh +41 -0
47 lines not on this page · raw message
Signature · 1 line
1.5.5
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.
--- git-clone.sh | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
git-clone.sh +2 -0
@@ -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
Signature · 1 line
1.5.5
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.
--- 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.
Documentation/git-remote.txt +19 -6
@@ -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'::
builtin-remote.c +24 -8
@@ -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);
t/t5505-remote.sh +25 -1
@@ -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
t/t5517-push-mirror.sh +1 -1
@@ -25,7 +25,7 @@ mk_repo_pair () { ( cd master && git init && - git remote add $1 up ../mirror + git remote add --push $1 up ../mirror ) }
Signature · 1 line
1.5.5
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.
--- 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.
Documentation/git-push.txt +18 -4
@@ -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
Documentation/git-remote.txt +5 -5
@@ -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 --------
builtin-push.c +55 -12
105 lines not on this page · raw message
t/t5400-send-pack.sh +1 -1
@@ -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 '
t/t5517-push-mirror.sh +82 -0
92 lines not on this page · raw message
Signature · 1 line
1.5.5
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).
--- git-pull.sh | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
git-pull.sh +6 -3
@@ -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 \
Signature · 1 line
1.5.5
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.
--- 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.
Documentation/git-pull.txt +5 -4
@@ -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
git-parse-remote.sh +8 -0
@@ -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} }
Signature · 1 line
1.5.5
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.
--- 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.
Documentation/git-fetch.txt +7 -0
@@ -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[]
builtin-fetch.c +61 -48
181 lines not on this page · raw message
t/t5510-fetch.sh +18 -1
@@ -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 &&
t/t5515-fetch-merge-logic.sh +2 -6
@@ -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/*
t/t5515/fetch.br-branches-default deleted +0 -8
@@ -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 ../
t/t5515/fetch.br-branches-default-merge deleted +0 -9
@@ -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 ../
t/t5515/fetch.br-branches-default-octopus deleted +0 -10
@@ -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 ../
t/t5515/fetch.br-branches-one deleted +0 -8
@@ -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 ../
t/t5515/fetch.br-branches-one-merge deleted +0 -9
@@ -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 ../
t/t5515/fetch.br-branches-one-octopus deleted +0 -9
@@ -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 ../
t/t5515/fetch.br-config-explicit deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-config-explicit-merge deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-config-explicit-octopus deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-config-glob deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-config-glob-merge deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-config-glob-octopus deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-explicit deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-explicit-merge deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-explicit-octopus deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-glob deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-glob-merge deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-remote-glob-octopus deleted +0 -11
@@ -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 ../
t/t5515/fetch.br-unconfig deleted +0 -11
@@ -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 ../
t/t5515/fetch.master deleted +0 -11
@@ -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 ../
t/t5515/refs.br-branches-default deleted +0 -12
@@ -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
t/t5515/refs.br-branches-default-merge deleted +0 -12
@@ -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
t/t5515/refs.br-branches-default-octopus deleted +0 -12
@@ -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
t/t5515/refs.br-branches-one deleted +0 -12
@@ -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
t/t5515/refs.br-branches-one-merge deleted +0 -12
@@ -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
t/t5515/refs.br-branches-one-octopus deleted +0 -12
@@ -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
t/t5515/refs.br-config-explicit deleted +0 -15
@@ -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
t/t5515/refs.br-config-explicit-merge deleted +0 -15
@@ -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
t/t5515/refs.br-config-explicit-octopus deleted +0 -15
@@ -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
t/t5515/refs.br-config-glob deleted +0 -15
@@ -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
t/t5515/refs.br-config-glob-merge deleted +0 -15
@@ -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
t/t5515/refs.br-config-glob-octopus deleted +0 -15
@@ -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
t/t5515/refs.br-remote-explicit deleted +0 -15
@@ -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
t/t5515/refs.br-remote-explicit-merge deleted +0 -15
@@ -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
t/t5515/refs.br-remote-explicit-octopus deleted +0 -15
@@ -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
t/t5515/refs.br-remote-glob deleted +0 -15
@@ -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
t/t5515/refs.br-remote-glob-merge deleted +0 -15
@@ -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
t/t5515/refs.br-remote-glob-octopus deleted +0 -15
@@ -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
t/t5515/refs.br-unconfig deleted +0 -11
@@ -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
t/t5515/refs.master deleted +0 -11
@@ -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
Signature · 1 line
1.5.5
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Paolo Bonzini, Mon, Apr 28, 2008 17:32:18 +0200:
Quoted 4 lines
This patch parallels what a previous patch did to "git push". It makes "git fetch" with no repository argument similar to "git remote update" with no default group set. Of course, "git fetch" with no arguments honors skipDefaultUpdate too.
You may consider to update "git remote add" to make all new remotes .skipDefaultUpdate. And otherwise, I promise to hate your patch everytime when I mindlessly type "git fetch" in, for instance, my v4l2 repo (which is a pretty collection of all kinds of remotes). All of sudden it starts updating them and losing old references. And that without me even touching configuration.
Please, consider making this behaviour non-default. Just because the all current repos suddenly start updating itself where they didn't before. Same goes for you "git push" patch.
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 2 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.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 6 lines
Quoted 2 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?
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 7 lines · Alex Riesen
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 4 lines
Quoted 2 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?
No, absolutely. In fact if I were you I would set skipDefaultUpdate *now* on the remotes of that repo.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
Quoted 4 lines
Quoted 3 lines · Alex Riesen
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 2 lines
Quoted 2 lines
my v4l2
repo (which is a pretty collection of all kinds of remotes)
Quoted 8 lines
Quoted 5 lines
Quoted 3 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?
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 5 lines · Alex Riesen
Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
Quoted 4 lines
Quoted 3 lines · Alex Riesen
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 2 lines
Quoted 2 lines
my v4l2
repo (which is a pretty collection of all kinds of remotes)
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 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?
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.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 2 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! 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.
Quoted 2 lines
How about renaming "skipDefaultUpdate" to "fetch.fetchAllRemotes" and let it default to false?
Renaming can be done (as a followup preferably, the patch series touches enough places like this). But not setting the default, as that would destroy the "base case" where "git fetch" just fetches from origin.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Hi,
Quoted 5 lines · Paolo Bonzini
Quoted 2 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?
Quoted 2 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.
Happily, I am quite certain that Junio will not allow such dramatic changes into Git, at least not without a long, long time of warning, during which I can safely undo the changes in my personal branch.
Because I do like to call "git remote update" from time to time, and I absolutely hate the idea of "origin" _not_ being special.
Ciao,
Dscho
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 7 lines
Quoted 5 lines
Quoted 3 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.
Quoted 4 lines
Quoted 2 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.
Quoted 1 line
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.
Quoted 1 line
I absolutely hate the idea of "origin" _not_ being special.
Well, Junio and Shawn convinced me of the contrary, so I guess they disagree with you on this one...
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Alex RiesenQuoted 5 lines · Alex Riesen
Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
Quoted 4 lines
Quoted 3 lines · Alex Riesen
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 2 lines
Quoted 2 lines
my v4l2
repo (which is a pretty collection of all kinds of remotes)
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 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.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 8 lines · Paolo Bonzini
Quoted 7 lines · Alex Riesen
Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:
Quoted 6 lines
Quoted 5 lines · Alex Riesen
Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:
Quoted 4 lines
Quoted 2 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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
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?
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 5 lines
Quoted 2 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.
Quoted 2 lines
Remind me to never employ you. I doubt you'd ever get any work done.
Well, the same should apply to reading mailing lists...
Quoted 3 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?
2) the patch does not touch refs/heads/* unless you are tweaking your configuration (and quite heavily so). IMHO that's using enough rope that you really ought to know about the reflog and... look for backwards incompatible changes in the release notes!
3) your complaint was that it gave errors. Alex did talk about losing his work, but questions 1 and 2 would apply to him too.
4) one man's stupidity is another man's... [fill in] In particular, did you understand the rationale for this change? Do you have any alternative ideas?
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 11 lines · Paolo Bonzini
Quoted 5 lines
Quoted 2 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.
Quoted 2 lines
Remind me to never employ you. I doubt you'd ever get any work done.
Quoted 8 lines
Well, the same should apply to reading mailing lists...
Quoted 3 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)?
Because I will lose some of the refs and then have to dig them up in the reflog.
Quoted 2 lines
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.
Quoted 2 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
Quoted 4 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.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 8 lines
Quoted 2 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.
Quoted 2 lines
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".
Quoted 3 lines
Now that I think about it, it's probably useful to have it togglable via command-line switch as well. Something along the lines of "git fetch --all-remotes", perhaps.
Making it accessible via a command-line switch is pointless, as we already have "git remote update" for that.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Paolo BonziniPaolo Bonzini, Tue, Apr 29, 2008 18:40:24 +0200:
Quoted 6 lines
Quoted 3 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.
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Paolo BonziniQuoting Paolo Bonzini <[email protected]>:
Quoted 24 lines
Quoted 9 lines
Quoted 3 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.
Quoted 2 lines
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".
Quoted 8 lines
Quoted 3 lines
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"?
Signature · 6 lines
Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to a message not in the archiveQuoted 1 line
Sorry but then why does this patch have to even touch "git fetch"? Isn't it enough to run "git remote update"?
I'm tired of answering. Please read the cover letter. It's not about adding new features (it does in patches 1 to 3, but only as means to an end). It's about rationalizing existing behavior so that "newbie usage patterns" generalize better, and patches 4 and 7 are the most important (and the most controversial) in this respect.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Hi,
Quoted 4 lines · Paolo Bonzini
Quoted 2 lines
Sorry but then why does this patch have to even touch "git fetch"? Isn't it enough to run "git remote update"?
I'm tired of answering. Please read the cover letter.
Actually, this is unfair. You did not answer it to my satisfaction, but I thought that maybe it is just me.
Alas, apparently it is not just me. I think that "git fetch" is something more concise than "git remote update", and that it is a good thing.
Ciao,
Dscho
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Paolo BonziniPaolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:
Quoted 9 lines
Quoted 3 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).
Quoted 4 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?
Quoted 2 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.
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).
Quoted 3 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? And an acceptable transition plan? ("Read RelNotes!", yes, you mentioned. Another one?)
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 4 lines
Quoted 1 line
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).
Quoted 3 lines
Quoted 1 line
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.
Quoted 2 lines
And an acceptable transition plan?
("Read RelNotes!", yes, you mentioned. Another one?)
See above.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Paolo Bonzini, Tue, Apr 29, 2008 23:15:02 +0200:
Quoted 10 lines
Quoted 7 lines
Quoted 4 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...
Quoted 4 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 <[email protected]>
Quoted 3 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?
Quoted 8 lines
Quoted 5 lines
Quoted 3 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.
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 5 lines
Quoted 2 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 <[email protected]>
http://permalink.gmane.org/gmane.comp.version-control.git/80720
Quoted 5 lines
Quoted 1 line
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".
Quoted 1 line
It is not. It seem to propose, instead of fixing existing behaviour,
Do you know how to "fix" existing behavior?
I mean, I just wonder why as long as I had one remote only, I could write "git push", while now I have to write "git push origin && git push mirror". The patch to "git fetch" comes from this observation too, and I think it is a good idea, even though I'm less attached to it and it would influence my workflow much less.
Paolo
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200:
Quoted 5 lines
Quoted 2 lines
Hmm... Which one do you mean? I cannot find his reply to message-id <[email protected]>
http://permalink.gmane.org/gmane.comp.version-control.git/80720
Just received it
Quoted 11 lines
Quoted 7 lines
Quoted 3 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"
$Quoted 4 lines
Quoted 1 line
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).
Quoted 5 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?
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Paolo BonziniHi,
Quoted 5 lines · Paolo Bonzini
I mean, I just wonder why as long as I had one remote only, I could write "git push", while now I have to write "git push origin && git push mirror". The patch to "git fetch" comes from this observation too, and I think it is a good idea, even though I'm less attached to it and it would influence my workflow much less.
I wonder why you need to make such a big change, which _is_ incompatible, and not do the obvious thing, namely introduce a subcommand to "git remote" which does the "push" equivalent of "git remote update"...
Do you really think that it is a good idea to push down a huge change like this down everybody else's throat, just because you do not want to type "git remote ..." but "git fetch ..." in your workflow?
Ciao,
Dscho
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 7 lines · Johannes Schindelin
I wonder why you need to make such a big change, which _is_ incompatible, and not do the obvious thing, namely introduce a subcommand to "git remote" which does the "push" equivalent of "git remote update"...
Do you really think that it is a good idea to push down a huge change like this down everybody else's throat, just because you do not want to type "git remote ..." but "git fetch ..." in your workflow?
I wonder this a bit, too, and I am even somebody who _likes_ the new behavior. But there is a difference between "should have been designed this way in the first place" and "is currently designed some other way, and will cause pain to switch it to this way."
So it might simply not be worth the trouble to change. OTOH, I think this is how we end up with many commands to do slightly different things, which can end up confusing new users. I'm not sure what the right answer is.
-Peff
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 9 lines · Jeff King
I wonder this a bit, too, and I am even somebody who _likes_ the new behavior. But there is a difference between "should have been designed this way in the first place" and "is currently designed some other way, and will cause pain to switch it to this way."
So it might simply not be worth the trouble to change. OTOH, I think this is how we end up with many commands to do slightly different things, which can end up confusing new users. I'm not sure what the right answer is.
Well, the thing is, push and fetch are different, so expecting the same behaviour and syntax from them is a lost cause to begin with. Even if we were designing fetch and push right now, I do not necessarily think the series shows a way that "should have been designed in the first place".
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
Quoted 1 line
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.
Quoted 4 lines
Quoted 4 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."
Agreed.
Quoted 9 lines
Quoted 4 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
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Alex RiesenHi,
Quoted 10 lines · Alex Riesen
Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:
Quoted 2 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.
Yes. And I can loose my work if "git fetch" (which I type without thinking) will now update some remote I didn't mean it to. Remote references can be shared - updated from different sites (think mirros like kernel.org and repo.or.cz). Setups like this are used elsewhere too (I use them).
Like I said, I think this change affects too many existing users in a very negative way.
But then, I respect Junio's very careful way of dealing with such issues, and am not really doubting that it will take a long, long time to change the default behaviour of Git, if at all. Which is a good thing.
And I am certain that Paolo does not believe his release notes argument either. Not seriously, anyway.
Ciao,
Dscho
Re: [PATCH 7/7] make "git fetch" update all fetch repositories
In reply to Paolo BonziniPaolo Bonzini, Tue, Apr 29, 2008 08:50:15 +0200:
Quoted 12 lines
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 3 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.
Re: [PATCH 2/7] add push line in git-clone
In reply to Paolo BonziniQuoted 3 lines · Paolo Bonzini
This patch makes git-clone add a remote.origin.push line, using the new ":" special refspec. This is useful in the following patches that modify the behavior of "git push"; right now, it only adds clarity.
Used together with [1/7], this change is Ok in a homogeneous environment, but it would break people who use git of different vintage on the same repository (think of a repository on a networked filesystem). You clone like this, and older git won't grok the push configuration anymore.
It may look a very minor point, but I think it deserves mentioning.
Re: [PATCH 1/7] add special "matching refs" refspec
In reply to Paolo BonziniQuoted 13 lines · Paolo Bonzini
remote.c +7
-0@@ -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 &&
remote.c static const struct refspec *check_pattern_match(const struct refspec *rs, · line 965
Quoted 10 lines
remote.c +4
-1!prefixcmp(src->name, rs[i].src) && src->name[strlen(rs[i].src)] == '/')return rs + i; } -return NULL ; +if (matching_refs !=-1 ) +return rs + matching_refs; +else +return NULL ; }
It is probably better to document that you would force if you have both "+:" and ":" for the same remote, even though I am not sure if allowing that (instead of diagnosing it as an error) is the right thing to do.
Is it an error to have both ":" and "some:other" refspecs for the same remote? If so who makes the check?
Otherwise this patch seems to be very cleanly done. Especially I like how the updated match_refs() looks.
Re: [PATCH 1/7] add special "matching refs" refspec
Quoted 10 lines
remote.c static const struct refspec *check_pattern_match(const struct refspec *rs, · line 954
Quoted 6 lines
remote.c +5
-0+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.
Quoted 2 lines
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.
Quoted 2 lines
Otherwise this patch seems to be very cleanly done. Especially I like how the updated
match_refs()looks.
Thanks. Should I resubmit?
Paolo
Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
In reply to Paolo BonziniQuoted 7 lines · Paolo Bonzini
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.
Quoted 3 lines
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).
Quoted 8 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).
Quoted 4 lines
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).
Quoted 6 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?
Quoted 6 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.
Quoted 4 lines
"BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes."
The series remove the need to switch from "git fetch" to "git remote update" as one learns the power of DVCS.
This was from me, and I do like this behavior better.
-Peff
Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
Jeff King, Tue, Apr 29, 2008 21:35:36 +0200:
Quoted 11 lines · Paolo Bonzini
Quoted 4 lines
This patch may cause incompatibilities to be warned about in the release notes. Luckily, these incompatibilities only affect users that already know their way in .git/config, because no porcelain command creates push refspecs.
I think you understand the compatibility issues, but I think it needs to be not "warned in the release notes" but "warned in the release notes, followed by a period of adjustment, and then the change". And maybe it would even make sense to wait for a larger-number version change (like 1.6.0).
But please, make this "period of adjustment" actually visible to the USER WHO DOES NOT READ RELEASE NOTES. Say loud and clear when you do something different. And better yet - do not do anything unexpected just yet. Describe it, print instructions about changing configuration. So that next less-minor-release with changed behavior (but the warning still in place) is less of a surprise.
Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
In reply to Jeff KingQuoted 5 lines · Jeff King
... 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?
Quoted 7 lines
Quoted 7 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?
Quoted 4 lines
Quoted 4 lines
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?
Quoted 3 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.
Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
Quoted 8 lines · Junio C Hamano
Quoted 5 lines · Jeff King
... 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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 3 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
Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum
Quoted 11 lines
Quoted 10 lines
Quoted 6 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?
Quoted 5 lines
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).
Quoted 2 lines
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.
Quoted 9 lines
Quoted 7 lines
Quoted 3 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
Re: [PATCH 2/7] add push line in git-clone
In reply to Junio C HamanoQuoted 7 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
Re: [PATCH 2/7] add push line in git-clone
Quoted 9 lines · Paolo Bonzini
Quoted 7 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
Re: [PATCH 2/7] add push line in git-clone
Quoted 7 lines · Paolo Bonzini
Quoted 6 lines · Paolo Bonzini
Quoted 6 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.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
It may look a very minor point, but I think it deserves mentioning.
I think it is reasonable to require cloning with the least-common-denominator version in this case. Think of what happened if the pack format changed.
Any news on this (and on 1/7, which is in pu)?
I did not personally find that argument convincing, and I thought list agreed with me with silence ;-).
The pack-format change is a big deal and benefit everybody. Comparing it with this change feels like comparing an apple and a poppy seed, doesn't it?
Re: [PATCH 2/7] add push line in git-clone
Quoted 10 lines · Junio C Hamano
Quoted 8 lines · Paolo Bonzini
Quoted 7 lines · Paolo Bonzini
Quoted 6 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.
Quoted 8 lines
Quoted 4 lines
Quoted 3 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).
Paolo
Re: [PATCH 2/7] add push line in git-clone
Quoted 5 lines · Paolo Bonzini
Quoted 5 lines
Quoted 4 lines
Quoted 3 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)?
Quoted 8 lines
Quoted 3 lines
The pack-format change is a big deal and benefit everybody. Comparing it with this change feels like comparing an apple and a poppy seed, doesn't it?
Yes, but it is the same. Another example is when remotes started being created in refs/remotes/origin upon cloning. In general, you cannot expect a clone to be downwards-compatible (or, you should expect a clone *not* to be downwards-compatible).
I think we are in agreement and that is all the more reason we have to be extremely careful not to introduce incompatibility without a clear advantage. The commands involved with your patch work with or without the new default entry in the config created by the clone exactly the same way, and the versions before your patch would choke with the new default entry.
Re: [PATCH 2/7] add push line in git-clone
Quoted 6 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