Re: error: src refspec refs/heads/master matches more than one.
Michael Haggerty mhag...@alum.mit.edu writes: I wonder whether we could give a way to specify a reference in an unambiguous, canonical fashion like I expected, for example by using a leading slash: /refs/heads/mybranch. This could be a way for the user to ask for DWIMming to be turned off without having to resort to plumbing commands like update-ref. This wouldn't necessarily solve the problem, but it would at least lead the new user to type git branch /refs/heads/mybranch instead of the ambiguous command above, which Git could either accept or reject in good conscience rather than having to speculate about what the user *really* meant. I think that supporting absolute reference names like this would also be useful for scripts, which otherwise probably often have subtle failure modes if the user has defined reference names that are ambiguous, modulo DWIM, with the reference that the script intended. I do agree that things start to become confusing to the end users when we tell refnames and object names apart and behave differently, e.g. git checkout master vs git checkout master^0 (this example uses a disambiguation syntax that is related to but different from what you brought up). For the name in git branch name [commit] (but not commit), I do not see much value in allowing the users to say refs/heads/ in the first place---all the local branch refs are to be created in refs/heads/ anyway and git branch /refs/tags/bar (if we were to allow your notation to name an absolute ref) will have to be checked and signaled as an error. Even though there is no reason to forbid a ref to be named in such a way at the lowest machinery level (read: at the sha1_name.c layer) [*1*], I would say it would be better to at least warn users when they create such a ref with Porcelain commands like branch, checkout -b, etc., or even outright forbid. In other contexts, however, it _might_ make sense, but I am somewhat skeptical. For example, if you have a branch 'foo' (whose ref being refs/heads/foo) and a branch 'refs/heads/foo' (whose ref being refs/heads/refs/heads/foo) at the same time, you need some way to clarify that you mean the former, and one way to do so may be git branch newfoo /refs/heads/foo and removing the latter would be git branch -D /refs/heads/refs/heads/foo perhaps. But this starts to sound like a workaround to a problem that the user ended up having such a strangely named branch in the first place, not a useful feature. [Footnote] *1* The way refs are used and the specific meanings given to some of the hierarchies under refs/ by the core-git Porcelain is not fundamental to the data model of Git. Git the SCM by convention uses refs/heads/ for branches, and it is perfectly fine for Git the SCM to enforce its own policy like that to its end users and forbid creating and using any ref outside that hierarchy as a local branch (e.g. checking it out), but I'd prefer it if we can keep the lower level a general filesystem to build SCM on top layer as separate from such policy decision as possible. -- 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: error: src refspec refs/heads/master matches more than one.
On 02/18/2014 08:51 PM, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. Not quite, I am afraid. Branch names used for git branch name and git checkout name are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because git checkout can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate. Saying that git checkout refs/heads/name must be equivalent to git checkout name is like arguing that assignment value+0 = x should be valid because value+0 is a valid value. Your logic is impeccable...and yet the user's logic is also quite reasonable. I fell into this trap when I started using Git, and so did most (all?) of my colleagues. I think the problem is partly caused by the visual and semantic similarity between references and Unix pathnames. For pathnames, the file that is called filename.txt in my current context has an unambiguous, canonical name that might be /home/mhagger/filename.txt. My first mental model of Git references was that branch and refs/heads/branch are synonyms, and that the latter is somehow the unambiguous and canonical way to write it. I think this mental model is what led me to make the universal beginner's mistake git branch refs/heads/mybranch It took me a while to figure out how to fix the situation, and the whole experience was very frustrating. I wonder whether we could give a way to specify a reference in an unambiguous, canonical fashion like I expected, for example by using a leading slash: /refs/heads/mybranch. This could be a way for the user to ask for DWIMming to be turned off without having to resort to plumbing commands like update-ref. This wouldn't necessarily solve the problem, but it would at least lead the new user to type git branch /refs/heads/mybranch instead of the ambiguous command above, which Git could either accept or reject in good conscience rather than having to speculate about what the user *really* meant. I think that supporting absolute reference names like this would also be useful for scripts, which otherwise probably often have subtle failure modes if the user has defined reference names that are ambiguous, modulo DWIM, with the reference that the script intended. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: error: src refspec refs/heads/master matches more than one.
Duy Nguyen pclo...@gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. -- 8 -- diff --git a/branch.c b/branch.c index 723a36b..3f0540f 100644 --- a/branch.c +++ b/branch.c @@ -251,6 +251,11 @@ void create_branch(const char *head, forcing = 1; } + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. So... -- 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: error: src refspec refs/heads/master matches more than one.
On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. -- 8 -- diff --git a/branch.c b/branch.c index 723a36b..3f0540f 100644 --- a/branch.c +++ b/branch.c @@ -251,6 +251,11 @@ void create_branch(const char *head, forcing = 1; } + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. I don't think requiring --force for these branch names that overlap with these special namespaces is a big leap from supporting them for inspection commands. Although I'm not sure how sensible it is to examine every remote name to catch something like git branch origin/master. Perhaps Duy's ambiguity check is the best thing for that case. -- 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: error: src refspec refs/heads/master matches more than one.
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: +if (!force dwim_ref(name, strlen(name), sha1, real_ref)) +die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), +name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. Just for the record: after seeing the respective arguments, I consider it the sanest way. It's conceivable to give a configuration option for augmenting the set of reserved prefixes. That would allow to adapt the arbitrariness to match the policies or ref name choices of a particular project while keeping the set of references addressed by the standard git commands in check automagically. -- David Kastrup -- 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: error: src refspec refs/heads/master matches more than one.
John Keeping j...@keeping.me.uk writes: There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. Not quite, I am afraid. Branch names used for git branch name and git checkout name are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because git checkout can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate. Saying that git checkout refs/heads/name must be equivalent to git checkout name is like arguing that assignment value+0 = x should be valid because value+0 is a valid value. For the first parameter to git branch, there is no ambiguity---it must be the name of a branch and cannot be an arbitrary commit object name, so special casing git branch refs/heads/master to mean git branch master may not be too bad. But then we need to either start rejecting git branch refs/tags/v1.0 or keep allowing it to create a ref refs/heads/refs/tags/v1.0 to denote the branch of that exact name given---neither of which is more consistent, so... -- 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: error: src refspec refs/heads/master matches more than one.
On Tue, Feb 18, 2014 at 11:51:05AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. Not quite, I am afraid. Branch names used for git branch name and git checkout name are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because git checkout can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate. Saying that git checkout refs/heads/name must be equivalent to git checkout name is like arguing that assignment value+0 = x should be valid because value+0 is a valid value. That isn't my argument. I agree that the create and view operations are distinct. The problem appears to be that not all users expect this and it caused them confusion because they are able to create refs like refs/heads/refs/heads/master. I don't think we should apply the mapping, but I also do not think that using a set of known (but arbitrary) constraints to prevent the creation of potentially confusing branch names is a particularly big leap from applying a similar set of rules in prettify_ref() and dwim_ref(). Especially if there's an escape hatch via '--force' or 'git update-ref' for those who know what they're doing. -- 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: error: src refspec refs/heads/master matches more than one.
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. Just for the record: after seeing the respective arguments, I consider it the sanest way. It's conceivable to give a configuration option for augmenting the set of reserved prefixes. That would allow to adapt the arbitrariness to match the policies or ref name choices of a particular project while keeping the set of references addressed by the standard git commands in check automagically. I am inclined to say that we should start by just giving a warning whenever git branch, git checkout -b, etc. tries to create a branch whose name begins with refs/ and other potentially ambiguous ones that match ref_rev_parse_rules[]. I personally do not think people name their branch with a name that begins with refs/ on purpose; I am not sure about other ones, like heads or tags. Personally I think it also is unlikely to want to have these words immediately followed by a slash in the branch name, so it may not even be necessary to give them any way to turn off the warning, which in turn would mean we can promote that warning to an die() that can be overridable with --force, but by going that first warn and see if people are annoyed route, we would hopefully find out soon enough that there may be some people who do want to name their branches in a funny way ;-) -- 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: error: src refspec refs/heads/master matches more than one.
Duy Nguyen pclouds at gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. I would propose to make this even stronger: Forbid to create any branches which start with any of: - refs/ - heads/ - remotes/ - tags/ as long as you do not use the force option. The idea here is that you also will not get ambiguities later when you pull new branches into your repository. so long Ingo -- 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: error: src refspec refs/heads/master matches more than one.
On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Josef Wolf j...@raven.inka.de writes:
Notice the refs/heads _within_ refs/heads!
Now I wonder how I managed to get into this situation and what's the best
way
to recover?
Probably you did something like git branch refs/heads/master. You can
remove it again with git branch -d refs/heads/master.
As a porcelain, git branch should prevent (or at least warn) users
from creating such refs, I think.
warn, possibly, but I do not see a reason to *prevent*.
A. You are not allowed to call your branch with a string that begins with
'refs/heads/'.
B. Why?
A. Because it will confuse you.
B. I know what I am doing.
A. ???
Prevent is a strong word. I meant we only do it if they force
it. Something like this..
-- 8 --
diff --git a/branch.c b/branch.c
index 723a36b..3f0540f 100644
--- a/branch.c
+++ b/branch.c
@@ -251,6 +251,11 @@ void create_branch(const char *head,
forcing = 1;
}
+ if (!force dwim_ref(name, strlen(name), sha1, real_ref))
+ die(_(creating ref refs/heads/%s makes %s ambiguous.\n
+ Use -f to create it anyway.),
+ name, name);
+
real_ref = NULL;
if (get_sha1(start_name, sha1)) {
if (explicit_tracking) {
-- 8 --
--
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: error: src refspec refs/heads/master matches more than one.
On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote: Josef Wolf j...@raven.inka.de writes: Notice the refs/heads _within_ refs/heads! Now I wonder how I managed to get into this situation and what's the best way to recover? Probably you did something like git branch refs/heads/master. You can remove it again with git branch -d refs/heads/master. As a porcelain, git branch should prevent (or at least warn) users from creating such refs, I think. -- Duy -- 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: error: src refspec refs/heads/master matches more than one.
On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote: On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote: Josef Wolf j...@raven.inka.de writes: Notice the refs/heads _within_ refs/heads! Probably you did something like git branch refs/heads/master. You can remove it again with git branch -d refs/heads/master. As a porcelain, git branch should prevent (or at least warn) users from creating such refs, I think. I don't think I did it the way Andreas thinks. This repository is maintained by a script, I don't create branches manually. The only command in this script that uses heads is git symbolic-ref HEAD refs/heads/$new_branch to create new branches without any ancestry. And I double-checked that this command is _not_ resposible for those ghost branches. BTW: I see such ghost branches reappearing again and again, so it must be something systematic. -- Josef Wolf j...@raven.inka.de -- 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: error: src refspec refs/heads/master matches more than one.
Josef Wolf j...@raven.inka.de writes: On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote: On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote: Josef Wolf j...@raven.inka.de writes: Notice the refs/heads _within_ refs/heads! Probably you did something like git branch refs/heads/master. You can remove it again with git branch -d refs/heads/master. As a porcelain, git branch should prevent (or at least warn) users from creating such refs, I think. I don't think I did it the way Andreas thinks. This repository is maintained by a script, I don't create branches manually. The only command in this script that uses heads is git symbolic-ref HEAD refs/heads/$new_branch to create new branches without any ancestry. And I double-checked that this command is _not_ resposible for those ghost branches. BTW: I see such ghost branches reappearing again and again, so it must be something systematic. You probably should check how $new_branch comes about. Also, once a directory refs/heads/refs/heads exists, refs/heads/$new_branch may possibly be resolved as a branch with the name refs/heads/$new_branch. -- David Kastrup -- 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: error: src refspec refs/heads/master matches more than one.
Duy Nguyen pclo...@gmail.com writes: On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote: Josef Wolf j...@raven.inka.de writes: Notice the refs/heads _within_ refs/heads! Now I wonder how I managed to get into this situation and what's the best way to recover? Probably you did something like git branch refs/heads/master. You can remove it again with git branch -d refs/heads/master. As a porcelain, git branch should prevent (or at least warn) users from creating such refs, I think. warn, possibly, but I do not see a reason to *prevent*. A. You are not allowed to call your branch with a string that begins with 'refs/heads/'. B. Why? A. Because it will confuse you. B. I know what I am doing. A. ??? -- 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: error: src refspec refs/heads/master matches more than one.
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote: Josef Wolf j...@raven.inka.de writes: Notice the refs/heads _within_ refs/heads! Now I wonder how I managed to get into this situation and what's the best way to recover? Probably you did something like git branch refs/heads/master. You can remove it again with git branch -d refs/heads/master. As a porcelain, git branch should prevent (or at least warn) users from creating such refs, I think. warn, possibly, but I do not see a reason to *prevent*. A. You are not allowed to call your branch with a string that begins with 'refs/heads/'. B. Why? A. Because it will confuse you. B. I know what I am doing. A. ??? A. But maybe Git will no longer know what you are doing. Its standard way of resolving references will mean that once a branch refs/heads/wibble exists, referring to a branch wibble will become extra hard. For example, stuff like push origin HEAD:refs/heads/wibble will maybe create or update a new branch wibble, or maybe it will just push to the existing branch refs/heads/wibble. -- David Kastrup -- 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: error: src refspec refs/heads/master matches more than one.
On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:
Josef Wolf j...@raven.inka.de writes:
The only command in this script that uses heads is
git symbolic-ref HEAD refs/heads/$new_branch
You probably should check how $new_branch comes about.
This is the line of code where $new_branch is comes to live:
my (undef, $new_branch, @new_path) = split (/, $new_item);
So it is impossible that it might contain any slashes.
In any other situation, this script cares only about branches which start with
the string scan-file-:
sub local_branches { grep {m+^scan-file-+} all_branches; }
sub remote_branches { grep {m+^remotes/origin/scan-file-+} all_branches; }
This is hard-coded, so I can't see any way for the user to inject refs/heads
Also, once a
directory refs/heads/refs/heads exists, refs/heads/$new_branch may
possibly be resolved as a branch with the name refs/heads/$new_branch.
Can you elobarte on this? I don't get what you are trying to say.
As I already said, this happens on opensuse with git-1.8.1.4.
I have not yet seen this problem on ubuntu with git-1.7.9.5.
--
Josef Wolf
j...@raven.inka.de
--
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: error: src refspec refs/heads/master matches more than one.
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: ... A. Because it will confuse you. B. I know what I am doing. A. ??? A. But maybe Git will no longer know what you are doing. Its standard way of resolving references will mean that once a branch refs/heads/wibble exists, referring to a branch wibble will become extra hard. For example, stuff like push origin HEAD:refs/heads/wibble will maybe create or update a new branch wibble, or maybe it will just push to the existing branch refs/heads/wibble. I suspect that is a bad example (do refs on _our_ side influence how RHS of the colon that names refs on the other side is interpreted), but I think I know what you are trying to say. But Git never knows what you are doing---it just does what you tell it to, so it comes back to It will confuse you to the point that you would not be able to guess what Git will do matches your expectation. Whenever I tell them that, a counterpoint B. makes is still I know what I am doing., which is stubborn, rather obvious, and unfortunate. How much of the namespace are we willing to carve out if we were to go this route anyway? Things we use, i.e. refs/heads and refs/tags, would be no-brainers, but do we also forbid refs/review, which we ourselves do not use but some people may have in their repositories? Anything that begins with refs/? Anything that begins with refs/ and has more than two slashes in it? -- 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: error: src refspec refs/heads/master matches more than one.
On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote: A. You are not allowed to call your branch with a string that begins with 'refs/heads/'. B. Why? A. Because it will confuse you. B. I know what I am doing. A. ??? Your reply in http://git.661346.n2.nabble.com/1-8-0-git-checkout-refs-heads-foo-checks-out-branch-foo-td536.html suggests that one should explicitly use the refs/heads prefix to to work around ambiguities in some situations. Are there any best-practices sugestions out there about when to use the refs/heads prefix and when not? It looks like git delibaretly cuts off this prefix in some situations. I don't think my problem stems from something like git branch refs/heads/master Anyway, some clarifications about the usage of this prefix would be great! -- Josef Wolf j...@raven.inka.de -- 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
