Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
Junio C Hamano wrote:
If you have to ask why, and cannot answer the question yourself,
then you would not know if such a caller exists. After a code
audit, I know there is no such caller that appends @{u} but if you
were writing a quick-and-dirty caller, I would not be surprised if
you find
Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
Ramkumar Ramachandra artag...@gmail.com writes:
2. Callers calling in with programmatic data, and expecting the function
to return and not die(). In this case, why would anyone ever
construct a string containing @{u} programmatically in the first
place?
If you have to ask why, and
Currently, when no (valid) upstream is configured for a branch, we get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when no (valid) upstream is configured for a branch, we get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some codepaths did this:
if
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
I did not mean You must do so or we should discard the patch. I
just wanted to make sure the log
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name - interpret_branch_name (recursion)
-
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name -
Junio C Hamano wrote:
interpret_branch_name - interpret_branch_name (recursion)
- get_sha1_basic - get_sha1 [context] (end-user data)
- substitute_branch_name - dwim (end-user data)
- strbuf_branchname (callers pass a branch name;
Ramkumar Ramachandra artag...@gmail.com writes:
@{u}. What am I missing?
You draw the arrow the other way around, that is what made the text
confusing.
--
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
14 matches
Mail list logo
