Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Johan Herland jo...@herland.net writes: Let me try to summarize my views on how refnames should work in Git, to see if we can identify where we differ on the principles (or if we, in fact, differ at all): Thanks; I think I already said where I think we differ in a separate message, but a short version is that the point of remote.$nick.fetch mapping is to solve The remote may call a ref $this, which is not the refname I want to or can use in my repository, so here is the rule to use when importing it in my local namespace. With the mapping, I can name the ref in my local namespace conveniently. E.g. their refs/heads/master cannot be our refs/heads/master at the same time, so use refs/heads/origin/master. The result of the above mapping, be it remotes/origin/master or remotes/origin/heads/master, should be designed to be useful for the local use of the ref in question. If you further need to remap it when using it locally, there is something wrong in the mapping you defined in your remote.$nick.fetch mapping in the first place. We do not force any structure under refs/remotes/; it is left entirely up to the user, even though we would like to suggest the best current practice by teaching clone and remote add to lay them out in a certain way. Another thing is that refs/remotes/ is not special at all. If notes hierarchies taken from a remote need to be somewhere other than refs/notes/, it is perfectly fine to introduce refs/remote-notes/ if that is the best layout when using them locally. What is special is refs/heads/ in that they are the _only_ refs you can check out to the working tree and directly advance them by working on the working tree files. I would support disallowing multi-level remote names, although I don't know if it is commonly used, and would break many existing users. I somewhat doubt it. We very much anticipated the use of multi-level branch names from the very beginning and have support (e.g. in for-each-ref and branch --list) to group/filter them according to prefixes, but I do not think there is anywhere we consciously try to give support for multi-level remote names to treat groups of remotes that share the same prefix. *2* Perhaps bar in the above is spelled topics, and the hierarchy may be used to collect non-integration single topic branches from more than one remote. An example that is more in line with such a usage might be: [remote jh] fetch = +refs/heads/*:refs/remotes/topics/heads/jh/* [remote jk] fetch = +refs/heads/*:refs/remotes/topics/heads/jk/* [remote fc] fetch = +refs/heads/*:refs/remotes/topics/heads/fc/* and I would expect git merge topics/jh/rbranch to merge the refs/remotes/topics/heads/jh/rbranch topic branch. I like the use case, but not necessarily your expectation. ;-) With the above configuration, and my series as-is, you could simply do git merge jh/rbranch to merge the refs/remotes/topics/heads/jh/rbranch topic branch. That dropping of 'topics/' is the issue. The user wanted to group them under 'topics/' hierarchy and made a conscous effort to set up the fetch refspec to map these refs there. These are done all for convenience when she deals with refs in her namespace in the repository. What justification do we have to second guess the user and force her to drop it when naming these refs? Furthermore, I don't see why you want/need the extra heads/ level in the refspec. Just like you wanted to have separate kinds of refs under a single remote, the layout is grouping kinds of refs other than branch heads related to the topics (as opposed to integration branches). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Santi Béjar sa...@agolina.net writes: The next question could be: why not make it work with $url too? As in: $ git merge git://git.kernel.org/pub/scm/git/git.git//master You need to remember merge is a local operation, working in your local repository. Like it or not, the UI of Git makes distinction between operations that are local and those that go to other repositories (e.g. git pull). That of course does _not_ prevent you from writing an alternative UI got merge anything that interprets anthing part and invokes git merge or git pull as its helper (after all, Git is designed to be scripted). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Junio C Hamano gits...@pobox.com writes: Just a few typofixes... Johan Herland jo...@herland.net writes: Let me try to summarize my views on how refnames should work in Git, to see if we can identify where we differ on the principles (or if we, in fact, differ at all): Thanks; I think I already said where I think we differ in a separate message, but a short version is that the point of remote.$nick.fetch mapping is to solve The remote may call a ref $this, which is not the refname I want to or can use in my repository, so here is the rule to use when importing it in my local namespace. With the mapping, I can name the ref in my local namespace conveniently. E.g. their refs/heads/master cannot be our refs/heads/master at the same time, so use refs/heads/origin/master. The last should be refs/remotes/origin/master. The result of the above mapping, be it remotes/origin/master or remotes/origin/heads/master, should be designed to be useful for the local use of the ref in question. If you further need to remap it when using it locally, there is something wrong in the mapping you defined in your remote.$nick.fetch mapping in the first place. We do not force any structure under refs/remotes/; it is left entirely up to the user, even though we would like to suggest the best current practice by teaching clone and remote add to lay them out in a certain way. Another thing is that refs/remotes/ is not special at all. If notes hierarchies taken from a remote need to be somewhere other than refs/notes/, it is perfectly fine to introduce refs/remote-notes/ if that is the best layout when using them locally. What is special is s/the best/the most convenient/; refs/heads/ in that they are the _only_ refs you can check out to the working tree and directly advance them by working on the working tree files. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
El 06/05/2013 19:11, Junio C Hamano gits...@pobox.com va escriure: Santi Béjar sa...@agolina.net writes: The next question could be: why not make it work with $url too? As in: $ git merge git://git.kernel.org/pub/scm/git/git.git//master You need to remember merge is a local operation, working in your local repository. Like it or not, the UI of Git makes distinction between operations that are local and those that go to other repositories (e.g. git pull). Of course! In fact I wanted to say git pull. Santi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
On Mon, May 6, 2013 at 7:06 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: Let me try to summarize my views on how refnames should work in Git, to see if we can identify where we differ on the principles (or if we, in fact, differ at all): Thanks; I think I already said where I think we differ in a separate message, but a short version is that the point of remote.$nick.fetch mapping is to solve The remote may call a ref $this, which is not the refname I want to or can use in my repository, so here is the rule to use when importing it in my local namespace. With the mapping, I can name the ref in my local namespace conveniently. E.g. their refs/heads/master cannot be our refs/heads/master at the same time, so use refs/remotes/origin/master. The result of the above mapping, be it remotes/origin/master or remotes/origin/heads/master, should be designed to be useful for the local use of the ref in question. If you further need to remap it when using it locally, there is something wrong in the mapping you defined in your remote.$nick.fetch mapping in the first place. Ok, so whereas I consider the refspec to be king, and that the expansion from convenient shorthands to full remote-tracking refnames should be derived from the chosen refspec, you would (if I understand you correctly) rather have a constant (i.e. independent of remotes and refspecs) set of rules for expanding shorthands to full refnames, and if the user chooses refspecs that don't mesh well with those rules, then that is the user's problem, and not Git's. We do not force any structure under refs/remotes/; it is left entirely up to the user, even though we would like to suggest the best current practice by teaching clone and remote add to lay them out in a certain way. If we were to suggest +refs/heads/*:refs/remotes/origin/heads/* as the best practice, I assume you do want origin/master to keep working. And since you do not want to use the configured refspec when expanding origin/master into refs/remotes/origin/heads/master, then I assume you would rather add a hardcoded (what I call a textual expansion in my patches) rule that would map $nick/$name into /refs/remotes/$nick/heads/$name But isn't the existence of such a rule evidence of us trying to impose (or at least hint) at a certain structure for refs/remotes/*? In light of this, I'm interested in your thoughts about the following related problem that I've just started looking at: git branch -r shows the remote-tracking branches in this repo. Currently, AFAICS, this just spits out all refs under refs/remotes/*. This behavior must clearly be modified if we are to allow remote-tracking tags at refs/remotes/$remote/tags/* (they currently show up in git branch -r, but shouldn't). One could say that the filter should merely change from refs/remotes/* to refs/remotes/*/heads/*, but this would break for existing (old-style) remotes. Should we add a heuristic for detecting when to use refs/remotes/* vs. refs/remotes/*/heads/* as a filter? My approach would be to iterate through the configured remotes, and for each remote list all refs that match the RHS of the refspec whose LHS is refs/heads/*. This would work for both old- and new-style remotes with no heuristics. If you agree that my approach is correct for enumerating remote-tracking branches, then what is different about using the refspec when expanding remote-tracking refs in general? In other words, given the following configuration: [remote origin] +refs/heads/*:refs/foo/bar/baz/* [remote foo] +refs/heads/*:refs/remotes/origin/heads/* 1. In your opininon, is refs/foo/bar/baz/master a remote-tracking branch? 2. Should refs/foo/bar/baz/master be listed by git branch -r? 3. Should the origin/master shorthand notation expand to refs/remotes/origin/heads/master from remote foo, or refs/foo/bar/baz/master from remote origin? ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Johan Herland jo...@herland.net writes: Ok, so whereas I consider the refspec to be king, and that the expansion from convenient shorthands to full remote-tracking refnames should be derived from the chosen refspec, you would (if I understand you correctly) rather have a constant (i.e. independent of remotes and refspecs) set of rules for expanding shorthands to full refnames, and if the user chooses refspecs that don't mesh well with those rules, then that is the user's problem, and not Git's. You need to dig your rhetoric from the other end of the tunnel. I would consider the local namespace for the refs to be the king, and we would design how they are resolved to be useful for user's local usage pattern. How the remote refs are copied by fetch following refspecs is one of the many components (e.g. the dwimming machinery checkout foo uses to guess that the user may want to fork from and integrate later with one of the refs under refs/remotes is one of them and it is not fetch) to complement the refname resolution rule to support the local usage of refs. In light of this, I'm interested in your thoughts about the following related problem that I've just started looking at: git branch -r shows the remote-tracking branches in this repo. Currently, Should we add a heuristic for detecting when to use refs/remotes/* vs. refs/remotes/*/heads/* as a filter? Didn't I already said that I do not think repurposing refs/remotes/ for these unified copies is the best approach? A change that I think is a good thing to add on top of your [45]/7 refactoring is to allow the user to add custom expansion/contraction rules. Then the user can group refs regardless of remotes and give meaningful shortening. As I said in a very early review, viewing fetch refspec to be king and refspecs are the only way the user may want to group things locally is myopic. The every-day usage of the local names ought to be the king, and everything else should serve to make it easier to use. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
On Sun, May 5, 2013 at 6:28 AM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: The $remote/$branch syntax can be interpreted in two subtly different ways: 1. A shorthand name for the remote-tracking branch corresponding to a specific $branch from a specific $remote. 2. A refname fragment, which - when appended to refs/remotes/ - yields the remote-tracking branch corresponding to a specific $branch from a specific $remote. I think both of the above are somewhat distorted views and they go against all the documentation we have so far. The real definition is: 3. $string (which may happen to have one or more slashes) is used by prepending a few common prefixes to see if the result forms a full refname, and refs/remotes/ is one of the prefixes. origin/master ends up referring refs/remotes/origin/master because of this. True, but from the POV of remote-tracking branches (which is what this series is concerned about, more on that below), #2 and #3 are equivalent. However, when configuring non-default refspecs (such as the +refs/heads/*:refs/remotes/origin/heads/*), it becomes obvious that the current code follows the latter interpretation: The $remote/$branch shorthand will no longer work, and you are forced to use $remote/heads/$branch instead. While I do _not_ think it is _wrong_ to use remotes/origin/heads/* as a namespace for branches you copy from the 'origin' remote, my gut feeling is that it is myopic to redefine that origin/master resolves to refs/remotes/origin/heads/master [*1*]. I guess my point is to raise the origin/master notation to a higher level of abstraction. Instead of it being purely a string that is appended to some common prefixes to yielf a (hopefully unambiguous) match, I want Git to support the idea that it refers to the master shorthand from the origin remote. In other words, just as you can write $something to refer to a ref in the local repo, you can also write $remote/$something to refer to a remote-tracking ref from another repo. Step back a bit. There must be a reason why somebody wants remotes/origin/heads/* instead of the traditional remotes/origin/* to keep the copies of branches taken from the origin. It is because she wants to use the parts of remotes/origin/ that are outside remote/origin/heads/ to store other things taken from that remote, no? They may be changes, pull-requests, notes, etc. Indeed. If origin/master were to map to refs/remotes/origin/heads/master and origin/jh/rtrack were to map to refs/remotes/origin/heads/jh/rtrack, [*2*] what short-hands hierarchies in refs/remotes/origin/ other than heads/ would have? The same. Today, you can use eggs to refer to either refs/heads/eggs or refs/tags/eggs, depending on which exists in your repo. (Having both exist is also possible, but then you must express more explicitly which of them you mean). In the same way, I want origin/eggs to refer to either refs/remotes/origin/heads/eggs or refs/remotes/origin/tags/eggs, depending on which is available (with the same behavior when both exist). This series only gets us halfway there, the other half consists of making Git work properly with remote tags (i.e. teaching Git to handle refs/remotes/$remote/tags/* as an extension of refs/tags/*). Part of that would surely be to add another rule that maps $remote/$tag through $remote's fetch refspec for tags to yield the corresponding remote-tracking tag (e.g. refs/remotes/$remote/tags/$tag if you're using namespaced remote refs). This rule would should cause problems for current users since it would map to _nothing_ if you're using the default refspec, alternatively refs/tags/$tag if you have explicitly set up mirroring of tags from the remote (refs/tags/*:refs/tags/*). If you do not special case heads/, $ git merge origin/pull-requests/4 is very straightforward to understand and explain when you use the definition #3 above. But if you do, then the above may refer to origin/heads/pull-requests/4, or perhaps there is no pull-requests/4 branch in the origin and the resolution may have to error out. Let's say that in the origin repo there may be either refs/pull-requests/4 or refs/heads/pull-requests/4, and they are fetched into our repo, and placed at either refs/remotes/origin/pull-requests/4 or refs/remotes/origin/heads/pull-requests/4, respectively. (If both are present, and fetched, we will get both in our local repo). When doing your $ git merge origin/pull-requests/4 we would either expand to refs/remotes/origin/pull-requests/4 (with the existing refs/remotes/%.*s rule) if that exists, or alternatively expand to refs/remotes/origin/heads/pull-requests/4 (with the new refspec-mapping rule from this series) if that exists. (If both exist, you would have to be more explicit to resolve the ambiguity - the same ambiguity that would have to be resolved if you did git merge pull-requests/4
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Johan Herland jo...@herland.net writes: I want to extend the same reasoning to remote-tracking refs, i.e. $remote/$name could be auto-completed into any of refs/remotes/$remote/$name refs/remotes/$remote/tags/$name refs/remotes/$remote/heads/$name without causing ambiguity in the common case. When there is ambiguity, we would resolve that in the same manner as for local refs. The current series only concerns itself with the branches, but the larger intention is to make it work for tags and other refs as well. Good ;-). So another issue that remains is the following, I think. When interpreting $nick/$name, assuming that we can tell where $nick for a remote ends and $name for the ref we take from the remote begins [*1*], how would we determine which refs/remotes/$remote/ is used for $nick? My gut feeling is that we should ignore any remote.$nick.fetch wildcard mapping, e.g. [remote foo] fetch = +refs/heads/*:refs/remotes/bar/heads/* fetch = +refs/tags/*:refs/remotes/baz/tags/* so that we look always in refs/remotes/$nick/ somewhere, for at least two reasons: * For sane people, bar and baz in the above example are both foo, so ignoring remote.foo.fetch mapping is a no-op for them. * For people who deliberately wanted to move foo's refs to different hierarchies depending on the hierarchies at the origin (i.e. branches to bar, tags to baz), they wanted to do so for a reason to group related things in bar (and baz) [*2*]. For them, mapping with remote.$nick.fetch means not allowing them to use the real name of the group (i.e. bar) they chose to name their refs. If the final end result you are shooting for is to introduce an extra level between the remote name and the branch names, i.e. heads/, any solution needs to at least have a plan (not necessarily a detailed design or implementation) for the other hierarchies. The possibility to have these other hierarchies per remote is the true progress that the heads/ at that level can give us; there is not much point to have heads/ after refs/remotes/origin/, if heads/ is the only thing that can come there. I fully agree. This series was meant as the first step in that direction (sorry for not describing my intentions more clearly). And I do not think we mind terribly if we extend the ref_rev_parse_rules[] used in dwim_ref() to also look at these refs/remotes/$nick/$name refs/remotes/$nick/tags/$name refs/remotes/$nick/heads/$name (the first of the above is existing refs/remotes/%.*s). I think it is going too far if you extend it further to refs/remotes/$nick/*/$name where the code does not control what an acceptable match for '*' is (i.e. origin/foo matching origin/changes/foo might be OK, but matching it with origin/randomstring/foo is not, unless the canned ref_rev_parse_rules[] knows about the randomstring, or there is a configuration mechanism for the user to tell us she cares about the randomstring hierarchy in her project). [Footnotes] *1* I offhand do not remember if we even allow multi-level remote nicks, but I do know we support multi-level branch names, so it may turn out that the only valid split of origin/jh/rbranch is topic 'jh/rbranch' from remote 'origin' and not topic 'rbranch' from remote 'origin/jh'. *2* Perhaps bar in the above is spelled topics, and the hierarchy may be used to collect non-integration single topic branches from more than one remote. An example that is more in line with such a usage might be: [remote jh] fetch = +refs/heads/*:refs/remotes/topics/heads/jh/* [remote jk] fetch = +refs/heads/*:refs/remotes/topics/heads/jk/* [remote fc] fetch = +refs/heads/*:refs/remotes/topics/heads/fc/* and I would expect git merge topics/jh/rbranch to merge the refs/remotes/topics/heads/jh/rbranch topic branch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
On Sun, May 5, 2013 at 9:02 PM, Junio C Hamano gits...@pobox.com wrote: So another issue that remains is the following, I think. When interpreting $nick/$name, assuming that we can tell where $nick for a remote ends and $name for the ref we take from the remote begins [*1*], how would we determine which refs/remotes/$remote/ is used for $nick? My code currently iterates for_each_remote() until we find a remote whose name == $nick. After all, the remote name is what the user interacts with when doing things like git fetch $remote and git push $remote Hence, I believe that the remote name is the most natural name to use for the $nick/$name shorthand. My gut feeling is that we should ignore any remote.$nick.fetch wildcard mapping, e.g. [remote foo] fetch = +refs/heads/*:refs/remotes/bar/heads/* fetch = +refs/tags/*:refs/remotes/baz/tags/* so that we look always in refs/remotes/$nick/ somewhere, for at least two reasons: * For sane people, bar and baz in the above example are both foo, so ignoring remote.foo.fetch mapping is a no-op for them. Agreed. * For people who deliberately wanted to move foo's refs to different hierarchies depending on the hierarchies at the origin (i.e. branches to bar, tags to baz), they wanted to do so for a reason to group related things in bar (and baz) [*2*]. For them, mapping with remote.$nick.fetch means not allowing them to use the real name of the group (i.e. bar) they chose to name their refs. Actually, this series currently accepts _both_. Observe (using your config from above): Shorthand - Expansion Matching rule foo/$branch - refs/remotes/bar/heads/$branchfoo's refspec foo/$tag - refs/remotes/baz/tags/$branch foo's refspec bar/heads/$branch - refs/remotes/bar/heads/$branchrefs/remotes/%.*s baz/tags/$tag - refs/remotes/baz/tags/$tagrefs/remotes/%.*s (If you want to lose the heads/ from the bar/heads/$branch shorthand (or lose tags/ from baz/tags/$tag), use this config instead: [remote foo] fetch = +refs/heads/*:refs/remotes/bar/* fetch = +refs/tags/*:refs/remotes/baz/tags/* ) Now, IINM you seem to mean that we shouldn't look at refspecs (or the config file) at all, but should instead require that $nick matches a subdirectory of refs/remotes, and then allow for some flexibility as to what comes between refs/remotes/$nick and $name (for example, one of /, /heads/, and /tags/). This would not allow the user to use the relevant $remote_name for $nick, which I argue might be the more natural name for the user to use, since it's the same name that is used for otherwise interacting with the remote. If the final end result you are shooting for is to introduce an extra level between the remote name and the branch names, i.e. heads/, any solution needs to at least have a plan (not necessarily a detailed design or implementation) for the other hierarchies. The possibility to have these other hierarchies per remote is the true progress that the heads/ at that level can give us; there is not much point to have heads/ after refs/remotes/origin/, if heads/ is the only thing that can come there. I fully agree. This series was meant as the first step in that direction (sorry for not describing my intentions more clearly). And I do not think we mind terribly if we extend the ref_rev_parse_rules[] used in dwim_ref() to also look at these refs/remotes/$nick/$name refs/remotes/$nick/tags/$name refs/remotes/$nick/heads/$name (the first of the above is existing refs/remotes/%.*s). This is not what I have in mind with this series (although the behavior will be identical for the refspecs suggested in the remote ref namespace discussion). Rather I would have the following three rules: refs/remotes/%.*s (which is - as you say - identical to your first rule) RHS from remote $nick's refspec matching LHS = refs/tags/$name RHS from remote $nick's refspec matching LHS = refs/heads/$name and indeed, my series implements the last of these (in addition to retaining the first). The middle one (for tags) would be added by a future patch series. The whole point of mapping through the refspecs, is that we DON'T hardcode any preference as to where remote-tracking branches (or tags, or whatever) should be located. It's _purely_ up to how the user has configured her refspecs, and any expansion for remote-tracking refs should obey those refspecs. I think it is going too far if you extend it further to refs/remotes/$nick/*/$name where the code does not control what an acceptable match for '*' is (i.e. origin/foo matching origin/changes/foo might be OK, but matching it with origin/randomstring/foo is not, unless the canned ref_rev_parse_rules[] knows about the
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Johan Herland jo...@herland.net writes: This would not allow the user to use the relevant $remote_name for $nick, which I argue might be the more natural name for the user to use, since it's the same name that is used for otherwise interacting with the remote. That is where we differ. The thing is, when you name a local ref (be it refs/heads/master or refs/remotes/origin/master) with a short-hand, you are still dealing with a refname, not interacting with the remote at all. Taking notice of remote.$nick.fetch mappings only to complicate the refname resolution logic is absolutely unacceptable, at least to somebody who comes from the we are interacting with refs, not with remotes school, like me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió: Johan Herland jo...@herland.net writes: This would not allow the user to use the relevant $remote_name for $nick, which I argue might be the more natural name for the user to use, since it's the same name that is used for otherwise interacting with the remote. That is where we differ. The thing is, when you name a local ref (be it refs/heads/master or refs/remotes/origin/master) with a short-hand, you are still dealing with a refname, not interacting with the remote at all. Taking notice of remote.$nick.fetch mappings only to complicate the refname resolution logic is absolutely unacceptable, at least to somebody who comes from the we are interacting with refs, not with remotes school, like me. Maybe we could mark it explicity with a double slash: $remote//$branch, or similar. And it even allows a slash in the remote nick: bar/baz//foo. See you, Santi P.D: Resend because the list rejected it, sorry for the duplicate. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
2013/5/6 Santi Béjar sa...@agolina.net: El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió: Johan Herland jo...@herland.net writes: This would not allow the user to use the relevant $remote_name for $nick, which I argue might be the more natural name for the user to use, since it's the same name that is used for otherwise interacting with the remote. That is where we differ. The thing is, when you name a local ref (be it refs/heads/master or refs/remotes/origin/master) with a short-hand, you are still dealing with a refname, not interacting with the remote at all. Taking notice of remote.$nick.fetch mappings only to complicate the refname resolution logic is absolutely unacceptable, at least to somebody who comes from the we are interacting with refs, not with remotes school, like me. Maybe we could mark it explicity with a double slash: $remote//$branch, or similar. And it even allows a slash in the remote nick: bar/baz//foo. The next question could be: why not make it work with $url too? As in: $ git merge git://git.kernel.org/pub/scm/git/git.git//master But I don't know if it can be problematic... I remember that there was a discussion about the remote#branch notation used in cogito, and at the end it was rejected. See you, Santi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Make $remote/$branch work with unconventional refspecs
Johan Herland jo...@herland.net writes: The $remote/$branch syntax can be interpreted in two subtly different ways: 1. A shorthand name for the remote-tracking branch corresponding to a specific $branch from a specific $remote. 2. A refname fragment, which - when appended to refs/remotes/ - yields the remote-tracking branch corresponding to a specific $branch from a specific $remote. I think both of the above are somewhat distorted views and they go against all the documentation we have so far. The real definition is: 3. $string (which may happen to have one or more slashes) is used by prepending a few common prefixes to see if the result forms a full refname, and refs/remotes/ is one of the prefixes. origin/master ends up referring refs/remotes/origin/master because of this. However, when configuring non-default refspecs (such as the +refs/heads/*:refs/remotes/origin/heads/*), it becomes obvious that the current code follows the latter interpretation: The $remote/$branch shorthand will no longer work, and you are forced to use $remote/heads/$branch instead. While I do _not_ think it is _wrong_ to use remotes/origin/heads/* as a namespace for branches you copy from the 'origin' remote, my gut feeling is that it is myopic to redefine that origin/master resolves to refs/remotes/origin/heads/master [*1*]. Step back a bit. There must be a reason why somebody wants remotes/origin/heads/* instead of the traditional remotes/origin/* to keep the copies of branches taken from the origin. It is because she wants to use the parts of remotes/origin/ that are outside remote/origin/heads/ to store other things taken from that remote, no? They may be changes, pull-requests, notes, etc. If origin/master were to map to refs/remotes/origin/heads/master and origin/jh/rtrack were to map to refs/remotes/origin/heads/jh/rtrack, [*2*] what short-hands hierarchies in refs/remotes/origin/ other than heads/ would have? If you do not special case heads/, $ git merge origin/pull-requests/4 is very straightforward to understand and explain when you use the definition #3 above. But if you do, then the above may refer to origin/heads/pull-requests/4, or perhaps there is no pull-requests/4 branch in the origin and the resolution may have to error out. While I do not reject refs/remotes/origin/heads/* layout as a possibility, I am somewhat skeptical that any solution that starts from the two interpretations above (both of which are flawed, that only consider what happens to the branches) will yield a generally useful result. If the final end result you are shooting for is to introduce an extra level between the remote name and the branch names, i.e. heads/, any solution needs to at least have a plan (not necessarily a detailed design or implementation) for the other hierarchies. The possibility to have these other hierarchies per remote is the true progress that the heads/ at that level can give us; there is not much point to have heads/ after refs/remotes/origin/, if heads/ is the only thing that can come there. [Footnotes] *1* Unlike the usual cautions from me, this does not have anything to do with backward compatibility; it is more about forward thinking. *2* Wait. Does origin/jh/rtrack map to refs/remotes/origin/jh/heads/rtrack which is rtrack branch taken from the origin/jh remote? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
