Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> [3] If commit 0000000 were treated specially, then there would be no
> unborn branches but only branches pointing at the empty commit. In that
> case, my expectation would change--the old branch should be left
> pointing at 0000000. But currently git has no concept of an unborn
> branch that is not HEAD.
And it probably is not a good thing to add such. Under that constraints,
HEAD that says refs/heads/foo where foo does not exist yet needs to be
special cased at places where it matters.
For that matter, even if we artificially created refs/heads/foo before any
commit is made and made it point at 0{40}, you would need to add special
cases to other parts of the system (e.g. "commit" needs to notice that the
result should be a root, not a child of 0{40}; "checkout other_branch"
needs to notice that it should refrain from running the equivalent of
"read-tree -m HEAD other_branch" because HEAD does not point at a real
tree; etc.), so it does not change the fact that the unborn branch is case
is special.
Note that I am not saying that we shouldn't add support for special cases
with special case codepaths.
Perhaps we would need to sprinkle more special case magic like this (this
is for the special case that arises from the same cause)?
builtin/branch.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..0997e75 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -640,6 +640,13 @@ static int edit_branch_description(const char *branch_name)
struct strbuf buf = STRBUF_INIT;
struct strbuf name = STRBUF_INIT;
+ strbuf_addf(&name, "refs/heads/%s", branch_name);
+ if (!ref_exists(name.buf)) {
+ strbuf_reset(&name);
+ return error("No such branch '%s'.", branch_name);
+ }
+ strbuf_reset(&name);
+
read_branch_desc(&buf, branch_name);
if (!buf.len || buf.buf[buf.len-1] != '\n')
strbuf_addch(&buf, '\n');
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html